Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 26 10月, 2013 1 次提交
  3. 28 5月, 2013 1 次提交
  5. 02 5月, 2013 1 次提交
    • N
      netpoll: convert mutex into a semaphore · bd7c4b60
      由 Neil Horman 提交于 
      Bart Van Assche recently reported a warning to me:

<IRQ>  [<ffffffff8103d79f>] warn_slowpath_common+0x7f/0xc0
[<ffffffff8103d7fa>] warn_slowpath_null+0x1a/0x20
[<ffffffff814761dd>] mutex_trylock+0x16d/0x180
[<ffffffff813968c9>] netpoll_poll_dev+0x49/0xc30
[<ffffffff8136a2d2>] ? __alloc_skb+0x82/0x2a0
[<ffffffff81397715>] netpoll_send_skb_on_dev+0x265/0x410
[<ffffffff81397c5a>] netpoll_send_udp+0x28a/0x3a0
[<ffffffffa0541843>] ? write_msg+0x53/0x110 [netconsole]
[<ffffffffa05418bf>] write_msg+0xcf/0x110 [netconsole]
[<ffffffff8103eba1>] call_console_drivers.constprop.17+0xa1/0x1c0
[<ffffffff8103fb76>] console_unlock+0x2d6/0x450
[<ffffffff8104011e>] vprintk_emit+0x1ee/0x510
[<ffffffff8146f9f6>] printk+0x4d/0x4f
[<ffffffffa0004f1d>] scsi_print_command+0x7d/0xe0 [scsi_mod]

This resulted from my commit ca99ca14 which introduced a mutex_trylock
operation in a path that could execute in interrupt context.  When mutex
debugging is enabled, the above warns the user when we are in fact
exectuting in interrupt context
interrupt context.

After some discussion, It seems that a semaphore is the proper mechanism to use
here.  While mutexes are defined to be unusable in interrupt context, no such
condition exists for semaphores (save for the fact that the non blocking api
calls, like up and down_trylock must be used when in irq context).
Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
Reported-by: NBart Van Assche <bvanassche@acm.org>
CC: Bart Van Assche <bvanassche@acm.org>
CC: David Miller <davem@davemloft.net>
CC: netdev@vger.kernel.org
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bd7c4b60
  7. 12 2月, 2013 1 次提交
    • N
      netpoll: Fix __netpoll_rcu_free so that it can hold the rtnl lock · 2cde6acd
      由 Neil Horman 提交于 
      __netpoll_rcu_free is used to free netpoll structures when the rtnl_lock is
already held.  The mechanism is used to asynchronously call __netpoll_cleanup
outside of the holding of the rtnl_lock, so as to avoid deadlock.
Unfortunately, __netpoll_cleanup modifies pointers (dev->np), which means the
rtnl_lock must be held while calling it.  Further, it cannot be held, because
rcu callbacks may be issued in softirq contexts, which cannot sleep.

Fix this by converting the rcu callback to a work queue that is guaranteed to
get scheduled in process context, so that we can hold the rtnl properly while
calling __netpoll_cleanup

Tested successfully by myself.
Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
CC: "David S. Miller" <davem@davemloft.net>
CC: Cong Wang <amwang@redhat.com>
CC: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2cde6acd
  9. 07 2月, 2013 1 次提交
    • N
      netpoll: protect napi_poll and poll_controller during dev_[open|close] · ca99ca14
      由 Neil Horman 提交于 
      Ivan Vercera was recently backporting commit
9c13cb8b to a RHEL kernel, and I noticed that,
while this patch protects the tg3 driver from having its ndo_poll_controller
routine called during device initalization, it does nothing for the driver
during shutdown. I.e. it would be entirely possible to have the
ndo_poll_controller method (or subsequently the ndo_poll) routine called for a
driver in the netpoll path on CPU A while in parallel on CPU B, the ndo_close or
ndo_open routine could be called.  Given that the two latter routines tend to
initizlize and free many data structures that the former two rely on, the result
can easily be data corruption or various other crashes.  Furthermore, it seems
that this is potentially a problem with all net drivers that support netpoll,
and so this should ideally be fixed in a common path.

As Ben H Pointed out to me, we can't preform dev_open/dev_close in atomic
context, so I've come up with this solution.  We can use a mutex to sleep in
open/close paths and just do a mutex_trylock in the napi poll path and abandon
the poll attempt if we're locked, as we'll just retry the poll on the next send
anyway.

