- 02 Sep, 2004 28 commits
-
-
Andrew Morton authored
The NFS symlink code cleanup causes older gcc's to barf. Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Trond Myklebust authored
Signed-off-by: Trond Myklebust <trond.myklebust@fys.uio.no> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Trond Myklebust authored
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>
-
Trond Myklebust authored
- 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>
-
Linus Torvalds authored
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
-
David S. Miller authored
into kernel.bkbits.net:/home/davem/net-2.6
-
Herbert Xu authored
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Kirill Korotaev authored
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>
-
Chris Wedgwood authored
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>
-
Dave Jones authored
Spotted with the source checker from Coverity.com. Signed-off-by: Dave Jones <davej@redhat.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Dave Jones authored
It can return NULL, so check for it. Spotted with the source checker from Coverity.com. Signed-off-by: Dave Jones <davej@redhat.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Dave Jones authored
Spotted with the source checker from Coverity.com. Signed-off-by: Dave Jones <davej@redhat.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Dave Jones authored
This looks odd, but there doesn't seem to be an isapnp_free() or similar.. Spotted with the source checker from Coverity.com. Signed-off-by: Dave Jones <davej@redhat.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Dave Jones authored
Spotted with the source checker from Coverity.com. Signed-off-by: Dave Jones <davej@redhat.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Dave Jones authored
Spotted with the source checker from Coverity.com. Signed-off-by: Dave Jones <davej@redhat.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Dave Jones authored
It appears that 'new' can be allocated, and next time around the loop, if something goes wrong, we lose the reference.. Spotted with the source checker from Coverity.com. Signed-off-by: Dave Jones <davej@redhat.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Dave Jones authored
Spotted with the source checker from Coverity.com. Signed-off-by: Dave Jones <davej@redhat.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Dave Jones authored
Spotted with the source checker from Coverity.com. Signed-off-by: Dave Jones <davej@redhat.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Dave Jones authored
Spotted with the source checker from Coverity.com. Signed-off-by: Dave Jones <davej@redhat.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Dave Jones authored
We dereference 'z' a few lines above this check. If it was possible to hit this condition, it wouldve triggered long ago, in the form of a crash. Spotted with the source checker from Coverity.com. Signed-off-by: Dave Jones <davej@redhat.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Dave Jones authored
1. If the ScatterGatherPool allocation fails, its pointless trying to allocate a RequestSensePool. 2. Free up the ScatterGatherPool if the RequestSensePool allocation fails. Spotted with the source checker from Coverity.com. Signed-off-by: Dave Jones <davej@redhat.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Dave Jones authored
Spotted with the source checker from Coverity.com. Signed-off-by: Dave Jones <davej@redhat.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Dave Jones authored
Spotted with the source checker from Coverity.com. Signed-off-by: Dave Jones <davej@redhat.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Dave Jones authored
Spotted with the source checker from Coverity.com. Signed-off-by: Dave Jones <davej@redhat.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Patrick McHardy authored
Yoshifuji's recent fragment patch prevents unnecessary fragmentation when the data can be kept in a single packet, but only for the first packet. When fragmenting, all fragments are still truncated to multiples of 8 and we might end up creating an unnecessary fragment. This dump shows the problem (MTU 1499): 172.16.1.123.32771 > 172.16.195.3.4135: udp 2937 (frag 7066:1472@0+) 172.16.1.123 > 172.16.195.3: udp (frag 7066:1472@1472+) 172.16.1.123 > 172.16.195.3: udp (frag 7066:1@2944) This patch always builds mtu sized fragments and truncates the previous fragment to a multiple of 8 bytes when allocating a new one. With the patch the dump looks like this: 172.16.1.123.32772 > 172.16.195.3.4135: udp 2937 (frag 49641:1472@0+) 172.16.1.123 > 172.16.195.3: udp (frag 49641:1473@1472) Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Eric Lemoine authored
Signed-off-by: David S. Miller <davem@davemloft.net>
-
Harald Welte authored
Signed-off-by: Harald Welte <laforge@netfilter.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Dave Jones authored
Spotted with the source checker from Coverity.com. Signed-off-by: Dave Jones <davej@redhat.com> Signed-off-by: Armin Schindler <armin@melware.de>
-
- 01 Sep, 2004 12 commits
-
-
bk://kernel.bkbits.net/davem/net-2.6Linus Torvalds authored
into ppc970.osdl.org:/home/torvalds/v2.6/linux
-
bk://cifs.bkbits.net/linux-2.5cifsLinus Torvalds authored
into ppc970.osdl.org:/home/torvalds/v2.6/linux
-
Steve French authored
Signed-of-by: Steve French (sfrench@us.ibm.com)
-
David S. Miller authored
into kernel.bkbits.net:/home/davem/sparc-2.6
-
David S. Miller authored
into nuts.davemloft.net:/disk1/BK/net-2.6
-
David S. Miller authored
Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jamal Hadi Salim authored
Signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Herbert Xu authored
If we end up with a fraggap, when we copy the data over to the next frag being built we must compute a checksum for the bit we copy over for the new fragment and subtract that checksum from the place we are copying it from. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Signed-off-by: David S. Miller <davem@davemloft.net>
-
Steve French authored
Signed-off-by: Steve French (sfrench@us.ibm.com)
-
Harald Welte authored
Signed-off-by: Harald Welte <laforge@netfilter.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Harald Welte authored
Signed-off-by: Harald Welte <laforge@netfilter.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-