Skip to content

L
linux
Switch branch/tag
  1. 06 Feb, 2009 8 commits
    • Pablo Neira Ayuso's avatar
      netlink: change return-value logic of netlink_broadcast() · ff491a73
      Pablo Neira Ayuso authored 
      Currently, netlink_broadcast() reports errors to the caller if no
messages at all were delivered:

1) If, at least, one message has been delivered correctly, returns 0.
2) Otherwise, if no messages at all were delivered due to skb_clone()
   failure, return -ENOBUFS.
3) Otherwise, if there are no listeners, return -ESRCH.

With this patch, the caller knows if the delivery of any of the
messages to the listeners have failed:

1) If it fails to deliver any message (for whatever reason), return
   -ENOBUFS.
2) Otherwise, if all messages were delivered OK, returns 0.
3) Otherwise, if no listeners, return -ESRCH.

In the current ctnetlink code and in Netfilter in general, we can add
reliable logging and connection tracking event delivery by dropping the
packets whose events were not successfully delivered over Netlink. Of
course, this option would be settable via /proc as this approach reduces
performance (in terms of filtered connections per seconds by a stateful
firewall) but providing reliable logging and event delivery (for
conntrackd) in return.

This patch also changes some clients of netlink_broadcast() that
may report ENOBUFS errors via printk. This error handling is not
of any help. Instead, the userspace daemons that are listening to
those netlink messages should resync themselves with the kernel-side
if they hit ENOBUFS.

BTW, netlink_broadcast() clients include those that call
cn_netlink_send(), nlmsg_multicast() and genlmsg_multicast() since they
internally call netlink_broadcast() and return its error value.
Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ff491a73
    • Alex Chiang's avatar
      e1000e: normalize usage of serdes_has_link · 612e244c
      Alex Chiang authored 
      Cosmetic change to use struct e1000_mac_info.serdes_has_link
consistently as the 'bool' that it's declared as.

No functional change.
Signed-off-by: default avatarAlex Chiang <achiang@hp.com>
Acked-by: default avatarJeff Kirsher <Jeffrey.t.kirsher@intel.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      612e244c
    • Peter P Waskiewicz Jr's avatar
      ixgbe: Display EEPROM version in ethtool -i queries · 34b0368c
      Peter P Waskiewicz Jr authored 
      Currently ixgbe does not display the EEPROM version in ethtool -i, where
other drivers do.  The EEPROM version is located at offset 0x29.  This
patch adds support to display it.
Signed-off-by: default avatarPeter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      34b0368c
    • Peter P Waskiewicz Jr's avatar
      ixgbe: Update link setup code to better support autonegotiation of speed · 3201d313
      Peter P Waskiewicz Jr authored 
      The current code has some flaws in it when performing autonegotiation,
especially on KX/KX4 links.  This patch updates the code to better handle
the autonegotiation states on link setup.  The patch also removes a redundant
link configuration call on driver load, and moves link configuration to
the ->open() path.
Signed-off-by: default avatarPeter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3201d313
    • Peter P Waskiewicz Jr's avatar
      ixgbe: Refactor set_num_queues() and cache_ring_register() · bc97114d
      Peter P Waskiewicz Jr authored 
      The current code to determine the number of queues the device will want
on driver initialization is ugly and difficult to maintain.  It also
doesn't allow for easy expansion for future features or future hardware.
This patch refactors these routines, and make them easier to deal with.
Signed-off-by: default avatarPeter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bc97114d
    • Herbert Xu's avatar
      gro: Fix frag_list merging on imprecisely split packets · 56035022
      Herbert Xu authored 
      The previous fix ad0f9904 (gro:
Fix handling of imprecisely split packets) only fixed the case
of frags merging, frag_list merging in the same circumstances
were still broken.

In particular, the packet headers end up in the data stream.

This patch fixes this plus another issue where an imprecisely
split packet header may be read incorrectly (this is mostly
harmless since it'll simply cause the packet to not match and
be rejected for GRO).

Thanks to Emil Tantilov and Jeff Kirsher for helping to track
this down.
Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      56035022
    • Graf Yang's avatar
      net: fix some trailing whitespaces · fe2918b0
      Graf Yang authored 
      Signed-off-by: default avatarGraf Yang <graf.yang@analog.com>
Signed-off-by: default avatarBryan Wu <cooloney@kernel.org>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fe2918b0
    • Herbert Xu's avatar
      tun: Limit amount of queued packets per device · 33dccbb0
      Herbert Xu authored 
      Unlike a normal socket path, the tuntap device send path does
not have any accounting.  This means that the user-space sender
may be able to pin down arbitrary amounts of kernel memory by
continuing to send data to an end-point that is congested.

Even when this isn't an issue because of limited queueing at
most end points, this can also be a problem because its only
response to congestion is packet loss.  That is, when those
local queues at the end-point fills up, the tuntap device will
start wasting system time because it will continue to send
data there which simply gets dropped straight away.

Of course one could argue that everybody should do congestion
control end-to-end, unfortunately there are people in this world
still hooked on UDP, and they don't appear to be going away
anywhere fast.  In fact, we've always helped them by performing
accounting in our UDP code, the sole purpose of which is to
provide congestion feedback other than through packet loss.

This patch attempts to apply the same bandaid to the tuntap device.
It creates a pseudo-socket object which is used to account our
packets just as a normal socket does for UDP.  Of course things
are a little complex because we're actually reinjecting traffic
back into the stack rather than out of the stack.

The stack complexities however should have been resolved by preceding
patches.  So this one can simply start using skb_set_owner_w.

For now the accounting is essentially disabled by default for
backwards compatibility.  In particular, we set the cap to INT_MAX.
This is so that existing applications don't get confused by the
sudden arrival EAGAIN errors.

In future we may wish (or be forced to) do this by default.
Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      33dccbb0
  3. 05 Feb, 2009 15 commits
  5. 04 Feb, 2009 17 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7