Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 22 2月, 2009 4 次提交
    • H
      tcp: Always set urgent pointer if it's beyond snd_nxt · 7691367d
      由 Herbert Xu 提交于 
      Our TCP stack does not set the urgent flag if the urgent pointer
does not fit in 16 bits, i.e., if it is more than 64K from the
sequence number of a packet.

This behaviour is different from the BSDs, and clearly contradicts
the purpose of urgent mode, which is to send the notification
(though not necessarily the associated data) as soon as possible.
Our current behaviour may in fact delay the urgent notification
indefinitely if the receiver window does not open up.

Simply matching BSD however may break legacy applications which
incorrectly rely on the out-of-band delivery of urgent data, and
conversely the in-band delivery of non-urgent data.

Alexey Kuznetsov suggested a safe solution of following BSD only
if the urgent pointer itself has not yet been transmitted.  This
way we guarantee that when the remote end sees the packet with
non-urgent data marked as urgent due to wrap-around we would have
advanced the urgent pointer beyond, either to the actual urgent
data or to an as-yet untransmitted packet.

The only potential downside is that applications on the remote
end may see multiple SIGURG notifications.  However, this would
occur anyway with other TCP stacks.  More importantly, the outcome
of such a duplicate notification is likely to be harmless since
the signal itself does not carry any information other than the
fact that we're in urgent mode.

Thanks to Ilpo Järvinen for fixing a critical bug in this and
Jeff Chua for reporting that bug.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Acked-by: NIlpo Järvinen <ilpo.jarvinen@helsinki.fi>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7691367d
    • R
      etherh: Get working again. · 7d3d5ec1
      由 Russell King 提交于 
      Further to a71558d0, this is round five of fixes to make etherh work
again. As mainline kernels stand, the fixes in b9a9b4b0 were the wrong
approach.

The 8390 driver was structured by Al Viro to allow the flexibility required
by platforms.  lib8390.c contains the core code which drivers explicitly
include:
- 8390.c includes lib8390.c to provide the standard ISA based driver.
- etherh.c includes it with the accessors defined for RiscPC platforms,
  where it is addressed via the MMIO accessors with a device dependent
  register spacing.

Other platform drivers do something similar.

However, b9a9b4b0 caused the kernel to contain not only the etherh private
build of lib8390 (included in etherh.c) but also lib8390.c itself, and
referred the new net_device_ops methods to the ISA version.  The result
of this is is not pretty:

Unable to handle kernel paging request at virtual address 12032030
pgd = c8330000
[12032030] *pgd=00000000
Internal error: Oops: 18331805 [#1]
Modules linked in: ipv6
CPU: 0    Not tainted  (2.6.29-rc3 #167)
PC is at do_set_multicast_list+0xd0/0x190
LR is at bitrev32+0x28/0x34
pc : [<c017aab4>]    lr : [<c0139120>]    psr: a0000093
sp : c8321d9c  ip : c8321d84  fp : c8321dbc
r10: c80c6800  r9 : 00000000  r8 : c80c6b60
r7 : c80c6b80  r6 : cc80c800  r5 : c80c6800  r4 : 00000000
r3 : cc80c80c  r2 : 00000004  r1 : 00000007  r0 : e0000000
Flags: NzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
...

Fix up b9a9b4b0 by making etherh's net_device_ops refer to the internal
lib8390 functions, and remove the build of the ISA 8390.c driver.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7d3d5ec1
    • H
      ipv6: fix sparse warning: Using plain integer as NULL pointer · 66da8c52
      由 Hannes Eder 提交于 
      Fix this sparse warning:
  net/ipv6/xfrm6_state.c:72:26: warning: Using plain integer as NULL pointer
Signed-off-by: NHannes Eder <hannes@hanneseder.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      66da8c52
    • D
      ixgbe: fix for 82598 Si errata causing buffer overflow · 54037505
      由 Don Skidmore 提交于 
      The failure happens when an interrupt occurs and the driver is reading
EICR.  This read will cause a clear-by-read which leads to two TLP
being inserted in the PCIe retry buffer leading to an overflow of the
buffer and corruption of TLPs.

The solution is different depending where the reading of EICR takes place.

For ixgbe_msix_lsc() since we are in MSIX mode and know OCD is enabled a
clear-by-write is done instead of the normal clear-by-read.

For ixgbe_intr() 0xffffffff is written to EIMC before the read, masking the
interrupts.
Signed-off-by: NDon Skidmore <donald.c.skidmore@intel.com>
Acked-by: NPeter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      54037505
  3. 21 2月, 2009 1 次提交
  5. 20 2月, 2009 10 次提交
  7. 19 2月, 2009 8 次提交
  9. 18 2月, 2009 17 次提交