1. 24 Sep, 2008 4 commits
    • Tejun Heo's avatar
      9p-trans_fd: don't do fs segment mangling in p9_fd_poll() · ec3c68f2
      Tejun Heo authored
      p9_fd_poll() is never called with user pointers and f_op->poll()
      doesn't expect its arguments to be from userland.  There's no need to
      set kernel ds before calling f_op->poll() from p9_fd_poll().  Remove
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarEric Van Hensbergen <ericvh@gmail.com>
    • Tejun Heo's avatar
      9p-trans_fd: clean up p9_conn_create() · 571ffeaf
      Tejun Heo authored
      * Use kzalloc() to allocate p9_conn and remove 0/NULL initializations.
      * Clean up error return paths.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarEric Van Hensbergen <ericvh@gmail.com>
    • Tejun Heo's avatar
      9p-trans_fd: fix trans_fd::p9_conn_destroy() · 7dc5d24b
      Tejun Heo authored
      p9_conn_destroy() first kills all current requests by calling
      p9_conn_cancel(), then waits for the request list to be cleared by
      waiting on p9_conn->equeue.  After that, polling is stopped and the
      trans is destroyed.  This sequence has a few problems.
      * Read and write works were never cancelled and the p9_conn can be
        destroyed while the works are running as r/w works remove requests
        from the list and dereference the p9_conn from them.
      * The list emptiness wait using p9_conn->equeue wouldn't trigger
        because p9_conn_cancel() always clears all the lists and the only
        way the wait can be triggered is to have another task to issue a
        request between the slim window between p9_conn_cancel() and the
        wait, which isn't safe under the current implementation with or
        without the wait.
      This patch fixes the problem by first stopping poll, which can
      schedule r/w works, first and cancle r/w works which guarantees that
      r/w works are not and will not run from that point and then calling
      p9_conn_cancel() and do the rest of destruction.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarEric Van Hensbergen <ericvh@gmail.com>
    • Tejun Heo's avatar
      9p: implement proper trans module refcounting and unregistration · 72029fe8
      Tejun Heo authored
      9p trans modules aren't refcounted nor were they unregistered
      properly.  Fix it.
      * Add 9p_trans_module->owner and reference the module on each trans
        instance creation and put it on destruction.
      * Protect v9fs_trans_list with a spinlock.  This isn't strictly
        necessary as the list is manipulated only during module loading /
        unloading but it's a good idea to make the API safe.
      * Unregister trans modules when the corresponding module is being
      * While at it, kill unnecessary EXPORT_SYMBOL on p9_trans_fd_init().
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarEric Van Hensbergen <ericvh@gmail.com>
  2. 18 Sep, 2008 3 commits
  3. 16 Sep, 2008 1 commit
  4. 15 Sep, 2008 1 commit
  5. 11 Sep, 2008 1 commit
    • Marcel Holtmann's avatar
      [Bluetooth] Fix regression from using default link policy · 7c6a329e
      Marcel Holtmann authored
      To speed up the Simple Pairing connection setup, the support for the
      default link policy has been enabled. This is in contrast to settings
      the link policy on every connection setup. Using the default link policy
      is the preferred way since there is no need to dynamically change it for
      every connection.
      For backward compatibility reason and to support old userspace the
      HCISETLINKPOL ioctl has been switched over to using hci_request() to
      issue the HCI command for setting the default link policy instead of
      just storing it in the HCI device structure.
      However the hci_request() can only be issued when the device is
      brought up. If used on a device that is registered, but still down
      it will timeout and fail. This is problematic since the command is
      put on the TX queue and the Bluetooth core tries to submit it to
      hardware that is not ready yet. The timeout for these requests is
      10 seconds and this causes a significant regression when setting up
      a new device.
      The userspace can perfectly handle a failure of the HCISETLINKPOL
      ioctl and will re-submit it later, but the 10 seconds delay causes
      a problem. So in case hci_request() is called on a device that is
      still down, just fail it with ENETDOWN to indicate what happens.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
  6. 09 Sep, 2008 2 commits
  7. 08 Sep, 2008 5 commits
    • Marcel Holtmann's avatar
      [Bluetooth] Reject L2CAP connections on an insecure ACL link · e7c29cb1
      Marcel Holtmann authored
      The Security Mode 4 of the Bluetooth 2.1 specification has strict
      authentication and encryption requirements. It is the initiators job
      to create a secure ACL link. However in case of malicious devices, the
      acceptor has to make sure that the ACL is encrypted before allowing
      any kind of L2CAP connection. The only exception here is the PSM 1 for
      the service discovery protocol, because that is allowed to run on an
      insecure ACL link.
      Previously it was enough to reject a L2CAP connection during the
      connection setup phase, but with Bluetooth 2.1 it is forbidden to
      do any L2CAP protocol exchange on an insecure link (except SDP).
      The new hci_conn_check_link_mode() function can be used to check the
      integrity of an ACL link. This functions also takes care of the cases
      where Security Mode 4 is disabled or one of the devices is based on
      an older specification.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
    • Marcel Holtmann's avatar
      [Bluetooth] Enforce correct authentication requirements · 09ab6f4c
      Marcel Holtmann authored
      With the introduction of Security Mode 4 and Simple Pairing from the
      Bluetooth 2.1 specification it became mandatory that the initiator
      requires authentication and encryption before any L2CAP channel can
      be established. The only exception here is PSM 1 for the service
      discovery protocol (SDP). It is meant to be used without any encryption
      since it contains only public information. This is how Bluetooth 2.0
      and before handle connections on PSM 1.
      For Bluetooth 2.1 devices the pairing procedure differentiates between
      no bonding, general bonding and dedicated bonding. The L2CAP layer
      wrongly uses always general bonding when creating new connections, but it
      should not do this for SDP connections. In this case the authentication
      requirement should be no bonding and the just-works model should be used,
      but in case of non-SDP connection it is required to use general bonding.
      If the new connection requires man-in-the-middle (MITM) protection, it
      also first wrongly creates an unauthenticated link key and then later on
      requests an upgrade to an authenticated link key to provide full MITM
      protection. With Simple Pairing the link key generation is an expensive
      operation (compared to Bluetooth 2.0 and before) and doing this twice
      during a connection setup causes a noticeable delay when establishing
      a new connection. This should be avoided to not regress from the expected
      Bluetooth 2.0 connection times. The authentication requirements are known
      up-front and so enforce them.
      To fulfill these requirements the hci_connect() function has been extended
      with an authentication requirement parameter that will be stored inside
      the connection information and can be retrieved by userspace at any
      time. This allows the correct IO capabilities exchange and results in
      the expected behavior.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
    • Marcel Holtmann's avatar
      [Bluetooth] Fix reference counting during ACL config stage · f1c08ca5
      Marcel Holtmann authored
      The ACL config stage keeps holding a reference count on incoming
      connections when requesting the extended features. This results in
      keeping an ACL link up without any users. The problem here is that
      the Bluetooth specification doesn't define an ownership of the ACL
      link and thus it can happen that the implementation on the initiator
      side doesn't care about disconnecting unused links. In this case the
      acceptor needs to take care of this.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
    • Stephen Hemminger's avatar
      bridge: don't allow setting hello time to zero · 8d4698f7
      Stephen Hemminger authored
      Dushan Tcholich reports that on his system ksoftirqd can consume
      between %6 to %10 of cpu time, and cause ~200 context switches per
      He then correlated this with a report by bdupree@techfinesse.com:
      and the culprit cause seems to be starting the bridge interface.
      In particular, when starting the bridge interface, his scripts
      are specifying a hello timer interval of "0".
      The bridge hello time can't be safely set to values less than 1
      second, otherwise it is possible to end up with a runaway timer.
      Signed-off-by: default avatarStephen Hemminger <shemminger@vyatta.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Daniel Lezcano's avatar
      netns : fix kernel panic in timewait socket destruction · d315492b
      Daniel Lezcano authored
      How to reproduce ?
       - create a network namespace
       - use tcp protocol and get timewait socket
       - exit the network namespace
       - after a moment (when the timewait socket is destroyed), the kernel
      # BUG: unable to handle kernel NULL pointer dereference at
      IP: [<ffffffff821e394d>] inet_twdr_do_twkill_work+0x6e/0xb8
      PGD 119985067 PUD 11c5c0067 PMD 0
      Oops: 0000 [1] SMP
      CPU 1
      Modules linked in: ipv6 button battery ac loop dm_mod tg3 libphy ext3 jbd
      edd fan thermal processor thermal_sys sg sata_svw libata dock serverworks
      sd_mod scsi_mod ide_disk ide_core [last unloaded: freq_table]
      Pid: 0, comm: swapper Not tainted 2.6.27-rc2 #3
      RIP: 0010:[<ffffffff821e394d>] [<ffffffff821e394d>]
      RSP: 0018:ffff88011ff7fed0 EFLAGS: 00010246
      RAX: ffffffffffffffff RBX: ffffffff82339420 RCX: ffff88011ff7ff30
      RDX: 0000000000000001 RSI: ffff88011a4d03c0 RDI: ffff88011ac2fc00
      RBP: ffffffff823392e0 R08: 0000000000000000 R09: ffff88002802a200
      R10: ffff8800a5c4b000 R11: ffffffff823e4080 R12: ffff88011ac2fc00
      R13: 0000000000000001 R14: 0000000000000001 R15: 0000000000000000
      FS: 0000000041cbd940(0000) GS:ffff8800bff839c0(0000)
      CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
      CR2: 0000000000000007 CR3: 00000000bd87c000 CR4: 00000000000006e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Process swapper (pid: 0, threadinfo ffff8800bff9e000, task
      Stack: ffffffff823392e0 0000000000000100 ffffffff821e3a3a
      0000000000000000 ffffffff821e3a61 ffff8800bff7c000 ffffffff8203c7e7
      ffff88011ff7ff10 ffff88011ff7ff10 0000000000000021 ffffffff82351108
      Call Trace:
      <IRQ> [<ffffffff821e3a3a>] ? inet_twdr_hangman+0x0/0x9e
      [<ffffffff821e3a61>] ? inet_twdr_hangman+0x27/0x9e
      [<ffffffff8203c7e7>] ? run_timer_softirq+0x12c/0x193
      [<ffffffff820390d1>] ? __do_softirq+0x5e/0xcd
      [<ffffffff8200d08c>] ? call_softirq+0x1c/0x28
      [<ffffffff8200e611>] ? do_softirq+0x2c/0x68
      [<ffffffff8201a055>] ? smp_apic_timer_interrupt+0x8e/0xa9
      [<ffffffff8200cad6>] ? apic_timer_interrupt+0x66/0x70
      <EOI> [<ffffffff82011f4c>] ? default_idle+0x27/0x3b
      [<ffffffff8200abbd>] ? cpu_idle+0x5f/0x7d
      Code: e8 01 00 00 4c 89 e7 41 ff c5 e8 8d fd ff ff 49 8b 44 24 38 4c 89 e7
      65 8b 14 25 24 00 00 00 89 d2 48 8b 80 e8 00 00 00 48 f7 d0 <48> 8b 04 d0
      48 ff 40 58 e8 fc fc ff ff 48 89 df e8 c0 5f 04 00
      RIP [<ffffffff821e394d>] inet_twdr_do_twkill_work+0x6e/0xb8
      RSP <ffff88011ff7fed0>
      CR2: 0000000000000007
      This patch provides a function to purge all timewait sockets related
      to a network namespace. The timewait sockets life cycle is not tied with
      the network namespace, that means the timewait sockets stay alive while
      the network namespace dies. The timewait sockets are for avoiding to
      receive a duplicate packet from the network, if the network namespace is
      freed, the network stack is removed, so no chance to receive any packets
      from the outside world. Furthermore, having a pending destruction timer
      on these sockets with a network namespace freed is not safe and will lead
      to an oops if the timer callback which try to access data belonging to 
      the namespace like for example in:
      		-> NET_INC_STATS_BH(twsk_net(tw), LINUX_MIB_TIMEWAITED);
      Purging the timewait sockets at the network namespace destruction will:
       1) speed up memory freeing for the namespace
       2) fix kernel panic on asynchronous timewait destruction
      Signed-off-by: default avatarDaniel Lezcano <dlezcano@fr.ibm.com>
      Acked-by: default avatarDenis V. Lunev <den@openvz.org>
      Acked-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  8. 07 Sep, 2008 5 commits
  9. 05 Sep, 2008 1 commit
  10. 03 Sep, 2008 1 commit
  11. 02 Sep, 2008 5 commits
  12. 01 Sep, 2008 1 commit
    • Cyrill Gorcunov's avatar
      sunrpc: fix possible overrun on read of /proc/sys/sunrpc/transports · 27df6f25
      Cyrill Gorcunov authored
      Vegard Nossum reported
      > I noticed that something weird is going on with /proc/sys/sunrpc/transports.
      > This file is generated in net/sunrpc/sysctl.c, function proc_do_xprt(). When
      > I "cat" this file, I get the expected output:
      >    $ cat /proc/sys/sunrpc/transports
      >    tcp 1048576
      >    udp 32768
      > But I think that it does not check the length of the buffer supplied by
      > userspace to read(). With my original program, I found that the stack was
      > being overwritten by the characters above, even when the length given to
      > read() was just 1.
      David Wagner added (among other things) that copy_to_user could be
      probably used here.
      Ingo Oeser suggested to use simple_read_from_buffer() here.
      The conclusion is that proc_do_xprt doesn't check for userside buffer
      size indeed so fix this by using Ingo's suggestion.
      Reported-by: default avatarVegard Nossum <vegard.nossum@gmail.com>
      Signed-off-by: default avatarCyrill Gorcunov <gorcunov@gmail.com>
      CC: Ingo Oeser <ioe-lkml@rameria.de>
      Cc: Neil Brown <neilb@suse.de>
      Cc: Chuck Lever <chuck.lever@oracle.com>
      Cc: Greg Banks <gnb@sgi.com>
      Cc: Tom Tucker <tom@opengridcomputing.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@citi.umich.edu>
  13. 29 Aug, 2008 2 commits
  14. 27 Aug, 2008 7 commits
  15. 26 Aug, 2008 1 commit