On 08/09, Frederic Weisbecker wrote:
>
> On Thu, Aug 08, 2013 at 08:15:21PM +0200, Oleg Nesterov wrote:
> > But probably we should move "attr.bp_len == HW_BREAKPOINT_LEN_1" check
> > from arch_build_bp_info() to its caller, arch_validate_hwbkpt_settings().
> >
> > Because:
> >
> > > But this
On Thu, Aug 08, 2013 at 08:15:21PM +0200, Oleg Nesterov wrote:
> On 08/08, Frederic Weisbecker wrote:
> >
> > I'm all for fixing this. May be we can start by backporting a patch that
> > ignores the value of gen_len for instruction breakpoints in x86?
>
> Or perhaps we can start with the
On Thu, Aug 08, 2013 at 08:15:21PM +0200, Oleg Nesterov wrote:
On 08/08, Frederic Weisbecker wrote:
I'm all for fixing this. May be we can start by backporting a patch that
ignores the value of gen_len for instruction breakpoints in x86?
Or perhaps we can start with the something like
On 08/09, Frederic Weisbecker wrote:
On Thu, Aug 08, 2013 at 08:15:21PM +0200, Oleg Nesterov wrote:
But probably we should move attr.bp_len == HW_BREAKPOINT_LEN_1 check
from arch_build_bp_info() to its caller, arch_validate_hwbkpt_settings().
Because:
But this bp_len
should
On 08/08, Frederic Weisbecker wrote:
>
> I'm all for fixing this. May be we can start by backporting a patch that
> ignores the value of gen_len for instruction breakpoints in x86?
Or perhaps we can start with the something like below.
But probably we should move "attr.bp_len ==
On Thu, Aug 08, 2013 at 05:41:07PM +0200, Oleg Nesterov wrote:
> On 08/07, Linus Torvalds wrote:
> >
> > Now, I do agree that the debug registers are *much* less likely to
> > have those kinds of really subtle issues, so maybe relaxing some of
> > the tests might be reasonable. I'd be a bit
On Thu, Aug 8, 2013 at 8:41 AM, Oleg Nesterov wrote:
>
> On x86 execute breakpoints are only a single byte, which has to be
> the first byte of the instruction. IOW the hardware requires len = 1
> in dr7 or it doesn't work (iirc).
>
> But for some reason perf requires bp_len = sizeof(long), not
On 08/07, Linus Torvalds wrote:
>
> Now, I do agree that the debug registers are *much* less likely to
> have those kinds of really subtle issues, so maybe relaxing some of
> the tests might be reasonable. I'd be a bit nervous about it, but if
> it's *only* the length/alignment, and Intel people
On 08/07, Linus Torvalds wrote:
Now, I do agree that the debug registers are *much* less likely to
have those kinds of really subtle issues, so maybe relaxing some of
the tests might be reasonable. I'd be a bit nervous about it, but if
it's *only* the length/alignment, and Intel people can be
On Thu, Aug 8, 2013 at 8:41 AM, Oleg Nesterov o...@redhat.com wrote:
On x86 execute breakpoints are only a single byte, which has to be
the first byte of the instruction. IOW the hardware requires len = 1
in dr7 or it doesn't work (iirc).
But for some reason perf requires bp_len =
On Thu, Aug 08, 2013 at 05:41:07PM +0200, Oleg Nesterov wrote:
On 08/07, Linus Torvalds wrote:
Now, I do agree that the debug registers are *much* less likely to
have those kinds of really subtle issues, so maybe relaxing some of
the tests might be reasonable. I'd be a bit nervous about
On 08/08, Frederic Weisbecker wrote:
I'm all for fixing this. May be we can start by backporting a patch that
ignores the value of gen_len for instruction breakpoints in x86?
Or perhaps we can start with the something like below.
But probably we should move attr.bp_len == HW_BREAKPOINT_LEN_1
On Wed, Aug 7, 2013 at 12:27 PM, Oleg Nesterov wrote:
>
> I guess Grazvydas only meant the "unnecessary" align/len/type checks.
Yeah, some of them may be a bit questionable, but we don't necessarily
know what each microarchitecture does for unsupported ("undefined")
situations.
Intel actually
On 08/07, Linus Torvalds wrote:
>
> It's a security issue: setting debug traps on kernel code/data
> addresses can not only leak information, it can cause serious trouble
> (taking a debug trap on the first instruction of an NMI handler etc)
> including kernel stack corruption...
I guess
On Wed, Aug 7, 2013 at 5:05 AM, Grazvydas Ignotas wrote:
>
> Personally I'd say the kernel should not limit what's written to debug
> registers. Why can't I write insane values to registers in _my_
> hardware? It's not like it's going to break the hardware or anything.
It may be your hardware,
On 08/07, Grazvydas Ignotas wrote:
>
> It's not that wine needs all this, it's the Windows games that use
> debug registers to store random values to them for their copy
> protection stuff.
Thanks.
> My wine commits try to sidestep these
> kernel restrictions/sanity checking.
My point was, it
On Tue, Aug 6, 2013 at 6:43 PM, Oleg Nesterov wrote:
> Felipe, thanks a lot. Yes fab840f is wrong, this "bug" is already
> used as a feature.
>
> Grazvydas, I cc'ed you because I do not really understand
> set_thread_context(). It does a couple of extra PTRACE_POKEUSER's
> with the "Linux 2.6.33+
On Tue, Aug 6, 2013 at 6:43 PM, Oleg Nesterov o...@redhat.com wrote:
Felipe, thanks a lot. Yes fab840f is wrong, this bug is already
used as a feature.
Grazvydas, I cc'ed you because I do not really understand
set_thread_context(). It does a couple of extra PTRACE_POKEUSER's
with the Linux
On 08/07, Grazvydas Ignotas wrote:
It's not that wine needs all this, it's the Windows games that use
debug registers to store random values to them for their copy
protection stuff.
Thanks.
My wine commits try to sidestep these
kernel restrictions/sanity checking.
My point was, it seems
On Wed, Aug 7, 2013 at 5:05 AM, Grazvydas Ignotas nota...@gmail.com wrote:
Personally I'd say the kernel should not limit what's written to debug
registers. Why can't I write insane values to registers in _my_
hardware? It's not like it's going to break the hardware or anything.
It may be
On 08/07, Linus Torvalds wrote:
It's a security issue: setting debug traps on kernel code/data
addresses can not only leak information, it can cause serious trouble
(taking a debug trap on the first instruction of an NMI handler etc)
including kernel stack corruption...
I guess Grazvydas
On Wed, Aug 7, 2013 at 12:27 PM, Oleg Nesterov o...@redhat.com wrote:
I guess Grazvydas only meant the unnecessary align/len/type checks.
Yeah, some of them may be a bit questionable, but we don't necessarily
know what each microarchitecture does for unsupported (undefined)
situations.
Intel
Felipe, thanks a lot. Yes fab840f is wrong, this "bug" is already
used as a feature.
Grazvydas, I cc'ed you because I do not really understand
set_thread_context(). It does a couple of extra PTRACE_POKEUSER's
with the "Linux 2.6.33+ needs ..." comment. It would be nice if you
can check if 3.11
Felipe, thanks a lot. Yes fab840f is wrong, this bug is already
used as a feature.
Grazvydas, I cc'ed you because I do not really understand
set_thread_context(). It does a couple of extra PTRACE_POKEUSER's
with the Linux 2.6.33+ needs ... comment. It would be nice if you
can check if 3.11 still
On Mon, Aug 5, 2013 at 11:57 AM, Oleg Nesterov wrote:
>
> Yes, yes, sure. I'll write the changelog and send git-revert tomorrow,
Thanks.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More
On 08/05, Linus Torvalds wrote:
>
> On Mon, Aug 5, 2013 at 11:46 AM, Oleg Nesterov wrote:
> >
> > Heh. I pulled wine-git.
> >
> > set_thread_context() does a lot of PTRACE_POKEUSER requests and then
> > it calls resume_after_ptrace() which simply does PTRACE_DETACH.
> >
> > I'll recheck tomorrow,
On Mon, Aug 5, 2013 at 11:46 AM, Oleg Nesterov wrote:
>
> Heh. I pulled wine-git.
>
> set_thread_context() does a lot of PTRACE_POKEUSER requests and then
> it calls resume_after_ptrace() which simply does PTRACE_DETACH.
>
> I'll recheck tomorrow, but it really looks as if it _wants_ to leak
>
On 08/04, Felipe Contreras wrote:
>
> I found a regression while running all v3.11-rcX kernels; Starcract II
> through wine crashes. The culprit is fab840f (ptrace: PTRACE_DETACH
> should do flush_ptrace_hw_breakpoint(child)), I revert that commit and
> there's no crash.
Heh. I pulled wine-git.
On Mon, Aug 5, 2013 at 12:43 PM, Felipe Contreras
wrote:
> On Mon, Aug 5, 2013 at 12:39 PM, Linus Torvalds
> wrote:
>
>> That said, Felipe, can you double-check that it's not timing-related
>> in some subtle way, and test multiple times with just that commit
>> reverted (and not reverted) to
On 08/05, Felipe Contreras wrote:
>
> Would it be possible to just revert that patch for v3.11, and fix it later?
Sure, but it would be nice to investigate.
I think we have the time for revert, this patch was added after 3.10
so I hope we can always revert it before 3.11.
Felipe, I'll try to
On 08/05, Linus Torvalds wrote:
>
> On Mon, Aug 5, 2013 at 6:29 AM, Oleg Nesterov wrote:
> >
> > I never used wine, but I am puzzled anyway. This patch really looks
> > like a simple and minor bugfix.
>
> The patch is indeed trivial, but.. What's the locking here?
>
> Afaik, ptrace_detach() by
On Mon, Aug 5, 2013 at 12:39 PM, Linus Torvalds
wrote:
> That said, Felipe, can you double-check that it's not timing-related
> in some subtle way, and test multiple times with just that commit
> reverted (and not reverted) to make sure that it's 100% that one
> single line by that particular
On Mon, Aug 5, 2013 at 12:11 PM, Oleg Nesterov wrote:
> On 08/05, Felipe Contreras wrote:
>>
>> On Mon, Aug 5, 2013 at 9:39 AM, Oleg Nesterov wrote:
>> >
>> > Hmm. It should not crash under strace... please see below.
>> >
>> >> 953 ptrace(PTRACE_ATTACH, 1035, 0, 0) = -1 EPERM (Operation not
On Mon, Aug 5, 2013 at 6:29 AM, Oleg Nesterov wrote:
>
> I never used wine, but I am puzzled anyway. This patch really looks
> like a simple and minor bugfix.
The patch is indeed trivial, but.. What's the locking here?
Afaik, ptrace_detach() by the parent can race with do_exit() by the
child,
On Mon, 5 August 2013 01:26:46 -0700, Christoph Hellwig wrote:
> On Sun, Aug 04, 2013 at 08:45:16PM -0700, Linus Torvalds wrote:
> > The patch looks right to me - we should pass in similar flags for the
> > create case as for tmpfile to the filesystem.
> >
> > But let's make sure we're all on the
On 08/05, Felipe Contreras wrote:
>
> On Mon, Aug 5, 2013 at 9:39 AM, Oleg Nesterov wrote:
> >
> > Hmm. It should not crash under strace... please see below.
> >
> >> 953 ptrace(PTRACE_ATTACH, 1035, 0, 0) = -1 EPERM (Operation not
> >> permitted)
> >
> > OK, so it actually uses ptrace ;)
> >
>
On Mon, Aug 5, 2013 at 9:39 AM, Oleg Nesterov wrote:
> On 08/05, Felipe Contreras wrote:
>>
>> On Mon, Aug 5, 2013 at 8:29 AM, Oleg Nesterov wrote:
>> >
>> > Could you please run wine under strace
>> >
>> > strace -f -e ptrace -o LOG wine ...
>> >
>> > and show the result?
>>
>> Sure.
>
On 08/05, Felipe Contreras wrote:
>
> On Mon, Aug 5, 2013 at 8:29 AM, Oleg Nesterov wrote:
> >
> > Could you please run wine under strace
> >
> > strace -f -e ptrace -o LOG wine ...
> >
> > and show the result?
>
> Sure.
Thanks.
> Note that the crash might have happened some time before
On Sun, Aug 04, 2013 at 08:45:16PM -0700, Linus Torvalds wrote:
> The patch looks right to me - we should pass in similar flags for the
> create case as for tmpfile to the filesystem.
>
> But let's make sure we're all on the same page. Al?
ACK. It used to happen as a side effect of O_CREAT
On Mon, Aug 5, 2013 at 8:29 AM, Oleg Nesterov wrote:
> On 08/04, Felipe Contreras wrote:
>>
>> I found a regression while running all v3.11-rcX kernels; Starcract II
>> through wine crashes.
>
> Thanks... just to clarify, Starcract crashes, wine or kernel?
It's Starcraft. In fact, it detects the
On 08/04, Felipe Contreras wrote:
>
> I found a regression while running all v3.11-rcX kernels; Starcract II
> through wine crashes.
Thanks... just to clarify, Starcract crashes, wine or kernel?
> The culprit is fab840f (ptrace: PTRACE_DETACH
> should do flush_ptrace_hw_breakpoint(child)), I
On Sun, Aug 04, 2013 at 08:45:16PM -0700, Linus Torvalds wrote:
> The patch looks right to me - we should pass in similar flags for the
> create case as for tmpfile to the filesystem.
>
> But let's make sure we're all on the same page. Al?
Given all the problems and very limited fs support I'd
On Sun, Aug 04, 2013 at 08:45:16PM -0700, Linus Torvalds wrote:
The patch looks right to me - we should pass in similar flags for the
create case as for tmpfile to the filesystem.
But let's make sure we're all on the same page. Al?
Given all the problems and very limited fs support I'd much
On 08/04, Felipe Contreras wrote:
I found a regression while running all v3.11-rcX kernels; Starcract II
through wine crashes.
Thanks... just to clarify, Starcract crashes, wine or kernel?
The culprit is fab840f (ptrace: PTRACE_DETACH
should do flush_ptrace_hw_breakpoint(child)), I revert
On Mon, Aug 5, 2013 at 8:29 AM, Oleg Nesterov o...@redhat.com wrote:
On 08/04, Felipe Contreras wrote:
I found a regression while running all v3.11-rcX kernels; Starcract II
through wine crashes.
Thanks... just to clarify, Starcract crashes, wine or kernel?
It's Starcraft. In fact, it
On Sun, Aug 04, 2013 at 08:45:16PM -0700, Linus Torvalds wrote:
The patch looks right to me - we should pass in similar flags for the
create case as for tmpfile to the filesystem.
But let's make sure we're all on the same page. Al?
ACK. It used to happen as a side effect of O_CREAT being
On 08/05, Felipe Contreras wrote:
On Mon, Aug 5, 2013 at 8:29 AM, Oleg Nesterov o...@redhat.com wrote:
Could you please run wine under strace
strace -f -e ptrace -o LOG wine ...
and show the result?
Sure.
Thanks.
Note that the crash might have happened some time before
On Mon, Aug 5, 2013 at 9:39 AM, Oleg Nesterov o...@redhat.com wrote:
On 08/05, Felipe Contreras wrote:
On Mon, Aug 5, 2013 at 8:29 AM, Oleg Nesterov o...@redhat.com wrote:
Could you please run wine under strace
strace -f -e ptrace -o LOG wine ...
and show the result?
Sure.
On 08/05, Felipe Contreras wrote:
On Mon, Aug 5, 2013 at 9:39 AM, Oleg Nesterov o...@redhat.com wrote:
Hmm. It should not crash under strace... please see below.
953 ptrace(PTRACE_ATTACH, 1035, 0, 0) = -1 EPERM (Operation not
permitted)
OK, so it actually uses ptrace ;)
On Mon, 5 August 2013 01:26:46 -0700, Christoph Hellwig wrote:
On Sun, Aug 04, 2013 at 08:45:16PM -0700, Linus Torvalds wrote:
The patch looks right to me - we should pass in similar flags for the
create case as for tmpfile to the filesystem.
But let's make sure we're all on the same
On Mon, Aug 5, 2013 at 6:29 AM, Oleg Nesterov o...@redhat.com wrote:
I never used wine, but I am puzzled anyway. This patch really looks
like a simple and minor bugfix.
The patch is indeed trivial, but.. What's the locking here?
Afaik, ptrace_detach() by the parent can race with do_exit() by
On Mon, Aug 5, 2013 at 12:11 PM, Oleg Nesterov o...@redhat.com wrote:
On 08/05, Felipe Contreras wrote:
On Mon, Aug 5, 2013 at 9:39 AM, Oleg Nesterov o...@redhat.com wrote:
Hmm. It should not crash under strace... please see below.
953 ptrace(PTRACE_ATTACH, 1035, 0, 0) = -1 EPERM
On Mon, Aug 5, 2013 at 12:39 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
That said, Felipe, can you double-check that it's not timing-related
in some subtle way, and test multiple times with just that commit
reverted (and not reverted) to make sure that it's 100% that one
single
On 08/05, Linus Torvalds wrote:
On Mon, Aug 5, 2013 at 6:29 AM, Oleg Nesterov o...@redhat.com wrote:
I never used wine, but I am puzzled anyway. This patch really looks
like a simple and minor bugfix.
The patch is indeed trivial, but.. What's the locking here?
Afaik, ptrace_detach() by
On 08/05, Felipe Contreras wrote:
Would it be possible to just revert that patch for v3.11, and fix it later?
Sure, but it would be nice to investigate.
I think we have the time for revert, this patch was added after 3.10
so I hope we can always revert it before 3.11.
Felipe, I'll try to make
On Mon, Aug 5, 2013 at 12:43 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Mon, Aug 5, 2013 at 12:39 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
That said, Felipe, can you double-check that it's not timing-related
in some subtle way, and test multiple times with just
On 08/04, Felipe Contreras wrote:
I found a regression while running all v3.11-rcX kernels; Starcract II
through wine crashes. The culprit is fab840f (ptrace: PTRACE_DETACH
should do flush_ptrace_hw_breakpoint(child)), I revert that commit and
there's no crash.
Heh. I pulled wine-git.
On Mon, Aug 5, 2013 at 11:46 AM, Oleg Nesterov o...@redhat.com wrote:
Heh. I pulled wine-git.
set_thread_context() does a lot of PTRACE_POKEUSER requests and then
it calls resume_after_ptrace() which simply does PTRACE_DETACH.
I'll recheck tomorrow, but it really looks as if it _wants_ to
On 08/05, Linus Torvalds wrote:
On Mon, Aug 5, 2013 at 11:46 AM, Oleg Nesterov o...@redhat.com wrote:
Heh. I pulled wine-git.
set_thread_context() does a lot of PTRACE_POKEUSER requests and then
it calls resume_after_ptrace() which simply does PTRACE_DETACH.
I'll recheck tomorrow,
On Mon, Aug 5, 2013 at 11:57 AM, Oleg Nesterov o...@redhat.com wrote:
Yes, yes, sure. I'll write the changelog and send git-revert tomorrow,
Thanks.
Linus
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
On Sun, Aug 4, 2013 at 8:45 PM, Linus Torvalds
wrote:
> The patch looks right to me - we should pass in similar flags for the
> create case as for tmpfile to the filesystem.
Alternatively, in case anyone ever wants to add more O_TMPFILE-related
flags, open could return -EINVAL if __O_TMPFILE is
On Sun, Aug 4, 2013 at 4:09 PM, Linus Torvalds
wrote:
> It's that time of the week again..
>
> "You apply 339 patches, what do you get
> Another week older and deeper in debt
> Saint Peter don't you call me 'cause I can't go
> I owe my soul to the company store"
>
> I had hoped things
The patch looks right to me - we should pass in similar flags for the
create case as for tmpfile to the filesystem.
But let's make sure we're all on the same page. Al?
Linus
On Sun, Aug 4, 2013 at 7:34 PM, Andy Lutomirski wrote:
> On 08/04/2013 02:09 PM, Linus Torvalds wrote:
On 08/04/2013 02:09 PM, Linus Torvalds wrote:
It's that time of the week again..
I still get filesystem corruption with O_TMPFILE. The program below,
run as flinktest foo proc (or flinktest foo linkat if you're root) will
produce a bogus inode. On ext4, once the inode is gone from cache,
" log spam
Linus Lüssing (1):
bridge: disable snooping if there is no querier
Linus Torvalds (1):
Linux 3.11-rc4
Linus Walleij (3):
Revert "gpio/omap: fix build error when OF_GPIO is not defined."
Revert "gpio/omap: auto request GPIO as input if us
):
bridge: disable snooping if there is no querier
Linus Torvalds (1):
Linux 3.11-rc4
Linus Walleij (3):
Revert gpio/omap: fix build error when OF_GPIO is not defined.
Revert gpio/omap: auto request GPIO as input if used as IRQ via DT
Revert gpio/omap: don't create an IRQ
On 08/04/2013 02:09 PM, Linus Torvalds wrote:
It's that time of the week again..
I still get filesystem corruption with O_TMPFILE. The program below,
run as flinktest foo proc (or flinktest foo linkat if you're root) will
produce a bogus inode. On ext4, once the inode is gone from cache,
The patch looks right to me - we should pass in similar flags for the
create case as for tmpfile to the filesystem.
But let's make sure we're all on the same page. Al?
Linus
On Sun, Aug 4, 2013 at 7:34 PM, Andy Lutomirski l...@mit.edu wrote:
On 08/04/2013 02:09 PM, Linus
On Sun, Aug 4, 2013 at 4:09 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
It's that time of the week again..
You apply 339 patches, what do you get
Another week older and deeper in debt
Saint Peter don't you call me 'cause I can't go
I owe my soul to the company store
I
On Sun, Aug 4, 2013 at 8:45 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
The patch looks right to me - we should pass in similar flags for the
create case as for tmpfile to the filesystem.
Alternatively, in case anyone ever wants to add more O_TMPFILE-related
flags, open could return
70 matches
Mail list logo
