Richard Purdie [Tue, 6 Sep 2005 22:19:05 +0000 (15:19 -0700)]
[PATCH] w100fb: Update corgi platform code to match new driver
This patch moves the platform specific Sharp SL-C7x0 LCD code from the
w100fb driver into a more appropriate place and updates the Corgi code to
match the new w100fb driver.
It also updates the corgi touchscreen code to match the new simplified
interface available from w100fb.
Signed-off-by: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Richard Purdie [Tue, 6 Sep 2005 22:19:03 +0000 (15:19 -0700)]
[PATCH] w100fb: Rewrite for platform independence
The code w100fb was based on was horribly Sharp SL-C7x0 specific and there
was little else that could be done as I had no access to anything else with
a w100 in it. There is no real documentation about this chipset available.
Ian Molton has access to other platforms with the w100 (Toshiba e-series)
and so between us, we've improved w100fb and made it platform independent.
Ian Molton also added support for the very similar w3220 and w3200
chipsets.
There are a lot of changes here and it nearly amounts to a rewrite of the
driver but it has been extensively tested and is being used in preference
to the original driver in the Zaurus community. I'd therefore like to
update the mainline code to reflect this.
Signed-off-by: Richard Purdie <rpurdie@rpsys.net> Acked-by: Antonino Daplas <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Richard Purdie [Tue, 6 Sep 2005 22:19:01 +0000 (15:19 -0700)]
[PATCH] Corgi Touchscreen: Allow the driver to share the PMU
The Corgi Touchscreen driver uses the PMU as an accurate timing source which
conflicts with its usage for performance monitoring. This patch allows it to
be shared with other users such as oprofile.
Signed-off-by: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Richard Purdie [Tue, 6 Sep 2005 22:19:00 +0000 (15:19 -0700)]
[PATCH] Corgi Keyboard: Code tidying
The input system handles key state tracking so there's no need for the driver
to do so as well. Also tidy up some comment formatting and remove a now
unneeded function.
Signed-off-by: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Richard Purdie [Tue, 6 Sep 2005 22:18:59 +0000 (15:18 -0700)]
[PATCH] Corgi Keyboard: Add some power management code
Add some power management code to the corgi keyboard driver so that only one
power event gets reported within any reasonable time frame and the driver
doesn't enter an infinte loop due to key repeat.
Signed-off-by: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Pierre Ossman [Tue, 6 Sep 2005 22:18:57 +0000 (15:18 -0700)]
[PATCH] mmc: wbsd Secure Digital support
Add support for Secure Digital specific features in the wbsd driver. Adds
support for read-only switch and wide bus transfers.
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx> Cc: Russell King <rmk@arm.linux.org.uk> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Pierre Ossman [Tue, 6 Sep 2005 22:18:56 +0000 (15:18 -0700)]
[PATCH] sd: SD copyright notice
Credit where credit is due.
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx> Cc: Russell King <rmk@arm.linux.org.uk> Cc: David Brownell <david-b@pacbell.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Pierre Ossman [Tue, 6 Sep 2005 22:18:55 +0000 (15:18 -0700)]
[PATCH] sd: SD 4-bit bus
Infrastructure for 4-bit bus transfers with SD cards.
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx> Cc: Russell King <rmk@arm.linux.org.uk> Cc: David Brownell <david-b@pacbell.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Pierre Ossman [Tue, 6 Sep 2005 22:18:54 +0000 (15:18 -0700)]
[PATCH] sd: SCR in sysfs
Export the SCR register through sysfs.
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx> Cc: Russell King <rmk@arm.linux.org.uk> Cc: David Brownell <david-b@pacbell.net> Cc: Greg KH <greg@kroah.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Pierre Ossman [Tue, 6 Sep 2005 22:18:53 +0000 (15:18 -0700)]
[PATCH] sd: SCR register
Read the SD specific SCR register from the card.
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx> Cc: Russell King <rmk@arm.linux.org.uk> Cc: David Brownell <david-b@pacbell.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Pierre Ossman [Tue, 6 Sep 2005 22:18:52 +0000 (15:18 -0700)]
[PATCH] sd: read-only switch
Support for the read-only switch on SD cards which must be enforced by the
host.
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx> Cc: Russell King <rmk@arm.linux.org.uk> Cc: David Brownell <david-b@pacbell.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Pierre Ossman [Tue, 6 Sep 2005 22:18:50 +0000 (15:18 -0700)]
[PATCH] sd: initialize SD cards
Support for the Secure Digital protocol in the MMC layer.
A summary of the legal issues surrounding SD cards, as understood by yours
truly:
Members of the Secure Digital Association, hereafter SDA, are required to sign
a NDA[1] before given access to any specifications. It has been speculated
that including an SD implementation would forbid these members to redistribute
Linux. This is the basic problem with SD support so it is unclear if it even
is a problem since it has no effect on those of us that aren't members.
The SDA doesn't seem to enforce these rules though since the patches included
here are based on documentation made public by some of the members. The most
complete specs[2] are actually released by Sandisk, one of the founding
companies of the SDA.
Because of this the NDA is considered a non-issue by most involved in the
discussions concerning these patches. It might be that the SDA is only
interested in protecting the so called "secure" bits of SD, which so far
hasn't been found in any public spec. (The card is split into two sections,
one "normal" and one "secure" which has an access scheme similar to TPM:s).
(As a side note, Microsoft is working to make things easier for us since they
want to be able to include the source code for a SD driver in one of their
development kits. HP is making sure that the new NDA will allow a Linux
implementation. So far only the SDIO specs have been opened up[3]. More will
hopefully follow.)
This patch contains the central parts of the SD support. If no MMC cards are
found on a bus then the MMC layer proceeds looking for SD cards. Helper
functions are extended to handle the special needs of SD cards.
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx> Cc: Russell King <rmk@arm.linux.org.uk> Cc: David Brownell <david-b@pacbell.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Roman Zippel [Tue, 6 Sep 2005 22:18:49 +0000 (15:18 -0700)]
[PATCH] hfs: NLS support
This adds NLS support to HFS. Using the kernel options iocharset and codepage
it's possible to map the disk encoding to a local mapping. If these options
are not used, it falls back to the old direct mapping.
Signed-off-by: Roman Zippel <zippel@linux-m68k.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The IPMI power control function proc_write_chassctrl was badly written, it
directly used userspace pointers, it assumed that strings were NULL
terminated, and it used the evil sscanf function. This converts over to
using the sysctl interface for this data and changes the semantics to be a
little more logical.
[PATCH] ipmi: add hacks for IPMI chassis poweroff for certain Dell servers
This patch allows Dell servers with IPMI controllers that predate IPMI 1.5
to use the standard poweroff or powercycle commands. These systems
firmware don't set the chassis capability bit in the Get Device ID, but
they do implement the standard poweroff and powercycle commands.
Tested on RHEL3 kernel 2.4.21-20.ELsmp on a PowerEdge 2600. The standard
ipmi_poweroff driver cannot drive these systems. With this patch, they
power off or powercycle as expected.
Signed-off-by: Matt Domsch <Matt_Domsch@dell.com> Signed-off-by: Corey Minyard <minyard@acm.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The "null message handler" in the IPMI driver is used in startup and panic
situations to handle messages. It was only designed to work with messages
from the local management controller, but in some cases it was used to get
messages from remote managmenet controllers, and the system would then
panic. This patch makes the "null message handler" in the IPMI driver more
general so it works with any kind of message.
[PATCH] ipmi: clean up versioning of the IPMI driver
This adds MODULE_VERSION, MODULE_DESCRIPTION, and MODULE_AUTHOR tags to the
IPMI driver modules. Also changes the MODULE_VERSION to remove the
prepended 'v' on each value, consistent with the module versioning policy.
This patch also removes all the version information from everything except
the ipmi_msghandler module.
Signed-off-by: Matt Domsch <Matt_Domsch@dell.com> Signed-off-by: Corey Minyard <minyard@acm.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
[PATCH] ipmi: OEM flag handling and hacks for some Dell machines
The ipmi driver does not have a way to handle firmware-generated events
which have the OEM[012] Data Available flags set. In such a case, the
SMS_ATN bit may never get cleared by firmware, leaving the driver looping
infinitely but never able to make any progress.
This patch first simplifies storage and use of the data returned from an
IPMI Get Device ID command.
It then creates a new per-OEM handler hook, which should know how to handle
events with the OEM[012] Data Available flags set. It then uses this to
implement a workaround for IPMI 1.5-capable Dell PowerEdge servers which
are susceptable to setting the OEM[012] Data Available flags when the
driver can't handle it.
Signed-off-by: Matt Domsch <Matt_Domsch@dell.com> Signed-off-by: Corey Minyard <minyard@acm.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
There are some interactions between IPMI NMI timeouts and the other operations
of the IPMI driver. This make sure those interactions are handled properly.
IPMI allows multiple IPMB channels on a single interface, and each channel
might have a different IPMB address. However, the driver has only one IPMB
address that it uses for everything. This patch adds new IOCTLS and a new
internal interface for setting per-channel IPMB addresses and LUNs. New
systems are coming out with support for multiple IPMB channels, and they are
broken without this patch.
Robert Love [Tue, 6 Sep 2005 22:18:30 +0000 (15:18 -0700)]
[PATCH] fix: dmi_check_system
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: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
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.
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.
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: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
[PATCH] remove duplicated sys_open32() code from 64bit archs
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 <miklos@szeredi.hu> Cc: <viro@parcelfarce.linux.theplanet.co.uk> Cc: Christoph Hellwig <hch@lst.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Eric Dumazet [Tue, 6 Sep 2005 22:18:16 +0000 (15:18 -0700)]
[PATCH] struct dentry: place d_hash close to d_parent and d_name to speedup lookups
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: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
John Hawkes [Tue, 6 Sep 2005 22:18:14 +0000 (15:18 -0700)]
[PATCH] cpusets: fix the "dynamic sched domains" bug
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 <hawkes@sgi.com>
Cc; Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Paul Jackson [Tue, 6 Sep 2005 22:18:13 +0000 (15:18 -0700)]
[PATCH] cpusets: confine oom_killer to mem_exclusive cpuset
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: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
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 <pj@sgi.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Paul Jackson [Tue, 6 Sep 2005 22:18:10 +0000 (15:18 -0700)]
[PATCH] cpusets: new __GFP_HARDWALL flag
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 <pj@sgi.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Paul Jackson [Tue, 6 Sep 2005 22:18:09 +0000 (15:18 -0700)]
[PATCH] cpusets: oom_kill tweaks
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: Paul Jackson <pj@sgi.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
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: John Hawkes <hawkes@sgi.com> Cc: Nick Piggin <nickpiggin@yahoo.com.au> Cc: Ingo Molnar <mingo@elte.hu> Cc: "Luck, Tony" <tony.luck@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Brian King [Tue, 6 Sep 2005 22:18:04 +0000 (15:18 -0700)]
[PATCH] block: CFQ refcounting fix
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: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Max Kellermann [Tue, 6 Sep 2005 22:18:03 +0000 (15:18 -0700)]
[PATCH] sunrpc: print unsigned integers in stats
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: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
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: Robert Love <rml@novell.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
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 <sfr@canb.auug.org.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
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: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
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."
Alex Williamson [Tue, 6 Sep 2005 22:17:54 +0000 (15:17 -0700)]
[PATCH] hpet: fix drift and url
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: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
[PATCH] vt: fix possible memory corruption in complement_pos
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.
[PATCH] remove verify_area(): remove fs/umsdos/notes as it only contain a verify_area related note
The file `fs/umsdos/notes' contains only a small note about a possible bug
involving verify_area(). Since umsdos is no longer in the kernel and
verify_area() is also gone, it seems to make sense that this file goes the way
of the Dodo.
After applying this patch the `fs/umsdos/' directory will be empty and can be
removed entirely.
Kumar Gala [Tue, 6 Sep 2005 22:17:47 +0000 (15:17 -0700)]
[PATCH] Remove non-arch consumers of asm/segment.h
asm/segment.h varies greatly on different architectures but is clearly
deprecated. Removing all non-architecture consumers will make it easier
for us to get ride of asm/segment.h all together.
Signed-off-by: Kumar Gala <kumar.gala@freescale.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
posix_timer_event() first checks that the thread (SIGEV_THREAD_ID case)
does not have PF_EXITING flag, then it calls send_sigqueue() which locks
task list. But if the thread exits in between the kernel will oops
(->sighand == NULL after __exit_sighand).
This patch moves the PF_EXITING check into the send_sigqueue(), it must be
done atomically under tasklist_lock. When send_sigqueue() detects exiting
thread it returns -1. In that case posix_timer_event will send the signal
to thread group.
Also, this patch fixes task_struct use-after-free in posix_timer_event.
Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Dave Johnson [Tue, 6 Sep 2005 22:17:40 +0000 (15:17 -0700)]
[PATCH] fix cramfs making duplicate entries in inode cache
Every time cramfs_lookup() is called to lookup and inode for a dentry,
get_cramfs_inode() will allocate a new inode without checking to see if that
inode already exists in the inode cache.
This is fine the first time, but if the dentry cache entry(ies) associated
with that inode are aged out, but the inode entry is not aged out (which can
be quite common if the inode has buffer cache linked to it), cramfs_lookup()
will be called again and another inode will be allocated and added to the
inode cache creating a duplicate in the inode cache.
The big issue here is that the buffers associated with each inode cache entry
are not shared between the duplicates!
The older inode entries are now orphaned as no dentry points to it and won't
be freed until the buffer cache assoicated with them are first freed. The
newest entry will have to create all new buffer cache for each part of its
file as the old buffer cache is now orphaned as well.
Patch below fixes this by making get_cramfs_inode() use the inode cache before
blindly creating a new entry every time. This eliminates the duplicate inodes
and duplicate buffer cache.
[PATCH] remove a redundant variable in sys_prctl()
The patch removes a redundant variable `sig' from sys_prctl().
For some reason, when sys_prctl is called with option == PR_SET_PDEATHSIG
then the value of arg2 is assigned to an int variable named sig. Then sig
is tested with valid_signal() and later used to set the value of
current->pdeath_signal .
There is no reason to use this intermediate variable since valid_signal()
takes a unsigned long argument, so it can handle being passed arg2
directly, and if the call to valid_signal is OK, then we know the value of
arg2 is in the range zero to _NSIG and thus it'll easily fit in a plain int
and thus there's no problem assigning it later to current->pdeath_signal
(which is an int).
The patch gets rid of the pointless variable `sig'.
This reduces the size of kernel/sys.o in 2.6.13-rc6-mm1 by 32 bytes on my
system.
Patch has been compile tested, boot tested, and just to make damn sure I
didn't break anything I wrote a quick test app that calls
prctl(PR_SET_PDEATHSIG ...) with the entire range of values for a
unsigned long, and it behaves as expected with and without the patch.
Peter Staubach [Tue, 6 Sep 2005 22:17:35 +0000 (15:17 -0700)]
[PATCH] largefile support for accounting
There is a problem in the accounting subsystem in the kernel can not
correctly handle files larger than 2GB. The output file containing the
process accounting data can grow very large if the system is large enough
and active enough. If the 2GB limit is reached, then the system simply
stops storing process accounting data.
Another annoying problem is that once the system reaches this 2GB limit,
then every process which exits will receive a signal, SIGXFSZ. This signal
is generated because an attempt was made to write beyond the limit for the
file descriptor. This signal makes it look like every process has exited
due to a signal, when in fact, they have not.
The solution is to add the O_LARGEFILE flag to the list of flags used to
open the accounting file. The rest of the accounting support is already
largefile safe.
The changes were tested by constructing a large file (just short of 2GB),
enabling accounting, and then running enough commands to cause the
accounting data generated to increase the size of the file to 2GB. Without
the changes, the file grows to 2GB and the last command run in the test
script appears to exit due a signal when it has not. With the changes,
things work as expected and quietly.
There are some user level changes required so that it can deal with
largefiles, but those are being handled separately.
Signed-off-by: Peter Staubach <staubach@redhat.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This patch simplifies the usage of do_notify_parent_cldstop(), it lessens
the source and .text size slightly, and makes the code (in my opinion) a
bit more readable.
I am sending this patch now because I'm afraid Paul will touch
do_notify_parent_cldstop() really soon, It's better to cleanup first.
I've had WARN_CONSOLE_UNLOCKED warnings when calling TIOCLINUX
TIOCL_BLANKSCREEN and TIOCL_UNBLANKSCREEN.
(I'm blind and I use a braille display. I use those functions to blank my
laptop's screen so people don't read it, and hopefully to conserve power.)
The warnings are from these places:
do_blank_screen at drivers/char/vt.c:2754 (Not tainted)
save_screen at drivers/char/vt.c:575 (Not tainted)
do_unblank_screen at drivers/char/vt.c:2822 (Not tainted)
set_palette at drivers/char/vt.c:2908 (Not tainted)
At a glance I would think the following patch ought to fix that. Tested on
one machine. Could you please tell me if this is correct and/or forward
the patch where appropriate...
Signed-off-by: Stephane Doyon <s.doyon@videotron.ca> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
projects / linux-2.6 / log