[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 8 Aug 2022 19:51:52 +0000
From: Liam Howlett <liam.howlett@...cle.com>
To: Ondrej Mosnacek <omosnace@...hat.com>
CC: Andrew Morton <akpm@...ux-foundation.org>,
Minchan Kim <minchan@...nel.org>,
"Christian Brauner (Microsoft)" <brauner@...nel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Hridya Valsaraju <hridya@...gle.com>,
Joel Fernandes <joel@...lfernandes.org>,
Martijn Coenen <maco@...roid.com>,
Suren Baghdasaryan <surenb@...gle.com>,
Todd Kjos <tkjos@...roid.com>,
"Matthew Wilcox (Oracle)" <willy@...radead.org>,
Linux kernel mailing list <linux-kernel@...r.kernel.org>,
Arve Hjønnevåg <arve@...roid.com>,
Carlos Llamas <cmllamas@...gle.com>
Subject: Re: Binder regression caused by commit a43cfc87caaf
* Liam R. Howlett <Liam.Howlett@...cle.com> [220808 11:07]:
> * Ondrej Mosnacek <omosnace@...hat.com> [220808 06:13]:
> > Hello,
> >
> > FYI, since commit a43cfc87caaf ("android: binder: stop saving a
> > pointer to the VMA") (found by git bisect) the binder test in
> > selinux-testsuite [1] started to trigger a lockdep assert BUG() in
> > find_vma() - see the end of [2] for an example.
> >
> > A minimal reproducer is:
> > ```
> > git clone https://github.com/SELinuxProject/selinux-testsuite.git
> > cd selinux-testsuite/tests/binder
> > make
> > setenforce 0 # if SELinux is enabled
> > ./init_binder.sh || true
> > ./manager -n -v & sleep 2
> > ./service_provider -n -v
> > ```
> > Requires the equivalent of libselinux-devel, make, gcc, and git-core
> > Fedora packages.
> > The last command will trigger the BUG; on good kernels it will
> > successfully enter the ioctl loop.
> >
> > [1] https://github.com/SELinuxProject/selinux-testsuite/
> > [2] https://s3.us-east-1.amazonaws.com/arr-cki-prod-datawarehouse-public/datawarehouse-public/2022/08/07/redhat:606549366/build_x86_64_redhat:606549366_x86_64/tests/5/results_0001/console.log/console.log
> >
>
> Thanks. It looks like binder has some paths that are not taking the
> necessary mmap lock for using VMAs. I'm looking into it now.
This does not fail for me, are you sure this is the reproducer? I see
the manager and service_provider communicate.
Looking at your trace and the code, the bug makes sense and I have
something that will probably fix the issue, but I'd like to verify.
Thanks,
Liam
Powered by blists - more mailing lists