- 16 Nov, 2007 15 commits
-
-
Greg Kroah-Hartman authored
-
Jens Axboe authored
patch 6eca9004 in mainline. For the locking to work, only the tag map and tag bit map may be shared (incidentally, I was just explaining this to Nick yesterday, but I apparently didn't review the code well enough myself). But we also share the busy list! The busy_list must be queue private, or we need a block_queue_tag covering lock as well. So we have to move the busy_list to the queue. This'll work fine, and it'll actually also fix a problem with blk_queue_invalidate_tags() which will invalidate tags across all shared queues. This is a bit confusing, the low level driver should call it for each queue seperately since otherwise you cannot kill tags on just a single queue for eg a hard drive that stops responding. Since the function has no callers currently, it's not an issue. This is fixed with commit 6eca9004 in Linus' tree. Signed-off-by:
Jens Axboe <jens.axboe@oracle.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Hugh Dickins authored
patch 487e9bf2 in mainline. It's possible to provoke unionfs (not yet in mainline, though in mm and some distros) to hit shmem_writepage's BUG_ON(page_mapped(page)). I expect it's possible to provoke the 2.6.23 ecryptfs in the same way (but the 2.6.24 ecryptfs no longer calls lower level's ->writepage). This came to light with the recent find that AOP_WRITEPAGE_ACTIVATE could leak from tmpfs via write_cache_pages and unionfs to userspace. There's already a fix (e4230030 - writeback: don't propagate AOP_WRITEPAGE_ACTIVATE) in the tree for that, and it's okay so far as it goes; but insufficient because it doesn't address the underlying issue, that shmem_writepage expects to be called only by vmscan (relying on backing_dev_info capabilities to prevent the normal writeback path from ever approaching it). That's an increasingly fragile assumption, and ramdisk_writepage (the other source of AOP_WRITEPAGE_ACTIVATEs) is already careful to check wbc->for_reclaim before returning it. Make the same check in shmem_writepage, thereby sidestepping the page_mapped BUG also. Signed-off-by:
Hugh Dickins <hugh@veritas.com> Cc: Erez Zadok <ezk@cs.sunysb.edu> Reviewed-by:
Pekka Enberg <penberg@cs.helsinki.fi> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
David Miller authored
[FUTEX]: Fix address computation in compat code. [ Upstream commit: 3c5fd9c7 ] compat_exit_robust_list() computes a pointer to the futex entry in userspace as follows: (void __user *)entry + futex_offset 'entry' is a 'struct robust_list __user *', and 'futex_offset' is a 'compat_long_t' (typically a 's32'). Things explode if the 32-bit sign bit is set in futex_offset. Type promotion sign extends futex_offset to a 64-bit value before adding it to 'entry'. This triggered a problem on sparc64 running 32-bit applications which would lock up a cpu looping forever in the fault handling for the userspace load in handle_futex_death(). Compat userspace runs with address masking (wherein the cpu zeros out the top 32-bits of every effective address given to a memory operation instruction) so the sparc64 fault handler accounts for this by zero'ing out the top 32-bits of the fault address too. Since the kernel properly uses the compat_uptr interfaces, kernel side accesses to compat userspace work too since they will only use addresses with the top 32-bit clear. Because of this compat futex layer bug we get into the following loop when executing the get_user() load near the top of handle_futex_death(): 1) load from address '0xfffffffff7f16bd8', FAULT 2) fault handler clears upper 32-bits, processes fault for address '0xf7f16bd8' which succeeds 3) goto #1 I want to thank Bernd Zeimetz, Josip Rodin, and Fabio Massimo Di Nitto for their tireless efforts helping me track down this bug. Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Frans Pop authored
sched: keep utime/stime monotonic cpustats use utime/stime as a ratio against sum_exec_runtime, as a consequence it can happen - when the ratio changes faster than time accumulates - that either can be appear to go backwards. Combined backport for 2.6.23 of the following patches from mainline: commit 73a2bcb0 Author: Peter Zijlstra <a.p.zijlstra@chello.nl> sched: keep utime/stime monotonic commit 9301899b Author: Balbir Singh <balbir@linux.vnet.ibm.com> sched: fix /proc/<PID>/stat stime/utime monotonicity, part 2 Signed-off-by:
Frans Pop <elendil@planet.nl> CC: Peter Zijlstra <a.p.zijlstra@chello.nl> CC: Balbir Singh <balbir@linux.vnet.ibm.com> Signed-off-by:
-
Ingo Molnar authored
patch a115d5ca in mainline. this Xen related commit: commit 966812dc Author: Jeremy Fitzhardinge <jeremy@goop.org> Date: Tue May 8 00:28:02 2007 -0700 Ignore stolen time in the softlockup watchdog broke the softlockup watchdog to never report any lockups. (!) print_timestamp defaults to 0, this makes the following condition always true: if (print_timestamp < (touch_timestamp + 1) || and we'll in essence never report soft lockups. apparently the functionality of the soft lockup watchdog was never actually tested with that patch applied ... Signed-off-by:
Ingo Molnar <mingo@elte.hu> Cc: Jeremy Fitzhardinge <jeremy@goop.org> Signed-off-by:
-
Jens Axboe authored
patch 6866bef4 in mainline. The out label should not include the unmap, the only way to jump there already has unmapped the source. 00002000 f7c21a00 00000000 00000000 c0489036 00018e32 00000002 00000000 00001000 Call Trace: [<c0487dd9>] pipe_to_user+0xca/0xd3 [<c0488233>] __splice_from_pipe+0x53/0x1bd [<c0454947>] ------------[ cut here ]------------ filemap_fault+0x221/0x380 [<c0487d0f>] pipe_to_user+0x0/0xd3 [<c0489036>] sys_vmsplice+0x3b7/0x422 [<c045ec3f>] kernel BUG at mm/highmem.c:206! handle_mm_fault+0x4d5/0x8eb [<c041ed5b>] kmap_atomic+0x1c/0x20 [<c045d33d>] unmap_vmas+0x3d1/0x584 [<c045f717>] free_pgtables+0x90/0xa0 [<c041d84b>] pgd_dtor+0x0/0x1 [<c044d665>] audit_syscall_exit+0x2aa/0x2c6 [<c0407817>] do_syscall_trace+0x124/0x169 [<c0404df2>] syscall_call+0x7/0xb ======================= Code: 2d 00 d0 5b 00 25 00 00 e0 ff 29 invalid opcode: 0000 [#1] c2 89 d0 c1 e8 0c 8b 14 85 a0 6c 7c c0 4a 85 d2 89 14 85 a0 6c 7c c0 74 07 31 c9 4a 75 15 eb 04 <0f> 0b eb fe 31 c9 81 3d 78 38 6d c0 78 38 6d c0 0f 95 c1 b0 01 EIP: [<c045bbc3>] kunmap_high+0x51/0x8e SS:ESP 0068:f5960df0 SMP Modules linked in: netconsole autofs4 hidp nfs lockd nfs_acl rfcomm l2cap bluetooth sunrpc ipv6 ib_iser rdma_cm ib_cm iw_cmib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi scsi_transport_iscsi dm_mirror dm_multipath dm_mod video output sbs batteryac parport_pc lp parport sg i2c_piix4 i2c_core floppy cfi_probe gen_probe scb2_flash mtd chipreg tg3 e1000 button ide_cd serio_raw cdrom aic7xxx scsi_transport_spi sd_mod scsi_mod ext3 jbd ehci_hcd ohci_hcd uhci_hcd CPU: 3 EIP: 0060:[<c045bbc3>] Not tainted VLI EFLAGS: 00010246 (2.6.23 #1) EIP is at kunmap_high+0x51/0x8e Signed-off-by:
-
Andrew Morton authored
patch e4230030 in mainline. This is a writeback-internal marker but we're propagating it all the way back to userspace!. Signed-off-by:
-
Christoph Lameter authored
patch 05aa3450 in mainline. SLUB: Fix memory leak by not reusing cpu_slab Fix the memory leak that may occur when we attempt to reuse a cpu_slab that was allocated while we reenabled interrupts in order to be able to grow a slab cache. The per cpu freelist may contain objects and in that situation we may overwrite the per cpu freelist pointer loosing objects. This only occurs if we find that the concurrently allocated slab fits our allocation needs. If we simply always deactivate the slab then the freelist will be properly reintegrated and the memory leak will go away. Signed-off-by:
Christoph Lameter <clameter@sgi.com> Cc: Hugh Dickins <hugh@veritas.com> Signed-off-by:
-
Tsugikazu Shibata authored
patch 3b6662f1 upstream. Here is another sync patch of Documentation/ja_JP/HOWTO Japanese developer sent me some cosmetic changes and also follow changes of HOWTO Cross reference URL (sosdg.org/qiyong/lxr) known_regression explanations on kernel dev. process Signed-off-by:
Tsugikazu Shibata <tshibata@ab.jp.nec.com> Signed-off-by:
-
Jan Kiszka authored
patch 22800a28 in mainline. Commit faf8c714 caused a regression: parameter names longer than MAX_KBUILD_MODNAME will now be rejected, although we just need to keep the module name part that short. This patch restores the old behaviour while still avoiding that memchr is called with its length parameter larger than the total string length. Signed-off-by:
Jan Kiszka <jan.kiszka@web.de> Cc: Dave Young <hidave.darkstar@gmail.com> Signed-off-by:
-
Dave Young authored
patch faf8c714 in mainline. If memchr argument is longer than strlen(kp->name), there will be some weird result. It will casuse duplicate filenames in sysfs for the "nousb". kernel warning messages are as bellow: sysfs: duplicate filename 'usbcore' can not be created WARNING: at fs/sysfs/dir.c:416 sysfs_add_one() [<c01c4750>] sysfs_add_one+0xa0/0xe0 [<c01c4ab8>] create_dir+0x48/0xb0 [<c01c4b69>] sysfs_create_dir+0x29/0x50 [<c024e0fb>] create_dir+0x1b/0x50 [<c024e3b6>] kobject_add+0x46/0x150 [<c024e2da>] kobject_init+0x3a/0x80 [<c053b880>] kernel_param_sysfs_setup+0x50/0xb0 [<c053b9ce>] param_sysfs_builtin+0xee/0x130 [<c053ba33>] param_sysfs_init+0x23/0x60 [<c024d062>] __next_cpu+0x12/0x20 [<c052aa30>] kernel_init+0x0/0xb0 [<c052aa30>] kernel_init+0x0/0xb0 [<c052a856>] do_initcalls+0x46/0x1e0 [<c01bdb12>] create_proc_entry+0x52/0x90 [<c0158d4c>] register_irq_proc+0x9c/0xc0 [<c01bda94>] proc_mkdir_mode+0x34/0x50 [<c052aa30>] kernel_init+0x0/0xb0 [<c052aa92>] kernel_init+0x62/0xb0 [<c0104f83>] kernel_thread_helper+0x7/0x14 ======================= kobject_add failed for usbcore with -EEXIST, don't try to register things with the same name in the same directory. [<c024e466>] kobject_add+0xf6/0x150 [<c053b880>] kernel_param_sysfs_setup+0x50/0xb0 [<c053b9ce>] param_sysfs_builtin+0xee/0x130 [<c053ba33>] param_sysfs_init+0x23/0x60 [<c024d062>] __next_cpu+0x12/0x20 [<c052aa30>] kernel_init+0x0/0xb0 [<c052aa30>] kernel_init+0x0/0xb0 [<c052a856>] do_initcalls+0x46/0x1e0 [<c01bdb12>] create_proc_entry+0x52/0x90 [<c0158d4c>] register_irq_proc+0x9c/0xc0 [<c01bda94>] proc_mkdir_mode+0x34/0x50 [<c052aa30>] kernel_init+0x0/0xb0 [<c052aa92>] kernel_init+0x62/0xb0 [<c0104f83>] kernel_thread_helper+0x7/0x14 ======================= Module 'usbcore' failed to be added to sysfs, error number -17 The system will be unstable now. Signed-off-by:
Dave Young <hidave.darkstar@gmail.com> Cc: Greg KH <greg@kroah.com> Signed-off-by:
-
Linus Torvalds authored
The kernel has for random historical reasons allowed ptrace() accesses to access (and insert) pages into the page cache above the size of the file. However, Nick broke that by mistake when doing the new fault handling in commit 54cb8821 ("mm: merge populate and nopage into fault (fixes nonlinear)". The breakage caused a hang with gdb when trying to access the invalid page. The ptrace "feature" really isn't worth resurrecting, since it really is wrong both from a portability _and_ from an internal page cache validity standpoint. So this removes those old broken remnants, and fixes the ptrace() hang in the process. Noticed and bisected by Duane Griffin, who also supplied a test-case (quoth Nick: "Well that's probably the best bug report I've ever had, thanks Duane!"). Cc: Duane Griffin <duaneg@dghda.com> Acked-by:
Nick Piggin <npiggin@suse.de> Signed-off-by:
-
J. Bruce Fields authored
patch 97855b49 in mainline. It's currently possible to send posix_locks_deadlock() into an infinite loop (under the BKL). For now, fix this just by bailing out after a few iterations. We may want to fix this in a way that better clarifies the semantics of deadlock detection. But that will take more time, and this minimal fix is probably adequate for any realistic scenario, and is simple enough to be appropriate for applying to stable kernels now. Thanks to George Davis for reporting the problem. Cc: "George G. Davis" <gdavis@mvista.com> Signed-off-by:
J. Bruce Fields <bfields@citi.umich.edu> Acked-by:
Alan Cox <alan@redhat.com> Signed-off-by:
-
Gregory Haskins authored
patch 3aa416b0 in mainline. It is possible for the current->curr_chain_key to become inconsistent with the current index if the chain fails to validate. The end result is that future lock_acquire() operations may inadvertently fail to find a hit in the cache resulting in a new node being added to the graph for every acquire. Signed-off-by:
Gregory Haskins <ghaskins@novell.com> Signed-off-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by:
-
- 12 Oct, 2007 2 commits
-
-
Greg Kroah-Hartman authored
-
Jeff Garzik authored
commit 6c08772e in mainline. * corruption fix: we only want the lower 16 bits of length (0 == 64kb) * ditto: the upper layer sets max-phys-segments to LIBATA_MAX_PRD, so we must reset it to own hw-specific length. * delete unused mv_fill_sg() return value Signed-off-by:
Jeff Garzik <jgarzik@redhat.com> Signed-off-by:
-
- 09 Oct, 2007 7 commits
-
-
Linus Torvalds authored
-
git://ftp.linux-mips.org/pub/scm/upstream-linusLinus Torvalds authored
* 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus: [MIPS] Au1000: set the PCI controller IO base [MIPS] Alchemy: Fix USB initialization. [MIPS] IP32: Fix fatal typo in address computation.
-
Trond Myklebust authored
The recent fix for a circular lock dependency unfortunately introduced a potential memory leak in the event where the call to nlmsvc_lookup_host fails for some reason. Thanks to Roel Kluin for spotting this. Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by:
-
Jeff Garzik authored
The recent mv_fill_sg() rewrite, to fix a data corruption problem related to IOMMU virtual merging, forgot to account for the potentially-increased size of the scatter/gather table after its run. Additionally, the DMA boundary is reduced from 0xffffffff to 0xffff to more closely match the needs of mv_fill_sg(). Signed-off-by:
-
Florian Fainelli authored
The PCI controller IO base was not set in the au1000 pci code. Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
John Crispin <blogic@openwrt.org> Signed-off-by:
Florian Fainelli <florian.fainelli@telecomint.eu> Signed-off-by:
Ralf Baechle <ralf@linux-mips.org>
-
Florian Fainelli authored
This patch fixes a wrong ifdef in the board setup code, leading to the GPIO pin not being pulled high, and thus the USB switch not being powered at all. This finishes the rename of CONFIG_USB_OHCI to CONFIG_USB_OHCI_HCD, which started in 2005 (before 2.6.12-rc2), then probably because things were working anyway for most people got forgotten. [Ralf: Paolo's original patch didn't fix the module case, Florian's patch only fixed MTX1 etc. so this is a combined patch plus some cleanups.] Cc: Giuseppe Patanè <giuseppe.patane@tvblob.com> Cc: Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by:
-
Giuseppe Sacco authored
Signed-off-by:
Giuseppe Sacco <eppesuig@debian.org> Signed-off-by:
-
- 08 Oct, 2007 11 commits
-
-
Maarten Bressers authored
When building a custom keymap, after setting GENERATE_KEYMAP := 1 in drivers/char/Makefile, the kernel build fails like this: CC drivers/char/vt.o make[2]: *** No rule to make target `drivers/char/%.map', needed by `drivers/char/defkeymap.c'. Stop. make[1]: *** [drivers/char] Error 2 make: *** [drivers] Error 2 This was caused by commit af8b1287, which deleted a necessary colon from the Makefile rule that generates the keymap, since that rule contains both a target and a target-pattern. The following patch puts the colon back: Signed-off-by:Maarten Bressers <mbres@gentoo.org> Cc: Yoichi Yuasa <yoichi_yuasa@tripeaks.co.jp> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
-
Karsten Keil authored
Fix against access random data bytes outside the dev->chanmap array. Thanks to Oliver Neukum for pointing me to this issue. Signed-off-by:
Karsten Keil <kkeil@suse.de> Signed-off-by:
-
Linus Torvalds authored
* 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6: [IPv6]: Fix ICMPv6 redirect handling with target multicast address [PKT_SCHED] cls_u32: error code isn't been propogated properly [ROSE]: Fix rose.ko oops on unload [TCP]: Fix fastpath_cnt_hint when GSO skb is partially ACKed
-
Yan Zheng authored
When IOCB_FLAG_RESFD flag is set and iocb->aio_resfd is incorrect, statement 'goto out_put_req' is executed. At label 'out_put_req', aio_put_req(..) is called, which requires 'req->ki_filp' set. Signed-off-by: Yan Zheng<yanzheng@21cn.com> Cc: Zach Brown <zach.brown@oracle.com> Signed-off-by:
-
Yan Zheng authored
find_lock_page increases page's usage count, we should decrease it before return VM_FAULT_SIGBUS Signed-off-by: Yan Zheng<yanzheng@21cn.com> Cc: Nick Piggin <nickpiggin@yahoo.com.au> Signed-off-by:
-
Yan Zheng authored
The test for VM_CAN_NONLINEAR always fails Signed-off-by: Yan Zheng<yanzheng@21cn.com> Signed-off-by:
-
Peter Zijlstra authored
All the current page_mkwrite() implementations also set the page dirty. Which results in the set_page_dirty_balance() call to _not_ call balance, because the page is already found dirty. This allows us to dirty a _lot_ of pages without ever hitting balance_dirty_pages(). Not good (tm). Force a balance call if ->page_mkwrite() was successful. Signed-off-by:
-
Brian Haley authored
When the ICMPv6 Target address is multicast, Linux processes the redirect instead of dropping it. The problem is in this code in ndisc_redirect_rcv(): if (ipv6_addr_equal(dest, target)) { on_link = 1; } else if (!(ipv6_addr_type(target) & IPV6_ADDR_LINKLOCAL)) { ND_PRINTK2(KERN_WARNING "ICMPv6 Redirect: target address is not link-local.\n"); return; } This second check will succeed if the Target address is, for example, FF02::1 because it has link-local scope. Instead, it should be checking if it's a unicast link-local address, as stated in RFC 2461/4861 Section 8.1: - The ICMP Target Address is either a link-local address (when redirected to a router) or the same as the ICMP Destination Address (when redirected to the on-link destination). I know this doesn't explicitly say unicast link-local address, but it's implied. This bug is preventing Linux kernels from achieving IPv6 Logo Phase II certification because of a recent error that was found in the TAHI test suite - Neighbor Disovery suite test 206 (v6LC.2.3.6_G) had the multicast address in the Destination field instead of Target field, so we were passing the test. This won't be the case anymore. The patch below fixes this problem, and also fixes ndisc_send_redirect() to not send an invalid redirect with a multicast address in the Target field. I re-ran the TAHI Neighbor Discovery section to make sure Linux passes all 245 tests now. Signed-off-by:Brian Haley <brian.haley@hp.com> Acked-by:
David L Stevens <dlstevens@us.ibm.com> Signed-off-by:
-
Stephen Hemminger authored
Signed-off-by:
Stephen Hemminger <shemminger@linux-foundation.org> Signed-off-by:
-
Alexey Dobriyan authored
Commit a3d38402 aka "[AX.25]: Fix unchecked rose_add_loopback_neigh uses" transformed rose_loopback_neigh var into statically allocated one. However, on unload it will be kfree's which can't work. Steps to reproduce: modprobe rose rmmod rose BUG: unable to handle kernel NULL pointer dereference at virtual address 00000008 printing eip: c014c664 *pde = 00000000 Oops: 0000 [#1] PREEMPT DEBUG_PAGEALLOC Modules linked in: rose ax25 fan ufs loop usbhid rtc snd_intel8x0 snd_ac97_codec ehci_hcd ac97_bus uhci_hcd thermal usbcore button processor evdev sr_mod cdrom CPU: 0 EIP: 0060:[<c014c664>] Not tainted VLI EFLAGS: 00210086 (2.6.23-rc9 #3) EIP is at kfree+0x48/0xa1 eax: 00000556 ebx: c1734aa0 ecx: f6a5e000 edx: f7082000 esi: 00000000 edi: f9a55d20 ebp: 00200287 esp: f6a5ef28 ds: 007b es: 007b fs: 0000 gs: 0033 ss: 0068 Process rmmod (pid: 1823, ti=f6a5e000 task=f7082000 task.ti=f6a5e000) Stack: f9a55d20 f9a5200c 00000000 00000000 00000000 f6a5e000 f9a5200c f9a55a00 00000000 bf818cf0 f9a51f3f f9a55a00 00000000 c0132c60 65736f72 00000000 f69f9630 f69f9528 c014244a f6a4e900 00200246 f7082000 c01025e6 00000000 Call Trace: [<f9a5200c>] rose_rt_free+0x1d/0x49 [rose] [<f9a5200c>] rose_rt_free+0x1d/0x49 [rose] [<f9a51f3f>] rose_exit+0x4c/0xd5 [rose] [<c0132c60>] sys_delete_module+0x15e/0x186 [<c014244a>] remove_vma+0x40/0x45 [<c01025e6>] sysenter_past_esp+0x8f/0x99 [<c012bacf>] trace_hardirqs_on+0x118/0x13b [<c01025b6>] sysenter_past_esp+0x5f/0x99 ======================= Code: 05 03 1d 80 db 5b c0 8b 03 25 00 40 02 00 3d 00 40 02 00 75 03 8b 5b 0c 8b 73 10 8b 44 24 18 89 44 24 04 9c 5d fa e8 77 df fd ff <8b> 56 08 89 f8 e8 84 f4 fd ff e8 bd 32 06 00 3b 5c 86 60 75 0f EIP: [<c014c664>] kfree+0x48/0xa1 SS:ESP 0068:f6a5ef28 Signed-off-by:
Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by:
-
Ilpo Järvinen authored
When only GSO skb was partially ACKed, no hints are reset, therefore fastpath_cnt_hint must be tweaked too or else it can corrupt fackets_out. The corruption to occur, one must have non-trivial ACK/SACK sequence, so this bug is not very often that harmful. There's a fackets_out state reset in TCP because fackets_out is known to be inaccurate and that fixes the issue eventually anyway. In case there was also at least one skb that got fully ACKed, the fastpath_skb_hint is set to NULL which causes a recount for fastpath_cnt_hint (the old value won't be accessed anymore), thus it can safely be decremented without additional checking. Reported by Cedric Le Goater <clg@fr.ibm.com> Signed-off-by:
Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Signed-off-by:
-
- 07 Oct, 2007 5 commits
-
-
Dmitry Torokhov authored
We should only reparent to a class former class devices that form the base of class hierarchy. Nested devices should still grow from their real parents. Signed-off-by:
Dmitry Torokhov <dtor@mail.ru> Tested-by:
Andrey Borzenkov <arvidjaar@mail.ru> Tested-by:
Anssi Hannula <anssi.hannula@gmail.com> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6Linus Torvalds authored
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6: firewire: point to migration document
-
Attila Kinali authored
Add the manufacturer and card id of teltonica pcmcia modems to serial_cs.c Signed-off-by:
Attila Kinali <attila@kinali.ch> Acked-by:
-
Pavel Machek authored
Document sequence of keypresses that actually works. Yes, this changed year-or-so ago. Signed-off-by:
Pavel Machek <pavel@suse.cz> Signed-off-by:
-
Al Viro authored
Async signals should not be reported as sent by current in audit log. As it is, we call audit_signal_info() too early in check_kill_permission(). Note that check_kill_permission() has that test already - it needs to know if it should apply current-based permission checks. So the solution is to move the call of audit_signal_info() between those. Bogosity in question is easily reproduced - add a rule watching for e.g. kill(2) from specific process (so that audit_signal_info() would not short-circuit to nothing), say load_policy, watch the bogus OBJ_PID entry in audit logs claiming that write(2) on selinuxfs file issued by load_policy(8) had somehow managed to send a signal to syslogd... Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Acked-by:
Steve Grubb <sgrubb@redhat.com> Acked-by:
Eric Paris <eparis@redhat.com> Signed-off-by:
-
