On Sun, Dec 16, 2012 at 05:04:03PM +, Al Viro wrote:
> That's just from a couple of days of RTFS. The locking in there is far too
> convoluted as it is; worse, it's not localized code-wise, so rechecking
> correctness is going to remain a big time-sink ;-/
>
> Making it *more* complex
On Sun, Dec 16, 2012 at 05:04:03PM +, Al Viro wrote:
> FWIW, I've done some checking of ->mmap_sem uses yesterday. Got further than
> the last time; catch so far, just from find_vma() audit:
> * arm swp_emulate.c - missing ->mmap_sem around find_vma(). Fix sent to
> rmk.
> * blackfin ptrace
On Sun, Dec 16, 2012 at 05:04:03PM +, Al Viro wrote:
> BTW, the __get_user_pages()/find_extend_vma()/mlock_vma_pages_range() pile is
> really asking for trouble; sure, the recursion there is limited, but it
> deserves a comment.
Agreed, how about this?
---
From: Johannes Weiner
Subject:
On Sun, Dec 16, 2012 at 05:04:03PM +, Al Viro wrote:
> Moreover, I'm not quite convinced that huge_memory.c and ksm.c can't run
> into all kinds of interesting races with ongoing coredump. Looking into
> it...
Specifically, is collapse_huge_page() safe in parallel with ->core_dump()?
It
On Fri, Dec 14, 2012 at 08:12:45AM -0800, Andy Lutomirski wrote:
> On Fri, Dec 14, 2012 at 6:49 AM, Al Viro wrote:
> > On Fri, Dec 14, 2012 at 03:14:50AM -0800, Andy Lutomirski wrote:
> >
> >> > Wait a minute. get_user_pages() relies on ->mmap_sem being held. Unless
> >> > I'm seriously
* Andy Lutomirski wrote:
> On Fri, Dec 14, 2012 at 6:49 AM, Al Viro wrote:
> > On Fri, Dec 14, 2012 at 03:14:50AM -0800, Andy Lutomirski wrote:
> >
> >> > Wait a minute. get_user_pages() relies on ->mmap_sem being held. Unless
> >> > I'm seriously misreading your patch it removes that
* Andy Lutomirski l...@amacapital.net wrote:
On Fri, Dec 14, 2012 at 6:49 AM, Al Viro v...@zeniv.linux.org.uk wrote:
On Fri, Dec 14, 2012 at 03:14:50AM -0800, Andy Lutomirski wrote:
Wait a minute. get_user_pages() relies on -mmap_sem being held. Unless
I'm seriously misreading your
On Fri, Dec 14, 2012 at 08:12:45AM -0800, Andy Lutomirski wrote:
On Fri, Dec 14, 2012 at 6:49 AM, Al Viro v...@zeniv.linux.org.uk wrote:
On Fri, Dec 14, 2012 at 03:14:50AM -0800, Andy Lutomirski wrote:
Wait a minute. get_user_pages() relies on -mmap_sem being held. Unless
I'm
On Sun, Dec 16, 2012 at 05:04:03PM +, Al Viro wrote:
Moreover, I'm not quite convinced that huge_memory.c and ksm.c can't run
into all kinds of interesting races with ongoing coredump. Looking into
it...
Specifically, is collapse_huge_page() safe in parallel with -core_dump()?
It *can*
On Sun, Dec 16, 2012 at 05:04:03PM +, Al Viro wrote:
BTW, the __get_user_pages()/find_extend_vma()/mlock_vma_pages_range() pile is
really asking for trouble; sure, the recursion there is limited, but it
deserves a comment.
Agreed, how about this?
---
From: Johannes Weiner
On Sun, Dec 16, 2012 at 05:04:03PM +, Al Viro wrote:
FWIW, I've done some checking of -mmap_sem uses yesterday. Got further than
the last time; catch so far, just from find_vma() audit:
* arm swp_emulate.c - missing -mmap_sem around find_vma(). Fix sent to
rmk.
* blackfin ptrace -
On Sun, Dec 16, 2012 at 05:04:03PM +, Al Viro wrote:
That's just from a couple of days of RTFS. The locking in there is far too
convoluted as it is; worse, it's not localized code-wise, so rechecking
correctness is going to remain a big time-sink ;-/
Making it *more* complex doesn't
On Fri, Dec 14, 2012 at 6:49 AM, Al Viro wrote:
> On Fri, Dec 14, 2012 at 03:14:50AM -0800, Andy Lutomirski wrote:
>
>> > Wait a minute. get_user_pages() relies on ->mmap_sem being held. Unless
>> > I'm seriously misreading your patch it removes that protection. And yes,
>> > I'm aware of
On Fri, Dec 14, 2012 at 03:14:50AM -0800, Andy Lutomirski wrote:
> > Wait a minute. get_user_pages() relies on ->mmap_sem being held. Unless
> > I'm seriously misreading your patch it removes that protection. And yes,
> > I'm aware of execve-related exception; it's in special circumstances -
>
On Thu, Dec 13, 2012 at 11:27 PM, Al Viro wrote:
> On Thu, Dec 13, 2012 at 09:49:43PM -0800, Andy Lutomirski wrote:
>> This is a serious cause of mmap_sem contention. MAP_POPULATE
>> and MCL_FUTURE, in particular, are disastrous in multithreaded programs.
>>
>> Signed-off-by: Andy Lutomirski
>>
On Thu, Dec 13, 2012 at 11:27 PM, Al Viro v...@zeniv.linux.org.uk wrote:
On Thu, Dec 13, 2012 at 09:49:43PM -0800, Andy Lutomirski wrote:
This is a serious cause of mmap_sem contention. MAP_POPULATE
and MCL_FUTURE, in particular, are disastrous in multithreaded programs.
Signed-off-by: Andy
On Fri, Dec 14, 2012 at 03:14:50AM -0800, Andy Lutomirski wrote:
Wait a minute. get_user_pages() relies on -mmap_sem being held. Unless
I'm seriously misreading your patch it removes that protection. And yes,
I'm aware of execve-related exception; it's in special circumstances -
On Fri, Dec 14, 2012 at 6:49 AM, Al Viro v...@zeniv.linux.org.uk wrote:
On Fri, Dec 14, 2012 at 03:14:50AM -0800, Andy Lutomirski wrote:
Wait a minute. get_user_pages() relies on -mmap_sem being held. Unless
I'm seriously misreading your patch it removes that protection. And yes,
I'm
On Thu, Dec 13, 2012 at 09:49:43PM -0800, Andy Lutomirski wrote:
> This is a serious cause of mmap_sem contention. MAP_POPULATE
> and MCL_FUTURE, in particular, are disastrous in multithreaded programs.
>
> Signed-off-by: Andy Lutomirski
> ---
>
> Sensible people use anonymous mappings. I
This is a serious cause of mmap_sem contention. MAP_POPULATE
and MCL_FUTURE, in particular, are disastrous in multithreaded programs.
Signed-off-by: Andy Lutomirski
---
Sensible people use anonymous mappings. I write kernel patches :)
I'm not entirely thrilled by the aesthetics of this
This is a serious cause of mmap_sem contention. MAP_POPULATE
and MCL_FUTURE, in particular, are disastrous in multithreaded programs.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
Sensible people use anonymous mappings. I write kernel patches :)
I'm not entirely thrilled by the
On Thu, Dec 13, 2012 at 09:49:43PM -0800, Andy Lutomirski wrote:
This is a serious cause of mmap_sem contention. MAP_POPULATE
and MCL_FUTURE, in particular, are disastrous in multithreaded programs.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
Sensible people use anonymous
22 matches
Mail list logo
