Commits · e31cd2a33e417cd7e9328dfa32449223c968297c · nexedi / linux

07 Sep, 2004 11 commits

[PKT_SCHED]: Fix gact compile warnings. · e31cd2a3
Jamal Hadi Salim authored Sep 06, 2004
```
Signed-off-by: David S. Miller <davem@davemloft.net>
```
e31cd2a3

[NET]: Move SOCK_foo types into linux/net.h · f758b3ae

Arnaldo Carvalho de Melo authored Sep 06, 2004

Every arch defines them the same without exception
and with this we only need to update one spot when
adding new socket types.
Signed-off-by: Arnaldo Carvalho de Melo <acme@conectiva.com.br>
Signed-off-by: David S. Miller <davem@davemloft.net>

f758b3ae

[NET]: Do less atomic count changes in dev_queue_xmit. · 43da55cb
Andi Kleen authored Sep 06, 2004
```
With suggestions from Herbert Xu
Signed-off-by: David S. Miller <davem@davemloft.net>
```
43da55cb

[NET]: Fully plug netigh_create/inetdev_destroy race. · cb402627

Herbert Xu authored Sep 06, 2004

So here is a patch to make sure that there is a barrier between the
reading of dev->*_ptr and *dev->neigh_parms.

With these barriers in place, it's clear that *dev->neigh_parms can no
longer be NULL since once the parms are allocated, that pointer is never
reset to NULL again.  Therefore I've also removed the parms check in
these paths.

They were bogus to begin with since if they ever triggered then we'll
have dead neigh entries stuck in the hash table.

Unfortunately I couldn't arrange for this to happen with DECnet due
to the dn_db->parms.up() call that's sandwiched between the assignment
of dev->dn_ptr and dn_db->neigh_parms.  So I've kept the parms check
there but it will now fail instead of continuing.  I've also added an
smp_wmb() there so that at least we won't be reading garbage from
dn_db->neigh_parms.

DECnet is also buggy since there is no locking at all in the destruction
path.  It either needs locking or RCU like IPv4.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>

cb402627

[PACKET]: Fix deref before NULL check in packet_release() · 0c5b8d8a

Dave Jones authored Sep 06, 2004

Using the automated source checker at coverity.com, they picked up
on some code in packet_release() where a NULL check was done
after dereferencing.  Patch below.
Signed-off-by: Dave Jones <davej@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

0c5b8d8a

[AX25]: Fix digipeat leak. · 2f122062

Dave Jones authored Sep 06, 2004

Signed-off-by: Dave Jones <davej@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

2f122062

[SUNGEM]: Add NAPI support. · 6cb553d2
Eric Lemoine authored Sep 06, 2004
```
Signed-off-by: David S. Miller <davem@davemloft.net>
```
6cb553d2
[NET]: Fix CONFIG_COMPAT build with networking disabled. · f77bdc6f
Andi Kleen authored Sep 06, 2004
```
Signed-off-by: David S. Miller <davem@davemloft.net>
```
f77bdc6f

[TCP]: Make sure SKB tso factor is setup early enough. · 5a6bdc92

David S. Miller authored Sep 06, 2004

It needs to be set so that congestion window
calculations have a valid value to work with.
This means that doing it at write queue running
time is too late.
Signed-off-by: David S. Miller <davem@davemloft.net>

5a6bdc92

[TCP]: Calculate SKB tso factor more accurately. · 95d26736

David S. Miller authored Sep 06, 2004

Eliminate tp->mss_tso_factor.  Instead, we calculate the
SKB tso factor as we walk the write queue for initial
transmit or fragment SKBs.
Signed-off-by: David S. Miller <davem@davemloft.net>

95d26736

[TCP]: Make TSO play nice with congestion window. · 14a1f445

David S. Miller authored Sep 06, 2004

Previously TSO would not abide by the congestion
window properly.  Essentially, each TSO packet would
be trated just like 1 normal packet, even though a TSO
packet generates more than 1 normal packet.  This
violates congestion window rules entirely.

So now we record the TSO factor, a count of how many
real packets a TSO packet will generate, and include
this in all the packet counting routines.

This initial version has a bug in that skb_entail() is
not the correct time to figure out the TSO factor for
the SKB, and tp->mss_tso_factor is not necessarily the
right value for a given SKB.  Will fix this up next.
Signed-off-by: David S. Miller <davem@davemloft.net>

14a1f445

03 Sep, 2004 1 commit

[NET]: Add reference counting to neigh_parms. · 10bc9563

Herbert Xu authored Sep 02, 2004

I've added a refcnt on neigh_parms as well as a dead flag.  The latter
is checked under the tbl_lock before adding a neigh entry to the hash
table.

The non-trivial bit of the patch is the first chunk of net/core/neighbour.c.
I removed that line because not doing so would mean that I have to drop
the reference to the parms right there.  That would've lead to race
conditions since many places dereference neigh->parms without holding
locks.  It's also unnecessary to reset n->parms since we're no longer
in a hurry to see it go due to the new ref counting.

You'll also notice that I've put all dereferences of dev->*_ptr under
the rcu_read_lock().  Without this we may get a neigh_parms that's
already been released.

