- 24 Mar, 2008 40 commits
-
-
Tony Battersby authored
commit: 4d2de3a5 When sending a SCSI command to a tape drive via the SCSI Generic (sg) driver, if the command has a data transfer length more than scatter_elem_sz (32 KB default) and not a multiple of 512, then I either hit BUG_ON(!valid_dma_direction(direction)) in dma_unmap_sg() or else the command never completes (depending on the LLDD). When constructing scatterlists, the sg driver rounds up the scatterlist element sizes to be a multiple of 512. This can result in sum(scatterlist lengths) > bufflen. In this case, scsi_req_map_sg() incorrectly sets bio->bi_size to sum(scatterlist lengths) rather than to bufflen. When the command completes, req_bio_endio() detects that bio->bi_size != 0, and so it doesn't call bio_endio(). This causes the command to be resubmitted, resulting in BUG_ON or the command never completing. This patch makes scsi_req_map_sg() set bio->bi_size to bufflen rather than to sum(scatterlist lengths), which fixes the problem. Signed-off-by:
Tony Battersby <tonyb@cybernetics.com> Acked-by:
Mike Christie <michaelc@cs.wisc.edu> Signed-off-by:
James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by:
Chris Wright <chrisw@sous-sol.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Misha Zhilin authored
commit: b5f7a0ec USB: ehci: Fixes completion for multi-qtd URB the short read case When use of urb->status in the EHCI driver was reworked last August (commit 14c04c0f ), a bug was inserted in the handling of early completion for bulk transactions that need more than one qTD (e.g. more than 20KB in one URB). This patch resolves that problem by ensuring that the early completion status is preserved until the URB is handed back to its submitter, instead of resetting it after each qTD. Signed-off-by:
Misha Zhilin <misha@epiphan.com> Signed-off-by:
David Brownell <dbrownell@users.sourceforge.net> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Sven Andersen authored
[upstream commit: 4ae897df ] Add EM1010PC to ftdi_sio.c Signed-off-by:
Sven Andersen <s.andersen@cryonet.de> Cc: stable <stable@kernel.org> Signed-off-by:
-
Kevin Vance authored
commit: 546d7eec Workaround for the FT232RL-based, Matrix Orbital VK204-25-USB serial port added to the ftdi_sio driver. The device has an invalid endpoint descriptor, which must be modified before it can be used. Signed-off-by:
Kevin Vance <kvance@kvance.com> Signed-off-by:
-
Samuel Thibault authored
commit: 8182ec49 VT notifier callbacks need to be aware of console switches. This is already partially done from console_callback(), but at that time fg_console, cursor positions, etc. are not yet updated and hence screen readers fetch the old values. This adds an update notify after all of the values are updated in redraw_screen(vc, 1). Signed-off-by:
Samuel Thibault <samuel.thibault@ens-lyon.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Michael Halcrow authored
commit: e4465fda When the page is not up to date, ecryptfs_prepare_write() should be acting much like ecryptfs_readpage(). This includes the painfully obvious step of actually decrypting the page contents read from the lower encrypted file. Note that this patch resolves a bug in eCryptfs in 2.6.24 that one can produce with these steps: # mount -t ecryptfs /secret /secret # echo "abc" > /secret/file.txt # umount /secret # mount -t ecryptfs /secret /secret # echo "def" >> /secret/file.txt # cat /secret/file.txt Without this patch, the resulting data returned from cat is likely to be something other than "abc\ndef\n". (Thanks to Benedikt Driessen for reporting this.) Signed-off-by:
Michael Halcrow <mhalcrow@us.ibm.com> Cc: Benedikt Driessen <bdriessen@escrypt.com> Signed-off-by:
-
Dan Williams authored
commit: 6497dcff Initialize 'ack' to zero in case the descriptor has been recycled. Prevents "kernel BUG at crypto/async_tx/async_xor.c:185!" Signed-off-by:
Dan Williams <dan.j.williams@intel.com> Acked-by:
Shannon Nelson <shannon.nelson@intel.com> [chrisw@sous-sol.org: backport to 2.6.24.3] Signed-off-by:
-
Atsushi Nemoto authored
commit: 179956f4 Fix NCFGR.SPD setting on 10Mbps. This bug was introduced by conversion to generic PHY layer in kernel 2.6.23. Signed-off-by:
Atsushi Nemoto <anemo@mba.ocn.ne.jp> Signed-off-by:
Jeff Garzik <jeff@garzik.org> Signed-off-by:
Haavard Skinnemoen <hskinnemoen@atmel.com> Signed-off-by:
-
Hiroshi Shimamoto authored
[upstream commit: 3d97775a ] Move out tick_nohz_stop_sched_tick() call from the loop in cpu_idle same as 32-bit version. Signed-off-by:
Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Cc: Ed Tomlinson <edt@aei.ca> Signed-off-by:
-
Atsushi Nemoto authored
commit: f6febccd The atmel_spi driver does not initialize clock polarity correctly (except for at91rm9200 CS0 channel) in some case. The atmel_spi driver uses gpio-controlled chipselect. OTOH spi clock signal is controlled by CSRn.CPOL bit, but this register controls clock signal correctly only in 'real transfer' duration. At the time of cs_activate() call, CSRn.CPOL will be initialized correctly, but the controller do not know which channel is to be used next, so clock signal will stay at the inactive state of last transfer. If clock polarity of new transfer and last transfer was differ, new transfer will start with wrong clock signal state. For example, if you started SPI MODE 2 or 3 transfer after SPI MODE 0 or 1 transfer, the clock signal state at the assertion of chipselect will be low. Of course this will violates SPI transfer. This patch is short term solution for this problem. It makes all CSRn.CPOL match for the transfer before activating chipselect. For longer term, the best fix might be to let NPCS0 stay selected permanently in MR and overwrite CSR0 with to the new slave's settings before asserting CS. Signed-off-by:
-
Michael Buesch authored
This is a backport of upstream commit 013978b6 ("b43: Changes to enable BCM4311 rev 02 with wireless core revision 13") and the changes include the following: (1) Add the 802.11 rev 13 device to the ssb_device_id table to load b43. (2) Add PHY revision 9 to the supported list. (3) Change the 2-bit routing code for address extensions to 0b10 rather than the 0b01 used for the 32-bit case. (4) Remove some magic numbers in the DMA setup. The DMA implementation for this chip supports full 64-bit addressing with one exception. Whenever the Descriptor Ring Buffer is in high memory, a fatal DMA error occurs. This problem was not present in 2.6.24-rc2 due to code to "Bias the placement of kernel pages at lower PFNs". When commit 44048d70 reverted that code, the DMA error appeared. As a "fix", use the GFP_DMA flag when allocating the buffer for 64-bit DMA. At present, this problem is thought to arise from a hardware error. Signed-off-by:
Michael Buesch <mb@bu3sch.de> Cc: Larry Finger <Larry.Finger@lwfinger.net> Cc: John W. Linville <linville@tuxdriver.com> Cc: Alexey Zaytsev <alexey.zaytsev@gmail.com> Signed-off-by:
-
Mike Pagano authored
As of 2.6.24, running the archttp passthrough daemon with the arcmsr driver produces an endless spew of dma_free_coherent warnings: WARNING: at arch/x86/kernel/pci-dma_64.c:169 dma_free_coherent() It turns out that coherent memory is not needed, so commit 76d78300 by Nick Cheng <nick.cheng@areca.com.tw> switched it to kmalloc (as well as making a lot of other changes which have not been included here). James Bottomley pointed out that the new kmalloc usage was also wrong, I corrected this in commit 69e562c2. This patch combines both of the above for the purpose of fixing 2.6.24. details in http://bugs.gentoo.org/208493 . Signed-off-by:
Daniel Drake <dsd@gentoo.org> Cc: Nick Cheng <nick.cheng@areca.com.tw> Cc: James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by:
-
Auke Kok authored
CRC stripping was only correctly enabled for packet split recieves which is used when receiving jumbo frames. Correctly enable SECRC also for normal buffer packet receives. Tested by Andy Gospodarek and Johan Andersson, see bugzilla #9940. Signed-off-by:
Auke Kok <auke-jan.h.kok@intel.com> Signed-off-by:
-
Ivan Kokshaysky authored
[upsteam commit: a0ca9909] Thanks to Loic Prylli <loic@myri.com>, who originally proposed this idea. Always using legacy configuration mechanism for the legacy config space and extended mechanism (mmconf) for the extended config space is a simple and very logical approach. It's supposed to resolve all known mmconf problems. It still allows per-device quirks (tweaking dev->cfg_size). It also allows to get rid of mmconf fallback code. This patch fixes a boot hang on Intel Q35 chipset as detailed at: http://bugs.gentoo.org/198810 Signed-off-by:
Ivan Kokshaysky <ink@jurassic.park.msu.ru> Signed-off-by:
Matthew Wilcox <willy@linux.intel.com> Signed-off-by:
-
Ivan Kokshaysky authored
[upstream commit: 91d35dd9] On alpha, ia64 and ppc64 only relocations to local data can go into read-only sections. The vast majority of module parameters use the global generic param_set_*/param_get_* functions, so the 'const' attribute for struct kernel_param is not only useless, but it also causes compile failures due to 'section type conflict' in those rare cases where param_set/get are local functions. This fixes http://bugzilla.kernel.org/show_bug.cgi?id=8964 Signed-off-by:
-
Alan Cox authored
[upstream commit: 6ddd6861 ] When masking, mask out the modes that are unsupported not the ones that are supported. This makes life happier. Signed-off-by:
Alan Cox <alan@redhat.com> Signed-off-by:
-
FUJITA Tomonori authored
commit 7d5d408c struct asc_dvc_var needs overrun buffer to be placed on an 8 byte boundary. advansys defines struct asc_dvc_var: struct asc_dvc_var { ... uchar overrun_buf[ASC_OVERRUN_BSIZE] __aligned(8); The problem is that struct asc_dvc_var is placed on shost->hostdata. So if the hostdata is not on an 8 byte boundary, the advansys crashes. The hostdata is placed on a sizeof(unsigned long) boundary so the 8 byte boundary is not garanteed with x86_32. With 2.6.23 and 2.6.24, the hostdata is on an 8 byte boundary by chance, but with the current git, it's not. This patch removes overrun_buf static array and use kzalloc. Signed-off-by:
FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Signed-off-by:
-
Patrick McHardy authored
Upstream commit 1b04ab45 : The function ebt_do_table doesn't take NF_DROP as a verdict from the targets. Signed-off-by:
Joonwoo Park <joonwpark81@gmail.com> Signed-off-by:
Patrick McHardy <kaber@trash.net> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Patrick McHardy authored
Upstream commit eb1197bc: http://bugzilla.kernel.org/show_bug.cgi?id=9920 The function skb_make_writable returns true or false. Signed-off-by:
-
Patrick McHardy authored
Upstream commit e2b58a67 : As reported by Tomas Simonaitis <tomas.simonaitis@gmail.com>, inserting new data in skbs queued over {ip,ip6,nfnetlink}_queue triggers a SKB_LINEAR_ASSERT in skb_put(). Going back through the git history, it seems this bug is present since at least 2.6.12-rc2, probably even since the removal of skb_linearize() for netfilter. Linearize non-linear skbs through skb_copy_expand() when enlarging them. Tested by Thomas, fixes bugzilla #9933. Signed-off-by:
-
Ned Forrester authored
commit: b97c74bd Fixes a sequencing bug in spi driver pxa2xx_spi.c in which the chip select for a transfer may be asserted before the clock polarity is set on the interface. As a result of this bug, the clock signal may have the wrong polarity at transfer start, so it may need to make an extra half transition before the intended clock/data signals begin. (This probably means all transfers are one bit out of sequence.) This only occurs on the first transfer following a change in clock polarity in systems using more than one more than one such polarity. The fix assures that the clock mode is properly set before asserting chip select. This bug was introduced in a patch merged on 2006/12/10, kernel 2.6.20. The patch defines an additional bit in: include/asm-arm/arch-pxa/regs-ssp.h for 2.6.25 and newer kernels but this addition must be made in: include/asm-arm/arch-pxa/pxa-regs.h for kernels between 2.6.20 and 2.6.24, inclusive Signed-off-by:
Ned Forrester <nforrester@whoi.edu> Signed-off-by:
-
Roel Kluin authored
commit: f81e8a43 This bug snuck in with commit 252e211e Author: Mark Fortescue <mark@mtfhpc.demon.co.uk> Date: Tue Oct 16 23:26:31 2007 -0700 Add in SunOS 4.1.x compatible mode for UFS Signed-off-by:
Roel Kluin <12o3l@tiscali.nl> Acked-by:
Evgeniy Dushistov <dushistov@mail.ru> Cc: Mark Fortescue <mark@mtfhpc.demon.co.uk> Signed-off-by:
-
Andy Whitcroft authored
commit: e5df70ab When we free a page via free_huge_page and we detect that we are in surplus the page will be returned to the buddy. After this we no longer own the page. However at the end free_huge_page we clear out our mapping pointer from page private. Even where the page is not a surplus we free the page to the hugepage pool, drop the pool locks and then clear page private. In either case the page may have been reallocated. BAD. Make sure we clear out page private before we free the page. Signed-off-by:
Andy Whitcroft <apw@shadowen.org> Acked-by:
Adam Litke <agl@us.ibm.com> Signed-off-by:
-
Serge E. Hallyn authored
commit: 09497284 Simplify the uid equivalence check in cap_task_kill(). Anyone can kill a process owned by the same uid. Without this patch wireshark is reported to fail. Signed-off-by:
Serge E. Hallyn <serue@us.ibm.com> Signed-off-by:
Andrew G. Morgan <morgan@kernel.org> Signed-off-by:
-
Thomas Gleixner authored
commit: a0c1e907 Not all architectures implement futex_atomic_cmpxchg_inatomic(). The default implementation returns -ENOSYS, which is currently not handled inside of the futex guts. Futex PI calls and robust list exits with a held futex result in an endless loop in the futex code on architectures which have no support. Fixing up every place where futex_atomic_cmpxchg_inatomic() is called would add a fair amount of extra if/else constructs to the already complex code. It is also not possible to disable the robust feature before user space tries to register robust lists. Compile time disabling is not a good idea either, as there are already architectures with runtime detection of futex_atomic_cmpxchg_inatomic support. Detect the functionality at runtime instead by calling cmpxchg_futex_value_locked() with a NULL pointer from the futex initialization code. This is guaranteed to fail, but the call of futex_atomic_cmpxchg_inatomic() happens with pagefaults disabled. On architectures, which use the asm-generic implementation or have a runtime CPU feature detection, a -ENOSYS return value disables the PI/robust features. On architectures with a working implementation the call returns -EFAULT and the PI/robust features are enabled. The relevant syscalls return -ENOSYS and the robust list exit code is blocked, when the detection fails. Fixes http://lkml.org/lkml/2008/2/11/149 Originally reported by: Lennart Buytenhek Signed-off-by:
-
Thomas Gleixner authored
commit: 3e4ab747 When the futex init code fails to initialize the futex pseudo file system it returns early without initializing the hash queues. Should the boot succeed then a futex syscall which tries to enqueue a waiter on the hashqueue will crash due to the unitilialized plist heads. Initialize the hash queues before the filesystem. Signed-off-by:
-
Russell King authored
commit: a0dd005d Ensure that the clock lookup always finds an entry for a specific device and ID before it falls back to finding just by ID. This fixes a problem reported by Holger Schurig where the BTUART was assigned the wrong clock. Tested-by:
Holger Schurig <hs4233@mail.mn-solutions.de> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Uli Luckas notes: The patch fixes the otherwise unusable bluetooth uart on pxa25x. The patch is written by Russell King [1] who also gave his OK for stable inclusion [2]. The patch is also available as commit a0dd005d to Linus' tree. [1] http://marc.info/?l=linux-arm-kernel&m=120298366510315 [2] http://marc.info/?l=linux-arm-kernel&m=120384388411097 Signed-off-by:
-
Thomas Gleixner authored
Commit: 9d55b992 The exception fixup for the futex macros __futex_atomic_op1/2 and futex_atomic_cmpxchg_inatomic() is missing an entry when the lock prefix is replaced by a NOP via SMP alternatives. Chuck Ebert tracked this down from the information provided in: https://bugzilla.redhat.com/show_bug.cgi?id=429412 A possible solution would be to add another fixup after the LOCK_PREFIX, so both the LOCK and NOP case have their own entry in the exception table, but it's not really worth the trouble. Simply replace LOCK_PREFIX with lock and keep those untouched by SMP alternatives. Signed-off-by:
-
James Bottomley authored
commit: cb84e2d2 This driver has been failing under heavy load with aic94xx: escb_tasklet_complete: REQ_TASK_ABORT, reason=0x6 aic94xx: escb_tasklet_complete: Can't find task (tc=4) to abort! The second message is because the driver fails to identify the task it's being asked to abort. On closer inpection, there's a thinko in the for each task loop over pending tasks in both the REQ_TASK_ABORT and REQ_DEVICE_RESET cases where it doesn't look at the task on the pending list but at the one on the ESCB (which is always NULL). Fix by looking at the right task. Also add a print for the case where the pending SCB doesn't have a task attached. Not sure if this will fix all the problems, but it's a definite first step. Signed-off-by:
-
James Bottomley authored
commit: ff83efac The spinlock is held over too large a region: pscratch is a permanent address (it's allocated at boot time and never changes). All you need the smp lock for is mediating the scratch in use flag, so fix this by moving the spinlock into the case where we set the pscratch_busy flag to false. Signed-off-by:
-
FUJITA Tomonori authored
commit: 2b28a472 This fixes a bug that can't handle a passthru command with more than two sg entries. Big thanks to Tim Pepper for debugging the problem. Signed-off-by:
Mark Salyzyn <Mark_Salyzyn@adaptec.com> Signed-off-by:
-
Alan Stern authored
This patch (as1038) fixes a bug in usb_stor_access_xfer_buf() and usb_stor_set_xfer_buf() (the bug was originally found by Boaz Harrosh): The routine must not attempt to write beyond the end of a scatter-gather list or beyond the number of bytes requested. This is the minimal 2.6.24 equivalent to as1035 + as1037 (7084191d "USB: usb-storage: don't access beyond the end of the sg buffer" + 6d512a80 "usb-storage: update earlier scatter-gather bug fix"). Mark Glines has confirmed that it fixes his problem. Signed-off-by:
-
Miklos Szeredi authored
[upstream commit 1a823ac9 ] I added a nasty local variable shadowing bug to fuse in 2.6.24, with the result, that the 'default_permissions' mount option is basically ignored. How did this happen? - old err declaration in inner scope - new err getting declared in outer scope - 'return err' from inner scope getting removed - old declaration not being noticed -Wshadow would have saved us, but it doesn't seem practical for the kernel :( More testing would have also saved us :(( Signed-off-by:
Miklos Szeredi <mszeredi@suse.cz> Signed-off-by:
-
Sebastian Siewior authored
[ Upstream commit: 6212f2c7 ] The XTS blockmode uses a copy of the IV which is saved on the stack and may or may not be properly aligned. If it is not, it will break hardware cipher like the geode or padlock. This patch encrypts the IV in place so we don't have to worry about alignment. Signed-off-by:
Sebastian Siewior <sebastian@breakpoint.cc> Tested-by:
Stefan Hellermann <stefan@the2masters.de> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Joy Latten authored
[ Upstream commit: 2f40a178 ] When using aes-xcbc-mac for authentication in IPsec, the kernel crashes. It seems this algorithm doesn't account for the space IPsec may make in scatterlist for authtag. Thus when crypto_xcbc_digest_update2() gets called, nbytes may be less than sg[i].length. Since nbytes is an unsigned number, it wraps at the end of the loop allowing us to go back into loop and causing crash in memcpy. I used update function in digest.c to model this fix. Please let me know if it looks ok. Signed-off-by:
Joy Latten <latten@austin.ibm.com> Signed-off-by:
-
Jeff Garzik authored
commit 2551a13e Signed-off-by:
Jeff Garzik <jgarzik@redhat.com> Acked-by:
-
Jan Beulich authored
commit e9427101 Its previous use in a call to on_each_cpu() was pointless, as at the time that code gets executed only one CPU is online. Further, the function can be __cpuinit, and for this to work without CONFIG_HOTPLUG_CPU setup_nmi() must also get an attribute (this one can even be __init; on 64-bits check_timer() also was lacking that attribute). Signed-off-by:
Jan Beulich <jbeulich@novell.com> Signed-off-by:
-
James Bottomley authored
commit: e88a0c2c Date: Sun, 9 Mar 2008 11:57:56 -0500 Subject: drivers: fix dma_get_required_mask There's a bug in the current implementation of dma_get_required_mask() where it ands the returned mask with the current device mask. This rather defeats the purpose if you're using the call to determine what your mask should be (since you will at that time have the default DMA_32BIT_MASK). This bug results in any driver that uses this function *always* getting a 32 bit mask, which is wrong. Fix by removing the and with dev->dma_mask. Signed-off-by:
-
Nick Piggin authored
commit: f7009264 iov_iter_advance() skips over zero-length iovecs, however it does not properly terminate at the end of the iovec array. Fix this by checking against i->count before we skip a zero-length iov. The bug was reproduced with a test program that continually randomly creates iovs to writev. The fix was also verified with the same program and also it could verify that the correct data was contained in the file after each writev. Signed-off-by:
Nick Piggin <npiggin@suse.de> Tested-by:
"Kevin Coffman" <kwc@citi.umich.edu> Cc: "Alexey Dobriyan" <adobriyan@gmail.com> Signed-off-by:
-
Aurelien Jarno authored
x86: Clear DF before calling signal handler The Linux kernel currently does not clear the direction flag before calling a signal handler, whereas the x86/x86-64 ABI requires that. This become a real problem with gcc version 4.3, which assumes that the direction flag is correctly cleared at the entry of a function. This patches changes the setup_frame() functions to clear the direction before entering the signal handler. This is a backport of patch e40cd10c ("x86: clear DF before calling signal handler") that has been applied in 2.6.25-rc. Signed-off-by:
Aurelien Jarno <aurelien@aurel32.net> Signed-off-by:
-
