- Aug 16, 2009
-
-
Greg Kroah-Hartman authored
-
Maxime Bizon authored
commit bc146d23 upstream. I'm using ide on 2.6.30.1 with xfs filesystem. I noticed a kernel memory leak after writing lots of data, the kmalloc-96 slab cache keeps growing. It seems the struct ide_cmd kmalloced by idedisk_prepare_flush is never kfreed. Commit a09485df ("ide: move request type specific code from ide_end_drive_cmd() to callers (v3)") and f505d49f ("ide: fix barriers support") cause this regression, cmd->rq must now be set for ide_complete_cmd to honor the IDE_TFLAG_DYN flag. Signed-off-by:
Maxime Bizon <mbizon@freebox.fr> Acked-by:
Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Cc: Simon Kirby <sim@netnation.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Takashi Iwai authored
commit 100d5eb3 upstream. Without the initialization of vmaster NID, the dB information got confused for ALC269 codec. Reference: Novell bnc#527361 https://bugzilla.novell.com/show_bug.cgi?id=527361 Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Trond Myklebust authored
commit 1ae88b2e upstream. We can't call nfs_readdata_release()/nfs_writedata_release() without first initialising and referencing args.context. Doing so inside nfs_direct_read_schedule_segment()/nfs_direct_write_schedule_segment() causes an Oops. We should rather be calling nfs_readdata_free()/nfs_writedata_free() in those cases. Looking at the O_DIRECT code, the "struct nfs_direct_req" is already referencing the nfs_open_context for us. Since the readdata and writedata structures carry a reference to that, we can simplify things by getting rid of the extra nfs_open_context references, so that we can replace all instances of nfs_readdata_release()/nfs_writedata_release(). Reported-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> Tested-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Robert Richter authored
Backport for 2.6.30-stable of: 469535a5 ring-buffer: Fix advance of reader in rb_buffer_peek() When calling rb_buffer_peek() from ring_buffer_consume() and a padding event is returned, the function rb_advance_reader() is called twice. This may lead to missing samples or under high workloads to the warning below. This patch fixes this. If a padding event is returned by rb_buffer_peek() it will be consumed by the calling function now. Also, I simplified some code in ring_buffer_consume(). ------------[ cut here ]------------ WARNING: at /dev/shm/.source/linux/kernel/trace/ring_buffer.c:2289 rb_advance_reader+0x2e/0xc5() Hardware name: Anaheim Modules linked in: Pid: 29, comm: events/2 Tainted: G W 2.6.31-rc3-oprofile-x86_64-standard-00059-g5050dc2 #1 Call Trace: [<ffffffff8106776f>] ? rb_advance_reader+0x2e/0xc5 [<ffffffff81039ffe>] warn_slowpath_common+0x77/0x8f [<ffffffff8103a025>] warn_slowpath_null+0xf/0x11 [<ffffffff8106776f>] rb_advance_reader+0x2e/0xc5 [<ffffffff81068bda>] ring_buffer_consume+0xa0/0xd2 [<ffffffff81326933>] op_cpu_buffer_read_entry+0x21/0x9e [<ffffffff810be3af>] ? __find_get_block+0x4b/0x165 [<ffffffff8132749b>] sync_buffer+0xa5/0x401 [<ffffffff810be3af>] ? __find_get_block+0x4b/0x165 [<ffffffff81326c1b>] ? wq_sync_buffer+0x0/0x78 [<ffffffff81326c76>] wq_sync_buffer+0x5b/0x78 [<ffffffff8104aa30>] worker_thread+0x113/0x1ac [<ffffffff8104dd95>] ? autoremove_wake_function+0x0/0x38 [<ffffffff8104a91d>] ? worker_thread+0x0/0x1ac [<ffffffff8104dc9a>] kthread+0x88/0x92 [<ffffffff8100bdba>] child_rip+0xa/0x20 [<ffffffff8104dc12>] ? kthread+0x0/0x92 [<ffffffff8100bdb0>] ? child_rip+0x0/0x20 ---[ end trace f561c0a58fcc89bd ]--- Cc: Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
Robert Richter <robert.richter@amd.com> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Linus Torvalds authored
commit e6949583 upstream. kernel_sendpage() does the proper default case handling for when the socket doesn't have a native sendpage implementation. Now, arguably this might be something that we could instead solve by just specifying that all protocols should do it themselves at the protocol level, but we really only care about the common protocols. Does anybody really care about sendpage on something like Appletalk? Not likely. Acked-by:
Julien TINNES <julien@cr0.org> Acked-by:
Tavis Ormandy <taviso@sdf.lonestar.org> Signed-off-by:
-
Oleg Nesterov authored
commit 704b836c upstream. The problem is minor, but without ->cred_guard_mutex held we can race with exec() and get the new ->mm but check old creds. Now we do not need to re-check task->mm after ptrace_may_access(), it can't be changed to the new mm under us. Strictly speaking, this also fixes another very minor problem. Unless security check fails or the task exits mm_for_maps() should never return NULL, the caller should get either old or new ->mm. Signed-off-by:
Oleg Nesterov <oleg@redhat.com> Acked-by:
Serge Hallyn <serue@us.ibm.com> Signed-off-by:
James Morris <jmorris@namei.org> Signed-off-by:
-
Oleg Nesterov authored
commit 00f89d21 upstream. mm_for_maps() takes ->mmap_sem after security checks, this looks strange and obfuscates the locking rules. Move this lock to its single caller, m_start(). Signed-off-by:
-
Oleg Nesterov authored
commit 13f0feaf upstream. It would be nice to kill __ptrace_may_access(). It requires task_lock(), but this lock is only needed to read mm->flags in the middle. Convert mm_for_maps() to use ptrace_may_access(), this also simplifies the code a little bit. Also, we do not need to take ->mmap_sem in advance. In fact I think mm_for_maps() should not play with ->mmap_sem at all, the caller should take this lock. With or without this patch, without ->cred_guard_mutex held we can race with exec() and get the new ->mm but check old creds. Signed-off-by:
-
Alok Kataria authored
commit 7d5b0056 upstream. With CONFIG_STACK_PROTECTOR turned on, VMI doesn't boot with more than one processor. The problem is with the gs value not being initialized correctly when registering the secondary processor for VMI's case. The patch below initializes the gs value for the AP to __KERNEL_STACK_CANARY. Without this the secondary processor keeps on taking a GP on every gs access. Signed-off-by:
Alok N Kataria <akataria@vmware.com> LKML-Reference: <1249425262.18955.40.camel@ank32.eng.vmware.com> Signed-off-by:
-
Eric Dumazet authored
commit bd3f0221 upstream. I noticed oprofile memleaked in linux-2.6 current tree, and tracked this ring-buffer leak. Signed-off-by:
Eric Dumazet <eric.dumazet@gmail.com> LKML-Reference: <4A7C06B9.2090302@gmail.com> Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
-
Michael Buesch authored
commit 18753ebc upstream. access_ok() checks must be done on every part of the userspace structure that is accessed. If access_ok() on one part of the struct succeeded, it does not imply it will succeed on other parts of the struct. (Does depend on the architecture implementation of access_ok()). This changes the __get_user() users to first check access_ok() on the data structure. Signed-off-by:
Michael Buesch <mb@bu3sch.de> Cc: Pete Zaitcev <zaitcev@redhat.com> Signed-off-by:
-
Alan Stern authored
commit 01105a24 upstream. This patch (as1272) changes the error code returned when an open call for a USB device node fails to locate the corresponding device. The appropriate error code is -ENODEV, not -ENOENT. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> CC: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by:
-
Rogerio Brito authored
commit c15e3ca1 upstream. Add a quirk entry for the Leading Driver UD-11 usb flash drive. As Alan Stern told me, the device doesn't deal correctly with the locking media feature of the device, and this patch incorporates it. Compiled, tested, working. Signed-off-by:
Rogerio Brito <rbrito@ime.usp.br> Cc: Phil Dibowitz <phil@ipom.com> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Robert Hancock <hancockrwd@gmail.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Dhaval Vasa authored
commit 50d0678e upstream. reference: http://www.open-rd.org Signed-off-by:
Dhaval Vasa <dhaval.vasa@einfochips.com> Signed-off-by:
-
Marko Hänninen authored
commit c47aacc6 upstream. Attached patch adds USB vendor and product IDs for Bayer's USB to serial converter cable used by Bayer blood glucose meters. It seems to be a FT232RL based device and works without any problem with ftdi_sio driver when this patch is applied. See: http://winglucofacts.com/cables/ Signed-off-by:
Marko Hänninen <bugitus@gmail.com> Signed-off-by:
-
Greg Kroah-Hartman authored
commit 2c63abf9 upstream. [Mike Galbraith did the upstream revert, which was more complex] Staging: rt2870: Revert d44ca7 Removal of kernel_thread() API The sanity check this patch introduced triggers on shutdown, apparently due to threads having already exited by the time BUG_ON() is reached. Cc: Mike Galbraith <efault@gmx.de> Cc: Peter Teoh <htmldeveloper@gmail.com> Signed-off-by:
-
Xiao Guangrong authored
commit 69dd647f upstream. Use CONFIG_HOTPLUG_CPU, not CONFIG_CPU_HOTPLUG When hot-unpluging a cpu, it will leak memory allocated at cpu hotplug, but only if CPUMASK_OFFSTACK=y, which is default to n. The bug was introduced by 8969a5ed ("generic-ipi: remove kmalloc()"). Signed-off-by:
Xiao Guangrong <xiaoguangrong@cn.fujitsu.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Jens Axboe <jens.axboe@oracle.com> Cc: Nick Piggin <nickpiggin@yahoo.com.au> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by:
-
Eric Sandeen authored
commit 69130c7c upstream. The FIEMAP_IOC_FIEMAP mapping ioctl was missing a 32-bit compat handler, which means that 32-bit suerspace on 64-bit kernels cannot use this ioctl command. The structure is nicely aligned, padded, and sized, so it is just this simple. Tested w/ 32-bit ioctl tester (from Josef) on a 64-bit kernel on ext4. Signed-off-by:
Eric Sandeen <sandeen@redhat.com> Cc: <linux-ext4@vger.kernel.org> Cc: Mark Lord <lkml@rtr.ca> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Josef Bacik <josef@redhat.com> Cc: Jan Kara <jack@suse.cz> Signed-off-by:
-
Linus Torvalds authored
commit 3440625d upstream. The new credentials code broke load_flat_shared_library() as it now uses an uninitialized cred pointer. Reported-by:
Bernd Schmidt <bernds_cb1@t-online.de> Tested-by:
-
Eric Dumazet authored
commit 9c8a8228 upstream. While looking at Jens Rosenboom bug report (http://lkml.org/lkml/2009/7/27/35 ) about strange sys_futex call done from a dying "ps" program, we found following problem. clone() syscall has special support for TID of created threads. This support includes two features. One (CLONE_CHILD_SETTID) is to set an integer into user memory with the TID value. One (CLONE_CHILD_CLEARTID) is to clear this same integer once the created thread dies. The integer location is a user provided pointer, provided at clone() time. kernel keeps this pointer value into current->clear_child_tid. At execve() time, we should make sure kernel doesnt keep this user provided pointer, as full user memory is replaced by a new one. As glibc fork() actually uses clone() syscall with CLONE_CHILD_SETTID and CLONE_CHILD_CLEARTID set, chances are high that we might corrupt user memory in forked processes. Following sequence could happen: 1) bash (or any program) starts a new process, by a fork() call that glibc maps to a clone( ... CLONE_CHILD_SETTID | CLONE_CHILD_CLEARTID ...) syscall 2) When new process starts, its current->clear_child_tid is set to a location that has a meaning only in bash (or initial program) context (&THREAD_SELF->tid) 3) This new process does the execve() syscall to start a new program. current->clear_child_tid is left unchanged (a non NULL value) 4) If this new program creates some threads, and initial thread exits, kernel will attempt to clear the integer pointed by current->clear_child_tid from mm_release() : if (tsk->clear_child_tid && !(tsk->flags & PF_SIGNALED) && atomic_read(&mm->mm_users) > 1) { u32 __user * tidptr = tsk->clear_child_tid; tsk->clear_child_tid = NULL; /* * We don't check the error code - if userspace has * not set up a proper pointer then tough luck. */ << here >> put_user(0, tidptr); sys_futex(tidptr, FUTEX_WAKE, 1, NULL, NULL, 0); } 5) OR : if new program is not multi-threaded, but spied by /proc/pid users (ps command for example), mm_users > 1, and the exiting program could corrupt 4 bytes in a persistent memory area (shm or memory mapped file) If current->clear_child_tid points to a writeable portion of memory of the new program, kernel happily and silently corrupts 4 bytes of memory, with unexpected effects. Fix is straightforward and should not break any sane program. Reported-by:
Jens Rosenboom <jens@mcbone.net> Acked-by:
-
Neil Brown authored
commit 70471daf upstream. The v1.x metadata does not have a fixed size and can grow when devices are added. If it grows enough to require an extra sector of storage, we need to update the 'sb_size' to match. Without this, md can write out an incomplete superblock with a bad checksum, which will be rejected when trying to re-assemble the array. Signed-off-by:
NeilBrown <neilb@suse.de> Signed-off-by:
-
roel kluin authored
commit 37b76c69 upstream. Fix misplaced parenthesis Signed-off-by:
Roel Kluin <roel.kluin@gmail.com> Signed-off-by:
-
roel kluin authored
commit c5ad4f59 upstream. Parentheses are required or the comparison occurs before the bitand. Signed-off-by:
-
Roel Kluin authored
commit 0ed586d0 upstream. The WAKE_MCAST bit is tested twice, the first should be WAKE_UCAST. Signed-off-by:
-
Stefan Richter authored
Commit ebbb16bf upstream. Increase the command ORB data structure to transport up to 16 bytes long CDBs (instead of 12 bytes), and tell the SCSI mid layer about it. This is notably necessary for READ CAPACITY(16) and friends, i.e. support of large disks. Signed-off-by:
Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by:
-
Stefan Richter authored
Commit af271941 upstream. Increase the command ORB data structure to transport up to 16 bytes long CDBs (instead of 12 bytes), and tell the SCSI mid layer about it. This is notably necessary for READ CAPACITY(16) and friends, i.e. support of large disks. Signed-off-by:
-
Michele Jr De Candia authored
commit 96f699ad upstream. I've tested TSL2550 driver and I've found a bug: when light is off, returned value from tsl2550_calculate_lux function is -1 when it should be 0 (sensor correctly read that light was off). I think the bug is that a zero c0 value (approximated value of ch0) is misinterpreted as an error. Signed-off-by:
Michele Jr De Candia <michele.decandia@valueteam.com> Acked-by:
Rodolfo Giometti <giometti@linux.it> Signed-off-by:
Jean Delvare <khali@linux-fr.org> Signed-off-by:
-
Jean Delvare authored
commit 1b54ab45 upstream. The SMSC LPC47M233 and LPC47M292 chips have the same device ID but are not compatible. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Luca Tettamanti authored
commit 8d282497 upstream. On newer Asus boards the "upper" limit of a sensor is encoded as delta from the "lower" limit. Fix the driver to correctly handle this case. Signed-off-by:
Luca Tettamanti <kronos.it@gmail.com> Tested-by:
Alex Macfarlane Smith <nospam@archifishal.co.uk> Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
commit 346c17a6 upstream. There are some broken devices that report multiple DMA xfer modes enabled at once (ATA spec doesn't allow it) but otherwise work fine with DMA so just delete ide_id_dma_bug(). [ As discovered by detective work by Frans and Bart, due to how handling of the ID block was handled before commit c4199930 ("ide-iops: only clear DMA words on setting DMA mode") this check was always seeing zeros in the fields or other similar garbage. Therefore this check wasn't actually checking anything. Now that the tests actually check the real bits, all we see are devices that trigger the check yet work perfectly fine, therefore killing this useless check is the best thing to do. -DaveM ] Reported-by:
Frans Pop <elendil@planet.nl> Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
commit ffc36c76 upstream. Add ide_host_enable_irqs() helper and use it in ide_host_register() before registering ports. Then remove no longer needed IRQ unmasking from in init_irq(). This should fix the problem with "screaming" shared IRQ on the first port (after request_irq() call while we have the unexpected IRQ pending on the second port) which was uncovered by my rework of the serialized interfaces support. Reported-by:
-
NeilBrown authored
commit 3a981b03 upstream. When an array is changed from RAID6 to RAID5, fewer drives are needed. So any device that is made superfluous by the level conversion must be marked as not-active. For the RAID6->RAID5 conversion, this will be a drive which only has 'Q' blocks on it. Signed-off-by:
-
Dan Williams authored
commit 95fc17aa upstream. Add missing call to safe_put_page from stop() by unifying open coded raid5_conf_t de-allocation under free_conf(). Signed-off-by:
Dan Williams <dan.j.williams@intel.com> Signed-off-by:
-
Pallipadi, Venkatesh authored
commit bdc6340f upstream. Changeset 3869c4aa that went in after 2.6.30-rc1 was a seemingly small change to _set_memory_wc() to make it complaint with SDM requirements. But, introduced a nasty bug, which can result in crash and/or strange corruptions when set_memory_wc is used. One such crash reported here http://lkml.org/lkml/2009/7/30/94 Actually, that changeset introduced two bugs. * change_page_attr_set() takes &addr as first argument and can the addr value might have changed on return, even for single page change_page_attr_set() call. That will make the second change_page_attr_set() in this routine operate on unrelated addr, that can eventually cause strange corruptions and bad page state crash. * The second change_page_attr_set() call, before setting _PAGE_CACHE_WC, should clear the earlier _PAGE_CACHE_UC_MINUS, as otherwise cache attribute will not be WC (will be UC instead). The patch below fixes both these problems. Sending a single patch to fix both the problems, as the change is to the same line of code. The change to have a addr_copy is not very clean. But, it is simpler than making more changes through various routines in pageattr.c. A huge thanks to Jerome for reporting this problem and providing a simple test case that helped us root cause the problem. Reported-by:
Jerome Glisse <glisse@freedesktop.org> Signed-off-by:
Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by:
Suresh Siddha <suresh.b.siddha@intel.com> LKML-Reference: <20090730214319.GA1889@linux-os.sc.intel.com> Acked-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
H. Peter Anvin <hpa@zytor.com> Signed-off-by:
-
H. Peter Anvin authored
commit f1f029c7 upstream. From Gabe Black in bugzilla 13888: native_save_fl is implemented as follows: 11static inline unsigned long native_save_fl(void) 12{ 13 unsigned long flags; 14 15 asm volatile("# __raw_save_flags\n\t" 16 "pushf ; pop %0" 17 : "=g" (flags) 18 : /* no input */ 19 : "memory"); 20 21 return flags; 22} If gcc chooses to put flags on the stack, for instance because this is inlined into a larger function with more register pressure, the offset of the flags variable from the stack pointer will change when the pushf is performed. gcc doesn't attempt to understand that fact, and address used for pop will still be the same. It will write to somewhere near flags on the stack but not actually into it and overwrite some other value. I saw this happen in the ide_device_add_all function when running in a simulator I work on. I'm assuming that some quirk of how the simulated hardware is set up caused the code path this is on to be executed when it normally wouldn't. A simple fix might be to change "=g" to "=r". Reported-by:
Gabe Black <spamforgabe@umich.edu> Signed-off-by:
-
Thomas Hellstrom authored
commit 8523acfe upstream. The code was incorrectly reserving memtypes using the page virtual address instead of the physical address. Furthermore, the code was not ignoring highmem pages as it ought to. ( upstream does not pass in highmem pages yet - but upcoming graphics code will do it and there's no reason to not handle this properly in the CPA APIs.) Fixes: http://bugzilla.kernel.org/show_bug.cgi?id=13884 Signed-off-by:
Thomas Hellstrom <thellstrom@vmware.com> Acked-by:
-
Mel Gorman authored
commit e084b2d9 upstream. Fix a post-2.6.24 performace regression caused by 3dfa5721 ("page-allocator: preserve PFN ordering when __GFP_COLD is set"). Narayanan reports "The regression is around 15%. There is no disk controller as our setup is based on Samsung OneNAND used as a memory mapped device on a OMAP2430 based board." The page allocator tries to preserve contiguous PFN ordering when returning pages such that repeated callers to the allocator have a strong chance of getting physically contiguous pages, particularly when external fragmentation is low. However, of the bulk of the allocations have __GFP_COLD set as they are due to aio_read() for example, then the PFNs are in reverse PFN order. This can cause performance degration when used with IO controllers that could have merged the requests. This patch attempts to preserve the contiguous ordering of PFNs for users of __GFP_COLD. Signed-off-by:
Mel Gorman <mel@csn.ul.ie> Reported-by:
Narayananu Gopalakrishnan <narayanan.g@samsung.com> Tested-by:
-
Eric Sandeen authored
commit e4c6f8be upstream. As reported in Red Hat bz #509671, i_blocks for files on hugetlbfs get accounting wrong when doing something like: $ > foo $ date > foo date: write error: Invalid argument $ /usr/bin/stat foo File: `foo' Size: 0 Blocks: 18446744073709547520 IO Block: 2097152 regular ... This is because hugetlb_unreserve_pages() is unconditionally removing blocks_per_huge_page(h) on each call rather than using the freed amount. If there were 0 blocks, it goes negative, resulting in the above. This is a regression from commit a5516438 ("hugetlb: modular state for hugetlb page size") which did: - inode->i_blocks -= BLOCKS_PER_HUGEPAGE * freed; + inode->i_blocks -= blocks_per_huge_page(h); so just put back the freed multiplier, and it's all happy again. Signed-off-by:
Andi Kleen <andi@firstfloor.org> Cc: William Lee Irwin III <wli@holomorphy.com> Signed-off-by:
-
Peter Korsgaard authored
commit b7d66c88 upstream. usb0 and usb1 mux settings in the sicrl register were swapped (twice!) in mpc834x_usb_cfg(), leading to various strange issues with fsl-ehci and full speed devices. The USB port config on mpc834x is done using 2 muxes: Port 0 is always used for MPH port 0, and port 1 can either be used for MPH port 1 or DR (unless DR uses UTMI phy or OTG, then it uses both ports) - See 8349 RM figure 1-4.. mpc8349_usb_cfg() had this inverted for the DR, and it also had the bit positions of the usb0 / usb1 mux settings swapped. It would basically work if you specified port1 instead of port0 for the MPH controller (and happened to use ULPI phys), which is what all the 834x dts have done, even though that configuration is physically invalid. Instead fix mpc8349_usb_cfg() and adjust the dts files to match reality. Signed-off-by:
Peter Korsgaard <jacmet@sunsite.dk> Signed-off-by:
Kumar Gala <galak@kernel.crashing.org> Signed-off-by:
-
