- 04 Jan, 2005 20 commits
-
-
Rusty Russell authored
Patrick McHardy spotted this, on top of previous fix. I neatened it. Signed-off-by:
Rusty Russell <rusty@rustcorp.com.au> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Rusty Russell authored
FTP connection tracking assumes it can just dereference tcphdr; not neccessarily true now we don't linearize in ftp conntrack helper or tcp connection tracking. Also found by nfsim. Signed-off-by:
-
Rusty Russell authored
The nat core calls skb_ip_make_writable() with a length too short. Found by nfsim. Signed-off-by:
-
Rusty Russell authored
UDP and TCP refer to potentially stale pointers after calling skb_ip_make_writable(), and UDP calls it with the wrong len argument. All found by nfsim. Signed-off-by:
-
Rusty Russell authored
Here is a patch that just makes it use get_free_pages to test the TLB theory. Another obvious improvement would be to not use list_heads for the hash table buckets - a single pointer would likely suffice and it would cut the hash table in half, saving cache, TLB and memory. Signed-off-by: -
Rusty Russell authored
The multiport match doesn't support ranges of ports, so a new match called "mport" was written. Now we have versioning of matches and targets, we can simply put this extension in multiport revision 1. Also, removes gratuitous checking in match: we basically trust iptables userspace these days. Signed-off-by:
Pablo Neira Ayuso <pablo@eurodev.net> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> (modified) Signed-off-by:
-
Rusty Russell authored
Anders Fugmann <afu@fugmann.dhs.org> wrote a patch to add bitops to ipt_MARK. I made a version based on the revision patch. Bart De Schuymer <bdschuym@pandora.be> provided the idea of overriding the target type. Signed-off-by:
-
Rusty Russell authored
This adds a new getsockopt to iptables, which allows userspace to query the revision number of extensions. iptables 1.3.0 (to be released soon) already has support for this. Signed-off-by:
-
Rusty Russell authored
Pablo Neira <pablo@eurodev.net> came up with the idea of stealing the last byte in the (already nul-terminated) name of a target/match to create a version. That patch motivated me to clean up the match and target searching in ip_tables, which makes this patch more trivial. I also renamed "version" to "revision" since the word "version" was used for iptables itself. Signed-off-by:
-
Rusty Russell authored
We now have a convenient kmod macro try_then_request_module(). 1) Split our current "generic" function into separate find_target_lock(), find_table_lock() and find_match_lock() functions explicitly. 2) Have those functions do try_module_get() for us, and fix up the one caller who didn't do that anyway. 3) Have the caller use try_then_request_module(). 4) Remove __ipt_mutex_up() and __ipt_find_target_lock() which weren't used (even in patch-o-matic AFAICT). This cleanup takes us closer to using standard list macros everywhere, and makes the version patch simpler. Signed-off-by:
-
Rusty Russell authored
We currently choose a "random" IP address to NAT to, where we have a range. Martin Josefsson pointed out that he uses the SAME target in iptables because changing IP addresses breaks Internet banking sites (among others) which assume the customer will be coming from a consistent IP address. In fact, we spend a fair bit of effort trying to balance the number of connections we NAT to each IP address. We can come pretty damn close just hashing the source and destination IP addresses, and it has the consistency property which is so desirable, as well as being faster. Signed-off-by:
-
Rusty Russell authored
Now we no longer do extra mangling, warn in that case. Signed-off-by:
-
Rusty Russell authored
On NF_IP_LOCAL_OUT, when destination NAT changes the destination interface, we also change the source address, so the packet is the same as if it were generated to go that way in the first place. This is not strictly necessary, I believe. This patch rips that code out to see what breaks. Signed-off-by:
-
Rusty Russell authored
On NF_IP_LOCAL_OUT or NF_IP_PRE_ROUTING, if destination NAT is not sufficient to create a unique tuple, we try changing the source port as well. However, this is also not strictly necessary: if the tuple is not unique, we will also try to change the source on the NF_IP_POST_ROUTING hook. When we finally confirm the connection, if the tuple is still not unique the packet will be dropped (this is required anyway as we could race: the conntrack is not placed in the hash until the packet is about to leave the box anyway). In fact, we only need best effort *everywhere*. This patch rips that code out to see what breaks. Signed-off-by:
-
Rusty Russell authored
ip_conntrack_alter_reply checks that the reply isn't already taken, but there's little point, since there's *still* a race after it is called (which we handle at confirm time anyway). Signed-off-by: -
Rusty Russell authored
The NAT code has the concept of multiple ranges: you can say "map this connection onto IP 192.168.1.2 - 192.168.1.4, 192.168.1.7 ports 1024-65535, and 192.168.1.10". I implemented this because we could. But it's not actually *used* by many (any?) people, and you can approximate this by a random match (from patch-o-matic) if you really want to. It adds complexity to the code. Signed-off-by:
-
Rusty Russell authored
Writing the nfsim testcase for the ECN target revealed a hole in the rule checking: when checking whether the rule specified TCP, you need to check it isn't inverted. Signed-off-by:
-
Rusty Russell authored
nfsim now generates non-linear packets: when run under valgrind it finds linear assumptions very nicely. This is the second thing I tried, and it found a real bug. In this case, checking the UDP checksum is correct, but overkill, and like the ICMP header handling, does not handle non-linear packets. Remove UDP checksum, fix ICMP error. Signed-off-by: Rusty Russell Signed-off-by: -
Chris Wright authored
OK, somehow I managed to botch this one. It happens to work fine, but I should have been more careful with forward porting this 1+ year old patch. The exec-time calc should go in bprm_apply_creds, not bprm_free_security. Thanks to Stephen for spotting my mistake. Signed-off-by:
Chris Wright <chrisw@osdl.org> Signed-off-by:
-
bk://nfsclient.bkbits.net/linux-2.6Linus Torvalds authored
into ppc970.osdl.org:/home/torvalds/v2.6/linux
-
- 05 Jan, 2005 1 commit
-
-
bk://nfsclient.bkbits.net/linux-2.6Trond Myklebust authored
into fys.uio.no:/home/linux/bitkeeper/nfsclient-2.6
-
- 04 Jan, 2005 19 commits
-
-
Trond Myklebust authored
Don't label all retries as "server seeing garbage". Report correct error for buffer overflows. Fix incorrect buffer overflow test that was masking AUTH_REJECTEDCRED, AUTH_REJECTEDVERF,... errors. Signed-off-by:Trond Myklebust <Trond.Myklebust@netapp.com>
-
Trond Myklebust authored
Description: Fix an NFS client bug introduced in 2.6.9-rc1. The "df" command was reporting the size of NFS file systems incorrectly. Signed-off-by:
Chuck Lever <cel@netapp.com> Signed-off-by:
Trond Myklebust <trond.myklebust@fys.uio.no>
-
Trond Myklebust authored
cache. Signed-off-by: -
Trond Myklebust authored
The behavior enabled by the "noac" mount option should be precisely equivalent to setting acreg{min,max} or acdir{min,max} to zero via mount options. Signed-off-by: -
Trond Myklebust authored
Other parts of the NFS client invoke nfs_wb_all() when they want to flush dirty cache pages. The direct path needs to do that, too. Signed-off-by:
-
Trond Myklebust authored
The initial implementation of NFS direct reads was entirely synchronous. The direct read logic issued one NFS READ operation at a time, and waited for the server's reply before issuing the next one. For large direct read requests, this is unnecessarily slow. This patch changes the NFS direct read path to dispatch NFS READ operations for a single direct read request in parallel and wait for them once. The direct read path is still synchronous in nature, but because the NFS READ operations are going in parallel, the completion wait should be much shorter. Signed-off-by:
-
Trond Myklebust authored
Reduce stack utilization in the NFS direct read path by using a dynamically allocated nfs_read_data structure instead of allocating one on the stack. This reduces stack utilization of nfs_direct_read_seg from over 900 bytes to less than 100 bytes. Signed-off-by:
-
Trond Myklebust authored
Reduce stack utilization in the NFS direct write path by using a dynamically allocated nfs_write_data structure instead of allocating one on the stack. This reduces stack utilization of nfs_direct_write_seg from over 900 bytes to less than 100 bytes. Signed-off-by:
-
Trond Myklebust authored
Immediately return control to the application if a short NFS write is detected in the NFS client's direct write path. This is better behavior than what the direct write path does today, which could result in data appearing at the wrong offset in the file. Eventually this code path should retry short writes at least once before giving up. Signed-off-by:
-
Trond Myklebust authored
Replace a C macro with sizeof(). Signed-off-by:
-
Trond Myklebust authored
Description: Ethereal and other tools display RPC XIDs in host order. This patch changes the RPC trace messages that display XIDs to print them in host order so they can be easily matched to XIDs that appear in Ethereal. Signed-off-by:
-
Trond Myklebust authored
Improve trace debugging messages for NFSv2/3 GETATTR and SETATTR procedures. Signed-off-by:
-
Trond Myklebust authored
Recently a patch set was accepted to allow the Linux NFS client to handle short writes by retrying the unwritten portion of the request. The only case that now results in an error is when the server makes no progress; that is, writes zero bytes. This patch changes the kernel log warning that is generated in that case to reflect the error condition more accurately. Signed-off-by:
-
Trond Myklebust authored
sillyrenames when renaming to an existing file. Signed-off-by:
Greg Banks <gnb@melbourne.sgi.com> Signed-off-by:
-
Trond Myklebust authored
Signed-off-by: -
Trond Myklebust authored
Signed-off-by: -
Trond Myklebust authored
know there are no pending timers. Signed-off-by: -
Trond Myklebust authored
inodes may be marked as stale in one instance (causing the dentry to be dropped) then re-enabled in the next instance. Signed-off-by: -
Trond Myklebust authored
Although it usually means that someone has deleted a file on the server, the ESTALE error may also indicate that the sysadmin has used exportfs to deny our client access to the server. Most NFS implementations therefore consider it a non-permanent condition, and allow inodes to "recover" when the sysadmin re-enables access. If, however, you want to work with broken servers, like unfsd, that reuse filehandles for new files after the original file gets deleted, then "recovery" is impossible, since it may be that the filehandle now points to a different file. Note that this is broken server behaviour that may happen even without us ever seeing the ESTALE error. In order to minimize (but we can never eliminate entirely) this race condition on unfsd servers, Linux has traditionally made ESTALE a permanent condition on all filehandles except the root filehandle. The problem is that if we apply this strict staleness criterion to directories (particularly so for he current directory), then all processes will need to re-walk the path starting from the mount point, in order to recover from the sysadmin intervention case. As this is not usual on other *NIX implementations, and may in any case be undermined by caching rules etc, this is being seen as a usability problem. This patch makes ESTALE a non-permanent condition on directories, but preserves the current behaviour for non-directories. Signed-off-by:
-
