From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joel Fernandes 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 Message-ID: <20181120204710.GB22801@google.com> References: <20181120052137.74317-1-joel@joelfernandes.org> <20181120183926.GA124387@google.com> <20181121070658.011d576d@canb.auug.org.au> <469B80CB-D982-4802-A81D-95AC493D7E87@amacapital.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <469B80CB-D982-4802-A81D-95AC493D7E87@amacapital.net> Sender: linux-kernel-owner@vger.kernel.org To: Andy Lutomirski Cc: Stephen Rothwell , Andy Lutomirski , LKML , Andrew Morton , Hugh Dickins , Jann Horn , Khalid Aziz , Linux API , "open list:KERNEL SELFTEST FRAMEWORK" , Linux-MM , marcandre.lureau@redhat.com, Matthew Wilcox , Mike Kravetz , Shuah Khan List-Id: linux-api@vger.kernel.org On Tue, Nov 20, 2018 at 01:33:18PM -0700, Andy Lutomirski wrote: > > > On Nov 20, 2018, at 1:07 PM, Stephen Rothwell wrote: > > > > Hi Joel, > > > >> On Tue, 20 Nov 2018 10:39:26 -0800 Joel Fernandes 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) > >>> 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 > >>>> 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: joel at joelfernandes.org (Joel Fernandes) Date: Tue, 20 Nov 2018 12:47:10 -0800 Subject: [PATCH -next 1/2] mm/memfd: make F_SEAL_FUTURE_WRITE seal more robust In-Reply-To: <469B80CB-D982-4802-A81D-95AC493D7E87@amacapital.net> References: <20181120052137.74317-1-joel@joelfernandes.org> <20181120183926.GA124387@google.com> <20181121070658.011d576d@canb.auug.org.au> <469B80CB-D982-4802-A81D-95AC493D7E87@amacapital.net> Message-ID: <20181120204710.GB22801@google.com> On Tue, Nov 20, 2018 at 01:33:18PM -0700, Andy Lutomirski wrote: > > > On Nov 20, 2018, at 1:07 PM, Stephen Rothwell wrote: > > > > Hi Joel, > > > >> On Tue, 20 Nov 2018 10:39:26 -0800 Joel Fernandes 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) > >>> 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 > >>>> 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: joel@joelfernandes.org (Joel Fernandes) Date: Tue, 20 Nov 2018 12:47:10 -0800 Subject: [PATCH -next 1/2] mm/memfd: make F_SEAL_FUTURE_WRITE seal more robust In-Reply-To: <469B80CB-D982-4802-A81D-95AC493D7E87@amacapital.net> References: <20181120052137.74317-1-joel@joelfernandes.org> <20181120183926.GA124387@google.com> <20181121070658.011d576d@canb.auug.org.au> <469B80CB-D982-4802-A81D-95AC493D7E87@amacapital.net> Message-ID: <20181120204710.GB22801@google.com> Content-Type: text/plain; charset="UTF-8" Message-ID: <20181120204710.geCHB6vU8TnE3weB9A2SEaSxsqfiV7EgCvHEVmh9mik@z> On Tue, Nov 20, 2018@01:33:18PM -0700, Andy Lutomirski wrote: > > > On Nov 20, 2018,@1:07 PM, Stephen Rothwell wrote: > > > > Hi Joel, > > > >> On Tue, 20 Nov 2018 10:39:26 -0800 Joel Fernandes 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) > >>> 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 > >>>> 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