All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joel Fernandes <joel@joelfernandes.org>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
	Andy Lutomirski <luto@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Hugh Dickins <hughd@google.com>, Jann Horn <jannh@google.com>,
	Khalid Aziz <khalid.aziz@oracle.com>,
	Linux API <linux-api@vger.kernel.org>,
	"open list:KERNEL SELFTEST FRAMEWORK" 
	<linux-kselftest@vger.kernel.org>, Linux-MM <linux-mm@kvack.org>,
	marcandre.lureau@redhat.com, Matthew Wilcox <willy@infradead.org>,
	Mike Kravetz <mike.kravetz@oracle.com>,
	Shuah Khan <shuah@kernel.org>
Subject: Re: [PATCH -next 1/2] mm/memfd: make F_SEAL_FUTURE_WRITE seal more robust
Date: Tue, 20 Nov 2018 12:47:10 -0800	[thread overview]
Message-ID: <20181120204710.GB22801@google.com> (raw)
In-Reply-To: <469B80CB-D982-4802-A81D-95AC493D7E87@amacapital.net>

On Tue, Nov 20, 2018 at 01:33:18PM -0700, Andy Lutomirski wrote:
> 
> > On Nov 20, 2018, at 1:07 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > 
> > Hi Joel,
> > 
> >> On Tue, 20 Nov 2018 10:39:26 -0800 Joel Fernandes <joel@joelfernandes.org> wrote:
> >> 
> >>> On Tue, Nov 20, 2018 at 07:13:17AM -0800, Andy Lutomirski wrote:
> >>> On Mon, Nov 19, 2018 at 9:21 PM Joel Fernandes (Google)
> >>> <joel@joelfernandes.org> wrote:  
> >>>> 
> >>>> A better way to do F_SEAL_FUTURE_WRITE seal was discussed [1] last week
> >>>> where we don't need to modify core VFS structures to get the same
> >>>> behavior of the seal. This solves several side-effects pointed out by
> >>>> Andy [2].
> >>>> 
> >>>> [1] https://lore.kernel.org/lkml/20181111173650.GA256781@google.com/
> >>>> [2] https://lore.kernel.org/lkml/69CE06CC-E47C-4992-848A-66EB23EE6C74@amacapital.net/
> >>>> 
> >>>> Suggested-by: Andy Lutomirski <luto@kernel.org>
> >>>> Fixes: 5e653c2923fd ("mm: Add an F_SEAL_FUTURE_WRITE seal to memfd")  
> >>> 
> >>> What tree is that commit in?  Can we not just fold this in?  
> >> 
> >> It is in linux-next. Could we keep both commits so we have the history?
> > 
> > Well, its in Andrew's mmotm, so its up to him.
> > 
> > 
> 
> Unless mmotm is more magical than I think, the commit hash in your fixed
> tag is already nonsense. mmotm gets rebased all the time, and is only
> barely a git tree.

I wouldn't go so far to call it nonsense. It was a working patch, it just did
things differently. Your help with improving the patch is much appreciated.

I am Ok with whatever Andrew wants to do, if it is better to squash it with
the original, then I can do that and send another patch.

- Joel

WARNING: multiple messages have this Message-ID (diff)
From: joel at joelfernandes.org (Joel Fernandes)
Subject: [PATCH -next 1/2] mm/memfd: make F_SEAL_FUTURE_WRITE seal more robust
Date: Tue, 20 Nov 2018 12:47:10 -0800	[thread overview]
Message-ID: <20181120204710.GB22801@google.com> (raw)
In-Reply-To: <469B80CB-D982-4802-A81D-95AC493D7E87@amacapital.net>

