- 06 Feb, 2009 10 commits
-
-
Li Zefan authored
I happened to forked lots of processes, and hit NULL pointer dereference. It is because in copy_process() after checking max_threads, 0 is returned but not -EAGAIN. The bug is introduced by "CRED: Detach the credentials from task_struct" (commit f1752eec). Signed-off-by:
Li Zefan <lizf@cn.fujitsu.com> Signed-off-by:
David Howells <dhowells@redhat.com> Acked-by:
James Morris <jmorris@namei.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
git://neil.brown.name/mdLinus Torvalds authored
* 'for-linus' of git://neil.brown.name/md: md: Ensure an md array never has too many devices. md: Fix a bug in linear.c causing which_dev() to return the wrong device. md: Allow read error in a single drive raid1 to be passed up.
-
NeilBrown authored
Each different metadata format supported by md supports a different maximum number of devices. We really should be enforcing this maximum in the kernel, but we aren't quite doing that properly. We currently only enforce it at the 'hot_add' point, which is an older interface which is not used by current userspace. We need to also enforce it at 'add_new_disk' time for active arrays and at 'do_md_run' time when starting a new array. So move the test from 'hot_add' into 'bind_rdev_to_array' which is called from both 'hot_add' and 'add_new_disk, and add a new test in 'analyse_sbs' which is called from 'do_md_run'. This bug (or missing feature) has been around "forever" and so the patch is suitable for any -stable that is currently maintained. Cc: stable@kernel.org Signed-off-by:NeilBrown <neilb@suse.de>
-
Andre Noll authored
ab5bd5cb introduced the following bug in linear software raid for large arrays on 32 bit machines: which_dev() computes the device holding a given sector by shifting down the sector number to a 32 bit range, dividing by the array spacing and looking up the resulting index in the hash table of the array. Because the computed index might be slightly too small, a loop at the end of which_dev() increases the index until the given sector actually falls into the range of the device associated with that index. The changes of the above mentioned commit caused this loop to check whether the _index_ rather than the sector number is small enough, effectively bypassing the loop and thus possibly returning the wrong device. As reported by Simon Kirby, this leads to errors such as linear_make_request: Sector 2340486136 out of bounds on dev sdi: 156301312 sectors, offset 2109870464 Fix this bug by introducing a local variable for the index so that the variable containing the passed sector is left unchanged. Cc: stable@kernel.org Signed-off-by:
Andre Noll <maan@systemlinux.org> Signed-off-by:
-
NeilBrown authored
If a raid1 only has a single working device and gets a read error, we choose to simply return that error up to the filesystem (or whatever) rather than failing the whole array. However the codes doesn't quite do that. We attempt a readbalance which allocates the same drive, so we retry the read - indefinitely. Instead: If read_balance in the error case chooses the same drive that just failed, treat it as a failure and don't retry. Signed-off-by: -
Masami Hiramatsu authored
Prevent kprobes from catching spurious faults which will cause infinite recursive page-fault and memory corruption by stack overflow. Signed-off-by:
Masami Hiramatsu <mhiramat@redhat.com> Cc: <stable@kernel.org> [2.6.28.x] Signed-off-by:
-
Al Viro authored
... and yes, gcc is insane enough to eat that without complaint. We probably want sparse to scream on those... Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/mfasheh/ocfs2Linus Torvalds authored
* 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mfasheh/ocfs2: Revert "configfs: Silence lockdep on mkdir(), rmdir() and configfs_depend_item()"
-
git://git.kernel.org/pub/scm/linux/kernel/git/lethal/sh-2.6Linus Torvalds authored
* 'sh/for-2.6.29' of git://git.kernel.org/pub/scm/linux/kernel/git/lethal/sh-2.6: sh: Fix up T-bit error handling in SH-4A mutex fastpath. sh: Fix up spurious syscall restarting. sh: fcnvds fix with denormalized numbers on SH-4 FPU. sh: Only reserve memory under CONFIG_ZERO_PAGE_OFFSET when it != 0. sh: Handle calling csum_partial with misaligned data sh: ap325rxa: Enable ov772x in defconfig. sh: ap325rxa: Add ov772x support. sh: ap325rxa: control camera power toggling. sh: mach-migor: Enable ov772x and tw9910 in defconfig.
-
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6Linus Torvalds authored
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6: Revert "tcp: Always set urgent pointer if it's beyond snd_nxt" ipv6: Copy cork options in ip6_append_data udp: Fix UDP short packet false positive gianfar: Fix potential soft reset race gianfar: Fix BD_LENGTH_MASK definition cxgb3: Fix lro switch iwlwifi: save PCI state before suspend, restore after resume iwlwifi: clean key table in iwl_clear_stations_table
-
- 05 Feb, 2009 30 commits
-
-
David S. Miller authored
This reverts commit 64ff3b93. Jeff Chua reports that it breaks rlogin for him. Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Herbert Xu authored
As the options passed to ip6_append_data may be ephemeral, we need to duplicate it for corking. This patch applies the simplest fix which is to memdup all the relevant bits. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
-
Jesper Dangaard Brouer authored
The UDP header pointer assignment must happen after calling pskb_may_pull(). As pskb_may_pull() can potentially alter the SKB buffer. This was exposted by running multicast traffic through the NIU driver, as it won't prepull the protocol headers into the linear area on receive. Signed-off-by:
Jesper Dangaard Brouer <hawk@comx.dk> Signed-off-by:
-
Alexey Dobriyan authored
lseek() further than length of the file will leave stale ->index (second-to-last during iteration). Next seq_read() will not notice that ->f_pos is big enough to return 0, but will print last item as if ->f_pos is pointing to it. Introduced in commit cb510b81 aka "seq_file: more atomicity in traverse()". Signed-off-by:
Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by:
-
Eric Biederman authored
In 2.6.25 some /proc files were converted to use the seq_file infrastructure. But seq_files do not correctly support pread(), which broke some usersapce applications. To handle pread correctly we can't assume that f_pos is where we left it in seq_read. So move traverse() so that we can eventually use it in seq_read and do thus some day support pread(). Signed-off-by:
Eric Biederman <ebiederm@xmission.com> Cc: Paul Turner <pjt@google.com> Cc: Alexey Dobriyan <adobriyan@gmail.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Dean Nelson authored
A missing type cast results in writing way beyond the end of a kzalloc()'d memory segment resulting in slab corruption. But it seems like the better solution is to define ->recv_msg_slots as a 'void *' rather than a 'struct xpc_notify_mq_msg_uv *' and add the type cast. Signed-off-by:
Dean Nelson <dcn@sgi.com> Cc: <stable@kernel.org> Signed-off-by:
-
Alexey Dobriyan authored
Do usual do {} while (0) dance, otherwise fs/gfs2/util.c:99: error: expected expression before 'else' drivers/scsi/lpfc/lpfc_sli.c:363: error: expected expression before 'else' Signed-off-by:Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Richard Henderson <rth@twiddle.net> Signed-off-by:
-
Dan Carpenter authored
If we return directly with -EPERM then lock_kernel() is still held. This was found with a code checker (http://repo.or.cz/w/smatch.git/). [akpm@linux-foundation.org: fix another such path - missed func_exit()] Signed-off-by:
Dan Carpenter <error27@gmail.com> Cc: <R.E.Wolff@BitWizard.nl> Signed-off-by:
-
Randy Dunlap authored
Fix namespace violations by changing non-kconfig CONFIG_ names to CNFG_*. Fixes breakage in staging/, which adds a real CONFIG_PANEL. Signed-off-by:
Randy Dunlap <randy.dunlap@oracle.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Manish Katiyar authored
drivers/rtc/rtc-ds1390.c:125: warning: unused variable 'rtc' Signed-off-by:
Manish Katiyar <mkatiyar@gmail.com> Signed-off-by:
Alessandro Zummo <a.zummo@towertech.it> Signed-off-by:
-
Mike Rapoport authored
Currently both da903x backlight and voltage reulator drivers have the same name. Rename the backlight driver to allow use of both drivers as modules. Signed-off-by:
Mike Rapoport <mike@compulab.co.il> Acked-by:
Eric Miao <eric.miao@marvell.com> Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by:
-
Hans-Christian Egtvedt authored
The ssc pointer is not valid when the id is not found in the list. Convert the message from a debug one into an error message and avoid dereferencing the bad pointer. Signed-off-by:
Hans-Christian Egtvedt <hans-christian.egtvedt@atmel.com> Cc: Kay Sievers <kay.sievers@vrfy.org> Cc: Huang Weiyi <weiyi.huang@gmail.com> Acked-by:
Haavard Skinnemoen <haavard.skinnemoen@atmel.com> Cc: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by:
-
Carsten Otte authored
Fix do_wp_page for VM_MIXEDMAP mappings. In the case where pfn_valid returns 0 for a pfn at the beginning of do_wp_page and the mapping is not shared writable, the code branches to label `gotten:' with old_page == NULL. In case the vma is locked (vma->vm_flags & VM_LOCKED), lock_page, clear_page_mlock, and unlock_page try to access the old_page. This patch checks whether old_page is valid before it is dereferenced. The regression was introduced by "mlock: mlocked pages are unevictable" (commit b291f000). Signed-off-by:
Carsten Otte <cotte@de.ibm.com> Cc: Nick Piggin <npiggin@suse.de> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: <stable@kernel.org> [2.6.28.x] Signed-off-by:
-
Johannes Weiner authored
With exclusive waiters, every process woken up through the wait queue must ensure that the next waiter down the line is woken when it has finished. Interruptible waiters don't do that when aborting due to a signal. And if an aborting waiter is concurrently woken up through the waitqueue, noone will ever wake up the next waiter. This has been observed with __wait_on_bit_lock() used by lock_page_killable(): the first contender on the queue was aborting when the actual lock holder woke it up concurrently. The aborted contender didn't acquire the lock and therefor never did an unlock followed by waking up the next waiter. Add abort_exclusive_wait() which removes the process' wait descriptor from the waitqueue, iff still queued, or wakes up the next waiter otherwise. It does so under the waitqueue lock. Racing with a wake up means the aborting process is either already woken (removed from the queue) and will wake up the next waiter, or it will remove itself from the queue and the concurrent wake up will apply to the next waiter after it. Use abort_exclusive_wait() in __wait_event_interruptible_exclusive() and __wait_on_bit_lock() when they were interrupted by other means than a wake up through the queue. [akpm@linux-foundation.org: coding-style fixes] Reported-by:
Chris Mason <chris.mason@oracle.com> Signed-off-by:
Johannes Weiner <hannes@cmpxchg.org> Mentored-by:
Oleg Nesterov <oleg@redhat.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Matthew Wilcox <matthew@wil.cx> Cc: Chuck Lever <cel@citi.umich.edu> Cc: Nick Piggin <nickpiggin@yahoo.com.au> Cc: Ingo Molnar <mingo@elte.hu> Cc: <stable@kernel.org> ["after some testing"] Signed-off-by:
-
Randy Dunlap authored
I got the "list is moderated message," so add it here. Signed-off-by:
-
Martin Kebert authored
Add support for the HP laptops of model 6710x for having correctly setup axes. Signed-off-by:
Martin Kebert <gkmarty@gmail.com> Signed-off-by:
Eric Piel <eric.piel@tremplin-utc.net> Acked-by:
Pavel Machek <pavel@suse.cz> Signed-off-by:
-
Pavel Herrmann authored
Add support for the HP laptops of model 6730x for having correctly setup axes. Signed-off-by:
Pavel Herrmann <morpheus.ibis@gmail.com> Signed-off-by:
-
Eric Piel authored
Add support for the HP laptops of model 6530x for having correctly setup axes. Reported-by:
Jerome Poulin <jeromepoulin@gmail.com> Signed-off-by:
-
Jiri Tersel authored
According to dmesg my laptop model HP 6510b is not being recognized by this driver. After I have modified "lis3lv02d.c" axes in Neverball are OK. Signed-off-by:
Jiri Tersel <tersel@mail.muni.cz> Signed-off-by:
-
Andrew Morton authored
The error-path code can call rfkill_unregister() with a pointer which does not contain the result of a call to rfkill_register(). It goes BUG(). Addresses http://bugzilla.kernel.org/show_bug.cgi?id=12560. Cc: Frans Pop <elendil@planet.nl> Cc: Larry Finger <Larry.Finger@lwfinger.net> Cc: Len Brown <lenb@kernel.org> Acked-by:
Matthew Garrett <mjg@redhat.com> Reported-by:
Helge Deller <deller@gmx.de> Testted-by:
-
Andrew Morton authored
Revert commit 0c2d64fb because it causes (arguably poorly designed) existing userspace to spend interminable periods closing billions of not-open file descriptors. We could bring this back, with some sort of opt-in tunable in /proc, which defaults to "off". Peter's alanysis follows: : I spent several hours trying to get to the bottom of a serious : performance issue that appeared on one of our servers after upgrading to : 2.6.28. In the end it's what could be considered a userspace bug that : was triggered by a change in 2.6.28. Since this might also affect other : people I figured I'd at least document what I found here, and maybe we : can even do something about it: : : : So, I upgraded some of debian.org's machines to 2.6.28.1 and immediately : the team maintaining our ftp archive complained that one of their : scripts that previously ran in a few minutes still hadn't even come : close to being done after an hour or so. Downgrading to 2.6.27 fixed : that. : : Turns out that script is forking a lot and something in it or python or : whereever closes all the file descriptors it doesn't want to pass on. : That is, it starts at zero and goes up to ulimit -n/RLIMIT_NOFILE and : closes them all with a few exceptions. : : Turns out that takes a long time when your limit -n is now 2^20 (1048576). : : With 2.6.27.* the ulimit -n was the standard 1024, but with 2.6.28 it is : now a thousand times that. : : 2.6.28 included a patch titled "rlimit: permit setting RLIMIT_NOFILE to : RLIM_INFINITY" (0c2d64fb)[1] that : allows, as the title implies, to set the limit for number of files to : infinity. : : Closer investigation showed that the broken default ulimit did not apply : to "system" processes (like stuff started from init). In the end I : could establish that all processes that passed through pam_limit at one : point had the bad resource limit. : : Apparently the pam library in Debian etch (4.0) initializes the limits : to some default values when it doesn't have any settings in limit.conf : to override them. Turns out that for nofiles this is RLIM_INFINITY. : Commenting out "case RLIMIT_NOFILE" in pam_limit.c:267 of our pam : package version 0.79-5 fixes that - tho I'm not sure what side effects : that has. : : Debian lenny (the upcoming 5.0 version) doesn't have this issue as it : uses a different pam (version). Reported-by:
Peter Palfrader <weasel@debian.org> Cc: Adam Tkac <vonsch@gmail.com> Cc: Michael Kerrisk <mtk.manpages@googlemail.com> Cc: <stable@kernel.org> [2.6.28.x] Signed-off-by:
-
Tony Battersby authored
shm_get_stat() assumes that the inode is a "struct shmem_inode_info", which is incorrect for !CONFIG_SHMEM (see fs/ramfs/inode.c: ramfs_get_inode() vs. mm/shmem.c: shmem_get_inode()). This bad assumption can cause shmctl(SHM_INFO) to lockup when shm_get_stat() tries to spin_lock(&info->lock). Users of !CONFIG_SHMEM may encounter this lockup simply by invoking the 'ipcs' command. Reported by Jiri Olsa back in February 2008: http://lkml.org/lkml/2008/2/29/74Signed-off-by:
Tony Battersby <tonyb@cybernetics.com> Cc: Jiri Kosina <jkosina@suse.cz> Reported-by:
Jiri Olsa <olsajiri@gmail.com> Cc: Hugh Dickins <hugh@veritas.com> Cc: <stable@kernel.org> [2.6.everything] Signed-off-by:
-
Andrea Righi authored
Avoid calling copy_from/to_user() with fb_info->lock mutex held in fbmem ioctl(). fb_mmap() is called under mm->mmap_sem (A) held, that also acquires fb_info->lock (B); fb_ioctl() takes fb_info->lock (B) and does copy_from/to_user() that might acquire mm->mmap_sem (A), causing a deadlock. NOTE: it doesn't push down the fb_info->lock in each own driver's fb_ioctl(), so there are still potential deadlocks elsewhere. Signed-off-by:
Andrea Righi <righi.andrea@gmail.com> Cc: Dave Jones <davej@redhat.com> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: Johannes Weiner <hannes@saeurebad.de> Cc: Krzysztof Helt <krzysztof.h1@wp.pl> Cc: Harvey Harrison <harvey.harrison@gmail.com> Cc: Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by:
-
David Brownell authored
Simple RTC driver for the MSP430 firmware on the DM355 EVM board. Other than not supporting atomic reads/writes of all four bytes, this is reasonable as a basic no-alarm RTC. Signed-off-by:
David Brownell <dbrownell@users.sourceforge.net> Signed-off-by:
Kevin Hilman <khilman@deeprootsystems.com> Acked-by:
-
Matthew Garrett authored
dell-laptop makes use of the power supply class information to choose which backlight interface to change. Add a depends on it. Signed-off-by:
-
Peter Zijlstra authored
The swap() macro is accidentally retuning the value of its first argument. Change it into a doesn't-return-anything macro before someone goes and relies upon this behaviour. Signed-off-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Wu Fengguang <wfg@linux.intel.com> Signed-off-by:
-
David Altobelli authored
The device can take a while to respond to an open/close request, so increase the time kernel will wait for response (1 ms to 10ms). Also, properly clean up a channel on a failed open, by calling the channel close routine. Just freeing the memory isn't sufficient, the device needs to be informed that the channel is no longer open, and the device memory cleared of references to freed dma buffer. Signed-off-by:
David Altobelli <david.altobelli@hp.com> Cc: Greg KH <greg@kroah.com> Signed-off-by:
-
Andrew Morton authored
alpha: kernel/async.c: In function 'run_one_entry': kernel/async.c:141: warning: format '%lli' expects type 'long long int', but argument 2 has type 'async_cookie_t' kernel/async.c:149: warning: format '%lli' expects type 'long long int', but argument 2 has type 'async_cookie_t' kernel/async.c:149: warning: format '%lld' expects type 'long long int', but argument 4 has type 's64' kernel/async.c: In function 'async_synchronize_cookie_special': kernel/async.c:250: warning: format '%lli' expects type 'long long int', but argument 3 has type 's64' Cc: Arjan van de Ven <arjan@infradead.org> Signed-off-by:
-
Andy Fleming authored
SOFT_RESET must be asserted for at least 3 TX clocks in order for it to work properly. The syncs in the gfar_write() commands have been hiding this, but we need to guarantee it. Signed-off-by:
Andy Fleming <afleming@freescale.com> Signed-off-by:
-
