Skip to content

L
linux
Switch branch/tag
  1. 17 Oct, 2012 1 commit
  3. 15 Oct, 2012 2 commits
  5. 08 Oct, 2012 8 commits
  7. 05 Oct, 2012 4 commits
  9. 04 Oct, 2012 15 commits
    • Gao feng's avatar
      ipv6: release reference of ip6_null_entry's dst entry in __ip6_del_rt · 6825a26c
      Gao feng authored 
      as we hold dst_entry before we call __ip6_del_rt,
so we should alse call dst_release not only return
-ENOENT when the rt6_info is ip6_null_entry.

and we already hold the dst entry, so I think it's
safe to call dst_release out of the write-read lock.
Signed-off-by: default avatarGao feng <gaofeng@cn.fujitsu.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6825a26c
    • Dave Jones's avatar
      Remove noisy printks from llcp_sock_connect · 32418cfe
      Dave Jones authored 
      Validation of userspace input shouldn't trigger dmesg spamming.
Signed-off-by: default avatarDave Jones <davej@redhat.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      32418cfe
    • David S. Miller's avatar
      Merge branch 'fixes-for-3.7' of git://gitorious.org/linux-can/linux-can · 19d4e663
      David S. Miller authored 
      Marc Kleine-Budde says:

====================
here are three patches for the v3.7 release cycle. Two patches by Peter Senna
Tschudin which fix the return values in the error handling path of the sja1000
peak pci and pcmcia driver. And one patch by myself that fixes a compile
breakage of the mpc5xxx_can mscan driver due to a section conflict.
====================
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      19d4e663
    • Erik Hugne's avatar
      tipc: prevent dropped connections due to rcvbuf overflow · e57edf6b
      Erik Hugne authored 
      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: default avatarErik Hugne <erik.hugne@ericsson.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e57edf6b
    • Dave Jones's avatar
      silence some noisy printks in irda · 09689581
      Dave Jones authored 
      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: default avatarDave Jones <davej@redhat.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      09689581
    • Eric Dumazet's avatar
      team: set qdisc_tx_busylock to avoid LOCKDEP splat · b3c581d5
      Eric Dumazet authored 
      If a qdisc is installed on a team device, its possible to get
a lockdep splat under stress, because nested dev_queue_xmit() can
lock busylock a second time (on a different device, so its a false
positive)

Avoid this problem using a distinct lock_class_key for team
devices.
Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
Cc: Jiri Pirko <jpirko@redhat.com>
Acked-by: default avatarJiri Pirko <jiri@resnulli.us>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b3c581d5
    • Eric Dumazet's avatar
      bonding: set qdisc_tx_busylock to avoid LOCKDEP splat · 49ee4920
      Eric Dumazet authored 
      If a qdisc is installed on a bonding device, its possible to get
