On Wed, Oct 23, 2019 at 12:10 PM Andrea Arcangeli wrote:
>
> Hello,
>
> On Sat, Oct 12, 2019 at 06:14:23PM -0700, Andy Lutomirski wrote:
> > [adding more people because this is going to be an ABI break, sigh]
>
> That wouldn't break the ABI, no more than when if you boot a kernel
> built with CONF
Hello,
On Sat, Oct 12, 2019 at 06:14:23PM -0700, Andy Lutomirski wrote:
> [adding more people because this is going to be an ABI break, sigh]
That wouldn't break the ABI, no more than when if you boot a kernel
built with CONFIG_USERFAULTFD=n.
All non-cooperative features can be removed any time
On Wed, Oct 23, 2019 at 5:44 AM Mike Rapoport wrote:
>
> On Wed, Oct 23, 2019 at 10:29:20AM +0300, Cyrill Gorcunov wrote:
> > On Tue, Oct 22, 2019 at 09:11:04PM -0700, Andy Lutomirski wrote:
> > > Trying again. It looks like I used the wrong address for Pavel.
> >
> > Thanks for CC Andy! I must c
On Wed, Oct 23, 2019 at 10:29:20AM +0300, Cyrill Gorcunov wrote:
> On Tue, Oct 22, 2019 at 09:11:04PM -0700, Andy Lutomirski wrote:
> > Trying again. It looks like I used the wrong address for Pavel.
>
> Thanks for CC Andy! I must confess I didn't dive into userfaultfd engine
> personally but let
On Tue, Oct 22, 2019 at 09:11:04PM -0700, Andy Lutomirski wrote:
> Trying again. It looks like I used the wrong address for Pavel.
Thanks for CC Andy! I must confess I didn't dive into userfaultfd engine
personally but let me CC more people involved from criu side. (overquoting
left untouched for
Trying again. It looks like I used the wrong address for Pavel.
On Sat, Oct 12, 2019 at 6:14 PM Andy Lutomirski wrote:
>
> [adding more people because this is going to be an ABI break, sigh]
>
> On Sat, Oct 12, 2019 at 5:52 PM Daniel Colascione wrote:
> >
> > On Sat, Oct 12, 2019 at 4:10 PM And
On Sat, Oct 12, 2019 at 6:14 PM Andy Lutomirski wrote:
> [adding more people because this is going to be an ABI break, sigh]
Just pinging this thread. I'd like to rev my patch and I'm not sure
what we want to do about problem Andy identified. Are we removing
UFFD_EVENT_FORK?
On Sun, Oct 13, 2019 at 3:14 AM Andy Lutomirski wrote:
> [adding more people because this is going to be an ABI break, sigh]
> On Sat, Oct 12, 2019 at 5:52 PM Daniel Colascione wrote:
> > On Sat, Oct 12, 2019 at 4:10 PM Andy Lutomirski wrote:
> > > On Sat, Oct 12, 2019 at 12:16 PM Daniel Colasci
On Sat, Oct 12, 2019 at 6:14 PM Andy Lutomirski wrote:
>
..
>
> > But maybe we can go further: let's separate authentication and
> > authorization, as we do in other LSM hooks. Let's split my
> > inode_init_security_anon into two hooks, inode_init_security_anon and
> > inode_create_anon. We'd defi
[adding more people because this is going to be an ABI break, sigh]
On Sat, Oct 12, 2019 at 5:52 PM Daniel Colascione wrote:
>
> On Sat, Oct 12, 2019 at 4:10 PM Andy Lutomirski wrote:
> >
> > On Sat, Oct 12, 2019 at 12:16 PM Daniel Colascione
> > wrote:
> > >
> > > The new secure flag makes us
On Sat, Oct 12, 2019 at 4:10 PM Andy Lutomirski wrote:
>
> On Sat, Oct 12, 2019 at 12:16 PM Daniel Colascione wrote:
> >
> > The new secure flag makes userfaultfd use a new "secure" anonymous
> > file object instead of the default one, letting security modules
> > supervise userfaultfd use.
> >
>
On Sat, Oct 12, 2019 at 12:16 PM Daniel Colascione wrote:
>
> The new secure flag makes userfaultfd use a new "secure" anonymous
> file object instead of the default one, letting security modules
> supervise userfaultfd use.
>
> Requiring that users pass a new flag lets us avoid changing the
> sem
12 matches
Mail list logo
