- 07 Sep, 2005 40 commits
-
-
Pekka Enberg authored
This patch converts kcalloc(1, ...) calls to use the new kzalloc() function. Signed-off-by:
Pekka Enberg <penberg@cs.helsinki.fi> Cc: "Luck, Tony" <tony.luck@intel.com> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Pekka J Enberg authored
This patch introduces a kzalloc wrapper and converts kernel/ to use it. It saves a little program text. Signed-off-by:
Adrian Bunk <bunk@stusta.de> Signed-off-by:
-
Robert Love authored
Background: 1) dmi_check_system() returns the count of the number of matches. Zero thus means no matches. 2) A match callback can return nonzero to stop the match checking. Bug: The count is incremented after we check for the nonzero return value, so it does not reflect the actual count. We could say this is intended, for some dumb reason, except that it means that a match on the first check returns zero--no matches--if the callback returns nonzero. Attached patch implements the count before calling the callback and thus before potentially short-circuiting. Signed-off-by:
Robert Love <rml@novell.com> Cc: Andrey Panin <pazke@donpac.ru> Signed-off-by:
-
Andrey Panin authored
This patch adds onboard devices and IPMI BMC discovery into DMI scan code. Drivers can use dmi_find_device() function to search for devices by type and name. Signed-off-by:
Andrey Panin <pazke@donpac.ru> Signed-off-by:
-
Andrey Panin authored
This patch changes dmi_string() function to allocate string copy by itself, to avoid code duplication in the next patch. Signed-off-by:
-
Andrey Panin authored
DMI debugging code is unused for ages. This patch removes it. Signed-off-by:
-
Andrey Panin authored
After elimination of central DMI blacklist dmi_scan_machine() function became a wrapper for dmi_iterate(). This patch moves some code around to kill unneeded function. Signed-off-by:
-
Miklos Szeredi authored
cifs_create() did totally the wrong thing with nd->intent.open.flags: it interpreted nd->intent.open.flags as the original open flags, not the one transformed for open_namei(). Also it used the intent data even if it was not filled in (if called from sys_mknod()). Signed-off-by:
Miklos Szeredi <miklos@szeredi.hu> Cc: <viro@parcelfarce.linux.theplanet.co.uk> Cc: Christoph Hellwig <hch@lst.de> Cc: Steven French <sfrench@us.ibm.com> Signed-off-by:
-
Miklos Szeredi authored
64 bit architectures all implement their own compatibility sys_open(), when in fact the difference is simply not forcing the O_LARGEFILE flag. So use the a common function instead. Signed-off-by:
-
Miklos Szeredi authored
Extract common code used by ptrace_attach() and may_ptrace_attach() into a separate function. Signed-off-by:
-
Miklos Szeredi authored
This patch fixes wrongly placed elements in the pid_directory_inos enum. Also add comment so this mistake is not repeated. Signed-off-by:
-
Miklos Szeredi authored
This patch cleans up proc_cwd_link() and proc_root_link() by factoring out common code into get_fs_struct(). Signed-off-by:
-
Miklos Szeredi authored
Extract common code into inline functions to make reading easier. Signed-off-by:
-
Miklos Szeredi authored
Remove unused ia_attr_flags from struct iattr, and related defines. Signed-off-by:
-
Jiri Slaby authored
This patch removes 1 whole entry, which is no longer maintained and 1 e-mail, which is not right. [comtrol was posted by Rolf Eike Beer] Signed-off-by:
Rolf Eike Beer <eike-kernel@sf-tec.de> Signed-off-by:
Jiri Slaby <xslaby@fi.muni.cz> Signed-off-by:
-
Olaf Hering authored
https://bugzilla.novell.com/show_bug.cgi?id=103746 Old 2.6.13 hotplug enviroment for 'plug in firewire disk' event: ==> debug.01139.ieee1394.add.8211 <== set -- ieee1394 UDEV_LOG='7' ACTION='add' DEVPATH='/class/ieee1394/00010410100036e0-0' SUBSYSTEM='ieee1394' SEQNUM='1139' PHYSDEVPATH='/devices/pci0001:10/0001:10:0d.0/0001:11:0a.0/fw-host0/00010410100036e0/00010410100036e0-0' PHYSDEVBUS='ieee1394' VENDOR_ID='000000' MODEL_ID='001010' GUID='00010410100036e0' SPECIFIER_ID='00609e' VERSION='010483' UDEVD_EVENT='1' Module spb2 is not loaded. grep sbp2 /lib/modules/2.6.13-20050901172817-default/modules.alias alias ieee1394:ven*mo*sp0000609Ever00010483* sbp2 printf 'ieee1394:ven%08Xmo%08Xsp%08Xver%08X\n' '0x000000' '0x001010' '0x00609e' '0x010483' ieee1394:ven00000000mo00001010sp0000609Ever00010483 modprobe -v ieee1394:ven00000000mo00001010sp0000609Ever00010483 insmod /lib/modules/2.6.13-20050901172817-default/kernel/drivers/ieee1394/sbp2.ko Providing a MODALIAS= enviroment variable with the content above will fix it. Signed-off-by:
Olaf Hering <olh@suse.de> Cc: Ben Collins <bcollins@debian.org> Signed-off-by:
-
Coywolf Qi Hunt authored
Signed-off-by:
Coywolf Qi Hunt <qiyong@fc-cn.com> Signed-off-by:
-
Eric Dumazet authored
dentry cache uses sophisticated RCU technology (and prefetching if available) but touches 2 cache lines per dentry during hlist lookup. This patch moves d_hash in the same cache line than d_parent and d_name fields so that : 1) One cache line is needed instead of two. 2) the hlist_for_each_rcu() prefetching has a chance to bring all the needed data in advance, not only the part that includes d_hash.next. I also changed one old comment that was wrong for 64bits. A further optimisation would be to separate dentry in two parts, one that is mostly read, and one writen (d_count/d_lock) to avoid false sharing on SMP/NUMA but this would need different field placement depending on 32bits or 64bits platform. Signed-off-by:
Eric Dumazet <dada1@cosmosbay.com> Signed-off-by:
-
John Hawkes authored
Revert the hack introduced last week. Signed-off-by:
John Hawkes <hawkes@sgi.com> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
John Hawkes authored
For a NUMA system with multiple CPUs per node, declaring a cpu-exclusive cpuset that includes only some, but not all, of the CPUs in a node will mangle the sched domain structures. Signed-off-by:
-
John Hawkes authored
Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Paul Jackson authored
Now the real motivation for this cpuset mem_exclusive patch series seems trivial. This patch keeps a task in or under one mem_exclusive cpuset from provoking an oom kill of a task under a non-overlapping mem_exclusive cpuset. Since only interrupt and GFP_ATOMIC allocations are allowed to escape mem_exclusive containment, there is little to gain from oom killing a task under a non-overlapping mem_exclusive cpuset, as almost all kernel and user memory allocation must come from disjoint memory nodes. This patch enables configuring a system so that a runaway job under one mem_exclusive cpuset cannot cause the killing of a job in another such cpuset that might be using very high compute and memory resources for a prolonged time. Signed-off-by:
Paul Jackson <pj@sgi.com> Signed-off-by:
-
Paul Jackson authored
This patch makes use of the previously underutilized cpuset flag 'mem_exclusive' to provide what amounts to another layer of memory placement resolution. With this patch, there are now the following four layers of memory placement available: 1) The whole system (interrupt and GFP_ATOMIC allocations can use this), 2) The nearest enclosing mem_exclusive cpuset (GFP_KERNEL allocations can use), 3) The current tasks cpuset (GFP_USER allocations constrained to here), and 4) Specific node placement, using mbind and set_mempolicy. These nest - each layer is a subset (same or within) of the previous. Layer (2) above is new, with this patch. The call used to check whether a zone (its node, actually) is in a cpuset (in its mems_allowed, actually) is extended to take a gfp_mask argument, and its logic is extended, in the case that __GFP_HARDWALL is not set in the flag bits, to look up the cpuset hierarchy for the nearest enclosing mem_exclusive cpuset, to determine if placement is allowed. The definition of GFP_USER, which used to be identical to GFP_KERNEL, is changed to also set the __GFP_HARDWALL bit, in the previous cpuset_gfp_hardwall_flag patch. GFP_ATOMIC and GFP_KERNEL allocations will stay within the current tasks cpuset, so long as any node therein is not too tight on memory, but will escape to the larger layer, if need be. The intended use is to allow something like a batch manager to handle several jobs, each job in its own cpuset, but using common kernel memory for caches and such. Swapper and oom_kill activity is also constrained to Layer (2). A task in or below one mem_exclusive cpuset should not cause swapping on nodes in another non-overlapping mem_exclusive cpuset, nor provoke oom_killing of a task in another such cpuset. Heavy use of kernel memory for i/o caching and such by one job should not impact the memory available to jobs in other non-overlapping mem_exclusive cpusets. This patch enables providing hardwall, inescapable cpusets for memory allocations of each job, while sharing kernel memory allocations between several jobs, in an enclosing mem_exclusive cpuset. Like Dinakar's patch earlier to enable administering sched domains using the cpu_exclusive flag, this patch also provides a useful meaning to a cpuset flag that had previously done nothing much useful other than restrict what cpuset configurations were allowed. Signed-off-by:
-
Paul Jackson authored
Add another GFP flag: __GFP_HARDWALL. A subsequent "cpuset_zone_allowed" patch will use this flag to mark GFP_USER allocations, and distinguish them from GFP_KERNEL allocations. Allocations (such as GFP_USER) marked GFP_HARDWALL are constrainted to the current tasks cpuset. Other allocations (such as GFP_KERNEL) can steal from the possibly larger nearest mem_exclusive cpuset ancestor, if memory is tight on every node in the current cpuset. This patch collides with Mel Gorman's patch to reduce fragmentation in the standard buddy allocator, which adds two GFP flags. This was discussed on linux-mm in July. Most likely, one of his flags for user reclaimable memory can be the same as my __GFP_HARDWALL flag, under some generic name meaning its user address space memory. Signed-off-by:
-
Paul Jackson authored
This patch series extends the use of the cpuset attribute 'mem_exclusive' to support cpuset configurations that: 1) allow GFP_KERNEL allocations to come from a potentially larger set of memory nodes than GFP_USER allocations, and 2) can constrain the oom killer to tasks running in cpusets in a specified subtree of the cpuset hierarchy. Here's an example usage scenario. For a few hours or more, a large NUMA system at a University is to be divided in two halves, with a bunch of student jobs running in half the system under some form of batch manager, and with a big research project running in the other half. Each of the student jobs is placed in a small cpuset, but should share the classic Unix time share facilities, such as buffered pages of files in /bin and /usr/lib. The big research project wants no interference whatsoever from the student jobs, and has highly tuned, unusual memory and i/o patterns that intend to make full use of all the main memory on the nodes available to it. In this example, we have two big sibling cpusets, one of which is further divided into a more dynamic set of child cpusets. We want kernel memory allocations constrained by the two big cpusets, and user allocations constrained by the smaller child cpusets where present. And we require that the oom killer not operate across the two halves of this system, or else the first time a student job runs amuck, the big research project will likely be first inline to get shot. Tweaking /proc/<pid>/oom_adj is not ideal -- if the big research project really does run amuck allocating memory, it should be shot, not some other task outside the research projects mem_exclusive cpuset. I propose to extend the use of the 'mem_exclusive' flag of cpusets to manage such scenarios. Let memory allocations for user space (GFP_USER) be constrained by a tasks current cpuset, but memory allocations for kernel space (GFP_KERNEL) by constrained by the nearest mem_exclusive ancestor of the current cpuset, even though kernel space allocations will still _prefer_ to remain within the current tasks cpuset, if memory is easily available. Let the oom killer be constrained to consider only tasks that are in overlapping mem_exclusive cpusets (it won't help much to kill a task that normally cannot allocate memory on any of the same nodes as the ones on which the current task can allocate.) The current constraints imposed on setting mem_exclusive are unchanged. A cpuset may only be mem_exclusive if its parent is also mem_exclusive, and a mem_exclusive cpuset may not overlap any of its siblings memory nodes. This patch was presented on linux-mm in early July 2005, though did not generate much feedback at that time. It has been built for a variety of arch's using cross tools, and built, booted and tested for function on SN2 (ia64). There are 4 patches in this set: 1) Some minor cleanup, and some improvements to the code layout of one routine to make subsequent patches cleaner. 2) Add another GFP flag - __GFP_HARDWALL. It marks memory requests for USER space, which are tightly confined by the current tasks cpuset. 3) Now memory requests (such as KERNEL) that not marked HARDWALL can if short on memory, look in the potentially larger pool of memory defined by the nearest mem_exclusive ancestor cpuset of the current tasks cpuset. 4) Finally, modify the oom killer to skip any task whose mem_exclusive cpuset doesn't overlap ours. Patch (1), the one time I looked on an SN2 (ia64) build, actually saved 32 bytes of kernel text space. Patch (2) has no affect on the size of kernel text space (it just adds a preprocessor flag). Patches (3) and (4) added about 600 bytes each of kernel text space, mostly in kernel/cpuset.c, which matters only if CONFIG_CPUSET is enabled. This patch: This patch applies a few comment and code cleanups to mm/oom_kill.c prior to applying a few small patches to improve cpuset management of memory placement. The comment changed in oom_kill.c was seriously misleading. The code layout change in select_bad_process() makes room for adding another condition on which a process can be spared the oom killer (see the subsequent cpuset_nodes_overlap patch for this addition). Also a couple typos and spellos that bugged me, while I was here. This patch should have no material affect. Signed-off-by: -
John Hawkes authored
I've already sent this to the maintainers, and this is now being sent to a larger community audience. I have fixed a problem with the ia64 version of build_sched_domains(), but a similar fix still needs to be made to the generic build_sched_domains() in kernel/sched.c. The "dynamic sched domains" functionality has recently been merged into 2.6.13-rcN that sees the dynamic declaration of a cpu-exclusive (a.k.a. "isolated") cpuset and rebuilds the CPU Scheduler sched domains and sched groups to separate away the CPUs in this cpu-exclusive cpuset from the remainder of the non-isolated CPUs. This allows the non-isolated CPUs to completely ignore the isolated CPUs when doing load-balancing. Unfortunately, build_sched_domains() expects that a sched domain will include all the CPUs of each node in the domain, i.e., that no node will belong in both an isolated cpuset and a non-isolated cpuset. Declaring a cpuset that violates this presumption will produce flawed data structures and will oops the kernel. To trigger the problem (on a NUMA system with >1 CPUs per node): cd /dev/cpuset mkdir newcpuset cd newcpuset echo 0 >cpus echo 0 >mems echo 1 >cpu_exclusive I have fixed this shortcoming for ia64 NUMA (with multiple CPUs per node). A similar shortcoming exists in the generic build_sched_domains() (in kernel/sched.c) for NUMA, and that needs to be fixed also. The fix involves dynamically allocating sched_group_nodes[] and sched_group_allnodes[] for each invocation of build_sched_domains(), rather than using global arrays for these structures. Care must be taken to remember kmalloc() addresses so that arch_destroy_sched_domains() can properly kfree() the new dynamic structures. Signed-off-by:
-
Brian King authored
I ran across a memory leak related to the cfq scheduler. The cfq init function increments the refcnt of the associated request_queue. This refcount gets decremented in cfq's exit function. Since blk_cleanup_queue only calls the elevator exit function when its refcnt goes to zero, the request_q never gets cleaned up. It didn't look like other io schedulers were incrementing this refcnt, so I removed the refcnt increment and it fixed the memory leak for me. To reproduce the problem, simply use cfq and use the scsi_host scan sysfs attribute to scan "- - -" repeatedly on a scsi host and watch the memory vanish. Signed-off-by:
Brian King <brking@us.ibm.com> Acked-by:
Jens Axboe <axboe@suse.de> Signed-off-by:
-
Max Kellermann authored
The sunrpc stats are collected in unsigned integers, but they are printed with '%d'. That can result in negative numbers in /proc/net/rpc when the highest bit of a counter is set. The following patch changes '%d' to '%u' where appropriate. Cc: "David S. Miller" <davem@davemloft.net> Cc: Trond Myklebust <trond.myklebust@fys.uio.no> Signed-off-by:
-
John McCutchan authored
People have run into a problem when they do this: watch (file1, all_events); watch (file2, some_events); if file2 is a hard link to file1, some events will be missed because by default we replace the mask. The patch below adds a flag IN_MASK_ADD which will cause inotify to add to the existing mask if present. Signed-off-by:
John McCutchan <ttb@tentacle.dhs.org> Signed-off-by:
-
Stephen Rothwell authored
This makes sense now that we have asm-powerpc. Signed-off-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
-
Stephen Rothwell authored
This patch gathers all the struct flock64 definitions (and the operations), puts them under !CONFIG_64BIT and cleans up the arch files. Signed-off-by:
-
Stephen Rothwell authored
This patch just gathers together all the struct flock definitions except xtensa into asm-generic/fcntl.h. Signed-off-by:
-
Stephen Rothwell authored
This patch puts the most popular of each fcntl operation/flag into asm-generic/fcntl.h and cleans up the arch files. Signed-off-by:
-
Stephen Rothwell authored
This patch puts the most popular of each open flag into asm-generic/fcntl.h and cleans up the arch files. Signed-off-by:
-
Stephen Rothwell authored
These two files are basically identical, so make one just include the other (protecting the 32-bit-only parts with __powerpc64__). Also remove some completely unused defines. Signed-off-by:
-
Stephen Rothwell authored
This set of patches creates asm-generic/fcntl.h and consolidates as much as possible from the asm-*/fcntl.h files into it. This patch just gathers all the identical bits of the asm-*/fcntl.h files into asm-generic/fcntl.h. Signed-off-by:
Yoichi Yuasa <yuasa@hh.iij4u.or.jp> Signed-off-by:
-
Philipp Matthias Hahn authored
While installing Debian on our new IBM X41 Tablet, I tried briefly to use the built-in Atmel TPM. The Athmel TPM is also located on the LPC-bus of the ICH6. To make it work I had to apply the following patch: Signed-off-by:
Philipp Matthias Hahn <pmhahn@titan.lahn.de> Acked-by:
Kylene Jo Hall <kjhall@us.ibm.com> Signed-off-by:
-
Jesper Juhl authored
Here's a small warning fix for drivers/isdn/i4l/isdn_v110.c drivers/isdn/i4l/isdn_v110.c:523: warning: `ret' might be used uninitialized in this function In addition to Karsten Keil signing off on the patch, Thomas Pfeiffer also commented on the patch, saying "initializing ret with the value zero is correct and should be done." Please apply. Signed-off-by:
Jesper Juhl <jesper.juhl@gmail.com> Signed-off-by:
Karsten Keil <kkeil@suse.de> Signed-off-by:
-
Alex Williamson authored
The HPET driver is using a parts per second drift factor instead of the standard parts per million drift the time interpolator code expects. This patch fixes that problem and updates the URL for the HPET spec. Signed-off-by:
Alex Williamson <alex.williamson@hp.com> Cc: "Robert W. Picco" <bob.picco@hp.com> Acked-by:
"Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com> Signed-off-by:
-
Antonino A. Daplas authored
Based on a patch from Andr Pereira de Almeida <andre@cachola.com.br> It might be possible for the saved pointer (*p) to become invalid in between vc_resizes, so saving the screen offset instead of the screen pointer is saner. This bug is very hard to trigger though, but Andre probably did, if he's submitting this patch. Anyway, with Andre's patch, it's still possible for the offsets to be still illegal, if the new screen size is smaller than the old one. So I've also added checks if the offsets are still within the screenbuffer size. Signed-off-by:
Antonino Daplas <adaplas@pol.net> Signed-off-by:
-