following lockdep splat under stress :

 =============================================
 [ INFO: possible recursive locking detected ]
 3.6.0+ #211 Not tainted
 ---------------------------------------------
 ping/4876 is trying to acquire lock:
  (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock){+.-...}, at: [<ffffffff8157a191>] dev_queue_xmit+0xe1/0x830

 but task is already holding lock:
  (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock){+.-...}, at: [<ffffffff8157a191>] dev_queue_xmit+0xe1/0x830

 other info that might help us debug this:
  Possible unsafe locking scenario:

        CPU0
        ----
   lock(dev->qdisc_tx_busylock ?: &qdisc_tx_busylock);
   lock(dev->qdisc_tx_busylock ?: &qdisc_tx_busylock);

  *** DEADLOCK ***

  May be due to missing lock nesting notation

 6 locks held by ping/4876:
  #0:  (sk_lock-AF_INET){+.+.+.}, at: [<ffffffff815e5030>] raw_sendmsg+0x600/0xc30
  #1:  (rcu_read_lock_bh){.+....}, at: [<ffffffff815ba4bd>] ip_finish_output+0x12d/0x870
  #2:  (rcu_read_lock_bh){.+....}, at: [<ffffffff8157a0b0>] dev_queue_xmit+0x0/0x830
  #3:  (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock){+.-...}, at: [<ffffffff8157a191>] dev_queue_xmit+0xe1/0x830
  #4:  (&bond->lock){++.?..}, at: [<ffffffffa02128c1>] bond_start_xmit+0x31/0x4b0 [bonding]
  #5:  (rcu_read_lock_bh){.+....}, at: [<ffffffff8157a0b0>] dev_queue_xmit+0x0/0x830

 stack backtrace:
 Pid: 4876, comm: ping Not tainted 3.6.0+ #211
 Call Trace:
  [<ffffffff810a0145>] __lock_acquire+0x715/0x1b80
  [<ffffffff810a256b>] ? mark_held_locks+0x9b/0x100
  [<ffffffff810a1bf2>] lock_acquire+0x92/0x1d0
  [<ffffffff8157a191>] ? dev_queue_xmit+0xe1/0x830
  [<ffffffff81726b7c>] _raw_spin_lock+0x3c/0x50
  [<ffffffff8157a191>] ? dev_queue_xmit+0xe1/0x830
  [<ffffffff8106264d>] ? rcu_read_lock_bh_held+0x5d/0x90
  [<ffffffff8157a191>] dev_queue_xmit+0xe1/0x830
  [<ffffffff8157a0b0>] ? netdev_pick_tx+0x570/0x570
  [<ffffffffa0212a6a>] bond_start_xmit+0x1da/0x4b0 [bonding]
  [<ffffffff815796d0>] dev_hard_start_xmit+0x240/0x6b0
  [<ffffffff81597c6e>] sch_direct_xmit+0xfe/0x2a0
  [<ffffffff8157a249>] dev_queue_xmit+0x199/0x830
  [<ffffffff8157a0b0>] ? netdev_pick_tx+0x570/0x570
  [<ffffffff815ba96f>] ip_finish_output+0x5df/0x870
  [<ffffffff815ba4bd>] ? ip_finish_output+0x12d/0x870
  [<ffffffff815bb964>] ip_output+0x54/0xf0
  [<ffffffff815bad48>] ip_local_out+0x28/0x90
  [<ffffffff815bc444>] ip_send_skb+0x14/0x50
  [<ffffffff815bc4b2>] ip_push_pending_frames+0x32/0x40
  [<ffffffff815e536a>] raw_sendmsg+0x93a/0xc30
  [<ffffffff8128d570>] ? selinux_file_send_sigiotask+0x1f0/0x1f0
  [<ffffffff8109ddb4>] ? __lock_is_held+0x54/0x80
  [<ffffffff815f6730>] ? inet_recvmsg+0x220/0x220
  [<ffffffff8109ddb4>] ? __lock_is_held+0x54/0x80
  [<ffffffff815f6855>] inet_sendmsg+0x125/0x240
  [<ffffffff815f6730>] ? inet_recvmsg+0x220/0x220
  [<ffffffff8155cddb>] sock_sendmsg+0xab/0xe0
  [<ffffffff810a1650>] ? lock_release_non_nested+0xa0/0x2e0
  [<ffffffff810a1650>] ? lock_release_non_nested+0xa0/0x2e0
  [<ffffffff8155d18c>] __sys_sendmsg+0x37c/0x390
  [<ffffffff81195b2a>] ? fsnotify+0x2ca/0x7e0
  [<ffffffff811958e8>] ? fsnotify+0x88/0x7e0
  [<ffffffff81361f36>] ? put_ldisc+0x56/0xd0
  [<ffffffff8116f98a>] ? fget_light+0x3da/0x510
  [<ffffffff8155f6c4>] sys_sendmsg+0x44/0x80
  [<ffffffff8172fc22>] system_call_fastpath+0x16/0x1b

Avoid this problem using a distinct lock_class_key for bonding
devices.
Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
Cc: Jay Vosburgh <fubar@us.ibm.com>
Cc: Andy Gospodarek <andy@greyhouse.net>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      49ee4920
    • Nicolas Dichtel's avatar
      sctp: check src addr when processing SACK to update transport state · edfee033
      Nicolas Dichtel authored 
      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: default avatarNicolas Dichtel <nicolas.dichtel@6wind.com>
