Ion Badulescu <[EMAIL PROTECTED]> writes:
> On 23 Apr 2001 12:54:22 -0600, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>
> > I'll include it again. I had it attached as a plain text attachment,
> > I don't know if that is a problem or not.
>
> Actually it was attached as text/x-patch, not as
On 23 Apr 2001 12:54:22 -0600, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> I'll include it again. I had it attached as a plain text attachment,
> I don't know if that is a problem or not.
Actually it was attached as text/x-patch, not as text/plain... so
pine certainly refused to display it
"Manfred Spraul" <[EMAIL PROTECTED]> writes:
> > Well looking a little more closely than I did last night it looks like
> > access_process_vm (called from ptrace) can cause what amounts to a
> > page fault at pretty arbitrary times.
>
> It's also used for several /proc/ files.
>
> I remember
Manfred Spraul [EMAIL PROTECTED] writes:
Well looking a little more closely than I did last night it looks like
access_process_vm (called from ptrace) can cause what amounts to a
page fault at pretty arbitrary times.
It's also used for several /proc/pid files.
I remember that I got
On 23 Apr 2001 12:54:22 -0600, Eric W. Biederman [EMAIL PROTECTED] wrote:
I'll include it again. I had it attached as a plain text attachment,
I don't know if that is a problem or not.
Actually it was attached as text/x-patch, not as text/plain... so
pine certainly refused to display it
> Well looking a little more closely than I did last night it looks like
> access_process_vm (called from ptrace) can cause what amounts to a
> page fault at pretty arbitrary times.
It's also used for several /proc/ files.
I remember that I got crashes with concurrent exec+cat
/proc//cmdline
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On 23 Apr 2001, Eric W. Biederman wrote:
> >
> > ptrace is protected by the big kernel lock, but exec isn't so that
> > doesn't help. Hmm. ptrace does require that the process be stopped
> > in all cases
>
> Right. Ptrace definitely cannot access
On 23 Apr 2001, Eric W. Biederman wrote:
>
> ptrace is protected by the big kernel lock, but exec isn't so that
> doesn't help. Hmm. ptrace does require that the process be stopped
> in all cases
Right. Ptrace definitely cannot access a process at "arbitrary" times. In
fact, it is very
"David S. Miller" <[EMAIL PROTECTED]> writes:
> Eric W. Biederman writes:
> > In building a patch for 2.4.3 I also discovered that we are not taking
> > the mmap_sem around do_brk in the exec paths.
>
> Does that really matter? Who else can get at the address space? We
> are a singly
>And of course since much of the code in the kernel is built on the
>copy a good example neglecting the locking without a big comment,
>invites trouble elsewhere like in elf_load_library. Where we could
>have multiple threads running.
Out of interest: does anything, anywhere, actually use
"David S. Miller" <[EMAIL PROTECTED]> writes:
> Eric W. Biederman writes:
> > In building a patch for 2.4.3 I also discovered that we are not taking
> > the mmap_sem around do_brk in the exec paths.
>
> Does that really matter?
In the library loader I can certainly see it making a
David S. Miller [EMAIL PROTECTED] writes:
Eric W. Biederman writes:
In building a patch for 2.4.3 I also discovered that we are not taking
the mmap_sem around do_brk in the exec paths.
Does that really matter?
In the library loader I can certainly see it making a difference.
Who
And of course since much of the code in the kernel is built on the
copy a good example neglecting the locking without a big comment,
invites trouble elsewhere like in elf_load_library. Where we could
have multiple threads running.
Out of interest: does anything, anywhere, actually use
On 23 Apr 2001, Eric W. Biederman wrote:
ptrace is protected by the big kernel lock, but exec isn't so that
doesn't help. Hmm. ptrace does require that the process be stopped
in all cases
Right. Ptrace definitely cannot access a process at arbitrary times. In
fact, it is very serialized
David S. Miller [EMAIL PROTECTED] writes:
Eric W. Biederman writes:
In building a patch for 2.4.3 I also discovered that we are not taking
the mmap_sem around do_brk in the exec paths.
Does that really matter? Who else can get at the address space? We
are a singly referenced
Well looking a little more closely than I did last night it looks like
access_process_vm (called from ptrace) can cause what amounts to a
page fault at pretty arbitrary times.
It's also used for several /proc/pid files.
I remember that I got crashes with concurrent exec+cat
/proc/pid/cmdline
Linus Torvalds [EMAIL PROTECTED] writes:
On 23 Apr 2001, Eric W. Biederman wrote:
ptrace is protected by the big kernel lock, but exec isn't so that
doesn't help. Hmm. ptrace does require that the process be stopped
in all cases
Right. Ptrace definitely cannot access a process at
Eric W. Biederman writes:
> In building a patch for 2.4.3 I also discovered that we are not taking
> the mmap_sem around do_brk in the exec paths.
Does that really matter? Who else can get at the address space? We
are a singly referenced address space at that point... perhaps ptrace?
A little while ago I was playing with building an elf self extracting
binary. In doing so I discovered that the linux kernel does not
handle elf program headers with multiple BSS segments.
In building a patch for 2.4.3 I also discovered that we are not taking
the mmap_sem around do_brk in the
A little while ago I was playing with building an elf self extracting
binary. In doing so I discovered that the linux kernel does not
handle elf program headers with multiple BSS segments.
In building a patch for 2.4.3 I also discovered that we are not taking
the mmap_sem around do_brk in the
Eric W. Biederman writes:
In building a patch for 2.4.3 I also discovered that we are not taking
the mmap_sem around do_brk in the exec paths.
Does that really matter? Who else can get at the address space? We
are a singly referenced address space at that point... perhaps ptrace?
Later,
21 matches
Mail list logo
