- 09 Jul, 2005 3 commits
-
-
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 <dlstevens@us.ibm.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
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 37 commits
-
-
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: -
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:
-
NeilBrown authored
We oops in list_for_each_entry(), because release_stateowner frees something on the list we're traversing. Signed-off-by:
-
NeilBrown authored
Make sure we don't try to delete client recovery directories multiple times; fixes some spurious error messages. Signed-off-by:
-
NeilBrown authored
Oops, this lookup_one_len needs the i_sem. Signed-off-by:
-
NeilBrown authored
We need to fsync the recovery directory after writing to it, but we weren't doing this correctly. (For example, we weren't taking the i_sem when calling ->fsync().) Just reuse the existing nfsd fsync code instead. Signed-off-by:
-
NeilBrown authored
We need to remove the recovery directory here too. (This chunk just got lost somehow in the process of commuting the reboot recovery patches past the other patches.) Signed-off-by:
-
Dominik Brodowski authored
As a follow-up, we can allow the yenta-driver to be limited to PCMCIA operation. Signed-off-by:
Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by:
-
Russell King authored
If probing for the correct interrupt fails on yenta bridges, the driver falls back to polling for interrupt actions. However, CardBus cards cannot be used then. Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Dominik Brodowski authored
PCMCIA/CardBus is handled by a team of developers at the specified mailing list. Additional developers wanting to help are most welcome. Signed-off-by:
-
Dominik Brodowski authored
As a follow-up, remove the inclusion of pcmcia/version.h in many files. Signed-off-by:
-
Pavel Roskin authored
One correction is needed. Changes are not needed for drivers/scsi/pcmcia/nsp_cs.c because it uses versioning in the compatibility part, which is never used in 2.6 kernels. The only right thing we could to that compatibility code would be to remove it throughout the file, but that would be a separate patch. Cc: Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by:
-
Pavel Roskin authored
The Linux PCMCIA code has some data that was apparently used (or meant to be used) to ensure that only proper client drivers are loaded. This is now ensured (to a certain degree) by the fact that the most client drivers are part of the kernel. Also, the version information has not been updated despite major changes in PCMCIA API. This has made it meaningless. This patch removes servinfo_t and pcmcia_get_card_services_info. They are not used in any userspace utilities such as pcmcia-cs and pcmciautils. drivers/pcmcia/pcmcia_ioctl.c is adjusted accordingly. CS_RELEASE and CS_RELEASE_CODE are removed. include/pcmcia/version.h is empty now. It will be removed later, but for now it's left in the tree to avoid touching all PCMCIA clients. The only driver that needs to be changed is drivers/scsi/pcmcia/nsp_cs.c, which uses CS_RELEASE_CODE. Signed-off-by:
Pavel Roskin <proski@gnu.org> Signed-off-by:
-
Dominik Brodowski authored
Reduce the occurences of "client_handle_t" which is nothing else than a pointer to struct pcmcia_device by now. Signed-off-by:
-
Dominik Brodowski authored
Reduce the occurences of "client_handle_t" which is nothing else than a pointer to struct pcmcia_device by now. Signed-off-by:
-
Dominik Brodowski authored
Move the "event handler" to struct pcmcia_driver -- the unified event handler will disappear really soon, but switching it to struct pcmcia_driver in the meantime allows for better "step-by-step" patches. Signed-off-by:
-
Dominik Brodowski authored
Schedule removal of the PCMCIA ioctl (and thus kernel support for the pcmcia-cs userspace package) for November 2005. A big "thank you" to Dave Hinds for his great work on supporting PCMCIA in Linux. Things are just done differently by now, so the ongoing work to make PCMCIA behave like any other hotpluggable bus should continue. Signed-off-by:
-
Ian Campbell authored
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=f354942cb301fed273f423fb5c4f57bde3efc5b2 converted the check_region() calls in drivers/pcmcia/i82365.c into request_regions. Unfortunately this seems to have broken things. isa_probe() used to call check_region() and then call add_pcic() which would request_region(). Now isa_probe() calls request_region() and then calls add_pcic() which calls request_region() again, this fails and add_pcic() returns immediately without doing all the setup etc. On the face of it the patch below fixes the problem, by not doing the second request region in add_pcic(). I think this is preferable to remove the call in isa_probe() since identify() touches the I/O regions and is called before add_pcic(). However I haven't fully grokked the meaning of the code which follows the request_region() in isa_probe(), so I'm not sure that the handling WRT multiple sockets and multiple bridge chips is correct. In particular I'm not convinced that the regions for subsequent sockets and/or bridges will be requested at all. I suspect a more thorough reworking by someone who understands what is going on there might be in order. I should mention that I'm actually messing about with this on an ARM platform with wacky memory and i/o mapping offsets etc, it doesn't quite work yet for other reasons which preclude full testing etc, but I think the problem above is still present for more normal x86 stuff. Signed-off-by:
Ian Campbell <icampbell@arcom.com> Signed-off-by:
-
Michael Krufky authored
- Fix bug in lgdt3302_read_status to return correct FE_HAS_SIGNAL and FS_HAS_CARRIER status. - Removed #if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,10). Signed-off-by:
Mac Michaels <wmichaels1@earthlink.net> Signed-off-by:
Michael Krufky <mkrufky@m1k.net> Signed-off-by:
-