I've tested this here by flooding netconsole with messages on a system whos nic
driver I modfied to periodically return NETDEV_TX_BUSY, so that the netpoll tx
workqueue would be forced to send frames and poll the device.  While this was
going on I rapidly ifdown/up'ed the interface and watched for any problems.
I've not found any.
Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
CC: Ivan Vecera <ivecera@redhat.com>
CC: "David S. Miller" <davem@davemloft.net>
CC: Ben Hutchings <bhutchings@solarflare.com>
CC: Francois Romieu <romieu@fr.zoreil.com>
CC: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ca99ca14
  11. 09 1月, 2013 1 次提交
  13. 15 8月, 2012 6 次提交
  15. 18 7月, 2012 1 次提交
  17. 04 7月, 2011 1 次提交
  19. 18 10月, 2010 1 次提交
    • N
      bonding: Fix bonding drivers improper modification of netpoll structure · c2355e1a
      由 Neil Horman 提交于 
      The bonding driver currently modifies the netpoll structure in its xmit path
while sending frames from netpoll.  This is racy, as other cpus can access the
netpoll structure in parallel. Since the bonding driver points np->dev to a
slave device, other cpus can inadvertently attempt to send data directly to
slave devices, leading to improper locking with the bonding master, lost frames,
and deadlocks.  This patch fixes that up.

This patch also removes the real_dev pointer from the netpoll structure as that
data is really only used by bonding in the poll_controller, and we can emulate
its behavior by check each slave for IS_UP.
Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c2355e1a
  21. 18 9月, 2010 1 次提交
  23. 11 8月, 2010 1 次提交
  25. 16 6月, 2010 4 次提交
  27. 06 5月, 2010 2 次提交
    • D
      netpoll: Use 'bool' for netpoll_rx() return type. · ffb27362
      由 David S. Miller 提交于 
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ffb27362
    • W
      netpoll: add generic support for bridge and bonding devices · 0e34e931
      由 WANG Cong 提交于 
      This whole patchset is for adding netpoll support to bridge and bonding
devices. I already tested it for bridge, bonding, bridge over bonding,
and bonding over bridge. It looks fine now.

To make bridge and bonding support netpoll, we need to adjust
some netpoll generic code. This patch does the following things:

1) introduce two new priv_flags for struct net_device:
   IFF_IN_NETPOLL which identifies we are processing a netpoll;
   IFF_DISABLE_NETPOLL is used to disable netpoll support for a device
   at run-time;

2) introduce one new method for netdev_ops:
   ->ndo_netpoll_cleanup() is used to clean up netpoll when a device is
     removed.

3) introduce netpoll_poll_dev() which takes a struct net_device * parameter;
   export netpoll_send_skb() and netpoll_poll_dev() which will be used later;

4) hide a pointer to struct netpoll in struct netpoll_info, ditto.

5) introduce ->real_dev for struct netpoll.

6) introduce a new status NETDEV_BONDING_DESLAE, which is used to disable
   netconsole before releasing a slave, to avoid deadlocks.

Cc: David Miller <davem@davemloft.net>
Cc: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: NWANG Cong <amwang@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0e34e931
  29. 14 1月, 2010 1 次提交
  31. 29 3月, 2009 1 次提交
  33. 17 3月, 2009 1 次提交
    • H
      GRO: Move netpoll checks to correct location · d1c76af9
      由 Herbert Xu 提交于 
      As my netpoll fix for net doesn't really work for net-next, we
need this update to move the checks into the right place.  As it
stands we may pass freed skbs to netpoll_receive_skb.

This patch also introduces a netpoll_rx_on function to avoid GRO
completely if we're invoked through netpoll.  This might seem
paranoid but as netpoll may have an external receive hook it's
better to be safe than sorry.  I don't think we need this for
2.6.29 though since there's nothing immediately broken by it.

This patch also moves the GRO_* return values to netdevice.h since
VLAN needs them too (I tried to avoid this originally but alas
this seems to be the easiest way out).  This fixes a bug in VLAN
where it continued to use the old return value 2 instead of the
correct GRO_DROP.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d1c76af9
  35. 16 12月, 2008 1 次提交
    • H
      net: Add Generic Receive Offload infrastructure · d565b0a1
      由 Herbert Xu 提交于 
      This patch adds the top-level GRO (Generic Receive Offload) infrastructure.
