On Thu, Mar 15, 2007 at 05:53:04PM -0800, Andrew Morton wrote:
My, what a lot of code you have here. I note that nobody can be assed even
reviewing it. Now why is that?
I hope, Al could find some time again.
On Sun, 11 Mar 2007 20:04:56 +0300 Alexey Dobriyan [EMAIL PROTECTED] wrote:
Fix
Hi all,
I've found some strange ext3 ioctl under CONFIG_JBD_DEBUG:
EXT3_IOC_WAIT_FOR_READONLY.
I had DEBUG_SPINLOCK enabled and my kernel was crashed on wait-for-readonly.c
test from ext3-tools because ioctl handler tries to use uninitialized
EXT3_SB(sb)-ro_wait_queue and waits
CONFIG_MODULES=n case fixed, We're still discussing if making
module_mutex global is OK, though.
-
[PATCH 1/2] Race between cat /proc/kallsyms and rmmod
Iterating code of /proc/kallsyms calls module_get_kallsym() which grabs
and drops
[cc'ing folks whose proc files are affected]
kallsyms_lookup() can call module_address_lookup() which iterates over
modules list without module_mutex taken. Comment at the top of
module_address_lookup() says it's for oops resolution so races are
irrelevant, but in some cases it's reachable from
On Friday 16 March 2007 11:57, Pavel Emelianov wrote:
Oleg Nesterov wrote:
On 03/14, Eric W. Biederman wrote:
Pavel Emelianov [EMAIL PROTECTED] writes:
Hi.
I'm looking at how alloc_pid() works and can't understand
one (simple/stupid) thing.
It first kmem_cache_alloc()-s a strct
Eric Dumazet wrote:
On Friday 16 March 2007 11:57, Pavel Emelianov wrote:
Oleg Nesterov wrote:
On 03/14, Eric W. Biederman wrote:
Pavel Emelianov [EMAIL PROTECTED] writes:
Hi.
I'm looking at how alloc_pid() works and can't understand
one (simple/stupid) thing.
It first
William Lee Irwin III [EMAIL PROTECTED] writes:
William Lee Irwin III [EMAIL PROTECTED] writes:
Radix trees' space behavior is extremely poor in sparsely-populated
index spaces. There is no way they would save space or even come close
to the current space footprint.
On Wed, Mar 14, 2007 at
On Thu, Mar 15, 2007 at 10:34:35PM +0530, Srivatsa Vaddagiri wrote:
On Thu, Mar 15, 2007 at 04:24:37AM -0700, Paul Menage wrote:
If there really was a grouping that was always guaranteed to match the
way you wanted to group tasks for e.g. resource control, then yes, it
would be great to use
On Thu, Mar 15, 2007 at 12:12:50PM -0700, Paul Menage wrote:
On 3/15/07, Srivatsa Vaddagiri [EMAIL PROTECTED] wrote:
On Thu, Mar 15, 2007 at 04:24:37AM -0700, Paul Menage wrote:
If there really was a grouping that was always guaranteed to match
the way you wanted to group tasks for e.g.
On Fri, 2007-03-16 at 05:32 -0600, Eric W. Biederman wrote:
Ian Kent [EMAIL PROTECTED] writes:
On Mon, 12 Mar 2007, [EMAIL PROTECTED] wrote:
From: Sukadev Bhattiprolu [EMAIL PROTECTED]
Subject: [PATCH 2/2] Replace pid_t in autofs with struct pid reference.
Make autofs
Ingo Molnar wrote:
* Alexey Dobriyan [EMAIL PROTECTED] wrote:
[cc'ing folks whose proc files are affected]
kallsyms_lookup() can call module_address_lookup() which iterates over
modules list without module_mutex taken. Comment at the top of
module_address_lookup() says it's for oops
* Paulo Marques [EMAIL PROTECTED] wrote:
looking at the problem from another angle: wouldnt this be something
that would benefit from freeze_processes()/unfreeze_processes(), and
hence no locking would be required?
I also considered this, but it seemed a little too blunt to stop
On Fri, 2007-03-16 at 15:44 +0100, Cedric Le Goater wrote:
How about you send over the autofs4 bit and I'll have a look (the autofs
patch looked fine). That would save me a bit of time and if there are
any changes needed I can send an updated patch for you guys to review. I
don't think
Ingo Molnar wrote:
* Paulo Marques [EMAIL PROTECTED] wrote:
looking at the problem from another angle: wouldnt this be something
that would benefit from freeze_processes()/unfreeze_processes(), and
hence no locking would be required?
I also considered this, but it seemed a little too blunt to
Oleg Nesterov [EMAIL PROTECTED] writes:
Sukadev Bhattiprolu wrote:
This means that idle threads (except swapper) are visible to
for_each_process()
and do_each_thread(). Looks dangerous and somewhat strange to me.
Could you explain this change?
Good catch. I've been so busy pounding
William Lee Irwin III [EMAIL PROTECTED] writes:
On Fri, Mar 16, 2007 at 07:04:28AM -0600, Eric W. Biederman wrote:
Grr. s/patricia tree/fib tree/. We use that in the networking for
the forwarding information base and I got mis-remembered it. Anyway
the interesting thing with the binary
Herbert wrote:
looks good to me, except for the potential issue with
the double indirection introducing too much overhear
It's not the indirection count that I worry about.
It's the scalability of the locking. We must avoid as
much as possible adding any global locks on key code paths.
This
17 matches
Mail list logo
