1. 17 Apr, 2009 1 commit
  2. 16 Apr, 2009 1 commit
    • Patrick McHardy's avatar
      netfilter: nf_nat: add support for persistent mappings · 98d500d6
      Patrick McHardy authored
      The removal of the SAME target accidentally removed one feature that is
      not available from the normal NAT targets so far, having multi-range
      mappings that use the same mapping for each connection from a single
      client. The current behaviour is to choose the address from the range
      based on source and destination IP, which breaks when communicating
      with sites having multiple addresses that require all connections to
      originate from the same IP address.
      
      Introduce a IP_NAT_RANGE_PERSISTENT option that controls whether the
      destination address is taken into account for selecting addresses.
      
      http://bugzilla.kernel.org/show_bug.cgi?id=12954
      
      Signed-off-by: default avatarPatrick McHardy <kaber@trash.net>
      98d500d6
  3. 15 Apr, 2009 4 commits
  4. 14 Apr, 2009 4 commits
  5. 13 Apr, 2009 1 commit
  6. 11 Apr, 2009 3 commits
  7. 07 Apr, 2009 2 commits
    • Steffen Klassert's avatar
      xfrm: fix fragmentation on inter family tunnels · d1d88e5d
      Steffen Klassert authored
      
      
      If an ipv4 packet (not locally generated with IP_DF flag not set) bigger
      than mtu size is supposed to go via a xfrm ipv6 tunnel, the packetsize
      check in xfrm4_tunnel_check_size() is omited and ipv6 drops the packet
      without sending a notice to the original sender of the ipv4 packet.
      
      Another issue is that ipv4 connection tracking does reassembling of
      incomming fragmented packets. If such a reassembled packet is supposed to
      go via a xfrm ipv6 tunnel it will be droped, even if the original sender
      did proper fragmentation.
      
      According to RFC 2473 (section 7) tunnel ipv6 packets resulting from the
      encapsulation of an original packet are considered as locally generated
      packets. If such a packet passed the checks in xfrm{4,6}_tunnel_check_size()
      fragmentation is allowed according to RFC 2473 (section 7.1/7.2).
      
      This patch sets skb->local_df in xfrm6_prepare_output() to achieve
      fragmentation in this case.
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d1d88e5d
    • Adrian Bunk's avatar
      net/802/fddi.c: add MODULE_LICENSE · d9677a45
      Adrian Bunk authored
      
      
      This patch adds the missing MODULE_LICENSE("GPL").
      Signed-off-by: default avatarAdrian Bunk <bunk@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d9677a45
  8. 06 Apr, 2009 3 commits
  9. 04 Apr, 2009 2 commits
    • Eric Dumazet's avatar
      socket: use percpu_add() while updating sockets_in_use · 4e69489a
      Eric Dumazet authored
      
      
      sock_alloc() currently uses following code to update sockets_in_use
      
      get_cpu_var(sockets_in_use)++;
      put_cpu_var(sockets_in_use);
      
      This translates to :
      
      c0436274:       b8 01 00 00 00          mov    $0x1,%eax
      c0436279:       e8 42 40 df ff          call   c022a2c0 <add_preempt_count>
      c043627e:       bb 20 4f 6a c0          mov    $0xc06a4f20,%ebx
      c0436283:       e8 18 ca f0 ff          call   c0342ca0 <debug_smp_processor_id>
      c0436288:       03 1c 85 60 4a 65 c0    add    -0x3f9ab5a0(,%eax,4),%ebx
      c043628f:       ff 03                   incl   (%ebx)
      c0436291:       b8 01 00 00 00          mov    $0x1,%eax
      c0436296:       e8 75 3f df ff          call   c022a210 <sub_preempt_count>
      c043629b:       89 e0                   mov    %esp,%eax
      c043629d:       25 00 e0 ff ff          and    $0xffffe000,%eax
      c04362a2:       f6 40 08 08             testb  $0x8,0x8(%eax)
      c04362a6:       75 07                   jne    c04362af <sock_alloc+0x7f>
      c04362a8:       8d 46 d8                lea    -0x28(%esi),%eax
      c04362ab:       5b                      pop    %ebx
      c04362ac:       5e                      pop    %esi
      c04362ad:       c9                      leave
      c04362ae:       c3                      ret
      c04362af:       e8 cc 5d 09 00          call   c04cc080 <preempt_schedule>
      c04362b4:       8d 74 26 00             lea    0x0(%esi,%eiz,1),%esi
      c04362b8:       eb ee                   jmp    c04362a8 <sock_alloc+0x78>
      
      While percpu_add(sockets_in_use, 1) translates to a single instruction :
      
      c0436275:   64 83 05 20 5f 6a c0    addl   $0x1,%fs:0xc06a5f20
      Signed-off-by: default avatarEric Dumazet <dada1@cosmosbay.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4e69489a
    • Andy Adamson's avatar
      nfsd: don't use the deferral service, return NFS4ERR_DELAY · 2f425878
      Andy Adamson authored
      
      
      On an NFSv4.1 server cache miss that causes an upcall, NFS4ERR_DELAY will be
      returned. It is up to the NFSv4.1 client to resend only the operations that
      have not been processed.
      
      Initialize rq_usedeferral to 1 in svc_process(). It sill be turned off in
      nfsd4_proc_compound() only when NFSv4.1 Sessions are used.
      
      Note: this isn't an adequate solution on its own. It's acceptable as a way
      to get some minimal 4.1 up and working, but we're going to have to find a
      way to avoid returning DELAY in all common cases before 4.1 can really be
      considered ready.
      Signed-off-by: default avatarAndy Adamson <andros@netapp.com>
      Signed-off-by: default avatarBenny Halevy <bhalevy@panasas.com>
      [nfsd41: reverse rq_nodeferral negative logic]
      Signed-off-by: default avatarBenny Halevy <bhalevy@panasas.com>
      [sunrpc: initialize rq_usedeferral]
      Signed-off-by: default avatarAndy Adamson <andros@netapp.com>
      Signed-off-by: default avatarBenny Halevy <bhalevy@panasas.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@citi.umich.edu>
      2f425878
  10. 02 Apr, 2009 7 commits
  11. 01 Apr, 2009 5 commits
  12. 31 Mar, 2009 2 commits
  13. 30 Mar, 2009 3 commits
  14. 29 Mar, 2009 2 commits