Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 25 3月, 2008 1 次提交
    • P
      [NEIGH]: Fix race between pneigh deletion and ipv6's ndisc_recv_ns (v3). · fa86d322
      由 Pavel Emelyanov 提交于 
      Proxy neighbors do not have any reference counting, so any caller
of pneigh_lookup (unless it's a netlink triggered add/del routine)
should _not_ perform any actions on the found proxy entry. 

There's one exception from this rule - the ipv6's ndisc_recv_ns() 
uses found entry to check the flags for NTF_ROUTER.

This creates a race between the ndisc and pneigh_delete - after 
the pneigh is returned to the caller, the nd_tbl.lock is dropped 
and the deleting procedure may proceed.

One of the fixes would be to add a reference counting, but this
problem exists for ndisc only. Besides such a patch would be too 
big for -rc4.

So I propose to introduce a __pneigh_lookup() which is supposed
to be called with the lock held and use it in ndisc code to check
the flags on alive pneigh entry.


Changes from v2:
As David noticed, Exported the __pneigh_lookup() to ipv6 module. 
The checkpatch generates a warning on it, since the EXPORT_SYMBOL 
does not follow the symbol itself, but in this file all the 
exports come at the end, so I decided no to break this harmony.

Changes from v1:
Fixed comments from YOSHIFUJI - indentation of prototype in header
and the pndisc_check_router() name - and a compilation fix, pointed
by Daniel - the is_routed was (falsely) considered as uninitialized
by gcc.
Signed-off-by: NPavel Emelyanov <xemul@openvz.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fa86d322
  3. 21 3月, 2008 1 次提交
  5. 05 3月, 2008 1 次提交
  7. 04 3月, 2008 1 次提交
  9. 29 2月, 2008 2 次提交
  11. 24 2月, 2008 2 次提交
  13. 20 2月, 2008 3 次提交
  15. 18 2月, 2008 2 次提交
  17. 14 2月, 2008 2 次提交
  19. 13 2月, 2008 4 次提交
    • M
      [NET]: Fix race in dev_close(). (Bug 9750) · d8b2a4d2
      由 Matti Linnanvuori 提交于 
      There is a race in Linux kernel file net/core/dev.c, function dev_close.
The function calls function dev_deactivate, which calls function
dev_watchdog_down that deletes the watchdog timer. However, after that, a
driver can call netif_carrier_ok, which calls function
__netdev_watchdog_up that can add the watchdog timer again. Function
unregister_netdevice calls function dev_shutdown that traps the bug
!timer_pending(&dev->watchdog_timer). Moving dev_deactivate after
netif_running() has been cleared prevents function netif_carrier_on
from calling __netdev_watchdog_up and adding the watchdog timer again.
Signed-off-by: NMatti Linnanvuori <mattilinnanvuori@yahoo.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d8b2a4d2
    • L
      [RTNETLINK]: Send a single notification on device state changes. · 45b50354
      由 Laszlo Attila Toth 提交于 
      In do_setlink() a single notification is sent at the end of the
function if any modification occured. If the address has been changed,
another notification is sent.

Both of them is required because originally only the NETDEV_CHANGEADDR
notification was sent and although device state change implies address
change, some programs may expect the original notification. It remains
for compatibity.

If set_operstate() is called from do_setlink(), it doesn't send a
notification, only if it is called from rtnl_create_link() as earlier.
Signed-off-by: NLaszlo Attila Toth <panther@balabit.hu>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      45b50354
    • U
      [NET]: Fix comment for skb_pull_rcsum · fee54fa5
      由 Urs Thuermann 提交于 
      Fix comment for skb_pull_rcsum
Signed-off-by: NUrs Thuermann <urs@isnogud.escape.de>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fee54fa5
    • D
      [NDISC]: Fix race in generic address resolution · 69cc64d8
      由 David S. Miller 提交于 
      Frank Blaschka provided the bug report and the initial suggested fix
for this bug.  He also validated this version of this fix.

The problem is that the access to neigh->arp_queue is inconsistent, we
grab references when dropping the lock lock to call
neigh->ops->solicit() but this does not prevent other threads of
control from trying to send out that packet at the same time causing
corruptions because both code paths believe they have exclusive access
to the skb.

The best option seems to be to hold the write lock on neigh->lock
during the ->solicit() call.  I looked at all of the ndisc_ops
implementations and this seems workable.  The only case that needs
special care is the IPV4 ARP implementation of arp_solicit().  It
wants to take neigh->lock as a reader to protect the header entry in
neigh->ha during the emission of the soliciation.  We can simply
remove the read lock calls to take care of that since holding the lock
as a writer at the caller providers a superset of the protection
afforded by the existing read locking.

The rest of the ->solicit() implementations don't care whether the
neigh is locked or not.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      69cc64d8
  21. 08 2月, 2008 2 次提交
  23. 05 2月, 2008 1 次提交
  25. 04 2月, 2008 1 次提交
  27. 03 2月, 2008 1 次提交
  29. 02 2月, 2008 3 次提交
  31. 01 2月, 2008 4 次提交
  33. 29 1月, 2008 9 次提交