On Mon, 2012-07-23 at 12:36 +0900, sf...@users.sourceforge.net wrote:
> Ben Hutchings:
> > security_mmap_addr() is called with mmap_sem held, but anyway we don't
> > need to call it from aufs...
>
> security_mmap_addr() is called with mmap_sem held??
> Which source file are you reading?
do_mmap_p
Ben Hutchings:
> do_mmap_pgoff() /* The caller must hold down_write(¤t->mm->mmap_sem) =
> */
> -> get_unmapped_area() -> security_mmap_addr()
:::
Thanks.
And I am sorry. I was confused.
I have to correct the orders of security_mmap_addr() and ..._file() and
mmap_sem, which is
..._
On Mon, 2012-07-23 at 21:26 +0900, sf...@users.sourceforge.net wrote:
> Ben Hutchings:
> > do_mmap_pgoff() /* The caller must hold down_write(¤t->mm->mmap_sem) =
> > */
> > -> get_unmapped_area() -> security_mmap_addr()
> :::
>
> Thanks.
> And I am sorry. I was confused.
> I have to correct
Ben Hutchings:
> If the LSM mmap_addr callback needs to acquire mmap_sem then it will be
> using the wrong mm context, so this doesn't fix the problem. If it
LSM mmap_addr()? _file()?
If you mean _addr() acquires mmap_sem, then it means a simple problem of
LSM. Let's make it sure again together.
On Mon, Jul 23, 2012 at 10:36:21PM +0900, sf...@users.sourceforge.net wrote:
>
> Ben Hutchings:
> > If the LSM mmap_addr callback needs to acquire mmap_sem then it will be
> > using the wrong mm context, so this doesn't fix the problem. If it
>
> LSM mmap_addr()? _file()?
Gah, of course I meant
Ben Hutchings:
> > > If there is no lock higher than mmap_sem that might be used in this way,
> > > then there is no problem and there is also no need for using the
> > > workqueue.
> >
> > ??
> > I may be confused again.
> > Why workqueue is unnecessary?
>
> The work item runs on *some* workqu
