On Thu, Jan 10, 2008 at 02:12:59PM +0100, Andi Kleen wrote:
Adrian Bunk [EMAIL PROTECTED] writes:
Technically you are the one who has to deal with problems in your
patches, not the people pointing at the problems.
If you believe that my patch adds a new problem then please describe
it
On Thu, Jan 10, 2008 at 05:25:37PM +0530, Ananth N Mavinakayanahalli wrote:
From: Ananth N Mavinakayanahalli [EMAIL PROTECTED]
Create a toplevel tests/ directory to house in-kernel subsystem specific
tests.
PS: I am not sure if I've gotten the Makefile change right.
Signed-off-by:
Hi Ananth.
On Thu, Jan 10, 2008 at 05:24:28PM +0530, Ananth N Mavinakayanahalli wrote:
The following series of patches create and populate the toplevel tests/
directory. This will henceforth be the place where all in-kernel tests
live.
Thanks for creating these patches.
Look good - one small
On Thu, 10 Jan 2008, Dave Young wrote:
Hi,
The patches are done on my side, please help to check.
This is the first one of the series about driver core changes.
If this one is accepted and there's no other problem I will post the others
for maintainer's review (they need your comment
Hi Mark.
On Thu, Jan 10, 2008 at 11:51:10AM +, Mark Brown wrote:
Signed-off-by: Mark Brown [EMAIL PROTECTED]
Signed-off-by: Liam Girdwood [EMAIL PROTECTED]
---
MAINTAINERS|9 ++
drivers/input/touchscreen/Kconfig | 52
On Wed, 9 Jan 2008 23:39:02 -0500
Mike Snitzer [EMAIL PROTECTED] wrote:
How much trouble am I asking for if I were to try to get your patchset
to fly on a fairly recent stable kernel (e.g. 2.6.22.15)? If
workable, is such an effort before it's time relative to your TODO?
Quite a bit :)
The
On Thu, 2008-01-10 at 12:54 +0200, Pekka J Enberg wrote:
Hi Matt,
On Thu, 10 Jan 2008, Pekka J Enberg wrote:
I'll double check the results for SLUB next but it seems obvious that your
patches are a net gain for SLOB and should be applied. One problem though
with SLOB seems to be that
The ioctl handlers are called with the BKL held, where as unlocked_ioctl
handlers are not. The drm_ioctl function is registered as an ioctl
handler. But it does not need the BKL to be held. Changing drm_ioctl to
register as an unlocked_ioctl function.
Signed-off-by: Nikanth Karthikesan [EMAIL
On Thu, 10 Jan 2008 13:53:59 +0300
Anton Salikhmetov [EMAIL PROTECTED] wrote:
Indeed, if msync() is called with MS_SYNC an explicit sync is
triggered, and Rik's suggestion would work. However, the POSIX
standard requires a call to msync() with MS_ASYNC to update the
st_ctime and st_mtime
This one's a fatal bug in the qla1280 32 bit descriptor handling, since
the unitialised req_cnt variable is used to count the number of
descriptor slots. It turns out that qla1280 only uses 32 bit
descriptors on x86 if HIGHMEM isn't enabled, which is why it's taken so
long to find someone with a
On Thu, 10 Jan 2008, Rafael J. Wysocki wrote:
On Wednesday, 9 of January 2008, Alan Stern wrote:
On Wed, 9 Jan 2008, Rafael J. Wysocki wrote:
In dpm_resume() you shouldn't need to use dpm_list_mtx at all, because
the list_move_tail() comes before the resume_device(). It's the same
On Thu, 2008-01-10 at 16:01 +0100, Jiri Kosina wrote:
On Wed, 9 Jan 2008, Alan Cox wrote:
default:
printk(%s: Unimplemented ioctl 0x%x\n, tape-name,
cmd);
+ unlock_kernel();
return -EINVAL;
Surely a bug ... shouldn't
On Thu, 2008-01-10 at 13:01 +1100, Rusty Russell wrote:
On Thursday 10 January 2008 09:10:37 James Bottomley wrote:
On Tue, 2008-01-08 at 11:39 +1100, Rusty Russell wrote:
On Tuesday 08 January 2008 02:48:23 James Bottomley wrote:
We're always open to new APIs (or more powerful and
Hi,
--
Jan Kara [EMAIL PROTECTED]
SUSE Labs, CR
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Thu, Jan 10, 2008 at 09:01:41PM +0530, Nikanth Karthikesan wrote:
On Thu, 2008-01-10 at 16:01 +0100, Jiri Kosina wrote:
On Wed, 9 Jan 2008, Alan Cox wrote:
default:
printk(%s: Unimplemented ioctl 0x%x\n, tape-name,
cmd);
+
On Thu, Jan 10, 2008 at 04:16:35PM +0100, Sam Ravnborg wrote:
On Thu, Jan 10, 2008 at 05:25:37PM +0530, Ananth N Mavinakayanahalli wrote:
From: Ananth N Mavinakayanahalli [EMAIL PROTECTED]
Create a toplevel tests/ directory to house in-kernel subsystem specific
tests.
PS: I am not
Hi,
sorry for the previous empty email...
Supriya noted in his testing that sometimes buffers removed by
__remove_assoc_queue() don't have b_assoc_mapping set (and thus IO error
won't be properly propagated). Actually, looking more into the code I found
there are some more races. The patch
2008/1/10, Rik van Riel [EMAIL PROTECTED]:
On Thu, 10 Jan 2008 13:53:59 +0300
Anton Salikhmetov [EMAIL PROTECTED] wrote:
Indeed, if msync() is called with MS_SYNC an explicit sync is
triggered, and Rik's suggestion would work. However, the POSIX
standard requires a call to msync() with
My kernel is _not_ tainted. [...]
this time my kernel isn't tainted either (comm: thunderbird-bin Not
tainted;
http://kerneloftruth.neucode.org/other/crash_ia32_64/not_tainted/moto_0041.jpg)
but still hardlocks:
http://kerneloftruth.neucode.org/other/crash_ia32_64/not_tainted/
ok, good. A
In message [EMAIL PROTECTED], Christoph Hellwig writes:
On Thu, Jan 10, 2008 at 09:59:19AM -0500, Erez Zadok wrote:
Dear Linus, Al, Christoph, and Andrew,
As per your request, I'm posting for review the unionfs code (and related
code) that's in my korg tree against mainline
On Thu, Jan 10, 2008 at 04:41:18PM +0100, Sam Ravnborg wrote:
On Thu, Jan 10, 2008 at 11:51:10AM +, Mark Brown wrote:
+wm97xx-ts-objs := wm97xx-core.o
Use
wm97xx-ts-y := wm97xx-core.o
+wm97xx-ts-objs += wm9713.o
+endif
So this becomes:
wm97xx-ts-$(CONFIG_TOUCHSCREEN_WM9713) +=
On Wednesday 09 January 2008 08:49:52 pm Greg KH wrote:
On Wed, Jan 02, 2008 at 01:42:23PM -0700, Bjorn Helgaas wrote:
The patch below was put in 2.6.23.12 as a fix for
http://bugzilla.kernel.org/show_bug.cgi?id=9514. It apparently
does make 9514 go away, but only by coincidence. There
On Jan 10, 2008 10:41 AM, Rik van Riel [EMAIL PROTECTED] wrote:
On Wed, 9 Jan 2008 23:39:02 -0500
Mike Snitzer [EMAIL PROTECTED] wrote:
How much trouble am I asking for if I were to try to get your patchset
to fly on a fairly recent stable kernel (e.g. 2.6.22.15)? If
workable, is such
On Thu, 10 Jan 2008 18:56:07 +0300
Anton Salikhmetov [EMAIL PROTECTED] wrote:
However, I don't see how they will work if there has been
something like a sync(2) done after the mmap'd region is
modified and the msync call. When the inode is written out
as part of the sync process,
On Thu, 10 Jan 2008, Pekka J Enberg wrote:
We probably don't have the same version of GCC which perhaps affects
memory layout (struct sizes) and thus allocation patterns?
No, struct sizes will not change with compiler versions - that would
create binary incompatibilities for libraries
On Thu, 2008-01-10 at 15:41 +0100, Jan Kara wrote:
On Wed, 09 Jan 2008 12:11:20 +0100
I wonder why UDF was doing a synchronous write in there. In fact I wonder
why it's writing the inode at all? extN doesn't do that. If for some
reason it really does want to make the inode
No-one else is using these afaics.
Signed-off-by: Jan Beulich [EMAIL PROTECTED]
---
include/linux/module.h | 17 -
kernel/module.c| 16 +++-
2 files changed, 15 insertions(+), 18 deletions(-)
--- linux-2.6.24-rc7/include/linux/module.h 2008-01-10
When the newer export flavors were added, it was apparently forgotten
to add respective code here.
In order to not double the (source) size of the function, add some
abstraction to reduce code duplication.
Signed-off-by: Jan Beulich [EMAIL PROTECTED]
---
kernel/module.c | 37
On Wed, 9 Jan 2008, Arjan van de Ven wrote:
+ if (valid_stack_ptr(tinfo, frame, sizeof(*frame)))
+ while (valid_stack_ptr(tinfo, frame, sizeof(*frame))) {
Why?
Why not just make this something like the appended instead?
This is *totally* untested, but the basic notion is
+ .type csum_partial, @function
ENTRY(csum_partial)
+ .type csum_partial, @function
ENTRY(csum_partial)
CFI_STARTPROC
pushl %esi
@@ -141,11 +142,13 @@ ENTRY(csum_partial)
ret
CFI_ENDPROC
ENDPROC(csum_partial)
+ .size csum_partial, . -
On January 10, 2008, Ingo Molnar wrote:
* Ed Tomlinson [EMAIL PROTECTED] wrote:
Matthew is not alone with this problem. I have it too. Its not new
here. Its been happening as long as I have had gentoo amd64
installed. It can be hard to reproduce but eventually, when 32 bit
apps
Short of getting a reply on the query why the argument of fls() here is
missing the decrement, here's a patch to add it (reducing the resulting
size when the incoming size is an exact power of two).
Signed-off-by: Jan Beulich [EMAIL PROTECTED]
Cc: James Bottomley [EMAIL PROTECTED]
---
2008/1/10, Rik van Riel [EMAIL PROTECTED]:
On Thu, 10 Jan 2008 18:56:07 +0300
Anton Salikhmetov [EMAIL PROTECTED] wrote:
However, I don't see how they will work if there has been
something like a sync(2) done after the mmap'd region is
modified and the msync call. When the inode is
Remove the dead .text.lock. Move _etext and __{start,stop}___ex_table
into their sections.
Signed-off-by: Jan Beulich [EMAIL PROTECTED]
---
arch/x86/kernel/vmlinux_64.lds.S | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
---
Rik van Riel wrote:
On Thu, 10 Jan 2008 18:56:07 +0300
Anton Salikhmetov [EMAIL PROTECTED] wrote:
However, I don't see how they will work if there has been
something like a sync(2) done after the mmap'd region is
modified and the msync call. When the inode is written out
as part of the
Subject: x86: Add the print code before the trapping instruction feature to
64 bit
From: Arjan van de Ven [EMAIL PROTECTED]
The 32 bit x86 tree has a very useful feature that prints the Code: line
for the code even before the trapping instrution (and the start of the
trapping instruction is
On Thu, 10 Jan 2008 08:36:57 -0800 (PST)
Linus Torvalds [EMAIL PROTECTED] wrote:
On Wed, 9 Jan 2008, Arjan van de Ven wrote:
+ if (valid_stack_ptr(tinfo, frame, sizeof(*frame)))
+ while (valid_stack_ptr(tinfo, frame,
sizeof(*frame))) {
Why?
Why not just make this
Anton Salikhmetov wrote:
2008/1/10, Rik van Riel [EMAIL PROTECTED]:
On Thu, 10 Jan 2008 18:56:07 +0300
Anton Salikhmetov [EMAIL PROTECTED] wrote:
However, I don't see how they will work if there has been
something like a sync(2) done after the mmap'd region is
modified and the msync
On Thursday, 10 of January 2008, Alan Stern wrote:
On Thu, 10 Jan 2008, Rafael J. Wysocki wrote:
On Wednesday, 9 of January 2008, Alan Stern wrote:
On Wed, 9 Jan 2008, Rafael J. Wysocki wrote:
In dpm_resume() you shouldn't need to use dpm_list_mtx at all, because
the
Hi all,
I've got an issue that's popped up with a deployed system running
2.6.10. I'm looking for some help figuring out why incoming network
packets aren't being processed fast enough.
After a recent userspace app change, we've started seeing packets being
dropped by the ethernet hardware
Hi Eric,
While testing the current network namespace stuff merged in net-2.6.25,
I bumped into the following problem with the /proc/net/ entries.
It doesn't always display the actual data of the current namespace,
but sometime displays data from other namespaces.
I bisected the problem to the
[Sorry for not replying earlier, I missed your message.]
On Friday, 4 of January 2008, Ingo Molnar wrote:
* Rafael J. Wysocki [EMAIL PROTECTED] wrote:
So you would need to fix that first. Would be fine for me, but is
out of scope for my patch.
OK, I'll fix that up later.
i'll
On Thursday, 10 of January 2008, Andi Kleen wrote:
On Thursday 10 January 2008 12:26:07 Adrian Bunk wrote:
On Thu, Jan 10, 2008 at 12:15:15PM +0100, Andi Kleen wrote:
But your patch does:
+config PM_CPUINIT
+ bool
+ depends on PM
That is because
Chris Friesen wrote:
Hi all,
I've got an issue that's popped up with a deployed system running
2.6.10. I'm looking for some help figuring out why incoming network
packets aren't being processed fast enough.
After a recent userspace app change, we've started seeing packets being
dropped
On Thu, 10 Jan 2008 20:38:45 +0900
FUJITA Tomonori [EMAIL PROTECTED] wrote:
Driver 'sd' needs updating - please use bus_type methods
The warning never appeared in RC6, and all google reveals are other
peoples logs that are posted about other issues.
Do I need to fix up something
On Thursday 10 January 2008 02:05:23 Robert Hancock wrote:
Tejun Heo wrote:
From: Ondrej Zary [EMAIL PROTECTED]
Prevent libata from starting/stopping non-ATA devices (like ATAPI floppy
drives) as they don't seem to like it:
sd 1:0:1:0: [sdb] Starting disk
ata2.01: configured for
On Thu, 2008-01-10 at 08:13 -0800, Linus Torvalds wrote:
On Thu, 10 Jan 2008, Pekka J Enberg wrote:
We probably don't have the same version of GCC which perhaps affects
memory layout (struct sizes) and thus allocation patterns?
No, struct sizes will not change with compiler versions
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Steven Rostedt
Sent: Thursday, January 10, 2008 6:44 AM
To: Ingo Molnar
Cc: LKML; Linus Torvalds; Andrew Morton; Thomas Gleixner;
Brown, Len; Pallipadi, Venkatesh; Adam Belay; Peter Zijlstra;
Andi Kleen
On Tue, Jan 08, 2008 at 10:03:05PM +0530, Sudhir Kumar wrote:
Hi Andrew,
Kernel build fails on my machine with error :
LD drivers/net/ehea/built-in.o
CC [M] drivers/net/ehea/ehea_main.o
drivers/net/ehea/ehea_main.c: In function ???ehea_driver_sysfs_add???:
Hello,
A long time ago, I have some troubles with 3Com (3c905) NIC on i386 and
amd64. Since 2.6.22, I never have seen this trouble but with 2.6.23.12
(sparc64/SMP), I randomly obtain a NETDEV WATCHDOG. It's not an hardware
trouble because I have tested with several NIC.
[Resent with proper subject and to additional recipients]
This patch against linus-current is compile-tested on x86 and x86-64.
Please review
Andre
---
Change sg.c to use the unlocked_ioctl instead of the ioctl handler.
The patch moves the BKL into sg.c and is thus a first step to get
rid of
I would suggest that if you guys are really serious about memory use, try
to do a size-based heap thing, and do best-fit in that heap. Or just some
iirc best fit usually also has some nasty long term fragmentation behaviour.
That is why it is usually also not used.
-Andi
--
To unsubscribe
Kok, Auke wrote:
You're using 2.6.10... you can always replace the e1000 module with the
out-of-tree version from e1000.sf.net, this might help a bit - the version in
the
2.6.10 kernel is very very old.
Do you have any reason to believe this would improve things? It seems
like the problem
Hello,
On Thu, 10 Jan 2008 18:43:10 +0100
BERTRAND Joël [EMAIL PROTECTED] wrote:
ifconfig returns :
eth2 Link encap:Ethernet HWaddr 00:04:75:df:1c:6d
inet adr:192.168.253.1 Bcast:192.168.253.255
Masque:255.255.255.0
UP BROADCAST RUNNING MULTICAST
On Jan 10, 2008 3:10 AM, Zhang Wei [EMAIL PROTECTED] wrote:
I think your patch is good. What should I do next?
Cheers!
Wei.
I do not think all the review comments have been addressed, for
example my earlier comments about GFP_ATOMIC and spin_lock_irqsave
[1]. We have two options to take
On Thu, 2008-01-10 at 20:38 +0900, FUJITA Tomonori wrote:
CC'ed linux-scsi and James,
On Thu, 10 Jan 2008 08:51:50 +
Nick Warne [EMAIL PROTECTED] wrote:
Hi everybody - Happy New Year to you all!
OK, updated to git rc7 yesterday - I now see this in syslog:
Driver 'sd'
Paul Rolland wrote:
Hello,
On Thu, 10 Jan 2008 18:43:10 +0100
BERTRAND Joël [EMAIL PROTECTED] wrote:
ifconfig returns :
eth2 Link encap:Ethernet HWaddr 00:04:75:df:1c:6d
inet adr:192.168.253.1 Bcast:192.168.253.255
Masque:255.255.255.0
UP BROADCAST
Hi Steven.
Index: linux-compile-i386.git/arch/x86/Kconfig
===
--- linux-compile-i386.git.orig/arch/x86/Kconfig 2008-01-09
14:09:36.0 -0500
+++ linux-compile-i386.git/arch/x86/Kconfig 2008-01-09 14:10:07.0
On Thu, 10 Jan 2008, Pallipadi, Venkatesh wrote:
With 2.6.23, you can try compiling acpi processor.ko as a module and
doing insmod and rmmod in a loop. That should call cpu_idle_wait very
frequently.
The thing is, after the full boot, there's too many things going on to
keep a system fully
Needed since the plan is to not have a svc_create_thread helper and to
have current users of that function just call kthread_run directly.
Signed-off-by: Jeff Layton [EMAIL PROTECTED]
---
net/sunrpc/svcsock.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git
Move the initialzation in __svc_create_thread that happens prior to
thread creation to a new function. Export the function to allow
services to have better control over the svc_rqst structs.
Also rearrange the rqstp initialization to prevent NULL pointer
dereferences in svc_exit_thread in case
lockd makes itself freezable, but never calls try_to_freeze(). Have it
call try_to_freeze() within the main loop.
Signed-off-by: Jeff Layton [EMAIL PROTECTED]
---
fs/lockd/svc.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/fs/lockd/svc.c b/fs/lockd/svc.c
index
The main problem is this:
When a lock that a client is blocking on comes free, lockd does this in
nlmsvc_grant_blocked():
nlm_async_call(block-b_call, NLMPROC_GRANTED_MSG, nlmsvc_grant_ops);
the callback from this call is nlmsvc_grant_callback(). That function
does this at the end to wake
This is the seventh patchset to fix the use-after-free problem in lockd
which we originally discussed back in October. Along the way, Christoph
Hellwig mentioned that it would be advantageous to convert lockd to use
the kthread API. This patch set first makes that change and then patches
it to
Have lockd_up start lockd using kthread_run. With this change,
lockd_down now blocks until lockd actually exits, so there's no longer
need for the waitqueue code at the end of lockd_down. This also means
that only one lockd can be running at a time which simplifies the code
within lockd's main
It does look ugly. But .size and .type are oriented towards static
description, while the dwarf2 CurrentFrameInfo (CFI) annotations
are oriented towards dynamic traceback and unwinding. Forcing the
ENTRY/ENDPROC have nothing to do with dwarf2. That is CFI_STARTPROC/ENDPROC.
But actually
On Thu, 10 Jan 2008, Matt Mackall wrote:
(I'm not a fan of slabs per se - I think all the constructor/destructor
crap is just that: total crap - but the size/type binning is a big deal,
and I think SLOB was naïve to think a pure first-fit makes any sense. Now
you guys are
On Thu, Jan 10, 2008 at 05:48:43PM +0800, Dave Young wrote:
The patches are done on my side, please help to check.
Along with all of the other comments from people, I have a few.
This is the first one of the series about driver core changes.
If this one is accepted and there's no other
1) Interrupts are being processed on both cpus:
[EMAIL PROTECTED]:/root cat /proc/interrupts
CPU0 CPU1
30:17037564530785 U3-MPIC Level eth0
IIRC none of the e1000 driven cards are multi-queue, so while the above
shows that interrupts from eth0 have been
On Thu, 2008-01-10 at 10:28 -0800, Linus Torvalds wrote:
On Thu, 10 Jan 2008, Matt Mackall wrote:
(I'm not a fan of slabs per se - I think all the constructor/destructor
crap is just that: total crap - but the size/type binning is a big deal,
and I think SLOB was naïve to think
On Wed, 9 Jan 2008 20:22:54 +
Christoph Hellwig [EMAIL PROTECTED] wrote:
Please submit the mmiotrace for 2.6.25 and we'll find some way to make
it work.
Fair enough. Thanks to all for the encouraging words. I will start to
work towards sending mmio-trace to kernel.
We'll see how far I get
Originally based on a patch from Eric Biederman, but heavily changed.
PAT set as below
PAT(0,WB) | PAT(1,WT) | PAT(2,WC) | PAT(3,UC)
So, only change from boot setting is UC_MINUS - WC.
Also, PAT WC is enabled only on recent Intel CPUs. Other CPUs can be added as
they are tested with these
i386: Map only usable memory in identity map. Reserved memory maps to a
zero page.
Signed-off-by: Venkatesh Pallipadi [EMAIL PROTECTED]
Signed-off-by: Suresh Siddha [EMAIL PROTECTED]
Index: linux-2.6.git/arch/x86/kernel/e820_32.c
Straight forward port of pat-conflict.patch to x86 tree. Use a linear
list to keep track of all reserved region mappings.
Only UC access is allowed for RAM regions for now.
Signed-off-by: Venkatesh Pallipadi [EMAIL PROTECTED]
Signed-off-by: Suresh Siddha [EMAIL PROTECTED]
Index:
x86_64: Map only usable memory in identity map. All reserved memory maps to a
zero page. This is done later during the boot process, by pruning the
page table setup earlier to remove mappings for the reserved region. Prune
done after mem_init, so we can allocate pages as needed and before APs
Forward port of pci-mmap-conflict.patch to x86 tree.
Signed-off-by: Venkatesh Pallipadi [EMAIL PROTECTED]
Signed-off-by: Suresh Siddha [EMAIL PROTECTED]
Index: linux-2.6.git/arch/x86/pci/i386.c
===
---
Chris Friesen wrote:
Kok, Auke wrote:
You're using 2.6.10... you can always replace the e1000 module with the
out-of-tree version from e1000.sf.net, this might help a bit - the
version in the
2.6.10 kernel is very very old.
Do you have any reason to believe this would improve things? It
On Thu, 10 Jan 2008 12:27:22 -0600
James Bottomley [EMAIL PROTECTED] wrote:
OK, updated to git rc7 yesterday - I now see this in syslog:
Driver 'sd' needs updating - please use bus_type methods
Do I need to fix up something here?
No, you don't. It's harmless, a side effect of:
On Thu, 2008-01-10 at 19:05 +0100, Andre Noll wrote:
[Resent with proper subject and to additional recipients]
This patch against linus-current is compile-tested on x86 and x86-64.
Please review
This is rather long. For the utility of what you've just done, what's
wrong with just making
Rick Jones wrote:
1) Interrupts are being processed on both cpus:
[EMAIL PROTECTED]:/root cat /proc/interrupts
CPU0 CPU1
30:17037564530785 U3-MPIC Level eth0
IIRC none of the e1000 driven cards are multi-queue
the pci-express variants are, but the
On Thu, Jan 10, 2008 at 07:59:44PM +0100, Andi Kleen wrote:
Really, all this is doing is open coding what the ioctl handler is doing
anyway, isn't it? in which case, why bother to change it at all?
Because once it's open coded it is visible and can then be eliminated.
Does SCSI need the
On Thu, 2008-01-10 at 19:59 +0100, Andi Kleen wrote:
Really, all this is doing is open coding what the ioctl handler is doing
anyway, isn't it? in which case, why bother to change it at all?
Because once it's open coded it is visible and can then be eliminated.
Does SCSI need the BKL at
[EMAIL PROTECTED] writes:
x86_64: Map only usable memory in identity map.
I don't think that is needed or makes sense for reserved/ACPI * etc.
Only e820 holes should be truly unmapped because only those should
contain mmio.
All reserved memory maps to a
zero page.
Why zero page? Why not
We need to make sure that all mounts get into the
sb list. So, require that new setters of mnt-mnt_sb
use simple_set_mnt() instead of doing it themselves.
NFS does the same thing a few times in a row, so give
it a nice little helper.
---
linux-2.6.git-dave/fs/namespace.c |3 +--
---
linux-2.6.git-dave/fs/namespace.c | 21 ++---
1 file changed, 10 insertions(+), 11 deletions(-)
diff -puN fs/namespace.c~change-spinlock-to-mutex fs/namespace.c
--- linux-2.6.git/fs/namespace.c~change-spinlock-to-mutex 2008-01-10
10:45:47.0 -0800
+++
This is just RFC for now. I'm tracking down a wee bit of
list corruption. But, I wanted to send out so you could
compare to the last approach.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
We're moving a big chunk of the burden of keeping people from
writing to r/o filesystems from the superblock into the
vfsmount. This requires that we keep track somehow of the
mounts that might allow writes to a superblock.
You could track this directly by keeping a count of such
mounts in the
The comment tells most of the story. I want to make the
spinlock in this case into a mutex, and the current
underflow protection mechanism uses preempt disabling from
put/get_cpu_Var(). I can't use that with a mutex.
Without the preempt disabling, there is no limit to the
number of cpus that
On 19:59, Andi Kleen wrote:
But perhaps for such a long ioctl handler it would be better to move
the lock/unlock_kernel()s into the individual case ...: statements;
then it could be eliminated step by step.
Sure, I can do that if James likes the idea. Since not all case
statements need the
[EMAIL PROTECTED] writes:
Index: linux-2.6.git/include/asm-generic/iomap.h
===
--- linux-2.6.git.orig/include/asm-generic/iomap.h2008-01-08
03:31:37.0 -0800
+++ linux-2.6.git/include/asm-generic/iomap.h 2008-01-08
[EMAIL PROTECTED] writes:
i386: Map only usable memory in identity map. Reserved memory maps to a
zero page.
Same comments as for x86-64 version.
-Andi
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On , Joonwoo Park wrote:
--- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
+++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
@@ -6262,6 +6262,10 @@ static void __iwl_down(struct iwl_priv *priv)
/* tell the device to stop sending interrupts */
iwl_disable_interrupts(priv);
+
Hi Sam,
On Thu, 10 Jan 2008, Sam Ravnborg wrote:
Hi Steven.
Index: linux-compile-i386.git/arch/x86/Kconfig
===
--- linux-compile-i386.git.orig/arch/x86/Kconfig2008-01-09
14:09:36.0 -0500
+++
Missed the description on that one. Here it is:
We're shortly going to need to be able to block new
mnt_writers for long periods of time during a
superblock remount operation. Since this operation
can sleep, we can not use a spinlock. We opt for
a mutex instead.
This are very, very rarely
[EMAIL PROTECTED] writes:
/* Reset the direct mapping. Can block */
- if (p-flags 20)
- ioremap_change_attr(p-phys_addr, p-size, 0);
+ if (p-flags 20) {
+ free_mattr(p-phys_addr, p-phys_addr + get_vm_area_size(p),
+
Straight forward port of pat-drivers.patch to x86 tree
Signed-off-by: Venkatesh Pallipadi [EMAIL PROTECTED]
Signed-off-by: Suresh Siddha [EMAIL PROTECTED]
Index: linux-2.6.24-rc/drivers/char/drm/drm_proc.c
===
---
New interfaces exported for uc and wc accesses. Apps has to change to use
these new interfaces.
Signed-off-by: Venkatesh Pallipadi [EMAIL PROTECTED]
Signed-off-by: Suresh Siddha [EMAIL PROTECTED]
Index: linux-2.6.git/drivers/pci/pci-sysfs.c
This series is heavily derived from the PAT patchset by Eric Biederman and
Andi Kleen.
http://www.firstfloor.org/pub/ak/x86_64/pat/
This patchset is a followup of PAT support for X86_64
http://www.ussg.iu.edu/hypermail/linux/kernel/0712.1/2268.html
Things changed from the above (Dec 13 2007)
On Thu, 10 Jan 2008, Matt Mackall wrote:
Here I'm going to differ with you. The premises of the SLAB concept
(from the original paper) are:
a) fragmentation of conventional allocators gets worse over time
Even fragmentation of SLAB/SLUB gets worses over time. That is why we need
a defrag
On Wednesday 09 January 2008, H. Peter Anvin wrote:
Pavel Machek wrote:
Of course, if we'd been using kinit, soft panic would
have been done exclusively in userspace...
What's the status of kinit, btw?
Pavel
It's bitrotted a
701 - 800 of 1050 matches
Mail list logo