Roland McGrath | 19 Aug 01:10 2007

Re: [PATCH 2/5] exec: simplify ->sighand switching

> There is no any reason to do recalc_sigpending() after changing ->sighand.
> To begin with, recalc_sigpending() does not take ->sighand into account.

I agree.  I think that call dates from before some other cleanups in that
code, when ->signal was changed there.  At the time, it was the most
conservative change to leave recalc_sigpending in case the side effects it
used to have were desireable (we've since decided to change those anyway).

Roland McGrath | 19 Aug 01:12 2007

Re: [PATCH 3/5] exec: simplify the new ->sighand allocation

> 	- ENOMEM still can happen after de_thread(), ->sighand is not the last
> 	  object we have to allocate

As long as this is true, I think it's the incontrovertible argument there
is no reason not to simplify it.  (Not that I don't also agree with your
other reasons).

Paul E. McKenney | 19 Aug 01:19 2007

Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures

On Sat, Aug 18, 2007 at 03:41:13PM -0700, Linus Torvalds wrote:
> On Sat, 18 Aug 2007, Paul E. McKenney wrote:
> > 
> > One of the gcc guys claimed that he thought that the two-instruction
> > sequence would be faster on some x86 machines.  I pointed out that
> > there might be a concern about code size.  I chose not to point out
> > that people might also care about the other x86 machines.  ;-)
> Some (very few) x86 uarchs do tend to prefer "load-store" like code 
> generation, and doing a "mov [mem],reg + op reg" instead of "op [mem]" can 
> actually be faster on some of them. Not any that are relevant today, 
> though.


> Also, that has nothing to do with volatile, and should be controlled by 
> optimization flags (like -mtune). In fact, I thought there was a separate 
> flag to do that (ie something like "-mload-store"), but I can't find it, 
> so maybe that's just my fevered brain..

Good point, will suggest this if the need arises.

							Thanx, Paul
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo <at>
More majordomo info at

(Continue reading)

Neil Horman | 19 Aug 01:23 2007

Re: + proc-export-a-processes-resource-limits-via-proc-pid.patch added to -mm tree

> Neil, please, don't add tasklist_lock again. It was not easy to wipe it from
> fs/proc/ :) Just change this code to use rcu_read_lock().

Ok, done/tested.  Thanks!

Currently, there exists no method for a process to query the resource
limits of another process.  They can be inferred via some mechanisms but they
cannot be explicitly determined.  Given that this information can be usefull to
know during the debugging of an application, I've written this patch which
exports all of a processes limits via /proc/≤pid>/limits.  Tested successfully
by myself on x86 on top of 2.6.23-rc2-mm1.

Signed-off-by: Neil Horman <nhorman <at>>

 base.c |   77 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 77 insertions(+)

diff --git a/fs/proc/base.c b/fs/proc/base.c
index ed2b224..86130b0 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
 <at>  <at>  -74,6 +74,7  <at>  <at> 
 #include <linux/nsproxy.h>
 #include <linux/oom.h>
 #include <linux/elf.h>
+#include <linux/resource.h>
 #include "internal.h"

(Continue reading)

Roland McGrath | 19 Aug 01:25 2007

Re: [RFC,PATCH 5/5] exec: RT sub-thread can livelock and monopolize CPU on exec

Maybe it can use wait_task_inactive, which IIUC is being changed to address
the same RT issue.  OTOH, notify_count exists only for this.  So maybe the
better way is to clean that whole mechanism up somehow.  The exit.c changes
in your patch seem to be making it more mysterious rather than less so.
I haven't really thought much about the better solution.

Alan | 19 Aug 01:26 2007

Re: Thinking outside the box on file systems

On Wed, 2007-08-15 at 13:22 -0400, Kyle Moffett wrote:
> On Aug 15, 2007, at 13:09:31, Marc Perkel wrote:
> > The idea is that people have permissions - not files.  By people I  
> > mean users, groups, managers, applications
> > etc. One might even specify that there are no permission  
> > restrictions at all. Part of the process would be that the kernel  
> > load what code it will use for the permission system. It might even  
> > be a little perl script you write.
> >
> > Also - you aren't even giving permission to access files. It's  
> > permission to access name patterns. One could apply REGEX masks to  
> > names to determine permissions. So if you have permission to the  
> > name you have permission to the file.
> Please excuse me, I'm going to go stand over in the corner for a minute.
> *hahahahahaa hahahahahaaa hahaa hoo hee snicker sniff*
> *wanders back into the conversation*
> Sorry about that, pardon me.
> I suspect you will find it somewhat hard to convince *anybody* on  
> this list to put either a regex engine or a Perl interpreter into the  
> kernel.  I doubt you could even get a simple shell-style pattern  
> matcher in.  First of all, both of the former chew up enormous gobs  
> of stack space *AND* they're NP-complete.  You just can't do such  
> matching even in polynomial time, let alone something that scales  
> appropriately for an OS kernel like, say, O(log(n)).

(Continue reading)

Alan | 19 Aug 01:27 2007

Re: Thinking outside the box on file systems

On Wed, 2007-08-15 at 10:34 -0700, Marc Perkel wrote:

> Keep in mind that this is about thinking outside the
> box. Don't let new ideas scare you.

My cat thinks outside the box all the time.  Cleaning it up is a real

Jakub Narebski | 19 Aug 01:28 2007

Git User's Survey 2007

Hi all,

We would like to ask you a few questions about your use of the GIT
version control system. This survey is mainly to understand who is
using GIT, how and why.

The results will be discussed on the git mailing list and published to 
the GIT wiki at

We'll close the survey in three weeks starting from 20 August 2007,
on 10 September 2007.

Please devote a few minutes of your time to fill this simple
questionnaire, it will help a lot the git community to understand your
needs, what you like of GIT, and of course what you don't like  of it.

The survey can be found here:


Jakub Narebski
Roland McGrath | 19 Aug 01:27 2007

Re: [PATCH 1/5] exec: kill unsafe BUG_ON(sig->count) checks

Those BUG_ON's were there because of past bugs and fragility in the
de_thread and exit synchronization stuff.  There's no real need to leave
them (in fixed form) if we are confident of that stuff working right now,
or have other assertions to give us that confidence when we change it.

Al Viro | 19 Aug 02:03 2007

[PATCH] soft-fp.h tpyo

Signed-off-by: Al Viro <viro <at>>
diff --git a/include/math-emu/soft-fp.h b/include/math-emu/soft-fp.h
index a0721ef..a6f873b 100644
--- a/include/math-emu/soft-fp.h
+++ b/include/math-emu/soft-fp.h
 <at>  <at>  -98,7 +98,7  <at>  <at> 


 #define FP_SET_EXCEPTION(ex)				\