Acked-by: default avatarVlad Yasevich <vyasevich@gmail.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      edfee033
    • Nicolas Dichtel's avatar
      sctp: fix a typo in prototype of __sctp_rcv_lookup() · 57565993
      Nicolas Dichtel authored 
      Just to avoid confusion when people only reads this prototype.
Signed-off-by: default avatarNicolas Dichtel <nicolas.dichtel@6wind.com>
Acked-by: default avatarVlad Yasevich <vyasevich@gmail.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      57565993
    • David S. Miller's avatar
      Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net · e7b565e7
      David S. Miller authored 
      Jeff Kirsher says:

====================
This series contains fixes/updates to ixgbe only.  There are three
PTP fixes, polling loop fix and the addition of a device id (X540-AT1).
====================
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e7b565e7
    • Eric Dumazet's avatar
      ipv4: add a fib_type to fib_info · f4ef85bb
      Eric Dumazet authored 
      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: default avatarChris Clayton <chris2553@googlemail.com>
Bisected-by: default avatarChris Clayton <chris2553@googlemail.com>
Reported-by: default avatarDave Jones <davej@redhat.com>
Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
Cc: Julian Anastasov <ja@ssi.bg>
Tested-by: default avatarChris Clayton <chris2553@googlemail.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f4ef85bb
    • Marc Kleine-Budde's avatar
      can: mpc5xxx_can: fix section type conflict · 8cf437a0
      Marc Kleine-Budde authored 
      Since commit:
    6d99c4c5 can: mpc5xxx_can: make data used as *of_device_id.data const

both "struct mpc5xxx_can_data mpc5200_can_data" and "mpc5121_can_data" are
marked as "const" but also as "__devinitdata". This leads to the following
compile error:

drivers/net/can/mscan/mpc5xxx_can.c:383: error: mpc5200_can_data causes a section type conflict
drivers/net/can/mscan/mpc5xxx_can.c:383: error: mpc5200_can_data causes a section type conflict
drivers/net/can/mscan/mpc5xxx_can.c:388: error: mpc5121_can_data causes a section type conflict
drivers/net/can/mscan/mpc5xxx_can.c:388: error: mpc5121_can_data causes a section type conflict

This patch changes the "__devinitdata" to "__devinitconst" and marks the
"struct of_device_id mpc5xxx_can_table" as "const" and "__devinitconst", too.
Acked-by: default avatarUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      8cf437a0
    • Peter Senna Tschudin's avatar
      can: peak_pcmcia: fix error return code · ba9b6f9f
      Peter Senna Tschudin authored 
      Convert a nonnegative error return code to a negative one, as returned
elsewhere in the function.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// <smpl>
(
if@p1 (\(ret < 0\|ret != 0\))
 { ... return ret; }
|
ret@p1 = 0
)
... when != ret = e1
    when != &ret
*if(...)
{
  ... when != ret = e2
      when forall
 return ret;
}
// </smpl>
Signed-off-by: default avatarPeter Senna Tschudin <peter.senna@gmail.com>
Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      ba9b6f9f
    • Peter Senna Tschudin's avatar
      can: peak_pci: fix error return code · 4a4bfdcd
      Peter Senna Tschudin authored 
      Convert a nonnegative error return code to a negative one, as returned
elsewhere in the function.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// <smpl>
(
if@p1 (\(ret < 0\|ret != 0\))
 { ... return ret; }
|
ret@p1 = 0
)
... when != ret = e1
    when != &ret
*if(...)
{
  ... when != ret = e2
      when forall
 return ret;
}
// </smpl>
Signed-off-by: default avatarPeter Senna Tschudin <peter.senna@gmail.com>
Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      4a4bfdcd
    • David S. Miller's avatar
      cxgb4: Fix build error due to missing linux/vmalloc.h include. · c0b8b992
      David S. Miller authored 
      Reported-by: default avatarStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c0b8b992
  11. 03 Oct, 2012 10 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7