13 Mar, 2012
29 commits
-
commit 1c641e84719429bbfe62a95ed3545ee7fe24408f upstream.
Dave Jones reports a few Fedora users hitting the BUG_ON(mm->nr_ptes...)
in exit_mmap() recently.Quoting Hugh's discovery and explanation of the SMP race condition:
"mm->nr_ptes had unusual locking: down_read mmap_sem plus
page_table_lock when incrementing, down_write mmap_sem (or mm_users
0) when decrementing; whereas THP is careful to increment and
decrement it under page_table_lock.Now most of those paths in THP also hold mmap_sem for read or write
(with appropriate checks on mm_users), but two do not: when
split_huge_page() is called by hwpoison_user_mappings(), and when
called by add_to_swap().It's conceivable that the latter case is responsible for the
exit_mmap() BUG_ON mm->nr_ptes that has been reported on Fedora."The simplest way to fix it without having to alter the locking is to make
split_huge_page() a noop in nr_ptes terms, so by counting the preallocated
pagetables that exists for every mapped hugepage. It was an arbitrary
choice not to count them and either way is not wrong or right, because
they are not used but they're still allocated.Reported-by: Dave Jones
Reported-by: Hugh Dickins
Signed-off-by: Andrea Arcangeli
Acked-by: Hugh Dickins
Cc: David Rientjes
Cc: Josh Boyer
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 9bbb8168ed3d8b946f9c1901a63a675012de88f2 upstream.
Duplicate the data for iniAddac early on, to avoid having to do redundant
memcpy calls later. While we're at it, make AR5416 < v2.2 use the same
codepath. Fixes a reported crash on x86.Signed-off-by: Felix Fietkau
Reported-by: Magnus Määttä
Signed-off-by: John W. Linville
Signed-off-by: Greg Kroah-Hartman -
commit 8617b093d0031837a7be9b32bc674580cfb5f6b5 upstream.
rate control algorithms concludes the rate as invalid
with rate[i].idx < -1 , while they do also check for rate[i].count is
non-zero. it would be safer to zero initialize the 'count' field.
recently we had a ath9k rate control crash where the ath9k rate control
in ath_tx_status assumed to check only for rate[i].count being non-zero
in one instance and ended up in using invalid rate index for
'connection monitoring NULL func frames' which eventually lead to the crash.
thanks to Pavel Roskin for fixing it and finding the root cause.
https://bugzilla.redhat.com/show_bug.cgi?id=768639Cc: Pavel Roskin
Signed-off-by: Mohammed Shafi Shajakhan
Signed-off-by: John W. Linville
Signed-off-by: Greg Kroah-Hartman -
commit 5bccda0ebc7c0331b81ac47d39e4b920b198b2cd upstream.
The cifs code will attempt to open files on lookup under certain
circumstances. What happens though if we find that the file we opened
was actually a FIFO or other special file?Currently, the open filehandle just ends up being leaked leading to
a dentry refcount mismatch and oops on umount. Fix this by having the
code close the filehandle on the server if it turns out not to be a
regular file. While we're at it, change this spaghetti if statement
into a switch too.Reported-by: CAI Qian
Tested-by: CAI Qian
Reviewed-by: Shirish Pargaonkar
Signed-off-by: Jeff Layton
Signed-off-by: Steve French
Signed-off-by: Greg Kroah-Hartman -
commit b94cfaf6685d691dc3fab023cf32f65e9b7be09c upstream.
Don't clear vm_mm in a deleted VMA as it's unnecessary and might
conceivably break the filesystem or driver VMA close routine.Reported-by: Al Viro
Signed-off-by: David Howells
Acked-by: Al Viro
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 371528caec553785c37f73fa3926ea0de84f986f upstream.
There is an issue when memcg unregisters events that were attached to
the same eventfd:- On the first call mem_cgroup_usage_unregister_event() removes all
events attached to a given eventfd, and if there were no events left,
thresholds->primary would become NULL;- Since there were several events registered, cgroups core will call
mem_cgroup_usage_unregister_event() again, but now kernel will oops,
as the function doesn't expect that threshold->primary may be NULL.That's a good question whether mem_cgroup_usage_unregister_event()
should actually remove all events in one go, but nowadays it can't
do any better as cftype->unregister_event callback doesn't pass
any private event-associated cookie. So, let's fix the issue by
simply checking for threshold->primary.FWIW, w/o the patch the following oops may be observed:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000004
IP: [] mem_cgroup_usage_unregister_event+0x9c/0x1f0
Pid: 574, comm: kworker/0:2 Not tainted 3.3.0-rc4+ #9 Bochs Bochs
RIP: 0010:[] [] mem_cgroup_usage_unregister_event+0x9c/0x1f0
RSP: 0018:ffff88001d0b9d60 EFLAGS: 00010246
Process kworker/0:2 (pid: 574, threadinfo ffff88001d0b8000, task ffff88001de91cc0)
Call Trace:
[] cgroup_event_remove+0x2b/0x60
[] process_one_work+0x174/0x450
[] worker_thread+0x123/0x2d0Signed-off-by: Anton Vorontsov
Acked-by: KAMEZAWA Hiroyuki
Cc: Kirill A. Shutemov
Cc: Michal Hocko
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 5b6b0ad6e572b32a641116aaa5f897ffebe31e44 upstream.
On i.MX53 we have to write a special SDHCI_CMD_ABORTCMD to the
SDHCI_TRANSFER_MODE register during a MMC_STOP_TRANSMISSION
command. This works for SD cards. However, with MMC cards
the MMC_SET_BLOCK_COUNT command is used instead, but this
needs the same handling. Fix MMC cards by testing for the
MMC_SET_BLOCK_COUNT command aswell. Tested on a custom i.MX53
board with a Transcend MMC+ card and eMMC.The kernel started used MMC_SET_BLOCK_COUNT in 3.0, so this
is a regression for these boards introduced in 3.0; it should
go to 3.0/3.1/3.2-stable.Signed-off-by: Sascha Hauer
Acked-by: Shawn Guo
Signed-off-by: Chris Ball
Signed-off-by: Greg Kroah-Hartman -
commit 62aca403657fe30e5235c5331e9871e676d9ea0a upstream.
Michael Cree said:
: : I have noticed some user space problems (pulseaudio crashes in pthread
: : code, glibc/nptl test suite failures, java compiler freezes on SMP alpha
: : systems) that arise when using a 2.6.39 or later kernel on Alpha.
: : Bisecting between 2.6.38 and 2.6.39 (using glibc/nptl test suite as
: : criterion for good/bad kernel) eventually leads to:
: :
: : 8d7718aa082aaf30a0b4989e1f04858952f941bc is the first bad commit
: : commit 8d7718aa082aaf30a0b4989e1f04858952f941bc
: : Author: Michel Lespinasse
: : Date: Thu Mar 10 18:50:58 2011 -0800
: :
: : futex: Sanitize futex ops argument types
: :
: : Change futex_atomic_op_inuser and futex_atomic_cmpxchg_inatomic
: : prototypes to use u32 types for the futex as this is the data type the
: : futex core code uses all over the place.
: :
: : Looking at the commit I see there is a change of the uaddr argument in
: : the Alpha architecture specific code for futexes from int to u32, but I
: : don't see why this should cause a problem.Richard Henderson said:
: futex_atomic_cmpxchg_inatomic(u32 *uval, u32 __user *uaddr,
: u32 oldval, u32 newval)
: ...
: : "r"(uaddr), "r"((long)oldval), "r"(newval)
:
:
: There is no 32-bit compare instruction. These are implemented by
: consistently extending the values to a 64-bit type. Since the
: load instruction sign-extends, we want to sign-extend the other
: quantity as well (despite the fact it's logically unsigned).
:
: So:
:
: - : "r"(uaddr), "r"((long)oldval), "r"(newval)
: + : "r"(uaddr), "r"((long)(int)oldval), "r"(newval)
:
: should do the trick.Michael said:
: This fixes the glibc test suite failures and the pulseaudio related
: crashes, but it does not fix the java compiiler lockups that I was (and
: are still) observing. That is some other problem.Reported-by: Michael Cree
Tested-by: Michael Cree
Acked-by: Phil Carmody
Cc: Richard Henderson
Cc: Michel Lespinasse
Cc: Ivan Kokshaysky
Reviewed-by: Matt Turner
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit ee932bf9acb2e2c6a309e808000f24856330e3f9 upstream.
In the current kernel implementation, the Logitech Harmony 900 remote
control is matched to the cdc_ether driver through the generic
USB_CDC_SUBCLASS_MDLM entry. However, this device appears to be of the
pseudo-MDLM (Belcarra) type, rather than the standard one. This patch
blacklists the Harmony 900 from the cdc_ether driver and whitelists it for
the pseudo-MDLM driver in zaurus.Signed-off-by: Scott Talbert
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
commit e39d40c65dfd8390b50c03482ae9e289b8a8f351 upstream.
s3c2410_dma_suspend suspends channels from 0 to dma_channels.
s3c2410_dma_resume resumes channels in reverse order. So
pointer should be decremented instead of being incremented.Signed-off-by: Gusakov Andrey
Reviewed-by: Heiko Stuebner
Signed-off-by: Kukjin Kim
Signed-off-by: Greg Kroah-Hartman -
commit 52abb700e16a9aa4cbc03f3d7f80206cbbc80680 upstream.
Xommit ac5637611(genirq: Unmask oneshot irqs when thread was not woken)
fails to unmask when a !IRQ_ONESHOT threaded handler is handled by
handle_level_irq.This happens because thread_mask is or'ed unconditionally in
irq_wake_thread(), but for !IRQ_ONESHOT interrupts never cleared. So
the check for !desc->thread_active fails and keeps the interrupt
disabled.Keep the thread_mask zero for !IRQ_ONESHOT interrupts.
Document the thread_mask magic while at it.
Reported-and-tested-by: Sven Joachim
Reported-and-tested-by: Stefan Lippers-Hollmann
Signed-off-by: Thomas Gleixner
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 81b5482c32769abb6dfb979560dab2f952ba86fa upstream.
The code is currently always checking the first resource of every
device only (several times.) This has been broken since the ACPI check
was added in February 2010 in commit
91fedede0338eb6203cdd618d8ece873fdb7c22c.Fix the check to run on each resource individually, once.
Signed-off-by: Jean Delvare
Signed-off-by: Samuel Ortiz
Signed-off-by: Greg Kroah-Hartman -
commit 5189fa19a4b2b4c3bec37c3a019d446148827717 upstream.
There is only one error code to return for a bad user-space buffer
pointer passed to a system call in the same address space as the
system call is executed, and that is EFAULT. Furthermore, the
low-level access routines, which catch most of the faults, return
EFAULT already.Signed-off-by: H. Peter Anvin
Reviewed-by: Oleg Nesterov
Acked-by: Roland McGrath
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit c8e252586f8d5de906385d8cf6385fee289a825e upstream.
The regset common infrastructure assumed that regsets would always
have .get and .set methods, but not necessarily .active methods.
Unfortunately people have since written regsets without .set methods.Rather than putting in stub functions everywhere, handle regsets with
null .get or .set methods explicitly.Signed-off-by: H. Peter Anvin
Reviewed-by: Oleg Nesterov
Acked-by: Roland McGrath
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 7bff172a352a2fbe9856bba517d71a2072aab041 upstream.
A bug report with an old Sony laptop showed that we can't rely on BIOS
setting the pins of headphones but the driver should set always by
itself.Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit 3868137ea41866773e75d9ac4b9988dcc361ff1d upstream.
Some codecs don't supply the mute amp-capabilities although the lowest
volume gives the mute. It'd be handy if the parser provides the mute
mixers in such a case.This patch adds an extension amp-cap bit (which is used only in the
driver) to represent the min volume = mute state. Also modified the
amp cache code to support the fake mute feature when this bit is set
but the real mute bit is unset.In addition, conexant cx5051 parser uses this new feature to implement
the missing mute controls.Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=42825
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit 1d057720609ed052a6371fe1d53300e5e6328e94 upstream.
Enable the compat keyctl wrapper on s390x so that 32-bit s390 userspace can
call the keyctl() syscall.There's an s390x assembly wrapper that truncates all the register values to
32-bits and this then calls compat_sys_keyctl() - but the latter only exists if
CONFIG_KEYS_COMPAT is enabled, and the s390 Kconfig doesn't enable it.Without this patch, 32-bit calls to the keyctl() syscall are given an ENOSYS
error:[root@devel4 ~]# keyctl show
Session Keyring
-3: key inaccessible (Function not implemented)Signed-off-by: David Howells
Acked-by: dan@danny.cz
Cc: Carsten Otte
Reviewed-by: Christian Borntraeger
Cc: linux-s390@vger.kernel.org
Signed-off-by: Heiko Carstens
Signed-off-by: Martin Schwidefsky
Signed-off-by: Greg Kroah-Hartman -
commit 3380643b0eaa7ecf99c4f095bdfcb6e5df471616 upstream.
Signed-off-by: Jett.Zhou
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman -
commit 844990daa2e69a4258049ba9c2bae1180657dac3 upstream.
The hardware generates an interrupt for every completed command in the
queue while the code assumed that it will only generate one interrupt
when the queue is empty. So, explicitly check if the queue is really
empty. This patch fixed problems which occurred due to high traffic on
the bus. While we are here, move the completion-initialization after the
parameter error checking.Signed-off-by: Wolfram Sang
Cc: Shawn Guo
Cc: Marek Vasut
Cc: Lothar Waßmann
Signed-off-by: Greg Kroah-Hartman -
commit 97d2a10d5804d585ab0b58efbd710948401b886a upstream.
1. address has to be page aligned.
2. set_memory_x uses page size argument, not size.
Bug causes with following commit:
commit da28179b4e90dda56912ee825c7eaa62fc103797
Author: Mingarelli, Thomas
Date: Mon Nov 7 10:59:00 2011 +0100watchdog: hpwdt: Changes to handle NX secure bit in 32bit path
commit e67d668e147c3b4fec638c9e0ace04319f5ceccd upstream.
This patch makes use of the set_memory_x() kernel API in order
to make necessary BIOS calls to source NMIs.Signed-off-by: Maxim Uvarov
Signed-off-by: Wim Van Sebroeck
Signed-off-by: Greg Kroah-Hartman -
commit f6737055c1c432a9628a9a731f9881ad8e0a9eee upstream.
The GPI_28 IRQ was not registered properly. The registration of
IRQ_LPC32XX_GPI_28 was added and the (wrong) IRQ_LPC32XX_GPI_11 at
LPC32XX_SIC1_IRQ(4) was replaced by IRQ_LPC32XX_GPI_28 (see manual of
LPC32xx / interrupt controller).Signed-off-by: Roland Stigge
Signed-off-by: Greg Kroah-Hartman -
commit 35dd0a75d4a382e7f769dd0277732e7aa5235718 upstream.
This patch fixes the initialization of the interrupt controller of the LPC32xx
by correctly setting up SIC1 and SIC2 instead of (wrongly) using the same value
as for the Main Interrupt Controller (MIC).Signed-off-by: Roland Stigge
Signed-off-by: Greg Kroah-Hartman -
commit 94ed7830cba4dce57b18a2926b5d826bfd184bd6 upstream.
This patch fixes the wakeup disable function by clearing latched events.
Signed-off-by: Roland Stigge
Signed-off-by: Greg Kroah-Hartman -
commit ff424aa4c89d19082e8ae5a3351006bc8a4cd91b upstream.
This patch fixes a wrong loop limit on UART init.
Signed-off-by: Roland Stigge
Signed-off-by: Greg Kroah-Hartman -
commit 2707208ee8a80dbbd5426f5aa1a934f766825bb5 upstream.
This patch fixes a HW bug by flushing RX FIFOs of the UARTs on init. It was
ported from NXP's git.lpclinux.com tree.Signed-off-by: Roland Stigge
Signed-off-by: Greg Kroah-Hartman -
commit aed3f09db39596e539f90b11a5016aea4d8442e1 upstream.
Before loading the lut (gamma), check the active state of intel_crtc,
otherwise at least on gen2 hang ensue.This is reproducible in Xorg via:
xset dpms force off
then
xgamma -rgamma 2.0 # freeze.Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44505
Signed-off-by: Alban Browaeys
Signed-off-by: Chris Wilson
Reviewed-by: Jesse Barnes
Signed-off-by: Jesse Barnes
Signed-off-by: Greg Kroah-Hartman -
commit 048cd4e51d24ebf7f3552226d03c769d6ad91658 upstream.
The new is_compat_task() define for the !COMPAT case in
include/linux/compat.h conflicts with a similar define in
arch/s390/include/asm/compat.h.This is the minimal patch which fixes the build issues.
Signed-off-by: Heiko Carstens
Signed-off-by: Linus Torvalds
Cc: Jonathan Nieder
Signed-off-by: Greg Kroah-Hartman -
commit 3c761ea05a8900a907f32b628611873f6bef24b2 upstream.
The autofs compat handling fix caused a compile failure when
CONFIG_COMPAT isn't defined.Instead of adding random #ifdef'fery in autofs, let's just make the
compat helpers earlier to use: without CONFIG_COMPAT, is_compat_task()
just hardcodes to zero.We could probably do something similar for a number of other cases where
we have #ifdef's in code, but this is the low-hanging fruit.Reported-and-tested-by: Andreas Schwab
Signed-off-by: Linus Torvalds
Cc: Jonathan Nieder
Signed-off-by: Greg Kroah-Hartman -
commit a32744d4abae24572eff7269bc17895c41bd0085 upstream.
When the autofs protocol version 5 packet type was added in commit
5c0a32fc2cd0 ("autofs4: add new packet type for v5 communications"), it
obvously tried quite hard to be word-size agnostic, and uses explicitly
sized fields that are all correctly aligned.However, with the final "char name[NAME_MAX+1]" array at the end, the
actual size of the structure ends up being not very well defined:
because the struct isn't marked 'packed', doing a "sizeof()" on it will
align the size of the struct up to the biggest alignment of the members
it has.And despite all the members being the same, the alignment of them is
different: a "__u64" has 4-byte alignment on x86-32, but native 8-byte
alignment on x86-64. And while 'NAME_MAX+1' ends up being a nice round
number (256), the name[] array starts out a 4-byte aligned.End result: the "packed" size of the structure is 300 bytes: 4-byte, but
not 8-byte aligned.As a result, despite all the fields being in the same place on all
architectures, sizeof() will round up that size to 304 bytes on
architectures that have 8-byte alignment for u64.Note that this is *not* a problem for 32-bit compat mode on POWER, since
there __u64 is 8-byte aligned even in 32-bit mode. But on x86, 32-bit
and 64-bit alignment is different for 64-bit entities, and as a result
the structure that has exactly the same layout has different sizes.So on x86-64, but no other architecture, we will just subtract 4 from
the size of the structure when running in a compat task. That way we
will write the properly sized packet that user mode expects.Not pretty. Sadly, this very subtle, and unnecessary, size difference
has been encoded in user space that wants to read packets of *exactly*
the right size, and will refuse to touch anything else.Reported-and-tested-by: Thomas Meyer
Signed-off-by: Ian Kent
Signed-off-by: Linus Torvalds
Cc: Jonathan Nieder
Signed-off-by: Greg Kroah-Hartman
01 Mar, 2012
11 commits
-
commit 822bfa51ce44f2c63c300fdb76dc99c4d5a5ca9f upstream.
"nframes" comes from the user and "nframes * CD_FRAMESIZE_RAW" can wrap
on 32 bit systems. That would have been ok if we used the same wrapped
value for the copy, but we use a shifted value. We should just use the
checked version of copy_to_user() because it's not going to make a
difference to the speed.Signed-off-by: Dan Carpenter
Signed-off-by: Jens Axboe
Signed-off-by: Greg Kroah-Hartman -
commit 28d82dc1c4edbc352129f97f4ca22624d1fe61de upstream.
The current epoll code can be tickled to run basically indefinitely in
both loop detection path check (on ep_insert()), and in the wakeup paths.
The programs that tickle this behavior set up deeply linked networks of
epoll file descriptors that cause the epoll algorithms to traverse them
indefinitely. A couple of these sample programs have been previously
posted in this thread: https://lkml.org/lkml/2011/2/25/297.To fix the loop detection path check algorithms, I simply keep track of
the epoll nodes that have been already visited. Thus, the loop detection
becomes proportional to the number of epoll file descriptor and links.
This dramatically decreases the run-time of the loop check algorithm. In
one diabolical case I tried it reduced the run-time from 15 mintues (all
in kernel time) to .3 seconds.Fixing the wakeup paths could be done at wakeup time in a similar manner
by keeping track of nodes that have already been visited, but the
complexity is harder, since there can be multiple wakeups on different
cpus...Thus, I've opted to limit the number of possible wakeup paths when
the paths are created.This is accomplished, by noting that the end file descriptor points that
are found during the loop detection pass (from the newly added link), are
actually the sources for wakeup events. I keep a list of these file
descriptors and limit the number and length of these paths that emanate
from these 'source file descriptors'. In the current implemetation I
allow 1000 paths of length 1, 500 of length 2, 100 of length 3, 50 of
length 4 and 10 of length 5. Note that it is sufficient to check the
'source file descriptors' reachable from the newly added link, since no
other 'source file descriptors' will have newly added links. This allows
us to check only the wakeup paths that may have gotten too long, and not
re-check all possible wakeup paths on the system.In terms of the path limit selection, I think its first worth noting that
the most common case for epoll, is probably the model where you have 1
epoll file descriptor that is monitoring n number of 'source file
descriptors'. In this case, each 'source file descriptor' has a 1 path of
length 1. Thus, I believe that the limits I'm proposing are quite
reasonable and in fact may be too generous. Thus, I'm hoping that the
proposed limits will not prevent any workloads that currently work to
fail.In terms of locking, I have extended the use of the 'epmutex' to all
epoll_ctl add and remove operations. Currently its only used in a subset
of the add paths. I need to hold the epmutex, so that we can correctly
traverse a coherent graph, to check the number of paths. I believe that
this additional locking is probably ok, since its in the setup/teardown
paths, and doesn't affect the running paths, but it certainly is going to
add some extra overhead. Also, worth noting is that the epmuex was
recently added to the ep_ctl add operations in the initial path loop
detection code using the argument that it was not on a critical path.Another thing to note here, is the length of epoll chains that is allowed.
Currently, eventpoll.c defines:/* Maximum number of nesting allowed inside epoll sets */
#define EP_MAX_NESTS 4This basically means that I am limited to a graph depth of 5 (EP_MAX_NESTS
+ 1). However, this limit is currently only enforced during the loop
check detection code, and only when the epoll file descriptors are added
in a certain order. Thus, this limit is currently easily bypassed. The
newly added check for wakeup paths, stricly limits the wakeup paths to a
length of 5, regardless of the order in which ep's are linked together.
Thus, a side-effect of the new code is a more consistent enforcement of
the graph depth.Thus far, I've tested this, using the sample programs previously
mentioned, which now either return quickly or return -EINVAL. I've also
testing using the piptest.c epoll tester, which showed no difference in
performance. I've also created a number of different epoll networks and
tested that they behave as expectded.I believe this solves the original diabolical test cases, while still
preserving the sane epoll nesting.Signed-off-by: Jason Baron
Cc: Nelson Elhage
Cc: Davide Libenzi
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 971316f0503a5c50633d07b83b6db2f15a3a5b00 upstream.
signalfd_cleanup() ensures that ->signalfd_wqh is not used, but
this is not enough. eppoll_entry->whead still points to the memory
we are going to free, ep_unregister_pollwait()->remove_wait_queue()
is obviously unsafe.Change ep_poll_callback(POLLFREE) to set eppoll_entry->whead = NULL,
change ep_unregister_pollwait() to check pwq->whead != NULL under
rcu_read_lock() before remove_wait_queue(). We add the new helper,
ep_remove_wait_queue(), for this.This works because sighand_cachep is SLAB_DESTROY_BY_RCU and because
->signalfd_wqh is initialized in sighand_ctor(), not in copy_sighand.
ep_unregister_pollwait()->remove_wait_queue() can play with already
freed and potentially reused ->sighand, but this is fine. This memory
must have the valid ->signalfd_wqh until rcu_read_unlock().Reported-by: Maxime Bizon
Signed-off-by: Oleg Nesterov
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
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 -
commit c1c1a3d012fe5e82a9a025fb4b5a4f8ee67a53f6 upstream.
By hwmon sysfs interface convention, setting pwm_enable to zero sets a fan
to full speed. In the f75375s driver, this need be done by enabling
manual fan control, plus duty mode for the F875387 chip, and then setting
the maximum duty cycle. Fix a bug where the two necessary register writes
were swapped, effectively discarding the setting to full-speed.Signed-off-by: Nikolaus Schulz
Cc: Riku Voipio
Signed-off-by: Guenter Roeck
Signed-off-by: Greg Kroah-Hartman -
commit afa159538af61f1a65d48927f4e949fe514fb4fc upstream.
status has to be set to STREAMING before the streaming worker is
queued. hdpvr_transmit_buffers() will exit immediately otherwise.Reported-by: Joerg Desch
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit 6c635224602d760c1208ada337562f40d8ae93a5 upstream.
The current use of /tmp for file lists is insecure. Put them under
$objtree/debian instead.Signed-off-by: Ben Hutchings
Acked-by: maximilian attems
Signed-off-by: Michal Marek
Signed-off-by: Greg Kroah-Hartman -
commit 5d69703263d588dbb03f4e57091afd8942d96e6d upstream.
This patch fixes a regression that was introduced by
commit 0a5f38467765ee15478db90d81e40c269c8dda20
davinci_emac: Add Carrier Link OK check in Davinci RX HandlerSaid commit adds a check whether the carrier link is ok. If the link is
not ok, the skb is freed and no new dma descriptor added to the rx dma
channel. This causes trouble during initialization when the carrier
status has not yet been updated. If a lot of packets are received while
netif_carrier_ok returns false, all dma descriptors are freed and the
rx dma transfer is stopped.The bug occurs when the board is connected to a network with lots of
traffic and the ifconfig down/up is done, e.g., when reconfiguring
the interface with DHCP.The bug can be reproduced by flood pinging the davinci board while doing
ifconfig eth0 down
ifconfig eth0 up
on the board.After that, the rx path stops working and the overrun value reported
by ifconfig is counting up.This patch reverts commit 0a5f38467765ee15478db90d81e40c269c8dda20
and instead issues warnings only if cpdma_chan_submit returns -ENOMEM.Signed-off-by: Christian Riesch
Cc:
Cc: Cyril Chemparathy
Cc: Sascha Hauer
Tested-by: Rajashekhara, Sudhakar
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
commit ba9adbe67e288823ac1deb7f11576ab5653f833e upstream.
Set the RX FIFO flush watermark lower.
According to Federico and JMicron's reply,
setting it to 16QW would be stable on most platforms.
Otherwise, user might experience packet drop issue.Reported-by: Federico Quagliata
Fixed-by: Federico Quagliata
Signed-off-by: Guo-Fu Tseng
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
commit e0aac52e17a3db68fe2ceae281780a70fc69957f upstream.
Commit f11017ec2d1859c661f4e2b12c4a8d250e1f47cf (2.6.37)
moved the fwmark variable in subcontext that is invalidated before
reaching the ip_vs_ct_in_get call. As vaddr is provided as pointer
in the param structure make sure the fwmark variable is in
same context. As the fwmark templates can not be matched,
more and more template connections are created and the
controlled connections can not go to single real server.Signed-off-by: Julian Anastasov
Signed-off-by: Simon Horman
Signed-off-by: Pablo Neira Ayuso
Signed-off-by: Greg Kroah-Hartman
