Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 03 6月, 2009 1 次提交
  3. 02 6月, 2009 1 次提交
  5. 27 5月, 2009 1 次提交
  7. 26 5月, 2009 1 次提交
    • E
      net: txq_trans_update() helper · 08baf561
      由 Eric Dumazet 提交于 
      We would like to get rid of netdev->trans_start = jiffies; that about all net
drivers have to use in their start_xmit() function, and use txq->trans_start
instead.

This can be done generically in core network, as suggested by David.

Some devices, (particularly loopback) dont need trans_start update, because
they dont have transmit watchdog. We could add a new device flag, or rely
on fact that txq->tran_start can be updated is txq->xmit_lock_owner is
different than -1. Use a helper function to hide our choice.
Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      08baf561
  9. 20 5月, 2009 1 次提交
  11. 19 5月, 2009 1 次提交
  13. 18 5月, 2009 2 次提交
  15. 07 5月, 2009 1 次提交
  17. 03 5月, 2009 1 次提交
  19. 20 4月, 2009 1 次提交
    • J
      net: sch_netem: Fix an inconsistency in ingress netem timestamps. · 8caf1539
      由 Jarek Poplawski 提交于 
      Alex Sidorenko reported:

"while experimenting with 'netem' we have found some strange behaviour. It
seemed that ingress delay as measured by 'ping' command shows up on some
hosts but not on others.

After some investigation I have found that the problem is that skbuff->tstamp
field value depends on whether there are any packet sniffers enabled. That
is:

- if any ptype_all handler is registered, the tstamp field is as expected
- if there are no ptype_all handlers, the tstamp field does not show the delay"

This patch prevents unnecessary update of tstamp in dev_queue_xmit_nit()
on ingress path (with act_mirred) adding a check, so minimal overhead on
the fast path, but only when sniffers etc. are active.

Since netem at ingress seems to logically emulate a network before a host,
tstamp is zeroed to trigger the update and pretend delays are from the
outside.
Reported-by: NAlex Sidorenko <alexandre.sidorenko@hp.com>
Tested-by: NAlex Sidorenko <alexandre.sidorenko@hp.com>
Signed-off-by: NJarek Poplawski <jarkao2@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8caf1539
  21. 14 4月, 2009 1 次提交
  23. 22 3月, 2009 1 次提交
  25. 16 3月, 2009 1 次提交
    • J
      pkt_sched: Change misleading code in class delete. · 7cd0a638
      由 Jarek Poplawski 提交于 
      While looking for a possible reason of bugzilla report on HTB oops:
http://bugzilla.kernel.org/show_bug.cgi?id=12858
I found the code in htb_delete calling htb_destroy_class on zero
refcount is very misleading: it can suggest this is a common path, and
destroy is called under sch_tree_lock. Actually, this can never happen
like this because before deletion cops->get() is done, and after
delete a class is still used by tclass_notify. The class destroy is
always called from cops->put(), so without sch_tree_lock.

This doesn't mean much now (since 2.6.27) because all vulnerable calls
were moved from htb_destroy_class to htb_delete, but there was a bug
in older kernels. The same change is done for other classful scheds,
which, it seems, didn't have similar locking problems here.
Reported-by: Nm0sia <m0sia@m0sia.ru>
Signed-off-by: NJarek Poplawski <jarkao2@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7cd0a638
  27. 05 3月, 2009 1 次提交
  29. 27 2月, 2009 1 次提交
  31. 10 2月, 2009 1 次提交
  33. 01 2月, 2009 3 次提交
  35. 13 1月, 2009 2 次提交
  37. 09 1月, 2009 1 次提交
  39. 07 1月, 2009 1 次提交
  41. 06 1月, 2009 2 次提交
  43. 05 1月, 2009 1 次提交
    • M
      net: Fix for initial link state in 2.6.28 · 22604c86
      由 Michael Marineau 提交于 
      From: Michael Marineau <mike@marineau.org>

Commit b4730016 "Do not fire linkwatch
events until the device is registered." was made as a workaround for
drivers that call netif_carrier_off before registering the device.
Unfortunately this causes these drivers to incorrectly report their
link status as IF_OPER_UNKNOWN which can falsely set the IFF_RUNNING
flag when the interface is first brought up. This issues was
previously pointed out[1] but was dismissed saying that IFF_RUNNING is
not related to the link status. From my digging IFF_RUNNING, as
reported to userspace, is based on the link state. It is set based on
__LINK_STATE_START and IF_OPER_UP or IF_OPER_UNKNOWN. See [2], [3],
and [4]. (Whether or not the kernel has IFF_RUNNING set in flags is
not reported to user space so it may well be independent of the link,
I don't know if and when it may get set.)

The end result depends slightly depending on the driver. The the two I
tested were e1000e and b44. With e1000e if the system is booted
without a network cable attached the interface will falsely report
RUNNING when it is brought up causing NetworkManager to attempt to
start it and eventually time out. With b44 when the system is booted
with a network cable attached and brought up with dhcpcd it will time
out the first time.

The attached patch that will still set the operstate variable
correctly to IF_OPER_UP/DOWN/etc when linkwatch_fire_event is called
but then return rather than skipping the linkwatch_fire_event call
entirely as the previous fix did. (sorry it isn't inline, I don't have
a patch friendly email client at the moment)
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      22604c86
  45. 30 12月, 2008 3 次提交
  47. 23 12月, 2008 1 次提交
  49. 22 12月, 2008 1 次提交
  51. 15 12月, 2008 1 次提交
  53. 10 12月, 2008 2 次提交
  55. 04 12月, 2008 5 次提交