1. 09 9月, 2007 2 次提交
  2. 18 5月, 2007 1 次提交
  3. 05 5月, 2007 1 次提交
    • M
      [Bluetooth] Fix L2CAP and HCI setsockopt() information leaks · 0878b666
      Marcel Holtmann 提交于
      The L2CAP and HCI setsockopt() implementations have a small information
      leak that makes it possible to leak kernel stack memory to userspace.
      
      If the optlen parameter is 0, no data will be copied by copy_from_user(),
      but the uninitialized stack buffer will be read and stored later. A call
      to getsockopt() can now retrieve the leaked information.
      
      To fix this problem the stack buffer given to copy_from_user() must be
      initialized with the current settings.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      0878b666
  4. 26 4月, 2007 1 次提交
  5. 08 3月, 2007 1 次提交
    • J
      [PATCH] bluetooth: fix socket locking in hci_sock_dev_event() · b40df574
      Jiri Kosina 提交于
      [Bluetooth] Fix socket locking in hci_sock_dev_event()
      
      hci_sock_dev_event() uses bh_lock_sock() to lock the socket lock.
      This is not deadlock-safe against locking of the same socket lock in
      l2cap_connect_cfm() from softirq context. In addition to that,
      hci_sock_dev_event() doesn't seem to be called from softirq context,
      so it is safe to use lock_sock()/release_sock() instead.
      
      The lockdep warning can be triggered on my T42p simply by switching
      the Bluetooth off by the keyboard button.
      
        =================================
        [ INFO: inconsistent lock state ]
        2.6.21-rc2 #4
        ---------------------------------
        inconsistent {in-softirq-W} -> {softirq-on-W} usage.
        khubd/156 [HC0[0]:SC0[0]:HE1:SE1] takes:
         (slock-AF_BLUETOOTH){-+..}, at: [<e0ca5520>] hci_sock_dev_event+0xa8/0xc5 [bluetooth]
        {in-softirq-W} state was registered at:
          [<c012d1db>] mark_lock+0x59/0x414
          [<e0cef688>] l2cap_connect_cfm+0x4e/0x11f [l2cap]
          [<c012dfd7>] __lock_acquire+0x3e5/0xb99
          [<e0cef688>] l2cap_connect_cfm+0x4e/0x11f [l2cap]
          [<c012e7f2>] lock_acquire+0x67/0x81
          [<e0cef688>] l2cap_connect_cfm+0x4e/0x11f [l2cap]
          [<c036ee72>] _spin_lock+0x29/0x34
          [<e0cef688>] l2cap_connect_cfm+0x4e/0x11f [l2cap]
          [<e0cef688>] l2cap_connect_cfm+0x4e/0x11f [l2cap]
          [<e0ca17c3>] hci_send_cmd+0x126/0x14f [bluetooth]
          [<e0ca4ce4>] hci_event_packet+0x729/0xebd [bluetooth]
          [<e0ca205b>] hci_rx_task+0x2a/0x20f [bluetooth]
          [<e0ca209d>] hci_rx_task+0x6c/0x20f [bluetooth]
          [<c012d7be>] trace_hardirqs_on+0x10d/0x14e
          [<c011ac85>] tasklet_action+0x3d/0x68
          [<c011abba>] __do_softirq+0x41/0x92
          [<c011ac32>] do_softirq+0x27/0x3d
          [<c0105134>] do_IRQ+0x7b/0x8f
          [<c0103dec>] common_interrupt+0x24/0x34
          [<c0103df6>] common_interrupt+0x2e/0x34
          [<c0248e65>] acpi_processor_idle+0x1b3/0x34a
          [<c0248e68>] acpi_processor_idle+0x1b6/0x34a
          [<c010232b>] cpu_idle+0x39/0x4e
          [<c04bab0c>] start_kernel+0x372/0x37a
          [<c04ba42b>] unknown_bootoption+0x0/0x202
          [<ffffffff>] 0xffffffff
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      Acked-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b40df574
  6. 15 2月, 2007 1 次提交
    • T
      [PATCH] remove many unneeded #includes of sched.h · cd354f1a
      Tim Schmielau 提交于
      After Al Viro (finally) succeeded in removing the sched.h #include in module.h
      recently, it makes sense again to remove other superfluous sched.h includes.
      There are quite a lot of files which include it but don't actually need
      anything defined in there.  Presumably these includes were once needed for
      macros that used to live in sched.h, but moved to other header files in the
      course of cleaning it up.
      
      To ease the pain, this time I did not fiddle with any header files and only
      removed #includes from .c-files, which tend to cause less trouble.
      
      Compile tested against 2.6.20-rc2 and 2.6.20-rc2-mm2 (with offsets) on alpha,
      arm, i386, ia64, mips, powerpc, and x86_64 with allnoconfig, defconfig,
      allmodconfig, and allyesconfig as well as a few randconfigs on x86_64 and all
      configs in arch/arm/configs on arm.  I also checked that no new warnings were
      introduced by the patch (actually, some warnings are removed that were emitted
      by unnecessarily included header files).
      Signed-off-by: NTim Schmielau <tim@physik3.uni-rostock.de>
      Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      cd354f1a
  7. 11 2月, 2007 1 次提交
  8. 14 12月, 2006 1 次提交
  9. 22 11月, 2006 1 次提交
  10. 16 10月, 2006 1 次提交
  11. 01 7月, 2006 1 次提交
  12. 13 2月, 2006 1 次提交
  13. 12 1月, 2006 1 次提交
  14. 04 1月, 2006 1 次提交
    • E
      [NET]: move struct proto_ops to const · 90ddc4f0
      Eric Dumazet 提交于
      I noticed that some of 'struct proto_ops' used in the kernel may share
      a cache line used by locks or other heavily modified data. (default
      linker alignement is 32 bytes, and L1_CACHE_LINE is 64 or 128 at
      least)
      
      This patch makes sure a 'struct proto_ops' can be declared as const,
      so that all cpus can share all parts of it without false sharing.
      
      This is not mandatory : a driver can still use a read/write structure
      if it needs to (and eventually a __read_mostly)
      
      I made a global stubstitute to change all existing occurences to make
      them const.
      
      This should reduce the possibility of false sharing on SMP, and
      speedup some socket system calls.
      Signed-off-by: NEric Dumazet <dada1@cosmosbay.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      90ddc4f0
  15. 09 11月, 2005 1 次提交
  16. 29 10月, 2005 1 次提交
  17. 30 8月, 2005 2 次提交
  18. 26 4月, 2005 2 次提交
    • A
      [NET]: kill gratitious includes of major.h · 5523662c
      Al Viro 提交于
      	A lot of places in there are including major.h for no reason
      whatsoever.  Removed.  And yes, it still builds.
      
      	The history of that stuff is often amusing.  E.g. for net/core/sock.c
      the story looks so, as far as I've been able to reconstruct it: we used to
      need major.h in net/socket.c circa 1.1.early.  In 1.1.13 that need had
      disappeared, along with register_chrdev(SOCKET_MAJOR, "socket", &net_fops)
      in sock_init().  Include had not.  When 1.2 -> 1.3 reorg of net/* had moved
      a lot of stuff from net/socket.c to net/core/sock.c, this crap had followed...
      Signed-off-by: NAl Viro <viro@parcelfarce.linux.theplanet.co.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5523662c
    • A
      [PATCH] kill gratitious includes of major.h under net/* · b453257f
      Al Viro 提交于
      A lot of places in there are including major.h for no reason whatsoever.
      Removed.  And yes, it still builds. 
      
      The history of that stuff is often amusing.  E.g.  for net/core/sock.c
      the story looks so, as far as I've been able to reconstruct it: we used
      to need major.h in net/socket.c circa 1.1.early.  In 1.1.13 that need
      had disappeared, along with register_chrdev(SOCKET_MAJOR, "socket",
      &net_fops) in sock_init().  Include had not.  When 1.2 -> 1.3 reorg of
      net/* had moved a lot of stuff from net/socket.c to net/core/sock.c,
      this crap had followed... 
      Signed-off-by: NAl Viro <viro@parcelfarce.linux.theplanet.co.uk>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      b453257f
  19. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4