- 11 Jul, 2005 1 commit
-
-
David S. Miller authored
Signed-off-by:David S. Miller <davem@davemloft.net>
-
- 10 Jul, 2005 5 commits
-
-
David S. Miller authored
Also fix a bug in 32-bit syscall tracing. We forgot to update this code when we moved over to the convention that all 32-bit syscall arguments are zero extended by default. Signed-off-by: -
David S. Miller authored
Signed-off-by: -
David S. Miller authored
Signed-off-by: -
David S. Miller authored
Signed-off-by: -
David S. Miller authored
Signed-off-by:
-
- 09 Jul, 2005 12 commits
-
-
Linus Torvalds authored
-
Linus Torvalds authored
-
Linus Torvalds authored
-
Linus Torvalds authored
-
David S. Miller authored
Signed-off-by: -
David S. Miller authored
Signed-off-by: -
David L Stevens authored
This patch fixes the multicast group matching for IP_DROP_MEMBERSHIP, similar to the IP_ADD_MEMBERSHIP fix in a prior patch. Groups are identifiedby <group address,interface> and including the interface address in the match will fail if a leave-group is done by address when the join was done by index, or if different addresses on the same interface are used in the join and leave. Signed-off-by:David L Stevens <dlstevens@us.ibm.com> Signed-off-by:
-
David L Stevens authored
1) Adds (INCLUDE, empty)/leave-group equivalence to the full-state multicast source filter APIs (IPv4 and IPv6) 2) Fixes an incorrect errno in the IPv6 leave-group (ENOENT should be EADDRNOTAVAIL) Signed-off-by:
-
David L Stevens authored
1) In the full-state API when imsf_numsrc == 0 errno should be "0", but returns EADDRNOTAVAIL 2) An illegal filter mode change errno should be EINVAL, but returns EADDRNOTAVAIL 3) Trying to do an any-source option without IP_ADD_MEMBERSHIP errno should be EINVAL, but returns EADDRNOTAVAIL 4) Adds comments for the less obvious error return values Signed-off-by:
-
David L Stevens authored
1) Changes IP_ADD_SOURCE_MEMBERSHIP and MCAST_JOIN_SOURCE_GROUP to ignore EADDRINUSE errors on a "courtesy join" -- prior membership or not is ok for these. 2) Adds "leave group" equivalence of (INCLUDE, empty) filters in the delta-based API. Without this, mixing delta-based API calls that end in an (INCLUDE, empty) filter would not allow a subsequent regular IP_ADD_MEMBERSHIP. It also frees socket buffer memory that isn't needed for both the multicast group record and source filter. Signed-off-by:
-
David L Stevens authored
This patch corrects a few problems with the IP_ADD_MEMBERSHIP socket option: 1) The existing code makes an attempt at reference counting joins when using the ip_mreqn/imr_ifindex interface. Joining the same group on the same socket is an error, whatever the API. This leads to unexpected results when mixing ip_mreqn by index with ip_mreqn by address, ip_mreq, or other API's. For example, ip_mreq followed by ip_mreqn of the same group will "work" while the same two reversed will not. Fixed to always return EADDRINUSE on a duplicate join and removed the (now unused) reference count in ip_mc_socklist. 2) The group-search list in ip_mc_join_group() is comparing a full ip_mreqn structure and all of it must match for it to find the group. This doesn't correctly match a group that was joined with ip_mreq or ip_mreqn with an address (with or without an index). It also doesn't match groups that are joined by different addresses on the same interface. All of these are the same multicast group, which is identified by group address and interface index. Fixed the check to correctly match groups so we don't get duplicate group entries on the ip_mc_socklist. 3) The old code allocates a multicast address before searching for duplicates requiring it to free in various error cases. This patch moves the allocate until after the search and igmp_max_memberships check, so never a need to allocate, then free an entry. Signed-off-by: -
Alexey Kuznetsov authored
This was the full intention of the original code. Signed-off-by:
-
- 08 Jul, 2005 22 commits
-
-
David S. Miller authored
Signed-off-by: -
Victor Fusco authored
From: Victor Fusco <victor@cetuc.puc-rio.br> Fix the sparse warning "implicit cast to nocast type" Signed-off-by:
Victor Fusco <victor@cetuc.puc-rio.br> Signed-off-by:
Domen Puncer <domen@coderock.org> Signed-off-by:
-
David S. Miller authored
This is part of the grand scheme to eliminate the qlen member of skb_queue_head, and subsequently remove the 'list' member of sk_buff. Most users of skb_queue_len() want to know if the queue is empty or not, and that's trivially done with skb_queue_empty() which doesn't use the skb_queue_head->qlen member and instead uses the queue list emptyness as the test. Signed-off-by: -
David S. Miller authored
Noticed by Eddie C. Dost Signed-off-by: -
Chris Wright authored
I've been asked about this a couple times, and there's no info in MAINTAINERS file. Add MAINTAINERS entry for audit subsystem. Signed-off-by:
Chris Wright <chrisw@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Alasdair G Kergon authored
Set the target's split_io field when building a dm-mirror device so incoming bios won't span the mirror's internal regions. Without this, regions can be accessed while not holding correct locks and data corruption is possible. Reported-By:
"Zhao Qian" <zhaoqian@aaastor.com> From: Kevin Corry <kevcorry@us.ibm.com> Signed-Off-By:
Alasdair G Kergon <agk@redhat.com> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
-
Pavel Machek authored
One more system where video works with S3. Signed-off-by:
Pavel Machek <pavel@suse.cz> Signed-off-by:
-
Hirokazu Takata authored
This patch is for supporting Epson s1d13xxx framebuffer device for m32r. # Sorry, a little bigger. The Epson s1d13806 is already supported by 2.6.12 kernel, and its driver is placed as drivers/video/s1d13xxxfb.c. For the m32r, a header file include/asm-m32r/s1d13806.h was prepared for several m32r target platforms. It was originally generated by an Epson tool S1D13806CFG.EXE, and modified manually for the m32r platforms. Signed-off-by:
Hayato Fujiwara <fujiwara@linux-m32r.org> Signed-off-by:
Hirokazu Takata <takata@linux-m32r.org> Cc: "Antonino A. Daplas" <adaplas@pol.net> Signed-off-by:
-
NeilBrown authored
After discussion at the recent NFSv4 bake-a-thon, I realized that my assumption that NFS4_FH_PERSISTENT required filehandles to persist was a misreading of the spec. This also fixes an interoperability problem with the Solaris client. Signed-off-by:
J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by:
Neil Brown <neilb@cse.unsw.edu.au> Signed-off-by:
-
NeilBrown authored
We shouldn't be allowing, e.g., write locks on files not open for read. To enforce this, we add a pointer from the lock stateid back to the open stateid it came from, so that the check will continue to be correct even after the open is upgraded or downgraded. Signed-off-by:
Andy Adamson <andros@citi.umich.edu> Signed-off-by:
-
NeilBrown authored
As long as we're here, do some miscellaneous cleanup. Signed-off-by:
-
NeilBrown authored
The handling of close_lru in preprocess_stateid_op was a source of some confusion here recently. Try to make the logic a little clearer, by renaming find_openstateowner_id to make its purpose clearer and untangling some unnecessarily complicated goto's. Signed-off-by:
-
NeilBrown authored
nfs4_preprocess_seqid_op is called by NFSv4 operations that imply an implicit renewal of the client lease. Signed-off-by:
-
NeilBrown authored
from RFC 3530: "Share reservations are established by OPEN operations and by their nature are mandatory in that when the OPEN denies READ or WRITE operations, that denial results in such operations being rejected with error NFS4ERR_LOCKED." (Note that share_denied is really only a legal error for OPEN.) Signed-off-by:
-
NeilBrown authored
An OPEN from the same client/open stateowner requires a stateid update because of the share/deny access update. Signed-off-by:
-
NeilBrown authored
We're insisting that the lock sequence id field passed in the open_to_lockowner struct always be zero. This is probably thanks to the sentence in rfc3530: "The first request issued for any given lock_owner is issued with a sequence number of zero." But there doesn't seem to be any problem with allowing initial sequence numbers other than zero. And currently this is causing lock reclaims from the Linux client to fail. In the spirit of "be liberal in what you accept, conservative in what you send", we'll relax the check (and patch the Linux client as well). Signed-off-by:
-
NeilBrown authored
Add some comments on the use of so_seqid, in an attempt to avoid some of the confusion outlined in the previous patch.... Signed-off-by:
-
NeilBrown authored
The sequence number we store in the sequence id is the last one we received from the client. So on the next operation we'll check that the client gives us the next higher number. We increment sequence id's at the last moment, in encode, so that we're sure of knowing the right error return. (The decision to increment the sequence id depends on the exact error returned.) However on the *first* use of a sequence number, if we set the sequence number to the one received from the client and then let the increment happen on encode, we'll be left with a sequence number one to high. For that reason, ENCODE_SEQID_OP_TAIL only increments the sequence id on *confirmed* stateowners. This creates a problem for open reclaims, which are confirmed on first use. Therefore the open reclaim code, as a special exception, *decrements* the sequence id, cancelling out the undesired increment on encode. But this prevents the sequence id from ever being incremented in the case where multiple reclaims are sent with the same openowner. Yuch! We could add another exception to the open reclaim code, decrementing the sequence id only if this is the first use of the open owner. But it's simpler by far to modify the meaning of the op_seqid field: instead of representing the previous value sent by the client, we take op_seqid, after encoding, to represent the *next* sequence id that we expect from the client. This eliminates the need for special-case handling of the first use of a stateowner. Signed-off-by:
-
NeilBrown authored
Yeah, it's trivial, but this drives me up the wall.... Signed-off-by:
-
NeilBrown authored
A misreading of the spec lead us to convert all errors on open and lock reclaims to RECLAIM_BAD. This causes problems--for example, a reboot within the grace period could lead to reclaims with stale stateid's, and we'd like to return STALE errors in those cases. What rfc3530 actually says about RECLAIM_BAD: "The reclaim provided by the client does not match any of the server's state consistency checks and is bad." I'm assuming that "state consistency checks" refers to checks for consistency with the state recorded to stable storage, and that the error should be reserved for that case. Signed-off-by:
-
NeilBrown authored
A GRACE or NOGRACE response to a lock request should also bump the sequence id. So we delay the handling of grace period errors till after we've found the relevant owner. Signed-off-by:
-
NeilBrown authored
The GRACE and NOGRACE errors should bump the sequence id on open. So we delay the handling of these errors until nfsd4_process_open2, at which point we've set the open owner, so the encode routine will be able to bump the sequence id. Signed-off-by:
-
