linux-toradex.git/kernel, branch v3.2.9-rt13

Merge commit 'v3.2.9' into rt-3.2.9-rt13

2012-03-01T15:15:01+00:00

epoll: introduce POLLFREE to flush ->signalfd_wqh before kfree()

2012-03-01T00:31:23+00:00

commit d80e731ecab420ddcb79ee9d0ac427acbc187b4b upstream.

This patch is intentionally incomplete to simplify the review.
It ignores ep_unregister_pollwait() which plays with the same wqh.
See the next change.

epoll assumes that the EPOLL_CTL_ADD'ed file controls everything
f_op->poll() needs. In particular it assumes that the wait queue
can't go away until eventpoll_release(). This is not true in case
of signalfd, the task which does EPOLL_CTL_ADD uses its ->sighand
which is not connected to the file.

This patch adds the special event, POLLFREE, currently only for
epoll. It expects that init_poll_funcptr()'ed hook should do the
necessary cleanup. Perhaps it should be defined as EPOLLFREE in
eventpoll.

__cleanup_sighand() is changed to do wake_up_poll(POLLFREE) if
->signalfd_wqh is not empty, we add the new signalfd_cleanup()
helper.

ep_poll_callback(POLLFREE) simply does list_del_init(task_list).
This make this poll entry inconsistent, but we don't care. If you
share epoll fd which contains our sigfd with another process you
should blame yourself. signalfd is "really special". I simply do
not know how we can define the "right" semantics if it used with
epoll.

The main problem is, epoll calls signalfd_poll() once to establish
the connection with the wait queue, after that signalfd_poll(NULL)
returns the different/inconsistent results depending on who does
EPOLL_CTL_MOD/signalfd_read/etc. IOW: apart from sigmask, signalfd
has nothing to do with the file, it works with the current thread.

In short: this patch is the hack which tries to fix the symptoms.
It also assumes that nobody can take tasklist_lock under epoll
locks, this seems to be true.

Note:

	- we do not have wake_up_all_poll() but wake_up_poll()
	  is fine, poll/epoll doesn't use WQ_FLAG_EXCLUSIVE.

	- signalfd_cleanup() uses POLLHUP along with POLLFREE,
	  we need a couple of simple changes in eventpoll.c to
	  make sure it can't be "lost".

Reported-by: Maxime Bizon 
Signed-off-by: Oleg Nesterov 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

genirq: Handle pending irqs in irq_startup()

2012-03-01T00:31:17+00:00

commit b4bc724e82e80478cba5fe9825b62e71ddf78757 upstream.

An interrupt might be pending when irq_startup() is called, but the
startup code does not invoke the resend logic. In some cases this
prevents the device from issuing another interrupt which renders the
device non functional.

Call the resend function in irq_startup() to keep things going.

Reported-and-tested-by: Russell King 
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

genirq: Unmask oneshot irqs when thread was not woken

2012-03-01T00:31:16+00:00

commit ac5637611150281f398bb7a47e3fcb69a09e7803 upstream.

When the primary handler of an interrupt which is marked IRQ_ONESHOT
returns IRQ_HANDLED or IRQ_NONE, then the interrupt thread is not
woken and the unmask logic of the interrupt line is never
invoked. This keeps the interrupt masked forever.

This was not noticed as most IRQ_ONESHOT users wake the thread
unconditionally (usually because they cannot access the underlying
device from hard interrupt context). Though this behaviour was nowhere
documented and not necessarily intentional. Some drivers can avoid the
thread wakeup in certain cases and run into the situation where the
interrupt line s kept masked.

Handle it gracefully.

Reported-and-tested-by: Lothar Wassmann 
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

Merge commit 'v3.2.7' into rt-3.2.7-rt13

2012-02-24T03:33:05+00:00

relay: prevent integer overflow in relay_open()

2012-02-20T20:46:16+00:00

commit f6302f1bcd75a042df69866d98b8d775a668f8f1 upstream.

"subbuf_size" and "n_subbufs" come from the user and they need to be
capped to prevent an integer overflow.

Signed-off-by: Dan Carpenter 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman

kconfig-preempt-rt-full.patch

2012-02-15T16:33:03+00:00

Signed-off-by: Thomas Gleixner

wait-simple: Simple waitqueue implementation

2012-02-15T16:33:03+00:00

wait_queue is a swiss army knife and in most of the cases the
complexity is not needed. For RT waitqueues are a constant source of
trouble as we can't convert the head lock to a raw spinlock due to
fancy and long lasting callbacks.

Provide a slim version, which allows RT to replace wait queues. This
should go mainline as well, as it lowers memory consumption and
runtime overhead.

Signed-off-by: Thomas Gleixner

sysrq: Allow immediate Magic SysRq output for PREEMPT_RT_FULL

2012-02-15T16:33:02+00:00

Add a CONFIG option to allow the output from Magic SysRq to be output
immediately, even if this causes large latencies.

If PREEMPT_RT_FULL, printk() will not try to acquire the console lock
when interrupts or preemption are disabled.  If the console lock is
not acquired the printk() output will be buffered, but will not be
output immediately. Some drivers call into the Magic SysRq code
with interrupts or preemption disabled, so the output of Magic SysRq
will be buffered instead of printing immediately if this option is
not selected.

Even with this option selected, Magic SysRq output will be delayed
if the attempt to acquire the console lock fails.

Signed-off-by: Frank Rowand 
Link: http://lkml.kernel.org/r/4E7CEF60.5020508@am.sony.com
Signed-off-by: Thomas Gleixner

add /sys/kernel/realtime entry

2012-02-15T16:33:02+00:00

Add a /sys/kernel entry to indicate that the kernel is a
realtime kernel.

Clark says that he needs this for udev rules, udev needs to evaluate
if its a PREEMPT_RT kernel a few thousand times and parsing uname
output is too slow or so.

Are there better solutions? Should it exist and return 0 on !-rt?

Signed-off-by: Clark Williams 
Signed-off-by: Peter Zijlstra