On Tue, Nov 20, 2018 at 01:33:18PM -0700, Andy Lutomirski wrote:
> 
> > On Nov 20, 2018, at 1:07 PM, Stephen Rothwell <sfr at canb.auug.org.au> wrote:
> > 
> > Hi Joel,
> > 
> >> On Tue, 20 Nov 2018 10:39:26 -0800 Joel Fernandes <joel at joelfernandes.org> wrote:
> >> 
> >>> On Tue, Nov 20, 2018 at 07:13:17AM -0800, Andy Lutomirski wrote:
> >>> On Mon, Nov 19, 2018 at 9:21 PM Joel Fernandes (Google)
> >>> <joel at joelfernandes.org> wrote:  
> >>>> 
> >>>> A better way to do F_SEAL_FUTURE_WRITE seal was discussed [1] last week
> >>>> where we don't need to modify core VFS structures to get the same
> >>>> behavior of the seal. This solves several side-effects pointed out by
> >>>> Andy [2].
> >>>> 
> >>>> [1] https://lore.kernel.org/lkml/20181111173650.GA256781 at google.com/
> >>>> [2] https://lore.kernel.org/lkml/69CE06CC-E47C-4992-848A-66EB23EE6C74 at amacapital.net/
> >>>> 
> >>>> Suggested-by: Andy Lutomirski <luto at kernel.org>
> >>>> Fixes: 5e653c2923fd ("mm: Add an F_SEAL_FUTURE_WRITE seal to memfd")  
> >>> 
> >>> What tree is that commit in?  Can we not just fold this in?  
> >> 
> >> It is in linux-next. Could we keep both commits so we have the history?
> > 
> > Well, its in Andrew's mmotm, so its up to him.
> > 
> > 
> 
> Unless mmotm is more magical than I think, the commit hash in your fixed
> tag is already nonsense. mmotm gets rebased all the time, and is only
> barely a git tree.

I wouldn't go so far to call it nonsense. It was a working patch, it just did
things differently. Your help with improving the patch is much appreciated.

I am Ok with whatever Andrew wants to do, if it is better to squash it with
the original, then I can do that and send another patch.

- Joel

WARNING: multiple messages have this Message-ID (diff)
From: joel@joelfernandes.org (Joel Fernandes)
Subject: [PATCH -next 1/2] mm/memfd: make F_SEAL_FUTURE_WRITE seal more robust
Date: Tue, 20 Nov 2018 12:47:10 -0800	[thread overview]
Message-ID: <20181120204710.GB22801@google.com> (raw)
Message-ID: <20181120204710.geCHB6vU8TnE3weB9A2SEaSxsqfiV7EgCvHEVmh9mik@z> (raw)
In-Reply-To: <469B80CB-D982-4802-A81D-95AC493D7E87@amacapital.net>

On Tue, Nov 20, 2018@01:33:18PM -0700, Andy Lutomirski wrote:
> 
> > On Nov 20, 2018,@1:07 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > 
> > Hi Joel,
> > 
> >> On Tue, 20 Nov 2018 10:39:26 -0800 Joel Fernandes <joel@joelfernandes.org> wrote:
> >> 
> >>> On Tue, Nov 20, 2018@07:13:17AM -0800, Andy Lutomirski wrote:
> >>> On Mon, Nov 19, 2018 at 9:21 PM Joel Fernandes (Google)
> >>> <joel at joelfernandes.org> wrote:  
> >>>> 
> >>>> A better way to do F_SEAL_FUTURE_WRITE seal was discussed [1] last week
> >>>> where we don't need to modify core VFS structures to get the same
> >>>> behavior of the seal. This solves several side-effects pointed out by
> >>>> Andy [2].
> >>>> 
> >>>> [1] https://lore.kernel.org/lkml/20181111173650.GA256781 at google.com/
> >>>> [2] https://lore.kernel.org/lkml/69CE06CC-E47C-4992-848A-66EB23EE6C74 at amacapital.net/
> >>>> 
> >>>> Suggested-by: Andy Lutomirski <luto at kernel.org>
> >>>> Fixes: 5e653c2923fd ("mm: Add an F_SEAL_FUTURE_WRITE seal to memfd")  
> >>> 
> >>> What tree is that commit in?  Can we not just fold this in?  
> >> 
> >> It is in linux-next. Could we keep both commits so we have the history?
> > 
> > Well, its in Andrew's mmotm, so its up to him.
> > 
> > 
> 
> Unless mmotm is more magical than I think, the commit hash in your fixed
> tag is already nonsense. mmotm gets rebased all the time, and is only
> barely a git tree.

I wouldn't go so far to call it nonsense. It was a working patch, it just did
things differently. Your help with improving the patch is much appreciated.

I am Ok with whatever Andrew wants to do, if it is better to squash it with
the original, then I can do that and send another patch.