This is pretty similar to LRO except that this is protocol-independent.
Instead of holding packets in an lro_mgr structure, they're now held in
napi_struct.

For drivers that intend to use this, they can set the NETIF_F_GRO bit and
call napi_gro_receive instead of netif_receive_skb or just call netif_rx.
The latter will call napi_receive_skb automatically.  When napi_gro_receive
is used, the driver must either call napi_complete/napi_rx_complete, or
call napi_gro_flush in softirq context if the driver uses the primitives
__napi_complete/__napi_rx_complete.

Protocols will set the gro_receive and gro_complete function pointers in
order to participate in this scheme.

In addition to the packet, gro_receive will get a list of currently held
packets.  Each packet in the list has a same_flow field which is non-zero
if it is a potential match for the new packet.  For each packet that may
match, they also have a flush field which is non-zero if the held packet
must not be merged with the new packet.

Once gro_receive has determined that the new skb matches a held packet,
the held packet may be processed immediately if the new skb cannot be
merged with it.  In this case gro_receive should return the pointer to
the existing skb in gro_list.  Otherwise the new skb should be merged into
the existing packet and NULL should be returned, unless the new skb makes
it impossible for any further merges to be made (e.g., FIN packet) where
the merged skb should be returned.

Whenever the skb is merged into an existing entry, the gro_receive
function should set NAPI_GRO_CB(skb)->same_flow.  Note that if an skb
merely matches an existing entry but can't be merged with it, then
this shouldn't be set.

If gro_receive finds it pointless to hold the new skb for future merging,
it should set NAPI_GRO_CB(skb)->flush.

Held packets will be flushed by napi_gro_flush which is called by
napi_complete and napi_rx_complete.

Currently held packets are stored in a singly liked list just like LRO.
The list is limited to a maximum of 8 entries.  In future, this may be
expanded to use a hash table to allow more flows to be held for merging.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d565b0a1
  37. 05 3月, 2008 1 次提交
  39. 29 1月, 2008 2 次提交
  41. 11 10月, 2007 2 次提交
    • S
      [NET] netconsole: Support dynamic reconfiguration using configfs · 0bcc1816
      由 Satyam Sharma 提交于 
      Based upon initial work by Keiichi Kii <k-keiichi@bx.jp.nec.com>.

This patch introduces support for dynamic reconfiguration (adding, removing
and/or modifying parameters of netconsole targets at runtime) using a
userspace interface exported via configfs.  Documentation is also updated
accordingly.

Issues and brief design overview:

(1) Kernel-initiated creation / destruction of kernel objects is not
    possible with configfs -- the lifetimes of the "config items" is managed
    exclusively from userspace.  But netconsole must support boot/module
    params too, and these are parsed in kernel and hence netpolls must be
    setup from the kernel.  Joel Becker suggested to separately manage the
    lifetimes of the two kinds of netconsole_target objects -- those created
    via configfs mkdir(2) from userspace and those specified from the
    boot/module option string.  This adds complexity and some redundancy here
    and also means that boot/module param-created targets are not exposed
    through the configfs namespace (and hence cannot be updated / destroyed
    dynamically).  However, this saves us from locking / refcounting
    complexities that would need to be introduced in configfs to support
    kernel-initiated item creation / destroy there.

(2) In configfs, item creation takes place in the call chain of the
    mkdir(2) syscall in the driver subsystem.  If we used an ioctl(2) to
    create / destroy objects from userspace, the special userspace program is
    able to fill out the structure to be passed into the ioctl and hence
    specify attributes such as local interface that are required at the time
    we set up the netpoll.  For configfs, this information is not available at
    the time of mkdir(2).  So, we keep all newly-created targets (via
    configfs) disabled by default.  The user is expected to set various
    attributes appropriately (including the local network interface if
    required) and then write(2) "1" to the "enabled" attribute.  Thus,
    netpoll_setup() is then called on the set parameters in the context of
    _this_ write(2) on the "enabled" attribute itself.  This design enables
    the user to reconfigure existing netconsole targets at runtime to be
    attached to newly-come-up interfaces that may not have existed when
    netconsole was loaded or when the targets were actually created.  All this
    effectively enables us to get rid of custom ioctls.

(3) Ultra-paranoid configfs attribute show() and store() operations, with
    sanity and input range checking, using only safe string primitives, and
    compliant with the recommendations in Documentation/filesystems/sysfs.txt.

