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
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
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
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
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 1.
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 ca
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 ha
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 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, bu
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 se
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+
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 sti
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 majordo
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
> the
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.
s
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 make
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 mak
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 the
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 com
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, an
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 being
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 reve
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 mu
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 s
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 would
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, th
g when removing interface
r8169: remove "PHY reset until link up" 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 de
35 matches
Mail list logo
