Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965185AbbDWOJx (ORCPT ); Thu, 23 Apr 2015 10:09:53 -0400 Received: from bedivere.hansenpartnership.com ([66.63.167.143]:46020 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933887AbbDWOJt (ORCPT ); Thu, 23 Apr 2015 10:09:49 -0400 Message-ID: <1429798187.2170.3.camel@HansenPartnership.com> Subject: Re: [PATCH v4 2/2] efi: an sysfs interface for user to update efi firmware From: James Bottomley To: "Kweh, Hock Leong" Cc: Peter Jones , Andy Lutomirski , Greg Kroah-Hartman , Matt Fleming , Ming Lei , "Ong, Boon Leong" , LKML , "linux-efi@vger.kernel.org" , Sam Protsenko , Roy Franz , Borislav Petkov Date: Thu, 23 Apr 2015 07:09:47 -0700 In-Reply-To: References: <20150415131906.GC21491@kroah.com> <20150417134924.GB19794@kroah.com> <20150417143640.GB3671@codeblueprint.co.uk> <20150420144323.GA7261@kroah.com> <20150421075620.GA11000@kroah.com> <1429665679.2207.44.camel@HansenPartnership.com> <20150422132734.GB12062@redhat.com> <1429715913.2195.22.camel@HansenPartnership.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.11 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1348 Lines: 32 On Thu, 2015-04-23 at 08:30 +0000, Kweh, Hock Leong wrote: > > -----Original Message----- > > From: James Bottomley [mailto:James.Bottomley@HansenPartnership.com] > > Sent: Wednesday, April 22, 2015 11:19 PM > > > > > > Yes, I think we've all agreed we can do it ... it's now a question of whether we > > can stomach the ick factor of actually initiating a transaction in close ... I'm still > > feeling queasy. > > The file "close" here can I understand that the file system will call the "release" > function at the file_operations struct? > http://lxr.free-electrons.com/source/include/linux/fs.h#L1538 > > So, James you are meaning that we could initiating the update transaction > inside the f_ops->release() and return the error code if update failed in this > function? Well, that's what I was thinking. However the return value of ->release doesn't get propagated in sys_close (or indeed anywhere ... no idea why it returns an int) thanks to the task work additions, so we'd actually have to use the operation whose value is propagated in sys_close() which turns out to be flush. James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/