Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailing-List: linux-nfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: "NeilBrown" To: "Christoph Hellwig" Cc: "Mike Snitzer" , "Christoph Hellwig" , "Jeff Layton" , "Chuck Lever III" , "Linux NFS Mailing List" , "Anna Schumaker" , "Trond Myklebust" , "Dave Chinner" Subject: Re: [PATCH v11 00/20] nfs/nfsd: add support for localio In-reply-to: References: <>, Date: Sat, 06 Jul 2024 08:08:07 +1000 Message-id: <172021728732.11489.12447081357748108934@noble.neil.brown.name> Xref: photonic.trudheim.com org.kernel.vger.linux-nfs:86595 Newsgroups: org.kernel.vger.linux-nfs Path: photonic.trudheim.com!nntp.lore.kernel.org!not-for-mail On Fri, 05 Jul 2024, Christoph Hellwig wrote: > On Thu, Jul 04, 2024 at 02:31:46PM -0400, Mike Snitzer wrote: > > Some new layout misses the entire point of having localio work for > > NFSv3 and NFSv4. NFSv3 is very ubiquitous. > > I'm getting tird of bringing up this "oh NFSv3" again and again without > any explanation of why that matters for communication insides the > same Linux kernel instance with a kernel that obviously requires > patching. Why is running an obsolete protocol inside the same OS > instance required. Maybe it is, but if so it needs a very good > explanation. I would like to see a good explanation for why NOT NFSv3. I don't think NFSv3 is obsolete. The first dictionary is "No longer in use." which certainly doesn't apply. I think "deprecated" is a more relevant term. I believe that NFSv2 has been deprecated. I believe that NFSv4.0 should be deprecated. But I don't see any reason to consider NFSv3 to be deprecated. > > > And in this localio series, flexfiles is trained to use localio. > > (Which you apparently don't recognize or care about because nfsd > > doesn't have flexfiles server support). > > And you fail to explain why it matters. You are trying to sell this > code, you better have an explanation why it's complicated and convoluted > as hell. So far we are running in circles but there has been no clear > explanation of use cases. Please avoid sweeping statements like "complicated and convoluted" without backing them up with specifics. I don't particularly want to defend the current localio protocol, and I certainly see a number of points which can and must be improved. But it isn't clear to me that the big picture is either complicated or convoluted. Please provide details. Thanks, NeilBrown . Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailing-List: linux-nfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: "NeilBrown" To: "Mike Snitzer" Cc: "Chuck Lever III" , "Christoph Hellwig" , "Jeff Layton" , "Linux NFS Mailing List" , "Anna Schumaker" , "Trond Myklebust" , "Dave Chinner" Subject: Re: [PATCH v11 00/20] nfs/nfsd: add support for localio In-reply-to: References: <>, Date: Sat, 06 Jul 2024 15:52:02 +1000 Message-id: <172024512210.11489.13288458153195942042@noble.neil.brown.name> Xref: photonic.trudheim.com org.kernel.vger.linux-nfs:86597 Newsgroups: org.kernel.vger.linux-nfs Path: photonic.trudheim.com!nntp.lore.kernel.org!not-for-mail On Sat, 06 Jul 2024, Mike Snitzer wrote: > On Fri, Jul 05, 2024 at 02:59:31PM +0000, Chuck Lever III wrote: > >=20 > >=20 > > > On Jul 5, 2024, at 10:36=E2=80=AFAM, Mike Snitzer = wrote: > > >=20 > > > On Fri, Jul 05, 2024 at 07:18:29AM -0700, Christoph Hellwig wrote: > > >> On Fri, Jul 05, 2024 at 10:15:46AM -0400, Mike Snitzer wrote: > > >>> NFSv3 is needed because NFSv3 is used to initiate IO to NFSv3 knfsd on > > >>> the same host. > > >>=20 > > >> That doesn't really bring is any further. Why is it required? > > >>=20 > > >> I think we'll just need to stop this discussion until we have reasonab= le > > >> documentation of the use cases and assumptions, because without that > > >> we'll get hund up in dead loops. > > >=20 > > > It _really_ isn't material to the core capability that localio provides. > > > localio supporting NFSv3 is beneficial for NFSv3 users (NFSv3 in > > > containers). > > >=20 > > > Hammerspace needs localio to work with NFSv3 to assist with its "data > > > movers" that run on the host (using nfs and nfsd). > > >=20 > > > Please just remove yourself from the conversation if you cannot make > > > sense of this. If you'd like to be involved, put the work in to > > > understand the code and be professional. > >=20 > > Sorry, I can't make sense of this either, and I find the > > personal attack here completely inappropriate (and a bit > > hypocritical, to be honest). >=20 > Hi Chuck, >=20 > I'm out-gunned with this good-cop/bad-cop dynamic. I was replying to > Christoph. Who has taken to feign incapable of understanding localio > yet is perfectly OK with flexing like he is an authority on the topic. Ad Hominem doesn't achieve anything useful. Please stick with technical arguments. (They are the only ones I understand). NeilBrown . Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailing-List: linux-nfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: "NeilBrown" To: "Christoph Hellwig" Cc: "Christoph Hellwig" , "Mike Snitzer" , "Jeff Layton" , "Chuck Lever III" , "Linux NFS Mailing List" , "Anna Schumaker" , "Trond Myklebust" , "Dave Chinner" Subject: Re: [PATCH v11 00/20] nfs/nfsd: add support for localio In-reply-to: References: <>, Date: Sat, 06 Jul 2024 16:37:22 +1000 Message-id: <172024784245.11489.13308466638278184214@noble.neil.brown.name> Xref: photonic.trudheim.com org.kernel.vger.linux-nfs:86601 Newsgroups: org.kernel.vger.linux-nfs Path: photonic.trudheim.com!nntp.lore.kernel.org!not-for-mail On Sat, 06 Jul 2024, Christoph Hellwig wrote: > On Sat, Jul 06, 2024 at 08:08:07AM +1000, NeilBrown wrote: > > I would like to see a good explanation for why NOT NFSv3. > > I don't think NFSv3 is obsolete. The first dictionary is "No longer in > > use." which certainly doesn't apply. > > I think "deprecated" is a more relevant term. I believe that NFSv2 has > > been deprecated. I believe that NFSv4.0 should be deprecated. But I > > don't see any reason to consider NFSv3 to be deprecated. > > The obvious answer is that NFSv4.1/2 (which is really the same thing) > is the only version of NFS under development and open for new features > at the protocol level. So from the standardization perspective NFSv3 > is obsolete. RFC-1813 is certainly obsolete from a standardization perspective - it isn't even an IETF standard - only informational. It can't be extended with any hope of interoperability between implementations. But we don't want interoperability between implementations. We want to enhance the internal workings of one particular implementation. I don't see that the standards status affects that choice. > > But the more important point is that NFSv4 has a built-in way to bypass > the server for I/O namely pNFS. And bypassing the server by directly > going to a local file system is the text book example for what pNFS > does. So we'll need a really good argument why we need to reinvented > a different scheme for bypassing the server for I/O. Maybe there is > a really good killer argument for doing that, but it needs to be clearly > stated and defended instead of assumed. Could you provide a reference to the text book - or RFC - that describes a pNFS DS protocol that completely bypasses the network, allowing the client and MDS to determine if they are the same host and to potentially do zero-copy IO. If not, I will find it hard to understand your claim that it is "the text book example". Also, neither you nor I are in a position to assert what is needed for a change to get accepted. That is up the the people with M: in front of their email address. I believe that any council that either of us give will considered with genuine interest, but making demands seems out of place. Thanks, NeilBrown . From: Gaosheng Cui To: , , , , , , , , , , , , , , CC: , Subject: [PATCH -next] gss_krb5: Fix the error handling path for crypto_sync_skcipher_setkey Date: Sat, 6 Jul 2024 14:50:08 +0800 Message-ID: <20240706065008.451441-1-cuigaosheng1@huawei.com> X-Mailing-List: linux-nfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain Xref: photonic.trudheim.com org.kernel.vger.linux-nfs:86604 org.kernel.vger.netdev:355785 Newsgroups: org.kernel.vger.linux-nfs,org.kernel.vger.netdev Path: photonic.trudheim.com!nntp.lore.kernel.org!not-for-mail If we fail to call crypto_sync_skcipher_setkey, we should free the memory allocation for cipher, replace err_return with err_free_cipher to free the memory of cipher. Fixes: 4891f2d008e4 ("gss_krb5: import functionality to derive keys into the kernel") Signed-off-by: Gaosheng Cui --- net/sunrpc/auth_gss/gss_krb5_keys.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/sunrpc/auth_gss/gss_krb5_keys.c b/net/sunrpc/auth_gss/gss_krb5_keys.c index 06d8ee0db000..4eb19c3a54c7 100644 --- a/net/sunrpc/auth_gss/gss_krb5_keys.c +++ b/net/sunrpc/auth_gss/gss_krb5_keys.c @@ -168,7 +168,7 @@ static int krb5_DK(const struct gss_krb5_enctype *gk5e, goto err_return; blocksize = crypto_sync_skcipher_blocksize(cipher); if (crypto_sync_skcipher_setkey(cipher, inkey->data, inkey->len)) - goto err_return; + goto err_free_cipher; ret = -ENOMEM; inblockdata = kmalloc(blocksize, gfp_mask); -- 2.25.1 .