Incidentally a lot of these places were racy even before the RCU change.
For example, in the IPv6 case neigh->parms may be set to a value that's
just been released.

Finally in order to make sure that all stale entries are purged as
quickly as possible I've added neigh_ifdown/arp_ifdown calls after
every neigh_parms_release call.  In many cases we now have multiple
calls to neigh_ifdown in the shutdown path.  I didn't remove the
earlier calls because there may be hidden dependencies for them to
be there.  Once the respective maintainers have looked at them we
can probably remove most of them.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>

10bc9563

02 Sep, 2004 28 commits

[CREDITS]: Update netfilter entries. · 954bebf6

Harald Welte authored Sep 02, 2004

Add missing entries for netfilter core team
members, and update Rusty's personal URL.
Signed-off-by: Harald Welte <laforge@netfilter.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

954bebf6

[PKT_SCHED]: Fixed missed return in tcf_hash_init(). · 831eba9c
David S. Miller authored Sep 02, 2004
```
Noticed by Andrew Morton.
Signed-off-by: David S. Miller <davem@davemloft.net>
```
831eba9c

[NETFILTER]: Fix deadlock condition in conntrack/nat-helpers · 7cd101a5

Patrick McHardy authored Sep 02, 2004

There is a possible deadlock condition with conntrack/nat-helpers:

CPU1:
conntrack-helper:help: lock(private_lock)
ip_conntrack_expect_related: write_lock(ip_conntrack_lock)

CPU2:
nat-core:do_bindings: read_lock(ip_conntrack_lock)
nat-helper:help: lock(private_lock)

The lock in the nat-helper is unneccessary because the expectation
is never changed and is protected by ip_conntrack_lock.
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Harald Welte <laforge@netfilter.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

7cd101a5

[NETFILTER]: Fix confusing naming in NAT-helpers · 3c9df440

Patrick McHardy authored Sep 02, 2004

Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Harald Welte <laforge@netfilter.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

3c9df440

[PATCH] NFS: older gcc's don't like unsized arrays · 3411df4e

Andrew Morton authored Sep 02, 2004

The NFS symlink code cleanup causes older gcc's to barf.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

3411df4e

[PATCH] NFSv3: Fix up an unaligned access error in nfs3_proc_unlink_setup() · f409ac77
Trond Myklebust authored Sep 02, 2004
```
Signed-off-by: Trond Myklebust <trond.myklebust@fys.uio.no>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
```
f409ac77

[PATCH] NFS: fix problem of ESTALE errors on NFSv2 symlinks · da68991d

Trond Myklebust authored Sep 02, 2004

NFSv2: Fix another bad filehandle cast.
NFSv2: The symlink operation does not return a valid filehandle.
Signed-off-by: Trond Myklebust <trond.myklebust@fys.uio.no>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

da68991d

[PATCH] NFS: clean up the new symlink code · c8030e55

Trond Myklebust authored Sep 02, 2004

  - Now that the VFS no longer uses it, we don't need to cache the symlink
    string length.
  - Make ->readlink() take page offset+length arguments
  - Fix up page under/overflow checking on the readlink XDR code so that
    it matches read/write.
Signed-off-by: Trond Myklebust <trond.myklebust@fys.uio.no>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

c8030e55

The coverity source checker is wrong. Revert some of the "leak fixes". · d6ea9da0

Linus Torvalds authored Sep 02, 2004

Thanks to Davem for noticing. We probably should _not_ trust the
coverity reports that much.

Cset exclude: davej@redhat.com[torvalds]|ChangeSet|20040902213928|62770
Cset exclude: davej@redhat.com[torvalds]|ChangeSet|20040902213829|63705

d6ea9da0

Merge davem@nuts.davemloft.net:/disk1/BK/net-2.6 · 232cebfb
David S. Miller authored Sep 02, 2004
```
into kernel.bkbits.net:/home/davem/net-2.6
```
232cebfb
[IPV4/IPV6]: Use csum_sub() instead of csum_block_sub() w/zero 3rd arg. · 7511efde
Herbert Xu authored Sep 02, 2004
```
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
```
7511efde

[PATCH] fixed pidhashing patch · 37cbd41d

Kirill Korotaev authored Sep 02, 2004

This patch fixes strange and obscure pid implementation in current kernels:
- it removes calling of put_task_struct() from detach_pid()
  under tasklist_lock. This allows to use blocking calls
  in security_task_free() hooks (in __put_task_struct()).
- it saves some space = 5*5 ints = 100 bytes in task_struct
- it's smaller and tidy, more straigthforward and doesn't use
  any knowledge about pids using and assignment.
- it removes pid_links and pid_struct doesn't hold reference counters
  on task_struct. instead, new pid_structs and linked altogether and
  only one of them is inserted in hash_list.

Signed-off-by: Kirill Korotaev (kksx@mail.ru)
Signed-off-by: William Irwin <wli@holomorphy.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

37cbd41d

[PATCH] i386 reduce spurious interrupt noise · 3345ee71

Chris Wedgwood authored Sep 02, 2004

i386 hardware can (and does) see spurious interrupts from time to
tome.  Ideally I would like the printk removed completely but this is
probably good enough for now.
Signed-off-by: Chris Wedgwood <cw@f00f.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>