- 01 Jul, 2006 40 commits
-
-
Evgeniy Dushistov authored
This patch fixes buggy behaviour of UFS in such kind of scenario: open(, O_TRUNC...) ftruncate(, 1024) ftruncate(, 0) Such a scenario causes ufs_panic and remount read-only. This happen because of according to specification UFS should always allocate block for last byte, and many parts of our implementation rely on this, but `ufs_truncate' doesn't care about this. To make possible return error code and to know about old size, this patch removes `truncate' from ufs inode_operations and uses `setattr' method to call ufs_truncate. Signed-off-by:
Evgeniy Dushistov <dushistov@mail.ru> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Paolo 'Blaisorblade' Giarrusso authored
Rename actually_do_remove() to remove_files_and_dir(), make it call closedir(), make it ignore ENOENT (I see it frequently enough). ENOENT is probably due to multiple threads calling the exitcall functions together*, but fixing that is non-trivial; and ignoring it is perfectly ok in any case. * it can surely happen: last_ditch_exit() is installed as SIGTERM handler at boot, and it's not removed on thread creation. So killall vmlinux (which I do) surely causes that. I've seen also a crash which seems to do the same. Installing the handler on only the main thread would make UML do no cleanup when another thread exits, and we're not sure we want that. And mutual exclusion in that context is tricky - we can't use spinlock in code not on a kernel stack (spinlock debugging uses "current" a lot). Signed-off-by:
Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Cc: Jeff Dike <jdike@addtoit.com> Signed-off-by:
-
Paolo 'Blaisorblade' Giarrusso authored
The bug occurred to me when a UML left an empty ~/.uml/Sarge-norm folder - when trying to reuse not_dead_yet() failed one of its check. The comment says that's ok and means that we can take the directory, but while normally not_dead_yet() removes it and returns 0 (i.e. go on, use this), on failure it returns 0 but forgets to remove it. The fix is to remove it anytime we're going to return 0. But since "not_dead_yet" didn't make the interface so clear, causing this bug, and I couldn't find a convenient name for the mix of things it did, I split it into two parts: is_umdir_used() - returns a boolean, contains all checks of not_dead_yet() umdir_take_if_dead - tries to remove the dir unless it's used - returns whether it removed it, that is we now own it. With this changes the control flow is IMHO a bit clearer and needs less comment for control flow. Signed-off-by:
-
Paolo 'Blaisorblade' Giarrusso authored
Make __copy_*_user_inatomic really atomic to avoid "Sleeping function called in atomic context" warnings, especially from futex code. This is made by adding another kmap_atomic slot and making copy_*_user_skas use kmap_atomic; also copy_*_user() becomes atomic, but that's true and is not a problem for i386 (and we can always add might_sleep there as done elsewhere). For TT mode kmap is not used, so there's no need for this. I've had to use another slot since both KM_USER0 and KM_USER1 are used elsewhere and could cause conflicts. Till now we reused the kmap_atomic slot list from the subarch, but that's not needed as that list must contain the common ones (used by generic code) + the ones used in architecture specific code (and Uml till now used none); so I've taken the i386 one after comparing it with ones from other archs, and added KM_UML_USERCOPY. Signed-off-by:
-
Gerd Hoffmann authored
Hide the magic in alternative.h and provide some dummy inline functions for the UP case (gcc should manage to optimize away these calls). No changes in module.c. Cc: Dave Jones <davej@codemonkey.org.uk> Cc: Andi Kleen <ak@muc.de> Signed-off-by:
-
Bryan O'Sullivan authored
Remove ips namespace from infinipath drivers. This renames ips_common.h to ipath_common.h. Definitions, data structures, etc. that were not used by kernel modules have moved to user-only headers. All names including ips have been renamed to ipath. Some names have had an ipath prefix added. Signed-off-by:
Christian Bell <christian.bell@qlogic.com> Signed-off-by:
Bryan O'Sullivan <bryan.osullivan@qlogic.com> Cc: "Michael S. Tsirkin" <mst@mellanox.co.il> Cc: Roland Dreier <rolandd@cisco.com> Signed-off-by:
-
Bryan O'Sullivan authored
The receive work queue size should be ignored if the QP is created to use a shared receive queue according to the IB spec. Signed-off-by:
Ralph Campbell <ralph.campbell@qlogic.com> Signed-off-by:
-
Bryan O'Sullivan authored
Signed-off-by:
Dave Olson <dave.olson@qlogic.com> Signed-off-by:
-
Bryan O'Sullivan authored
We can't tell for sure if any packets are in the infinipath receive buffer when we shut down a chip port. Normally this is taken care of by orderly shutdown, but when processes are terminated, or sending process has a bug, we can continue to receive packets. So rather than writing zero to the address registers for the closing port, we point it at a dummy memory. Signed-off-by:
-
Bryan O'Sullivan authored
We must increment uaddr by size we are reading or writing, since it's passed as a char *, not a pointer to the appropriate size. Signed-off-by:
-
Bryan O'Sullivan authored
We do a few more explicit checks for specific models, and now also support the old PathScale serial number style, or new QLogic style. This is backwards compatible with previous versions of software and hardware. That is, older software will see a plausible serial number and correct GUID when used with a new board, while newer software will correctly handle an older board. Signed-off-by:
Mike Albaugh <mike.albaugh@qlogic.com> Signed-off-by:
-
Bryan O'Sullivan authored
This attribute group made it into the original driver, but should not have. Signed-off-by:
-
Bryan O'Sullivan authored
The two arrays only had space for 4 units. Also changed from ipath_set_sps_lid() to ipath_set_lid(); the sps was leftover. Signed-off-by:
-
Bryan O'Sullivan authored
This patch separates QP state used for sending and receiving RC packets so the processing in the receive interrupt handler can be done mostly without locks being held. ACK packets are now sent without requiring synchronization with the send tasklet. Signed-off-by:
-
Bryan O'Sullivan authored
This patch fixes some problems uncovered during IB compliance testing to return the right values for error counters returned by the Performance Get Counters packet. Signed-off-by:
-
Bryan O'Sullivan authored
Signed-off-by:
-
Bryan O'Sullivan authored
The tail register read became redundant as the result of earlier receive interrupt bug fixes. Drop another unneeded register read. And another line that got duplicated. Signed-off-by:
-
Bryan O'Sullivan authored
Signed-off-by:
-
Bryan O'Sullivan authored
Signed-off-by:
-
Bryan O'Sullivan authored
Do an extra check to see if in-memory tail changed while processing packets, and if so, going back through the loop again (but only once per call to ipath_kreceive()). In practice, this seems to be enough to guarantee that if we crossed the clearing of an interrupt at start of ipath_intr with a scheduled tail register update, that we'll process the "extra" packet that lost the interrupt because we cleared it just as it was about to arrive. Signed-off-by:
-
Bryan O'Sullivan authored
The problem was that I was updating the head register multiple times in the rcvhdrq processing loop, and setting the counter on each update. Since that meant that the tail register was ahead of head for all but the last update, we would get extra interrupts. The fix was to not write the counter value except on the last update. I also changed to update rcvhdrhead and rcvegrindexhead at most every 16 packets, if there were lots of packets in the queue (and of course, on the last packet, regardless). I also made some small cleanups while debugging this. With these changes, xeon/monty typically sees two openib packets per interrupt on sdp and ipoib, opteron/monty is about 1.25 pkts/intr. I'm seeing about 3800 Mbit/s monty/xeon, and 5000-5100 opteron/monty with netperf sdp. Netpipe doesn't show as good as that, peaking at about 4400 on opteron/monty sdp. Plain ipoib xeon is about 2100+ netperf, opteron 2900+, at 128KB Signed-off-by: olson@eng-12.pathscale.com Signed-off-by:
Bryan O'Sullivan <bos@pathscale.com> Cc: "Michael S. Tsirkin" <mst@mellanox.co.il> Cc: Roland Dreier <rolandd@cisco.com> Signed-off-by:
-
Bryan O'Sullivan authored
Also count the number of interrupts where that works (fastrcvint). On any interrupt where the port0 head and tail registers are not equal, just call the ipath_kreceive code without reading the interrupt status, thus saving the approximately 0.25usec processor stall waiting for the read to return. If any other interrupt bits are set, or head==tail, take the normal path, but that has been reordered to handle read ahead of pioavail. Also no longer call ipath_kreceive() from ipath_qcheck(), because that just seems to make things worse, and isn't really buying us anything, these days. Also no longer loop in ipath_kreceive(); better to not hold things off too long (I saw many cases where we would loop 4-8 times, and handle thousands (up to 3500) in a single call). Signed-off-by:
-
Bryan O'Sullivan authored
Made in-memory rcvhdrq tail update be in dma_alloc'ed memory, not random user or special kernel (needed for ppc, also "just the right thing to do"). Some cleanups to make unexpected link transitions less likely to produce complaints about packet errors, and also to not leave SMA packets stuck and unable to go out. A few other random debug and comment cleanups. Always init rcvhdrq head/tail registers to 0, to avoid race conditions (should have been that way some time ago). Signed-off-by:
-
Bryan O'Sullivan authored
This is not a DMA target, so no need to use dma_alloc_coherent on it. Signed-off-by:
-
Bryan O'Sullivan authored
This helps us to survive better when memory is fragmented. Signed-off-by:
-
Bryan O'Sullivan authored
Signed-off-by:
-
Bryan O'Sullivan authored
Signed-off-by:
-
Bryan O'Sullivan authored
Signed-off-by:
-
Bryan O'Sullivan authored
These limits are somewhat artificial in that we don't actually have any device limits. However, the verbs layer expects that such limits exist and are enforced, so we make up arbitrary (but sensible) limits. Signed-off-by:
Robert Walsh <robert.walsh@qlogic.com> Signed-off-by:
-
Bryan O'Sullivan authored
Signed-off-by:
-
Bryan O'Sullivan authored
Signed-off-by:
-
Bryan O'Sullivan authored
Signed-off-by:
-
Bryan O'Sullivan authored
Signed-off-by:
-
Bryan O'Sullivan authored
Signed-off-by:
-
Bryan O'Sullivan authored
Signed-off-by:
-
Bryan O'Sullivan authored
There is no longer a /dev/ipath_diag file; instead, there's /dev/ipath_diag0, 1, etc. It's still not possible to have diags run on more than one unit at a time, but that's easy to fix at some point. Signed-off-by:
-
Bryan O'Sullivan authored
Signed-off-by:
-
Bryan O'Sullivan authored
Signed-off-by:
-
Bryan O'Sullivan authored
Signed-off-by:
-
Bryan O'Sullivan authored
Signed-off-by:
-
