From: Johannes Kirchmair - SKIDATA <Johannes.Kirchmair@skidata.com>
To: "Sébastien Szymanski" <sebastien.szymanski@armadeus.com>,
"u-boot@lists.denx.de" <u-boot@lists.denx.de>
Subject: AW: [NFS] fetching kernel via nfs
Date: Thu, 16 May 2024 10:53:38 +0000 [thread overview]
Message-ID: <GVAP278MB0456BB0B0B5FEEB5CC0F22118CED2@GVAP278MB0456.CHEP278.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <5b5d6fe5-d436-4ac0-b6bf-7485196a97db@armadeus.com>
Hello Sébastien,
missed that because was testing on v2024.4.
And did not think about looking at master branch because it seemed to be broken for quite a while.
Anyways, thanks for the quick response and for fixing this thing.
Best regards
-----Ursprüngliche Nachricht-----
Von: Sébastien Szymanski <sebastien.szymanski@armadeus.com>
Gesendet: Mittwoch, 15. Mai 2024 18:53
An: Johannes Kirchmair - SKIDATA <Johannes.Kirchmair@skidata.com>; u-boot@lists.denx.de
Cc: joe.hershberger@ni.com; rfried.dev@gmail.com
Betreff: Re: [NFS] fetching kernel via nfs
[Sie erhalten nicht häufig E-Mails von sebastien.szymanski@armadeus.com. Weitere Informationen, warum dies wichtig ist, finden Sie unter https://aka.ms/LearnAboutSenderIdentification ]
EXTERNAL EMAIL
Hello,
On 5/15/24 14:40, Johannes Kirchmair - SKIDATA wrote:
> Dear u-boot people,
>
> I encountered some problems trying to fetch the Linux kernel via nfs (v3).
> One problem was that the nfs file lookup always returned NFS3ERR_BADHANDLE.
I have fixed this. See:
https://source.denx.de/u-boot/u-boot/-/commit/d2986567b27dae764b19886bcda1d24b7c41d075
Regards,
> This is due to the following line in nfs_lookup_req() function (net/nfs.c):
>
> len = (uint32_t *)p - (uint32_t *)&(data[0]);
> rpc_req(PROG_NFS, NFS_LOOKUP, data, len);
> } else { /* NFS_V3 */
> *p++ = htonl(NFS_FHSIZE); /* Dir handle length */ <===== this line
> memcpy(p, dirfh, NFS_FHSIZE);
> p += (NFS_FHSIZE / 4);
> *p++ = htonl(fnamelen);
>
> In the NFS_V3 case we add the dir file handle size to data and then the dir file handle.
> IUC, this is not correct here because dirfh includes already the size of the handle in the first 4 bytes.
> Feel free to correct me if I am wrong.
>
> As a result, if I remove the line "*p++ = htonl(NFS_FHSIZE);", it works fine.
>
> Don't have an in deps understanding of nfs, so I am not sure if this is the root problem here.
>
> Best regards Johannes
--
Sébastien Szymanski, Armadeus Systems
Software engineer
prev parent reply other threads:[~2024-05-16 10:53 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-15 12:40 [NFS] fetching kernel via nfs Johannes Kirchmair - SKIDATA
2024-05-15 16:53 ` Sébastien Szymanski
2024-05-16 10:53 ` Johannes Kirchmair - SKIDATA [this message]
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=GVAP278MB0456BB0B0B5FEEB5CC0F22118CED2@GVAP278MB0456.CHEP278.PROD.OUTLOOK.COM \
--to=johannes.kirchmair@skidata.com \
--cc=sebastien.szymanski@armadeus.com \
--cc=u-boot@lists.denx.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).