- 08 Feb, 2008 40 commits
-
-
Ed L. Cashin authored
An aoe driver user who had about 70 AoE targets found that he was hitting a BUG in sysfs_create_file because the aoe driver was trying to tell the kernel about an AoE device more than once. Each AoE device was reachable by several local network interfaces, and multiple ATA device indentify responses were returning from that single device. This patch eliminates a race condition so that aoe always informs the block layer of a new AoE device once in the presence of multiple incoming ATA device identify responses. Signed-off-by:
Ed L. Cashin <ecashin@coraid.com> Cc: Greg KH <greg@kroah.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Ed L. Cashin authored
What this Patch Does Even before this recent series of 12 patches to 2.6.22-rc4, the aoe driver was reusing a small set of skbs that were allocated once and were only used for outbound AoE commands. The network layer cannot be allowed to put_page on the data that is still associated with a bio we haven't returned to the block layer, so the aoe driver (even before the patch under discussion) is still the owner of skbs that have been handed to the network layer for transmission. We need to keep track of these skbs so that we can free them, but by tracking them, we can also easily re-use them. The new patch was a response to the behavior of certain network drivers. We cannot reuse an skb that the network driver still has in its transmit ring. Network drivers can defer transmit ring cleanup and then use the state in the skb to determine how many data segments to clean up in its transmit ring. The tg3 driver is one driver that behaves in this way. When the network driver defers cleanup of its transmit ring, the aoe driver can find itself in a situation where it would like to send an AoE command, and the AoE target is ready for more work, but the network driver still has all of the pre-allocated skbs. In that case, the new patch just calls alloc_skb, as you'd expect. We don't want to get carried away, though. We try not to do excessive allocation in the write path, so we cap the number of skbs we dynamically allocate. Probably calling it a "dynamic pool" is misleading. We were already trying to use a small fixed-size set of pre-allocated skbs before this patch, and this patch just provides a little headroom (with a ceiling, though) to accomodate network drivers that hang onto skbs, by allocating when needed. The d->skbpool_hd list of allocated skbs is necessary so that we can free them later. We didn't notice the need for this headroom until AoE targets got fast enough. Alternatives If the network layer never did a put_page on the pages in the bio's we get from the block layer, then it would be possible for us to hand skbs to the network layer and forget about them, allowing the network layer to free skbs itself (and thereby calling our own skb->destructor callback function if we needed that). In that case we could get rid of the pre-allocated skbs and also the d->skbpool_hd, instead just calling alloc_skb every time we wanted to transmit a packet. The slab allocator would effectively maintain the list of skbs. Besides a loss of CPU cache locality, the main concern with that approach the danger that it would increase the likelihood of deadlock when VM is trying to free pages by writing dirty data from the page cache through the aoe driver out to persistent storage on an AoE device. Right now we have a situation where we have pre-allocation that corresponds to how much we use, which seems ideal. Of course, there's still the separate issue of receiving the packets that tell us that a write has successfully completed on the AoE target. When memory is low and VM is using AoE to flush dirty data to free up pages, it would be perfect if there were a way for us to register a fast callback that could recognize write command completion responses. But I don't think the current problems with the receive side of the situation are a justification for exacerbating the problem on the transmit side. Signed-off-by:
-
Ed L. Cashin authored
When an AoE device is detected, the kernel is informed, and a new block device is created. If the device is unused, the block device corresponding to remote device that is no longer available may be removed from the system by telling the aoe driver to "flush" its list of devices. Without this patch, software like GPFS and LVM may attempt to read from AoE devices that were discovered earlier but are no longer present, blocking until the I/O attempt times out. Signed-off-by:
-
Ed L. Cashin authored
Adam Richter suggested eliminating this goto. Signed-off-by:
-
Ed L. Cashin authored
This patch adds a known default location for the udev configuration file and uses the more recent "==" syntax for SUBSYSTEM and KERNEL. Signed-off-by:
-
Ed L. Cashin authored
By returning unsigned long long, mac_addr does not generate compiler warnings on 64-bit architectures. Signed-off-by:
-
Ed L. Cashin authored
A remote AoE device is something can process ATA commands and is identified by an AoE shelf number and an AoE slot number. Such a device might have more than one network interface, and it might be reachable by more than one local network interface. This patch tracks the available network paths available to each AoE device, allowing them to be used more efficiently. Andrew Morton asked about the call to msleep_interruptible in the revalidate function. Yes, if a signal is pending, then msleep_interruptible will not return 0. That means we will not loop but will call aoenet_xmit with a NULL skb, which is a noop. If the system is too low on memory or the aoe driver is too low on frames, then the user can hit control-C to interrupt the attempt to do a revalidate. I have added a comment to the code summarizing that. Andrew Morton asked whether the allocation performed inside addtgt could use a more relaxed allocation like GFP_KERNEL, but addtgt is called when the aoedev lock has been locked with spin_lock_irqsave. It would be nice to allocate the memory under fewer restrictions, but targets are only added when the device is being discovered, and if the target can't be added right now, we can try again in a minute when then next AoE config query broadcast goes out. Andrew Morton pointed out that the "too many targets" message could be printed for failing GFP_ATOMIC allocations. The last patch in this series makes the messages more specific. Signed-off-by:
-
Ed L. Cashin authored
Signed-off-by:
-
Jan Beulich authored
Remains the question whether it is intended that many, perhaps even large, tables are compiled in without ever having a chance to get used, i.e. whether there shouldn't #ifdef CONFIG_xxx get added. [akpm@linux-foundation.org: fix cut-n-paste error] Signed-off-by:
Jan Beulich <jbeulich@novell.com> Acked-by:
"Eric W. Biederman" <ebiederm@xmission.com> Cc: Dave Jones <davej@codemonkey.org.uk> Signed-off-by:
-
Harvey Harrison authored
Signed-off-by:
Harvey Harrison <harvey.harrison@gmail.com> Signed-off-by:
-
Harvey Harrison authored
Signed-off-by:
-
Harvey Harrison authored
[akpm@linux-foundation.org: coding-style fixes] Signed-off-by:
-
Harvey Harrison authored
[akpm@linux-foundation.org: coding-style fixes] Signed-off-by:
-
Harvey Harrison authored
[akpm@linux-foundation.org: coding-style fixes] Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Harvey Harrison authored
[akpm@linux-foundation.org: coding-style fixes] Signed-off-by:
-
Nick Piggin authored
Support direct_access XIP method with brd. Signed-off-by:
Nick Piggin <npiggin@suse.de> Signed-off-by:
-
Nick Piggin authored
This is a rewrite of the ramdisk block device driver. The old one is really difficult because it effectively implements a block device which serves data out of its own buffer cache. It relies on the dirty bit being set, to pin its backing store in cache, however there are non trivial paths which can clear the dirty bit (eg. try_to_free_buffers()), which had recently lead to data corruption. And in general it is completely wrong for a block device driver to do this. The new one is more like a regular block device driver. It has no idea about vm/vfs stuff. It's backing store is similar to the buffer cache (a simple radix-tree of pages), but it doesn't know anything about page cache (the pages in the radix tree are not pagecache pages). There is one slight downside -- direct block device access and filesystem metadata access goes through an extra copy and gets stored in RAM twice. However, this downside is only slight, because the real buffercache of the device is now reclaimable (because we're not playing crazy games with it), so under memory intensive situations, footprint should effectively be the same -- maybe even a slight advantage to the new driver because it can also reclaim buffer heads. The fact that it now goes through all the regular vm/fs paths makes it much more useful for testing, too. text data bss dec hex filename 2837 849 384 4070 fe6 drivers/block/rd.o 3528 371 12 3911 f47 drivers/block/brd.o Text is larger, but data and bss are smaller, making total size smaller. A few other nice things about it: - Similar structure and layout to the new loop device handlinag. - Dynamic ramdisk creation. - Runtime flexible buffer head size (because it is no longer part of the ramdisk code). - Boot / load time flexible ramdisk size, which could easily be extended to a per-ramdisk runtime changeable size (eg. with an ioctl). - Can use highmem for the backing store. [akpm@linux-foundation.org: fix build] [byron.bbradley@gmail.com: make rd_size non-static] Signed-off-by:
Byron Bradley <byron.bbradley@gmail.com> Signed-off-by:
-
David Howells authored
Add platform MTD support for the ASB2303 board. Signed-off-by:
David Howells <dhowells@redhat.com> Acked-by:
David Woodhouse <dwmw2@infradead.org> Signed-off-by:
-
David Howells authored
Add architecture support for the MN10300/AM33 CPUs produced by MEI to the kernel. This patch also adds board support for the ASB2303 with the ASB2308 daughter board, and the ASB2305. The only processor supported is the MN103E010, which is an AM33v2 core plus on-chip devices. [akpm@linux-foundation.org: nuke cvs control strings] Signed-off-by:
Masakazu Urade <urade.masakazu@jp.panasonic.com> Signed-off-by:
Koichi Yasutake <yasutake.koichi@jp.panasonic.com> Signed-off-by:
-
David Howells authored
Allocate serial port UART type IDs for the MN10300 on-chip serial ports. Signed-off-by:
Alan Cox <alan@redhat.com> Signed-off-by:
-
David Howells authored
net2280 can't have a function called show_registers() because this can produce a namespace clash with an arch function of the same name. All this driver's functions and variables should really be prefixed with "net2280_" to avoid such a problem in future. Signed-off-by:
-
David Howells authored
Remove now unnecessary inclusions of {asm,linux}/a.out.h. [akpm@linux-foundation.org: fix alpha build] Signed-off-by: -
David Howells authored
Suppress A.OUT library support if CONFIG_ARCH_SUPPORTS_AOUT is not set. Not all architectures support the A.OUT binfmt, so the ELF binfmt should not be permitted to go looking for A.OUT libraries to load in such a case. Not only that, but under such conditions A.OUT core dumps are not produced either. To make this work, this patch also does the following: (1) Makes the existence of the contents of linux/a.out.h contingent on CONFIG_ARCH_SUPPORTS_AOUT. (2) Renames dump_thread() to aout_dump_thread() as it's only called by A.OUT core dumping code. (3) Moves aout_dump_thread() into asm/a.out-core.h and makes it inline. This is then included only where needed. This means that this bit of arch code will be stored in the appropriate A.OUT binfmt module rather than the core kernel. (4) Drops A.OUT support for Blackfin (according to Mike Frysinger it's not needed) and FRV. This patch depends on the previous patch to move STACK_TOP[_MAX] out of asm/a.out.h and into asm/processor.h as they're required whether or not A.OUT format is available. [jdike@addtoit.com: uml: re-remove accidentally restored code] Signed-off-by:Jeff Dike <jdike@linux.intel.com> Signed-off-by:
-
David Howells authored
Mark arches that support A.OUT format by including the following in their master Kconfig files: config ARCH_SUPPORTS_AOUT def_bool y This should also be set if the arch provides compatibility A.OUT support for an older arch, for instance x86_64 for i386 or sparc64 for sparc. I've guessed at which arches don't, based on comments in the code, however I'm sure that some of the ones I've marked as 'yes' actually should be 'no'. Signed-off-by:
-
David Howells authored
Move STACK_TOP[_MAX] out of asm/a.out.h and into asm/processor.h as they're required whether or not A.OUT format is available. Signed-off-by:
-
Li Zefan authored
Fix typo in comments. BTW: I have to fix coding style in arch/ia64/kernel/time.c also, otherwise checkpatch.pl will be complaining. Signed-off-by:
Li Zefan <lizf@cn.fujitsu.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: john stultz <johnstul@us.ibm.com> Signed-off-by:
-
Li Zefan authored
Function timekeeping_is_continuous() no longer checks flag CLOCK_IS_CONTINUOUS, and it checks CLOCK_SOURCE_VALID_FOR_HRES now. So rename the function accordingly. Signed-off-by:
-
Li Zefan authored
list_for_each_safe() suffices here. Signed-off-by:
-
Li Zefan authored
Flag CLOCK_SOURCE_WATCHDOG is cleared twice. Note clocksource_change_rating() won't do anyting with the cs flag. Signed-off-by:
-
Pavel Emelyanov authored
There's only one caller left - the kill_pgrp one - so merge these two functions and forget the kill_pgrp_info one. Signed-off-by:
Pavel Emelyanov <xemul@openvz.org> Reviewed-by:
Oleg Nesterov <oleg@tv-sign.ru> Signed-off-by:
-
Pavel Emelyanov authored
This is the first step (of two) in removing the kill_pgrp_info. All the users of this function are in kernel/signal.c, but all they need is to call __kill_pgrp_info() with the tasklist_lock read-locked. Fortunately, one of its users is the kill_something_info(), which already needs this lock in one of its branches, so clean these branches up and call the __kill_pgrp_info() directly. Based on Oleg's view of how this function should look. Signed-off-by:
-
Pavel Emelyanov authored
When sending the pid namespaces patches I wrongly converted the tsk->tgid into task_pid_vnr(tsk) in mqueue-s (the git id of this patch is b488893a). The proper behavior is to get the task_tgid_vnr(tsk). This seem to be the only mistake of that kind. Signed-off-by:
-
Pavel Emelyanov authored
Some time ago the xxx_vnr() calls (e.g. pid_vnr or find_task_by_vpid) were _all_ converted to operate on the current pid namespace. After this each call like xxx_nr_ns(foo, current->nsproxy->pid_ns) is nothing but a xxx_vnr(foo) one. Switch all the xxx_nr_ns() callers to use the xxx_vnr() calls where appropriate. Signed-off-by:
-
Oleg Nesterov authored
signal_struct->tsk points to the ->group_leader and thus we have the nasty code in de_thread() which has to change it and restart ->real_timer if the leader is changed. Use "struct pid *leader_pid" instead. This also allows us to kill now unneeded send_group_sig_info(). Signed-off-by:
Roland McGrath <roland@redhat.com> Acked-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Oleg Nesterov authored
There is a window when de_thread() switches the leader and drops tasklist_lock. In that window do_each_pid_task(PIDTYPE_PID) finds both new and old leaders. The problem is pretty much theoretical and probably can be ignored. Currently the only users of do_each_pid_task(PIDTYPE_PID) are send_sigio/send_sigurg, so they can send the signal to the same process twice. Signed-off-by:
-
Oleg Nesterov authored
kill_pid_info()->pid_task() could be the old leader of the execing process. In that case it is possible that the leader will be released before we take siglock. This means that kill_pid_info() (and thus sys_kill()) can return a false -ESRCH. Change the code to retry when lock_task_sighand() fails. The endless loop is not possible, __exit_signal() both clears ->sighand and does detach_pid(). Signed-off-by:
-
Eric W. Biederman authored
Use task_pgrp_vnr not task_pgrp_nr so we return the process id the processes pid namespace and not in the initial pid namespace. Signed-off-by:
-
Eric W. Biederman authored
[m.kozlowski@tuxland.pl: fix unbalanced parenthesis in irix_BSDsetpgrp()] Signed-off-by:
Mariusz Kozlowski <m.kozlowski@tuxland.pl> Signed-off-by:
-
Oleg Nesterov authored
With the new semantics of find_vpid() we don't need to play with ->nsproxy explicitely, _vxx() do the right things. Also s/tasklist/rcu/. Signed-off-by:
-
Eric W. Biederman authored
pid_vnr returns the user space pid with respect to the pid namespace the struct pid was allocated in. What we want before we return a pid to user space is the user space pid with respect to the pid namespace of current. pid_vnr is a very nice optimization but because it isn't quite what we want it is easy to use pid_vnr at times when we aren't certain the struct pid was allocated in our pid namespace. Currently this describes at least tiocgpgrp and tiocgsid in ttyio.c the parent process reported in the core dumps and the parent process in get_signal_to_deliver. So unless the performance impact is huge having an interface that does what we want instead of always what we want should be much more reliable and much less error prone. Signed-off-by:
-