- Joel

  reply	other threads:[~2018-11-20 20:47 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-20  5:21 [PATCH -next 1/2] mm/memfd: make F_SEAL_FUTURE_WRITE seal more robust Joel Fernandes (Google)
2018-11-20  5:21 ` Joel Fernandes (Google)
2018-11-20  5:21 ` joel
2018-11-20  5:21 ` [PATCH -next 2/2] selftests/memfd: modify tests for F_SEAL_FUTURE_WRITE seal Joel Fernandes (Google)
2018-11-20  5:21   ` Joel Fernandes (Google)
2018-11-20  5:21   ` joel
2018-11-22 23:21   ` Joel Fernandes
2018-11-22 23:21     ` Joel Fernandes
2018-11-22 23:21     ` joel
2018-11-20 15:13 ` [PATCH -next 1/2] mm/memfd: make F_SEAL_FUTURE_WRITE seal more robust Andy Lutomirski
2018-11-20 15:13   ` Andy Lutomirski
2018-11-20 15:13   ` Andy Lutomirski
2018-11-20 15:13   ` luto
2018-11-20 18:39   ` Joel Fernandes
2018-11-20 18:39     ` Joel Fernandes
2018-11-20 18:39     ` Joel Fernandes
2018-11-20 18:39     ` joel
2018-11-20 20:07     ` Stephen Rothwell
2018-11-20 20:07       ` Stephen Rothwell
2018-11-20 20:07       ` Stephen Rothwell
2018-11-20 20:07       ` sfr
2018-11-20 20:33       ` Andy Lutomirski
2018-11-20 20:33         ` Andy Lutomirski
2018-11-20 20:33         ` Andy Lutomirski
2018-11-20 20:33         ` luto
2018-11-20 20:47         ` Joel Fernandes [this message]
2018-11-20 20:47           ` Joel Fernandes
2018-11-20 20:47           ` Joel Fernandes
2018-11-20 20:47           ` joel
2018-11-20 21:02           ` Andy Lutomirski
2018-11-20 21:02             ` Andy Lutomirski
2018-11-20 21:02             ` Andy Lutomirski
2018-11-20 21:02             ` luto
2018-11-20 21:13             ` Joel Fernandes
2018-11-20 21:13               ` Joel Fernandes
2018-11-20 21:13               ` Joel Fernandes
2018-11-20 21:13               ` Joel Fernandes
2018-11-20 21:13               ` joel
2018-11-22  2:27               ` Andrew Morton
2018-11-22  2:27                 ` Andrew Morton
2018-11-22  2:27                 ` Andrew Morton
2018-11-22  2:27                 ` akpm
2018-11-22  3:25                 ` Andy Lutomirski
2018-11-22  3:25                   ` Andy Lutomirski
2018-11-22  3:25                   ` Andy Lutomirski
2018-11-22  3:25                   ` luto
2018-11-22 23:09                   ` Joel Fernandes
2018-11-22 23:09                     ` Joel Fernandes
2018-11-22 23:09                     ` Joel Fernandes
2018-11-22 23:09                     ` joel
2018-11-25  0:42                     ` Andrew Morton
2018-11-25  0:42                       ` Andrew Morton
2018-11-25  0:42                       ` Andrew Morton
2018-11-25  0:42                       ` akpm
2018-11-25  0:47                       ` Matthew Wilcox
2018-11-25  0:47                         ` Matthew Wilcox
2018-11-25  0:47                         ` Matthew Wilcox
2018-11-25  0:47                         ` willy
2018-11-26 13:35                         ` Joel Fernandes
2018-11-26 13:35                           ` Joel Fernandes
2018-11-26 13:35                           ` Joel Fernandes
2018-11-26 13:35                           ` joel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181120204710.GB22801@google.com \
    --to=joel@joelfernandes.org \
    --cc=akpm@linux-foundation.org \
    --cc=hughd@google.com \
    --cc=jannh@google.com \
    --cc=khalid.aziz@oracle.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luto@amacapital.net \
    --cc=luto@kernel.org \
    --cc=marcandre.lureau@redhat.com \
    --cc=mike.kravetz@oracle.com \
    --cc=sfr@canb.auug.org.au \
    --cc=shuah@kernel.org \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.