* Nick Piggin <[EMAIL PROTECTED]> wrote:
> > This means that even if some cpu is stuck in a spinlock loop with
> > interrupts disabled, you'd see it with this thing. The way it works
> > is that cross cpu vectored interrupts are disabled independently of
> > the processor interrupt level on
On Thu, Nov 01, 2007 at 10:02:04PM -0700, David Miller wrote:
> From: David Miller <[EMAIL PROTECTED]>
> Date: Wed, 31 Oct 2007 00:44:25 -0700 (PDT)
>
> > From: Nick Piggin <[EMAIL PROTECTED]>
> > Date: Wed, 31 Oct 2007 08:41:06 +0100
> >
> > > You could possibly even do a generic "best effort"
* Nick Piggin [EMAIL PROTECTED] wrote:
This means that even if some cpu is stuck in a spinlock loop with
interrupts disabled, you'd see it with this thing. The way it works
is that cross cpu vectored interrupts are disabled independently of
the processor interrupt level on sparc64.
On Thu, Nov 01, 2007 at 10:02:04PM -0700, David Miller wrote:
From: David Miller [EMAIL PROTECTED]
Date: Wed, 31 Oct 2007 00:44:25 -0700 (PDT)
From: Nick Piggin [EMAIL PROTECTED]
Date: Wed, 31 Oct 2007 08:41:06 +0100
You could possibly even do a generic best effort kind of thing with
On Thu, Nov 01, 2007 at 06:17:42PM -0700, Linus Torvalds wrote:
>
>
> On Fri, 2 Nov 2007, Nick Piggin wrote:
> >
> > But we do want to allow forced COW faults for MAP_PRIVATE mappings. gdb
> > uses this for inserting breakpoints (but fortunately, a COW page in a
> > MAP_PRIVATE mapping is a
From: David Miller <[EMAIL PROTECTED]>
Date: Wed, 31 Oct 2007 00:44:25 -0700 (PDT)
> From: Nick Piggin <[EMAIL PROTECTED]>
> Date: Wed, 31 Oct 2007 08:41:06 +0100
>
> > You could possibly even do a generic "best effort" kind of thing with
> > regular IPIs, that will timeout and continue if some
On Fri, 2 Nov 2007, Nick Piggin wrote:
>
> But we do want to allow forced COW faults for MAP_PRIVATE mappings. gdb
> uses this for inserting breakpoints (but fortunately, a COW page in a
> MAP_PRIVATE mapping is a much more natural thing for the VM).
Yes, I phrased that badly. I meant that I'd
On Thu, Nov 01, 2007 at 09:08:45AM -0700, Linus Torvalds wrote:
>
>
> On Thu, 1 Nov 2007, Nick Piggin wrote:
> >
> > Untested patch follows
>
> Ok, this looks ok.
>
> Except I would remove the VM_MAYSHARE bit from the test.
But we do want to allow forced COW faults for MAP_PRIVATE mappings.
On Thu, 1 Nov 2007, Nick Piggin wrote:
>
> Untested patch follows
Ok, this looks ok.
Except I would remove the VM_MAYSHARE bit from the test.
That whole bit should go, in fact.
We used to make it something different: iirc, a read-only SHARED mapping
was downgraded to a non-shared mapping,
On Thu, Nov 01, 2007 at 08:14:47AM -0700, Linus Torvalds wrote:
>
>
> On Thu, 1 Nov 2007, Nick Piggin wrote:
>
> > On Wed, Oct 31, 2007 at 04:08:21PM -0700, Linus Torvalds wrote:
> > >
> > > We made much bigger changes to ptrace support when we disallowed writing
> > > to read-only shared
On Thu, 1 Nov 2007, Nick Piggin wrote:
> On Wed, Oct 31, 2007 at 04:08:21PM -0700, Linus Torvalds wrote:
> >
> > We made much bigger changes to ptrace support when we disallowed writing
> > to read-only shared memory areas (we used to do the magic per-page COW
> > thing).
>
> Really? No, we
On Thu, 1 Nov 2007, Nick Piggin wrote:
On Wed, Oct 31, 2007 at 04:08:21PM -0700, Linus Torvalds wrote:
We made much bigger changes to ptrace support when we disallowed writing
to read-only shared memory areas (we used to do the magic per-page COW
thing).
Really? No, we still do
On Thu, Nov 01, 2007 at 08:14:47AM -0700, Linus Torvalds wrote:
On Thu, 1 Nov 2007, Nick Piggin wrote:
On Wed, Oct 31, 2007 at 04:08:21PM -0700, Linus Torvalds wrote:
We made much bigger changes to ptrace support when we disallowed writing
to read-only shared memory areas (we
On Thu, 1 Nov 2007, Nick Piggin wrote:
Untested patch follows
Ok, this looks ok.
Except I would remove the VM_MAYSHARE bit from the test.
That whole bit should go, in fact.
We used to make it something different: iirc, a read-only SHARED mapping
was downgraded to a non-shared mapping,
On Thu, Nov 01, 2007 at 09:08:45AM -0700, Linus Torvalds wrote:
On Thu, 1 Nov 2007, Nick Piggin wrote:
Untested patch follows
Ok, this looks ok.
Except I would remove the VM_MAYSHARE bit from the test.
But we do want to allow forced COW faults for MAP_PRIVATE mappings. gdb
uses
On Fri, 2 Nov 2007, Nick Piggin wrote:
But we do want to allow forced COW faults for MAP_PRIVATE mappings. gdb
uses this for inserting breakpoints (but fortunately, a COW page in a
MAP_PRIVATE mapping is a much more natural thing for the VM).
Yes, I phrased that badly. I meant that I'd be
From: David Miller [EMAIL PROTECTED]
Date: Wed, 31 Oct 2007 00:44:25 -0700 (PDT)
From: Nick Piggin [EMAIL PROTECTED]
Date: Wed, 31 Oct 2007 08:41:06 +0100
You could possibly even do a generic best effort kind of thing with
regular IPIs, that will timeout and continue if some CPUs don't
On Thu, Nov 01, 2007 at 06:17:42PM -0700, Linus Torvalds wrote:
On Fri, 2 Nov 2007, Nick Piggin wrote:
But we do want to allow forced COW faults for MAP_PRIVATE mappings. gdb
uses this for inserting breakpoints (but fortunately, a COW page in a
MAP_PRIVATE mapping is a much more
On Wed, Oct 31, 2007 at 04:08:21PM -0700, Linus Torvalds wrote:
>
>
> On Wed, 31 Oct 2007, Nick Piggin wrote:
> >
> > No that would be great. Fingers crossed it won't cause any problems.
>
> I actually doubt it will cause problems.
>
> We made much bigger changes to ptrace support when we
On Wed, 31 Oct 2007, Nick Piggin wrote:
>
> No that would be great. Fingers crossed it won't cause any problems.
I actually doubt it will cause problems.
We made much bigger changes to ptrace support when we disallowed writing
to read-only shared memory areas (we used to do the magic
On Wed, Oct 31, 2007 at 08:59:41AM -0700, Linus Torvalds wrote:
>
>
> On Wed, 31 Oct 2007, Nick Piggin wrote:
> >
> > Well the patch is right, in the context of the regression I introduced
> > (and so it should probably go into 2.6.23).
>
> Yeah, it probably is fine for -stable.
>
> And if
On 31/10/2007, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> But I just rebooted and tested - the cleaned-up patch does seem to work
> fine, and I get "Cannot access memory at address " rather than any
> reported problem.
I can confirm the same thing here, FWIW.
Cheers,
Duane.
--
"I never could
On Wed, 31 Oct 2007, Nick Piggin wrote:
>
> Well the patch is right, in the context of the regression I introduced
> (and so it should probably go into 2.6.23).
Yeah, it probably is fine for -stable.
And if mine (which actually changes behaviour, in that it makes ptrace get
an access error)
On Wed, Oct 31, 2007 at 08:11:10AM -0700, Linus Torvalds wrote:
>
>
> On Wed, 31 Oct 2007, Nick Piggin wrote:
> >
> > However I actually don't really like how this all works. I don't like that
> > filemap.c should have to know about ptrace, or exactly what ptrace wants
> > here.
>
> It
On Wed, 31 Oct 2007, Nick Piggin wrote:
>
> However I actually don't really like how this all works. I don't like that
> filemap.c should have to know about ptrace, or exactly what ptrace wants here.
It shouldn't. It should just fail when it fails. Then, handle_mm_fault()
should return an
On 31/10/2007, Nick Piggin <[EMAIL PROTECTED]> wrote:
> Well that's probably the best bug report I've ever had, thanks Duane!
Aw, shucks!
> The issue is a silly thinko -- I didn't pay enough attention to the ptrace
> rules in filemap_fault :( partly I think that's because I don't understand
>
From: Nick Piggin <[EMAIL PROTECTED]>
Date: Wed, 31 Oct 2007 08:41:06 +0100
> On Tue, Oct 30, 2007 at 11:56:00PM -0700, David Miller wrote:
> > From: Nick Piggin <[EMAIL PROTECTED]>
> > Date: Wed, 31 Oct 2007 07:42:21 +0100
> >
> > Anyways, my core suggestion is to add a hook here so platforms
On Tue, Oct 30, 2007 at 11:56:00PM -0700, David Miller wrote:
> From: Nick Piggin <[EMAIL PROTECTED]>
> Date: Wed, 31 Oct 2007 07:42:21 +0100
>
> > Sysrq+T fails to show the stack trace of a running task. Presumably this
> > is to avoid a garbled stack, however it can often be useful, and besides
On Tue, Oct 30, 2007 at 11:56:00PM -0700, David Miller wrote:
From: Nick Piggin [EMAIL PROTECTED]
Date: Wed, 31 Oct 2007 07:42:21 +0100
Sysrq+T fails to show the stack trace of a running task. Presumably this
is to avoid a garbled stack, however it can often be useful, and besides
there
From: Nick Piggin [EMAIL PROTECTED]
Date: Wed, 31 Oct 2007 08:41:06 +0100
On Tue, Oct 30, 2007 at 11:56:00PM -0700, David Miller wrote:
From: Nick Piggin [EMAIL PROTECTED]
Date: Wed, 31 Oct 2007 07:42:21 +0100
Anyways, my core suggestion is to add a hook here so platforms can
do the
On 31/10/2007, Nick Piggin [EMAIL PROTECTED] wrote:
Well that's probably the best bug report I've ever had, thanks Duane!
Aw, shucks!
The issue is a silly thinko -- I didn't pay enough attention to the ptrace
rules in filemap_fault :( partly I think that's because I don't understand
them and
On Wed, 31 Oct 2007, Nick Piggin wrote:
However I actually don't really like how this all works. I don't like that
filemap.c should have to know about ptrace, or exactly what ptrace wants here.
It shouldn't. It should just fail when it fails. Then, handle_mm_fault()
should return an error
On Wed, Oct 31, 2007 at 08:11:10AM -0700, Linus Torvalds wrote:
On Wed, 31 Oct 2007, Nick Piggin wrote:
However I actually don't really like how this all works. I don't like that
filemap.c should have to know about ptrace, or exactly what ptrace wants
here.
It shouldn't. It
On Wed, 31 Oct 2007, Nick Piggin wrote:
Well the patch is right, in the context of the regression I introduced
(and so it should probably go into 2.6.23).
Yeah, it probably is fine for -stable.
And if mine (which actually changes behaviour, in that it makes ptrace get
an access error)
On 31/10/2007, Linus Torvalds [EMAIL PROTECTED] wrote:
But I just rebooted and tested - the cleaned-up patch does seem to work
fine, and I get Cannot access memory at address xyz rather than any
reported problem.
I can confirm the same thing here, FWIW.
Cheers,
Duane.
--
I never could learn
On Wed, Oct 31, 2007 at 08:59:41AM -0700, Linus Torvalds wrote:
On Wed, 31 Oct 2007, Nick Piggin wrote:
Well the patch is right, in the context of the regression I introduced
(and so it should probably go into 2.6.23).
Yeah, it probably is fine for -stable.
And if mine (which
On Wed, 31 Oct 2007, Nick Piggin wrote:
No that would be great. Fingers crossed it won't cause any problems.
I actually doubt it will cause problems.
We made much bigger changes to ptrace support when we disallowed writing
to read-only shared memory areas (we used to do the magic per-page
On Wed, Oct 31, 2007 at 04:08:21PM -0700, Linus Torvalds wrote:
On Wed, 31 Oct 2007, Nick Piggin wrote:
No that would be great. Fingers crossed it won't cause any problems.
I actually doubt it will cause problems.
We made much bigger changes to ptrace support when we disallowed
From: Nick Piggin <[EMAIL PROTECTED]>
Date: Wed, 31 Oct 2007 07:42:21 +0100
> Sysrq+T fails to show the stack trace of a running task. Presumably this
> is to avoid a garbled stack, however it can often be useful, and besides
> there is no guarantee that the task won't start running in the middle
On Wed, Oct 31, 2007 at 12:45:35AM +, Duane Griffin wrote:
> Accessing a memory mapped region past the last page containing a valid
> file mapping produces a SIGBUS fault (as it should). Running a program
> that does this under gdb, then accessing the invalid memory from gdb,
> causes it to
On Wed, Oct 31, 2007 at 12:45:35AM +, Duane Griffin wrote:
> Accessing a memory mapped region past the last page containing a valid
> file mapping produces a SIGBUS fault (as it should). Running a program
> that does this under gdb, then accessing the invalid memory from gdb,
> causes it to
Accessing a memory mapped region past the last page containing a valid
file mapping produces a SIGBUS fault (as it should). Running a program
that does this under gdb, then accessing the invalid memory from gdb,
causes it to start consuming 100% CPU and become unkillable. Once in
that state,
Accessing a memory mapped region past the last page containing a valid
file mapping produces a SIGBUS fault (as it should). Running a program
that does this under gdb, then accessing the invalid memory from gdb,
causes it to start consuming 100% CPU and become unkillable. Once in
that state,
On Wed, Oct 31, 2007 at 12:45:35AM +, Duane Griffin wrote:
Accessing a memory mapped region past the last page containing a valid
file mapping produces a SIGBUS fault (as it should). Running a program
that does this under gdb, then accessing the invalid memory from gdb,
causes it to start
On Wed, Oct 31, 2007 at 12:45:35AM +, Duane Griffin wrote:
Accessing a memory mapped region past the last page containing a valid
file mapping produces a SIGBUS fault (as it should). Running a program
that does this under gdb, then accessing the invalid memory from gdb,
causes it to start
From: Nick Piggin [EMAIL PROTECTED]
Date: Wed, 31 Oct 2007 07:42:21 +0100
Sysrq+T fails to show the stack trace of a running task. Presumably this
is to avoid a garbled stack, however it can often be useful, and besides
there is no guarantee that the task won't start running in the middle of
46 matches
Mail list logo
