On Wed, Feb 27, 2013 at 6:20 PM, Linus Torvalds
wrote:
> On Wed, Feb 27, 2013 at 9:15 AM, Sedat Dilek wrote:
>>
>> Where is it?
>
> Oh sorry, I hadn't pushed it out, I was looking through other emails
> in the meantime.
>
> Pushed out now (but mirror delays to public sites etc..)
>
> The patch it
On Wed, Feb 27, 2013 at 9:15 AM, Sedat Dilek wrote:
>
> Where is it?
Oh sorry, I hadn't pushed it out, I was looking through other emails
in the meantime.
Pushed out now (but mirror delays to public sites etc..)
The patch itself is the same one I already attached earlier though
(the last versio
[ QUOTE ]
On Wed, Feb 27, 2013 at 3:15 AM, Heiko Carstens
wrote:
>
> Tested with 64 bit kernel with 64 bit and 31 bit mode user space as well as
> with 31 bit kernel and 31 bit user space. Each with legacy and flexible
> mmap layout.
> The bug is fixed and everything else still seems to work. Than
On Wed, Feb 27, 2013 at 3:15 AM, Heiko Carstens
wrote:
>
> Tested with 64 bit kernel with 64 bit and 31 bit mode user space as well as
> with 31 bit kernel and 31 bit user space. Each with legacy and flexible
> mmap layout.
> The bug is fixed and everything else still seems to work. Thanks!
>
> Te
On Tue, Feb 26, 2013 at 04:30:50PM -0800, Linus Torvalds wrote:
> On Tue, Feb 26, 2013 at 3:43 PM, Linus Torvalds
> wrote:
> >
> > So I'll need to extend on that logic a bit more.
>
> Ok, here's the fleshed-out patch. Also fixed to use "expand_stack()",
> which is what the page fault handling act
On Tue, Feb 26, 2013 at 3:43 PM, Linus Torvalds
wrote:
>
> So I'll need to extend on that logic a bit more.
Ok, here's the fleshed-out patch. Also fixed to use "expand_stack()",
which is what the page fault handling actually uses. And it has the
GROWSUP case as well as a comment about this all.
On Tue, Feb 26, 2013 at 8:08 AM, Linus Torvalds
wrote:
>
> It is totally untested, though. Does it work for you (and we should
> do the same thing for the grows-up case, obviously)?
Ok, thinking about this more, this is not good enough.
There is one case where growing into the previous/next vma
On Tue, Feb 26, 2013 at 7:51 AM, Linus Torvalds
wrote:
>
> I think the problem is that we add the guard page *after* we do the
> normal "let's try to expand" logic.
>
> I'll take a look.
Ahh, no. The guard page logic happens later at the fault time. We do
this in two phases - first "find_extend_v
On Tue, Feb 26, 2013 at 4:57 AM, Heiko Carstens
wrote:
>
> I was wrong. -EFAULT will be returned, however the vma will grow nevertheless.
> Which in turn will cause trouble.
Ok. We should fix that too.
There whole "access just past the end of the previous vma" should
never cause the stack above
On Mon, Feb 25, 2013 at 09:24:31PM -0800, Linus Torvalds wrote:
> On Mon, Feb 25, 2013 at 8:54 PM, Heiko Carstens
> wrote:
> > FWIW, I think the generic strncpy_from_user() implemention has the same
> > bug as the s390 variant:
> >
> > Following example:
> >
> > If there is a NUL terminated string
10 matches
Mail list logo
