1. 05 10月, 2012 5 次提交
    • E
      tipc: prevent dropped connections due to rcvbuf overflow · e57edf6b
      Erik Hugne 提交于
      When large buffers are sent over connected TIPC sockets, it
      is likely that the sk_backlog will be filled up on the
      receiver side, but the TIPC flow control mechanism is happily
      unaware of this since that is based on message count.
      
      The sender will receive a TIPC_ERR_OVERLOAD message when this occurs
      and drop it's side of the connection, leaving it stale on
      the receiver end.
      
      By increasing the sk_rcvbuf to a 'worst case' value, we avoid the
      overload caused by a full backlog queue and the flow control
      will work properly.
      
      This worst case value is the max TIPC message size times
      the flow control window, multiplied by two because a sender
      will transmit up to double the window size before a port is marked
      congested.
      We multiply this by 2 to account for the sk_buff and other overheads.
      Signed-off-by: NErik Hugne <erik.hugne@ericsson.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e57edf6b
    • D
      silence some noisy printks in irda · 09689581
      Dave Jones 提交于
      Fuzzing causes these printks to spew constantly.
      Changing them to DEBUG statements is consistent with other usage in the file,
      and makes them disappear when CONFIG_IRDA_DEBUG is disabled.
      Signed-off-by: NDave Jones <davej@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      09689581
    • N
      sctp: check src addr when processing SACK to update transport state · edfee033
      Nicolas Dichtel 提交于
      Suppose we have an SCTP connection with two paths. After connection is
      established, path1 is not available, thus this path is marked as inactive. Then
      traffic goes through path2, but for some reasons packets are delayed (after
      rto.max). Because packets are delayed, the retransmit mechanism will switch
      again to path1. At this time, we receive a delayed SACK from path2. When we
      update the state of the path in sctp_check_transmitted(), we do not take into
      account the source address of the SACK, hence we update the wrong path.
      Signed-off-by: NNicolas Dichtel <nicolas.dichtel@6wind.com>
      Acked-by: NVlad Yasevich <vyasevich@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      edfee033
    • N
      sctp: fix a typo in prototype of __sctp_rcv_lookup() · 57565993
      Nicolas Dichtel 提交于
      Just to avoid confusion when people only reads this prototype.
      Signed-off-by: NNicolas Dichtel <nicolas.dichtel@6wind.com>
      Acked-by: NVlad Yasevich <vyasevich@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      57565993
    • E
      ipv4: add a fib_type to fib_info · f4ef85bb
      Eric Dumazet 提交于
      commit d2d68ba9 (ipv4: Cache input routes in fib_info nexthops.)
      introduced a regression for forwarding.
      
      This was hard to reproduce but the symptom was that packets were
      delivered to local host instead of being forwarded.
      
      David suggested to add fib_type to fib_info so that we dont
      inadvertently share same fib_info for different purposes.
      
      With help from Julian Anastasov who provided very helpful
      hints, reproduced here :
      
      <quote>
              Can it be a problem related to fib_info reuse
      from different routes. For example, when local IP address
      is created for subnet we have:
      
      broadcast 192.168.0.255 dev DEV  proto kernel  scope link  src
      192.168.0.1
      192.168.0.0/24 dev DEV  proto kernel  scope link  src 192.168.0.1
      local 192.168.0.1 dev DEV  proto kernel  scope host  src 192.168.0.1
      
              The "dev DEV  proto kernel  scope link  src 192.168.0.1" is
      a reused fib_info structure where we put cached routes.
      The result can be same fib_info for 192.168.0.255 and
      192.168.0.0/24. RTN_BROADCAST is cached only for input
      routes. Incoming broadcast to 192.168.0.255 can be cached
      and can cause problems for traffic forwarded to 192.168.0.0/24.
      So, this patch should solve the problem because it
      separates the broadcast from unicast traffic.
      
              And the ip_route_input_slow caching will work for
      local and broadcast input routes (above routes 1 and 3) just
      because they differ in scope and use different fib_info.
      
      </quote>
      
      Many thanks to Chris Clayton for his patience and help.
      Reported-by: NChris Clayton <chris2553@googlemail.com>
      Bisected-by: NChris Clayton <chris2553@googlemail.com>
      Reported-by: NDave Jones <davej@redhat.com>
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Julian Anastasov <ja@ssi.bg>
      Tested-by: NChris Clayton <chris2553@googlemail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f4ef85bb
  2. 03 10月, 2012 3 次提交
  3. 02 10月, 2012 9 次提交
  4. 29 9月, 2012 1 次提交
  5. 28 9月, 2012 12 次提交
  6. 27 9月, 2012 6 次提交
    • S
      NFC: Fix sleeping in atomic when releasing socket · 50b78b2a
      Szymon Janc 提交于
      nfc_llcp_socket_release is calling lock_sock/release_sock while holding
      write lock for rwlock. Use bh_lock/unlock_sock instead.
      
      BUG: sleeping function called from invalid context at net/core/sock.c:2138
      in_atomic(): 1, irqs_disabled(): 0, pid: 56, name: kworker/1:1
      4 locks held by kworker/1:1/56:
      Pid: 56, comm: kworker/1:1 Not tainted 3.5.0-999-nfc+ #7
      Call Trace:
      [<ffffffff810952c5>] __might_sleep+0x145/0x200
      [<ffffffff815d7686>] lock_sock_nested+0x36/0xa0
      [<ffffffff81731569>] ? _raw_write_lock+0x49/0x50
      [<ffffffffa04aa100>] ? nfc_llcp_socket_release+0x30/0x200 [nfc]
      [<ffffffffa04aa122>] nfc_llcp_socket_release+0x52/0x200 [nfc]
      [<ffffffffa04ab9f0>] nfc_llcp_mac_is_down+0x20/0x30 [nfc]
      [<ffffffffa04a6fea>] nfc_dep_link_down+0xaa/0xf0 [nfc]
      [<ffffffffa04a9bb5>] nfc_llcp_timeout_work+0x15/0x20 [nfc]
      [<ffffffff810825f7>] process_one_work+0x197/0x7c0
      [<ffffffff81082596>] ? process_one_work+0x136/0x7c0
      [<ffffffff8172fbc9>] ? __schedule+0x419/0x9c0
      [<ffffffffa04a9ba0>] ? nfc_llcp_build_gb+0x1b0/0x1b0 [nfc]
      [<ffffffff81083090>] worker_thread+0x190/0x4c0
      [<ffffffff81082f00>] ? rescuer_thread+0x2a0/0x2a0
      [<ffffffff81088d1e>] kthread+0xae/0xc0
      [<ffffffff810caafd>] ? trace_hardirqs_on+0xd/0x10
      [<ffffffff8173acc4>] kernel_thread_helper+0x4/0x10
      [<ffffffff81732174>] ? retint_restore_args+0x13/0x13
      [<ffffffff81088c70>] ? flush_kthread_worker+0x150/0x150
      [<ffffffff8173acc0>] ? gs_change+0x13/0x13
      Signed-off-by: NSzymon Janc <szymon.janc@tieto.com>
      Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
      50b78b2a
    • S
      NFC: Fix sleeping in invalid context when netlink socket is closed · 3c0cc8aa
      Szymon Janc 提交于
      netlink_register_notifier requires notify functions to not sleep.
      nfc_stop_poll locks device mutex and must not be called from notifier.
      Create workqueue that will handle this for all devices.
      
      BUG: sleeping function called from invalid context at kernel/mutex.c:269
      in_atomic(): 0, irqs_disabled(): 0, pid: 4497, name: neard
      1 lock held by neard/4497:
      Pid: 4497, comm: neard Not tainted 3.5.0-999-nfc+ #5
      Call Trace:
      [<ffffffff810952c5>] __might_sleep+0x145/0x200
      [<ffffffff81743dde>] mutex_lock_nested+0x2e/0x50
      [<ffffffff816ffd19>] nfc_stop_poll+0x39/0xb0
      [<ffffffff81700a17>] nfc_genl_rcv_nl_event+0x77/0xc0
      [<ffffffff8174aa8c>] notifier_call_chain+0x5c/0x120
      [<ffffffff8174abd6>] __atomic_notifier_call_chain+0x86/0x140
      [<ffffffff8174ab50>] ? notifier_call_chain+0x120/0x120
      [<ffffffff815e1347>] ? skb_dequeue+0x67/0x90
      [<ffffffff8174aca6>] atomic_notifier_call_chain+0x16/0x20
      [<ffffffff8162119a>] netlink_release+0x24a/0x280
      [<ffffffff815d7aa8>] sock_release+0x28/0xa0
      [<ffffffff815d7be7>] sock_close+0x17/0x30
      [<ffffffff811b2a7c>] __fput+0xcc/0x250
      [<ffffffff811b2c0e>] ____fput+0xe/0x10
      [<ffffffff81085009>] task_work_run+0x69/0x90
      [<ffffffff8101b951>] do_notify_resume+0x81/0xd0
      [<ffffffff8174ef22>] int_signal+0x12/0x17
      Signed-off-by: NSzymon Janc <szymon.janc@tieto.com>
      Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
      3c0cc8aa
    • J
      NFC: Add dummy nfc_llc_shdlc_register definition · 7d777c3d
      John W. Linville 提交于
      This is used when CONFIG_NFC_SHDLC is disabled.
      Reported-by: NRandy Dunlap <rdunlap@xenotime.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
      7d777c3d
    • T
      NFC: LLCP raw socket support · 4463523b
      Thierry Escande 提交于
      This adds support for socket of type SOCK_RAW to LLCP.
      sk_buff are copied and sent to raw sockets with a 2 bytes extra header:
      The first byte header contains the nfc adapter index.
      The second one contains flags:
      - 0x01 - Direction (0=RX, 1=TX)
      - 0x02-0x80 - Reserved
      A raw socket has to be explicitly bound to a nfc adapter. This is achieved
      by specifying the adapter index to be bound to in the dev_idx field of the
      sockaddr_nfc_llcp struct passed to bind().
      Signed-off-by: NThierry Escande <thierry.escande@linux.intel.com>
      Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
      4463523b
    • S
      NFC: Use dynamic initialization for rwlocks · fe235b58
      Szymon Janc 提交于
      If rwlock is dynamically allocated but statically initialized it is
      missing proper lockdep annotation.
      
      INFO: trying to register non-static key.
      the code is fine but needs lockdep annotation.
      turning off the locking correctness validator.
      Pid: 3352, comm: neard Not tainted 3.5.0-999-nfc+ #2
      Call Trace:
      [<ffffffff810c8526>] __lock_acquire+0x8f6/0x1bf0
      [<ffffffff81739045>] ? printk+0x4d/0x4f
      [<ffffffff810c9eed>] lock_acquire+0x9d/0x220
      [<ffffffff81702bfe>] ? nfc_llcp_sock_from_sn+0x4e/0x160
      [<ffffffff81746724>] _raw_read_lock+0x44/0x60
      [<ffffffff81702bfe>] ? nfc_llcp_sock_from_sn+0x4e/0x160
      [<ffffffff81702bfe>] nfc_llcp_sock_from_sn+0x4e/0x160
      [<ffffffff817034a7>] nfc_llcp_get_sdp_ssap+0xa7/0x1b0
      [<ffffffff81706353>] llcp_sock_bind+0x173/0x210
      [<ffffffff815d9c94>] sys_bind+0xe4/0x100
      [<ffffffff8139209e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
      [<ffffffff8174ea69>] system_call_fastpath+0x16/0x1b
      Signed-off-by: NSzymon Janc <szymon.janc@tieto.com>
      Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
      fe235b58
    • J
      nfc: add dummy nfc_llc_shdlc_register definition · 8a14e8bf
      John W. Linville 提交于
      This is used when CONFIG_NFC_SHDLC is disabled.
      Reported-by: NRandy Dunlap <rdunlap@xenotime.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      8a14e8bf
  7. 26 9月, 2012 4 次提交