(4) A new function netpoll_print_options() is created in the netpoll API,
    that just prints out the configured parameters for a netpoll structure.
    netpoll_parse_options() is modified to use that and it is also exported to
    be used from netconsole.
Signed-off-by: NSatyam Sharma <satyam@infradead.org>
Acked-by: NKeiichi Kii <k-keiichi@bx.jp.nec.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0bcc1816
    • S
      [NET]: Make NAPI polling independent of struct net_device objects. · bea3348e
      由 Stephen Hemminger 提交于 
      Several devices have multiple independant RX queues per net
device, and some have a single interrupt doorbell for several
queues.

In either case, it's easier to support layouts like that if the
structure representing the poll is independant from the net
device itself.

The signature of the ->poll() call back goes from:

	int foo_poll(struct net_device *dev, int *budget)

to

	int foo_poll(struct napi_struct *napi, int budget)

The caller is returned the number of RX packets processed (or
the number of "NAPI credits" consumed if you want to get
abstract).  The callee no longer messes around bumping
dev->quota, *budget, etc. because that is all handled in the
caller upon return.

The napi_struct is to be embedded in the device driver private data
structures.

Furthermore, it is the driver's responsibility to disable all NAPI
instances in it's ->stop() device close handler.  Since the
napi_struct is privatized into the driver's private data structures,
only the driver knows how to get at all of the napi_struct instances
it may have per-device.

With lots of help and suggestions from Rusty Russell, Roland Dreier,
Michael Chan, Jeff Garzik, and Jamal Hadi Salim.

Bug fixes from Thomas Graf, Roland Dreier, Peter Zijlstra,
Joseph Fannin, Scott Wood, Hans J. Koch, and Michael Chan.

[ Ported to current tree and all drivers converted.  Integrated
  Stephen's follow-on kerneldoc additions, and restored poll_list
  handling to the old style to fix mutual exclusion issues.  -DaveM ]
Signed-off-by: NStephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bea3348e
  43. 06 12月, 2006 1 次提交
  45. 03 12月, 2006 5 次提交
    • S
      netpoll header cleanup · bf6bce71
      由 Stephen Hemminger 提交于 
      As Steve left netpoll beast, hopefully not to return soon.
He noticed that the header was messy. He straightened it
up and polished it a little, then waved goodbye.
Signed-off-by: NStephen Hemminger <shemminger@osdl.org>
      bf6bce71
    • S
      netpoll queue cleanup · 5de4a473
      由 Stephen Hemminger 提交于 
      The beast had a long and not very happy history. At one
point, a friend (netdump) had asked that he open up a little.
Well, the friend was long gone now, and the beast had
this dangling piece hanging (netpoll_queue).

It wasn't hard to stitch the netpoll_queue back in
where it belonged and make everything tidy.
Signed-off-by: NStephen Hemminger <shemminger@osdl.org>
      5de4a473
    • S
      netpoll retry cleanup · 2bdfe0ba
      由 Stephen Hemminger 提交于 
      The netpoll beast was still not happy. If the beast got
clogged pipes, it tended to stare blankly off in space
for a long time.

The problem couldn't be completely fixed because the
beast talked with irq's disabled. But it could be made
less painful and shorter.
Signed-off-by: NStephen Hemminger <shemminger@osdl.org>
      2bdfe0ba
    • S
      netpoll per device txq · b6cd27ed
      由 Stephen Hemminger 提交于 
      When the netpoll beast got really busy, it tended to clog
things, so it stored them for later. But the beast was putting
all it's skb's in one basket. This was bad because maybe some
pipes were clogged and others were not.
Signed-off-by: NStephen Hemminger <shemminger@osdl.org>
      b6cd27ed
    • S
      netpoll info leak · 93ec2c72
      由 Stephen Hemminger 提交于 
      After looking harder, Steve noticed that the netpoll
beast leaked a little every time it shutdown for a nap.
Not a big leak, but a nuisance kind of thing.

He took out his refcount duct tape and patched the
leak. It was overkill since there was already other
locking in that area, but it looked clean and wouldn't
attract fleas.
Signed-off-by: NStephen Hemminger <shemminger@osdl.org>
      93ec2c72
  47. 26 6月, 2006 1 次提交
  49. 13 10月, 2005 1 次提交