* 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 s
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" k
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
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 C
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. g
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, b
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 memo
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 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 disa
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 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 min
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 l
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) c
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
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 erro
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
> the
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 ca
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
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 sta
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 sta
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, SysRq-
23 matches
Mail list logo
