- 02 May, 2007 32 commits
-
-
Jens Axboe authored
There's a really rare and obscure bug in CFQ, that causes a crash in cfq_dispatch_insert() due to rq == NULL. One example of that is seen here: http://lkml.org/lkml/2007/4/15/41 Neil correctly diagnosed the situation for how this can happen, read that analysis here: http://lkml.org/lkml/2007/4/25/57 This looks like it requires md to trigger, even though it should potentially be possible to due with O_DIRECT (at least if you edit the kernel and doctor some of the unplug calls). The fix is to move the ->next_rq update to when we add a request to the rbtree. Then we remove the possibility for a request to exist in the rbtree code, but not have ->next_rq correctly updated. Signed-off-by:
Jens Axboe <jens.axboe@oracle.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Wang Zhenyu authored
[AGPGART] intel_agp: fix G965 GTT size detect On G965, I810_PGETBL_CTL is a mmio offset, but we wrongly take it as pci config space offset in detecting GTT size. This one line patch fixs this. Signed-off-by:
Wang Zhenyu <zhenyu.z.wang@intel.com> Signed-off-by:
Dave Jones <davej@redhat.com> Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
-
Tommi Kyntola authored
[ALSA] intel8x0 - Fix speaker output after S2RAM Fixed the mute speaker problem after S2RAM on some laptops: http://bugme.osdl.org/show_bug.cgi?id=6181Signed-off-by:
Tommi Kyntola <tommi.kyntola@ray.fi> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Jaroslav Kysela <perex@suse.cz> Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
-
Jean Delvare authored
Users have been complaining about the w83627ehf driver flooding their logs with debug messages like: w83627ehf 9191-0a10: Increasing fan 4 clock divider from 64 to 128 or: w83627ehf 9191-0290: Increasing fan 4 clock divider from 4 to 8 The reason is that we failed to actually write the LSB of the encoded clock divider value for that fan, causing the next read to report the same old value again and again. Additionally, the fan number was improperly reported, making the bug harder to find. Signed-off-by:
Jean Delvare <khali@linux-fr.org> Signed-off-by:
-
Jeff Mahoney authored
The listxattr() and getxattr() operations are only protected by a read lock. As a result, if either of these operations run in parallel, a race condition exists where the xattr_root will end up being cached twice, which results in the leaking of a reference and a BUG() on umount. This patch refactors get_xa_root(), __get_xa_root(), and create_xa_root(), into one get_xa_root() function that takes the appropriate locking around the entire critical section. Reported, diagnosed and tested by Andrea Righi <a.righi@cineca.it> Signed-off-by:
Jeff Mahoney <jeffm@suse.com> Cc: Andrea Righi <a.righi@cineca.it> Cc: "Vladimir V. Saveliev" <vs@namesys.com> Cc: Edward Shishkin <edward@namesys.com> Cc: Alex Zarochentsev <zam@namesys.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Balbir Singh authored
We broke the the alignment of members of taskstats to the 8 byte boundary with the CSA patches. In the current kernel, the taskstats structure is not suitable for use by 32 bit applications in a 64 bit kernel. On x86_64 Offsets of taskstats' members (64 bit kernel, 64 bit application) @taskstats'offsetof[@taskstats'indices] = ( 0, # version 4, # ac_exitcode 8, # ac_flag 9, # ac_nice 16, # cpu_count 24, # cpu_delay_total 32, # blkio_count 40, # blkio_delay_total 48, # swapin_count 56, # swapin_delay_total 64, # cpu_run_real_total 72, # cpu_run_virtual_total 80, # ac_comm 112, # ac_sched 113, # ac_pad 116, # ac_uid 120, # ac_gid 124, # ac_pid 128, # ac_ppid 132, # ac_btime 136, # ac_etime 144, # ac_utime 152, # ac_stime 160, # ac_minflt 168, # ac_majflt 176, # coremem 184, # virtmem 192, # hiwater_rss 200, # hiwater_vm 208, # read_char 216, # write_char 224, # read_syscalls 232, # write_syscalls 240, # read_bytes 248, # write_bytes 256, # cancelled_write_bytes ); Offsets of taskstats' members (64 bit kernel, 32 bit application) @taskstats'offsetof[@taskstats'indices] = ( 0, # version 4, # ac_exitcode 8, # ac_flag 9, # ac_nice 12, # cpu_count 20, # cpu_delay_total 28, # blkio_count 36, # blkio_delay_total 44, # swapin_count 52, # swapin_delay_total 60, # cpu_run_real_total 68, # cpu_run_virtual_total 76, # ac_comm 108, # ac_sched 109, # ac_pad 112, # ac_uid 116, # ac_gid 120, # ac_pid 124, # ac_ppid 128, # ac_btime 132, # ac_etime 140, # ac_utime 148, # ac_stime 156, # ac_minflt 164, # ac_majflt 172, # coremem 180, # virtmem 188, # hiwater_rss 196, # hiwater_vm 204, # read_char 212, # write_char 220, # read_syscalls 228, # write_syscalls 236, # read_bytes 244, # write_bytes 252, # cancelled_write_bytes ); This is one way to solve the problem without re-arranging structure members is to pack the structure. The patch adds an __attribute__((aligned(8))) to the taskstats structure members so that 32 bit applications using taskstats can work with a 64 bit kernel. Using __attribute__((packed)) would break the 64 bit alignment of members. The fix was tested on x86_64. After the fix, we got Offsets of taskstats' members (64 bit kernel, 64 bit application) @taskstats'offsetof[@taskstats'indices] = ( 0, # version 4, # ac_exitcode 8, # ac_flag 9, # ac_nice 16, # cpu_count 24, # cpu_delay_total 32, # blkio_count 40, # blkio_delay_total 48, # swapin_count 56, # swapin_delay_total 64, # cpu_run_real_total 72, # cpu_run_virtual_total 80, # ac_comm 112, # ac_sched 113, # ac_pad 120, # ac_uid 124, # ac_gid 128, # ac_pid 132, # ac_ppid 136, # ac_btime 144, # ac_etime 152, # ac_utime 160, # ac_stime 168, # ac_minflt 176, # ac_majflt 184, # coremem 192, # virtmem 200, # hiwater_rss 208, # hiwater_vm 216, # read_char 224, # write_char 232, # read_syscalls 240, # write_syscalls 248, # read_bytes 256, # write_bytes 264, # cancelled_write_bytes ); Offsets of taskstats' members (64 bit kernel, 32 bit application) @taskstats'offsetof[@taskstats'indices] = ( 0, # version 4, # ac_exitcode 8, # ac_flag 9, # ac_nice 16, # cpu_count 24, # cpu_delay_total 32, # blkio_count 40, # blkio_delay_total 48, # swapin_count 56, # swapin_delay_total 64, # cpu_run_real_total 72, # cpu_run_virtual_total 80, # ac_comm 112, # ac_sched 113, # ac_pad 120, # ac_uid 124, # ac_gid 128, # ac_pid 132, # ac_ppid 136, # ac_btime 144, # ac_etime 152, # ac_utime 160, # ac_stime 168, # ac_minflt 176, # ac_majflt 184, # coremem 192, # virtmem 200, # hiwater_rss 208, # hiwater_vm 216, # read_char 224, # write_char 232, # read_syscalls 240, # write_syscalls 248, # read_bytes 256, # write_bytes 264, # cancelled_write_bytes ); Signed-off-by:Balbir Singh <balbir@linux.vnet.ibm.com> Cc: Jay Lan <jlan@engr.sgi.com> Cc: Shailabh Nagar <nagar@watson.ibm.com> Signed-off-by:
-
Christoph Lameter authored
NR_FILE_PAGES must be accounted for depending on the zone that the page belongs to. If we replace the page in the radix tree then we may have to shift the count to another zone. Suggested-by:
Ethan Solomita <solo@google.com> Cc: Martin Bligh <mbligh@mbligh.org> Signed-off-by:
Christoph Lameter <clameter@sgi.com> Signed-off-by:
-
Taku Izumi authored
I encountered the following kernel panic. The cause of this problem was NULL pointer access in check_modem_status() in 8250.c. I confirmed this problem is fixed by the attached patch, but I don't know this is the correct fix. sadc[4378]: NaT consumption 2216203124768 [1] Modules linked in: binfmt_misc dm_mirror dm_mod thermal processor fan container button sg e100 eepro100 mii ehci_hcd ohci_hcd Pid: 4378, CPU 0, comm: sadc psr : 00001210085a2010 ifs : 8000000000000289 ip : [<a000000100482071>] Not tainted ip is at check_modem_status+0xf1/0x360 unat: 0000000000000000 pfs : 0000000000000289 rsc : 0000000000000003 rnat: 800000000000cc18 bsps: 0000000000000000 pr : 0000000000aa6a99 ldrs: 0000000000000000 ccv : 0000000000000000 fpsr: 0009804c8a70033f csd : 0000000000000000 ssd : 0000000000000000 b0 : a000000100481fb0 b6 : a0000001004822e0 b7 : a000000100477f20 f6 : 1003e2222222222222222 f7 : 0ffdba200000000000000 f8 : 100018000000000000000 f9 : 10002a000000000000000 f10 : 0fffdccccccccc8c00000 f11 : 1003e0000000000000000 r1 : a000000100b9af40 r2 : 0000000000000008 r3 : a000000100ad4e21 r8 : 00000000000000bb r9 : 0000000000000001 r10 : 0000000000000000 r11 : a000000100ad4d58 r12 : e0000000037b7df0 r13 : e0000000037b0000 r14 : 0000000000000001 r15 : 0000000000000018 r16 : a000000100ad4d6c r17 : 0000000000000000 r18 : 0000000000000000 r19 : 0000000000000000 r20 : a00000010099bc88 r21 : 00000000000000bb r22 : 00000000000000bb r23 : c003fffffc0ff3fe r24 : c003fffffc000000 r25 : 00000000000ff3fe r26 : a0000001009b7ad0 r27 : 0000000000000001 r28 : a0000001009b7ad8 r29 : 0000000000000000 r30 : a0000001009b7ad0 r31 : a0000001009b7ad0 Call Trace: [<a000000100013940>] show_stack+0x40/0xa0 sp=e0000000037b7810 bsp=e0000000037b1118 [<a0000001000145a0>] show_regs+0x840/0x880 sp=e0000000037b79e0 bsp=e0000000037b10c0 [<a0000001000368e0>] die+0x1c0/0x2c0 sp=e0000000037b79e0 bsp=e0000000037b1078 [<a000000100036a30>] die_if_kernel+0x50/0x80 sp=e0000000037b7a00 bsp=e0000000037b1048 [<a000000100037c40>] ia64_fault+0x11e0/0x1300 sp=e0000000037b7a00 bsp=e0000000037b0fe8 [<a00000010000bdc0>] ia64_leave_kernel+0x0/0x280 sp=e0000000037b7c20 bsp=e0000000037b0fe8 [<a000000100482070>] check_modem_status+0xf0/0x360 sp=e0000000037b7df0 bsp=e0000000037b0fa0 [<a000000100482300>] serial8250_get_mctrl+0x20/0xa0 sp=e0000000037b7df0 bsp=e0000000037b0f80 [<a000000100478170>] uart_read_proc+0x250/0x860 sp=e0000000037b7df0 bsp=e0000000037b0ee0 [<a0000001001c16d0>] proc_file_read+0x1d0/0x4c0 sp=e0000000037b7e10 bsp=e0000000037b0e80 [<a0000001001394b0>] vfs_read+0x1b0/0x300 sp=e0000000037b7e20 bsp=e0000000037b0e30 [<a000000100139cd0>] sys_read+0x70/0xe0 sp=e0000000037b7e20 bsp=e0000000037b0db0 [<a00000010000bc20>] ia64_ret_from_syscall+0x0/0x20 sp=e0000000037b7e30 bsp=e0000000037b0db0 [<a000000000010620>] __kernel_syscall_via_break+0x0/0x20 sp=e0000000037b8000 bsp=e0000000037b0db0 Fix the possible NULL pointer access in check_modem_status() in 8250.c. The check_modem_status() would access 'info' member of uart_port structure, but it is not initialized before uart_open() is called. The check_modem_status() can be called through /proc/tty/driver/serial before uart_open() is called. Signed-off-by:
Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by:
Taku Izumi <izumi2005@soft.fujitsu.com> Cc: Russell King <rmk@arm.linux.org.uk> Signed-off-by:
-
Hugh Dickins authored
I only have CONFIG_NUMA=y for build testing: surprised when trying a memhog to see lots of other processes killed with "No available memory (MPOL_BIND)". memhog is killed correctly once we initialize nodemask in constrained_alloc(). Signed-off-by:
Hugh Dickins <hugh@veritas.com> Acked-by:
William Irwin <bill.irwin@oracle.com> Acked-by:
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Signed-off-by:
-
Benjamin Herrenschmidt authored
While digging through my MAP_FIXED changes, I found that rather obvious bug in /dev/mem mmap implementation for nommu archs. get_unmapped_area() is expected to return an address, not a pfn. Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Acked-By:
David Howells <dhowells@redhat.com> Signed-off-by:
-
James Bottomley authored
3w-xxxx emulates a REQUEST_SENSE response by simply returning nothing. Unfortunately, it's assuming that the REQUEST_SENSE command is implemented with use_sg == 0, which is no longer the case. The oops occurs because it's clearing the scatterlist in request_buffer instead of the memory region. This is fixed by using tw_transfer_internal() to transfer correctly to the scatterlist. Acked-by:
adam radford <aradford@gmail.com> Signed-off-by:
James Bottomley <James.Bottomley@SteelEye.com> Signed-off-by:
-
Michal Januszewski authored
[PATCH] vt: fix potential race in VT_WAITACTIVE handler On a multiprocessor machine the VT_WAITACTIVE ioctl call may return 0 if fg_console has already been updated in redraw_screen() but the console switch itself hasn't been completed. Fix this by checking fg_console in vt_waitactive() with the console sem held. Signed-off-by:
Michal Januszewski <spock@gentoo.org> Acked-by:
Antonino Daplas <adaplas@pol.net> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
-
Zwane Mwaikambo authored
[PATCH] x86: Don't probe for DDC on VBE1.2 VBE1.2 doesn't support function 15h (DDC) resulting in a 'hang' whilst uncompressing kernel with some video cards. Make sure we check VBE version before fiddling around with DDC. http://bugzilla.kernel.org/show_bug.cgi?id=1458 Opened: 2003-10-30 09:12 Last update: 2007-02-13 22:03 Much thanks to Tobias Hain for help in testing and investigating the bug. Tested on; i386, Chips & Technologies 65548 VESA VBE 1.2 CONFIG_VIDEO_SELECT=Y CONFIG_FIRMWARE_EDID=Y Untested on x86_64. Signed-off-by:
Zwane Mwaikambo <zwane@infradead.org> Signed-off-by:
Andi Kleen <ak@suse.de> Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
-
Trond Myklebust authored
NFS: Fix an Oops in nfs_setattr() It looks like nfs_setattr() and nfs_rename() also need to test whether the target is a regular file before calling nfs_wb_all()... Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by:
-
Alan Cox authored
exec.c: fix coredump to pipe problem and obscure "security hole" The patch checks for "|" in the pattern not the output and doesn't nail a pid on to a piped name (as it is a program name not a file) Also fixes a very very obscure security corner case. If you happen to have decided on a core pattern that starts with the program name then the user can run a program called "|myevilhack" as it stands. I doubt anyone does this. Signed-off-by:
Alan Cox <alan@redhat.com> Confirmed-by:
Christopher S. Aker <caker@theshore.net> Signed-off-by:
-
Badari Pulavarty authored
cache_k8_northbridges() overflows beyond allocation cache_k8_northbridges() is storing config values to incorrect locations (in flush_words) and also its overflowing beyond the allocation, causing slab verification failures. Signed-off-by:
Badari Pulavarty <pbadari@us.ibm.com> Signed-off-by:
-
Olaf Kirch authored
This fixes and OOPS due to incorrect socket orpahning in the IRDA stack. [IrDA]: Correctly handling socket error This patch fixes an oops first reported in mid 2006 - see http://lkml.org/lkml/2006/8/29/358 The cause of this bug report is that when an error is signalled on the socket, irda_recvmsg_stream returns without removing a local wait_queue variable from the socket's sk_sleep queue. This causes havoc further down the road. In response to this problem, a patch was made that invoked sock_orphan on the socket when receiving a disconnect indication. This is not a good fix, as this sets sk_sleep to NULL, causing applications sleeping in recvmsg (and other places) to oops. This is against the latest net-2.6 and should be considered for -stable inclusion. Signed-off-by:
Olaf Kirch <olaf.kirch@oracle.com> Signed-off-by:
Samuel Ortiz <samuel@sortiz.org> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Aubrey.Li authored
Netpoll UDP input handler needs to pull up the UDP headers and handle receive checksum offloading properly just like the normal UDP input path does else we get corrupted checksums. [NET]: Fix UDP checksum issue in net poll mode. In net poll mode, the current checksum function doesn't consider the kind of packet which is padded to reach a specific minimum length. I believe that's the problem causing my test case failed. The following patch fixed this issue. Signed-off-by:
Aubrey.Li <aubreylee@gmail.com> Signed-off-by:
-
John Heffner authored
In 2.6.18 a change was made to the tcp_mem[] calculations, but this causes regressions for some folks up to 2.6.20 The following fix to smooth out the calculation from the pending 2.6.21 tree by John Heffner fixes the problem for these folks. [TCP]: Fix tcp_mem[] initialization. Change tcp_mem initialization function. The fraction of total memory is now a continuous function of memory size, and independent of page size. Signed-off-by:
John Heffner <jheffner@psc.edu> Signed-off-by:
-
Tom "spot" Callaway authored
[SPARC64]: Fix inline directive in pci_iommu.c While building a test kernel for the new esp driver (against git-current), I hit this bug. Trivial fix, put the inline declaration in the right place. :) Signed-off-by:
Tom "spot" Callaway <tcallawa@redhat.com> Signed-off-by:
-
David Miller authored
The 32-bit syscall trampoline for sys_ipc() on sparc64 was sign extending various arguments, which is bogus when using compat_sys_ipc() since that function expects zero extended copies of all the arguments. This bug breaks the sparc64 kernel when built with gcc-4.2.x among other things. [SPARC64]: Fix arg passing to compat_sys_ipc(). Do not sign extend args using the sys32_ipc stub, that is buggy and unnecessary. Based upon an excellent report by Mikael Pettersson. Signed-off-by:
-
David Miller authored
[SCSI] QLOGICPTI: Do not unmap DMA unless we actually mapped something. We only map DMA when cmd->request_bufflen is non-zero for non-sg buffers, we thus should make the same check when unmapping. Based upon a report from Pasi Pirhonen. Signed-off-by:
-
David Miller authored
[SPARC64]: Fix SBUS IOMMU allocation code. There are several IOMMU allocator bugs. Instead of trying to fix this overly complicated code, just mirror the PCI IOMMU arena allocator which is very stable and well stress tested. I tried to make the code as identical as possible so we can switch sun4u PCI and SBUS over to a common piece of IOMMU code. All that will be need are two callbacks, one to do a full IOMMU flush and one to do a streaming buffer flush. This patch gets rid of a lot of hangs and mysterious crashes on SBUS sparc64 systems, at least for me. Signed-off-by:
-
Hugh Dickins authored
sys_madvise has down_write of mmap_sem, then madvise_remove calls vmtruncate_range which takes i_mutex and i_alloc_sem: no, we can easily devise deadlocks from that ordering. madvise_remove drop mmap_sem while calling vmtruncate_range: luckily, since madvise_remove doesn't split or merge vmas, it's easy to handle this case with a NULL prev, without restructuring sys_madvise. (Though sad to retake mmap_sem when it's unlikely to be needed, and certainly down_read is sufficient for MADV_REMOVE, unlike the other madvices.) Signed-off-by:
-
Hugh Dickins authored
shmem_truncate_range has its own truncate_inode_pages_range, to free any pages racily instantiated while it was in progress: a SHMEM_PAGEIN flag is set when this might have happened. But holepunching gets no chance to clear that flag at the start of vmtruncate_range, so it's always set (unless a truncate came just before), so holepunch almost always does this second truncate_inode_pages_range. shmem holepunch has unlikely swap<->file races hereabouts whatever we do (without a fuller rework than is fit for this release): I was going to skip the second truncate in the punch_hole case, but Miklos points out that would make holepunch correctness more vulnerable to swapoff. So keep the second truncate, but follow it by an unmap_mapping_range to eliminate the disconnected pages (freed from pagecache while still mapped in userspace) that it might have left behind. Signed-off-by:
-
Hugh Dickins authored
Miklos Szeredi observes that during truncation of shmem page directories, info->lock is released to improve latency (after lowering i_size and next_index to exclude races); but this is quite wrong for holepunching, which receives no such protection from i_size or next_index, and is left vulnerable to races with shmem_unuse, shmem_getpage and shmem_writepage. Hold info->lock throughout when holepunching? No, any user could prevent rescheduling for far too long. Instead take info->lock just when needed: in shmem_free_swp when removing the swap entries, and whenever removing a directory page from the level above. But so long as we remove before scanning, we can safely skip taking the lock at the lower levels, except at misaligned start and end of the hole. Signed-off-by:
-
Hugh Dickins authored
Miklos Szeredi observes BUG_ON(!entry) in shmem_writepage() triggered in rare circumstances, because shmem_truncate_range() erroneously removes partially truncated directory pages at the end of the range: later reclaim on pages pointing to these removed directories triggers the BUG. Indeed, and it can also cause data loss beyond the hole. Fix this as in the patch proposed by Miklos, but distinguish between "limit" (how far we need to search: ignore truncation's next_index optimization in the holepunch case - if there are races it's more consistent to act on the whole range specified) and "upper_limit" (how far we can free directory pages: generally we must be careful to keep partially punched pages, but can relax at end of file - i_size being held stable by i_mutex). Signed-off-by:
-
Avi Kivity authored
PAGE_MASK is an unsigned long, so using it to mask physical addresses on i386 (which are 64-bit wide) leads to truncation. This can result in page->private of unrelated memory pages being modified, with disasterous results. Fix by not using PAGE_MASK for physical addresses; instead calculate the correct value directly from PAGE_SIZE. Also fix a similar BUG_ON(). Acked-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
Avi Kivity <avi@qumranet.com> Signed-off-by:
-
Avi Kivity authored
KVM shadow page tables are always in pae mode, regardless of the guest setting. This means that a guest pde (mapping 4MB of memory) is mapped to two shadow pdes (mapping 2MB each). When the guest writes to a pte or pde, we intercept the write and emulate it. We also remove any shadowed mappings corresponding to the write. Since the mmu did not account for the doubling in the number of pdes, it removed the wrong entry, resulting in a mismatch between shadow page tables and guest page tables, followed shortly by guest memory corruption. This patch fixes the problem by detecting the special case of writing to a non-pae pde and adjusting the address and number of shadow pdes zapped accordingly. Acked-by:
-
Jiri Kosina authored
HID: zeroing of bytes in output fields is bogus This patch removes bogus zeroing of unused bits in output reports, introduced in Simon's patch in commit d4ae650a. According to the specification, any sane device should not care about values of unused bits. What is worse, the zeroing is done in a way which is broken and might clear certain bits in output reports which are actually _used_ - a device that has multiple fields with one value of the size 1 bit each might serve as an example of why this is bogus - the second call of hid_output_report() would clear the first bit of report, which has already been set up previously. This patch will break LEDs on SpaceNavigator, because this device is broken and takes into account the bits which it shouldn't touch. The quirk for this particular device will be provided in a separate patch. Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Michael S. Tsirkin authored
In mthca_arbel_fmr_unmap(), the high bits of the key are masked off. This gets rid of the effect of adjust_key(), which makes sure that bits 3 and 23 of the key are equal when the Sinai throughput optimization is enabled, and so it may happen that an FMR will end up with bits 3 and 23 in the key being different. This causes data corruption, because when enabling the throughput optimization, the driver promises the HCA firmware that bits 3 and 23 of all memory keys will always be equal. Fix by re-applying adjust_key() after masking the key. Thanks to Or Gerlitz for reproducing the problem, and Ariel Shahar for help in debug. Signed-off-by:
Michael S. Tsirkin <mst@dev.mellanox.co.il> Signed-off-by:
Roland Dreier <rolandd@cisco.com> Signed-off-by:
-
NeilBrown authored
sk_info_authunix is not being protected properly so the object that it points to can be cache_put twice, leading to corruption. We borrow svsk->sk_defer_lock to provide the protection. We should probably rename that lock to have a more generic name - later. Thanks to Gabriel for reporting this. Cc: Greg Banks <gnb@melbourne.sgi.com> Cc: Gabriel Barazer <gabriel@oxeva.fr> Signed-off-by:
Neil Brown <neilb@suse.de> Signed-off-by:
-
- 27 Apr, 2007 3 commits
-
-
Greg Kroah-Hartman authored
-
YOSHIFUJI Hideaki authored
[IPV6]: Fix thinko in ipv6_rthdr_rcv() changes. Signed-off-by:
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Signed-off-by:
-
Sergey Vlasov authored
[IPV4] nl_fib_lookup: Initialise res.r before fib_res_put(&res) When CONFIG_IP_MULTIPLE_TABLES is enabled, the code in nl_fib_lookup() needs to initialize the res.r field before fib_res_put(&res) - unlike fib_lookup(), a direct call to ->tb_lookup does not set this field. Signed-off-by:
Sergey Vlasov <vsu@altlinux.ru> Signed-off-by:
-
- 26 Apr, 2007 2 commits
-
-
Greg Kroah-Hartman authored
-
YOSHIFUJI Hideaki authored
[IPV6]: Disallow RH0 by default. A security issue is emerging. Disallow Routing Header Type 0 by default as we have been doing for IPv4. Note: We allow RH2 by default because it is harmless. Signed-off-by:
-
- 25 Apr, 2007 2 commits
-
-
Greg Kroah-Hartman authored
-
Alexey Kuznetsov authored
[NETLINK]: Infinite recursion in netlink. Reply to NETLINK_FIB_LOOKUP messages were misrouted back to kernel, which resulted in infinite recursion and stack overflow. The bug is present in all kernel versions since the feature appeared. The patch also makes some minimal cleanup: 1. Return something consistent (-ENOENT) when fib table is missing 2. Do not crash when queue is empty (does not happen, but yet) 3. Put result of lookup Signed-off-by:
Alexey Kuznetsov <kuznet@ms2.inr.ac.ru> Signed-off-by:
-
- 13 Apr, 2007 1 commit
-
-
Greg Kroah-Hartman authored
-
