1. 23 Feb, 2009 7 commits
  2. 22 Feb, 2009 3 commits
    • Herbert Xu's avatar
      tcp: Always set urgent pointer if it's beyond snd_nxt · 7691367d
      Herbert Xu authored
      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: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Acked-by: default avatarIlpo Järvinen <ilpo.jarvinen@helsinki.fi>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7691367d
    • Russell King's avatar
      etherh: Get working again. · 7d3d5ec1
      Russell King authored
      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: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7d3d5ec1
    • Hannes Eder's avatar
      ipv6: fix sparse warning: Using plain integer as NULL pointer · 66da8c52
      Hannes Eder authored
      Fix this sparse warning:
        net/ipv6/xfrm6_state.c:72:26: warning: Using plain integer as NULL pointer
      Signed-off-by: default avatarHannes Eder <hannes@hanneseder.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      66da8c52
  3. 21 Feb, 2009 2 commits
  4. 20 Feb, 2009 9 commits
  5. 19 Feb, 2009 9 commits
  6. 18 Feb, 2009 10 commits