From: Teresa Remmet <t.remmet@phytec.de>
To: Sascha Hauer <s.hauer@pengutronix.de>
Cc: barebox@lists.infradead.org
Subject: Re: Transferring files over tftp
Date: Tue, 20 Nov 2018 14:46:42 +0100 [thread overview]
Message-ID: <1542721602.2913.11.camel@phytec.de> (raw)
In-Reply-To: <20181116073206.3773odofpb2xxnbl@pengutronix.de>
Hello Sascha,
Am Freitag, den 16.11.2018, 08:32 +0100 schrieb Sascha Hauer:
> Hi Teresa,
>
> On Thu, Nov 15, 2018 at 04:24:18PM +0100, Teresa Remmet wrote:
> >
> > Hello,
> >
> > I am facing tftp issues when trying to transfer files > 2GB. This
> > ends up in a crash:
> >
> >
> >
...
> >
> > Causing this seems to be commit:
> >
> > commit e3e55fa3aa698bb92fa4362a36e102749c13c124
> > Author: Sascha Hauer <s.hauer@pengutronix.de>
> > Date: Thu Aug 30 12:27:00 2018 +0200
> >
> > fs: tftp: improve file size handling
> >
> > Previously we used FILE_SIZE_STREAM unconditionally. Instead,
> > fill the
> > inode size with a valid filesize if we have one and only if not
> > fall
> > back to FILE_SIZE_STREAM.
> >
> > Reverting the commit reveals a second issue. After 2GB the transfer
> > breaks up silently.
> > Maybe some overflow? Any idea where to look at this further?
> As a first step try the attached patch which makes the filesize in
> tftp
> a 64bit type so that we at least can handle the filesize numbers.
Okay, this already seem to fix the problem. Transferring files >2GB
works here now, too. Thanks.
>
> I tried transferring a file > 2GiB here and it seemed to work,
> although
> I don't have a board with that amount of memory, so I had to write to
> /dev/null. I don't know if that makes a difference.
>
> Also you probably begin to hit the limits of the tftp servers. I
> realized that our tftp server (atftpd) only reports the filesize for
> files smaller than 2GiB, with bigger files it only reports '0'.
Okay I use tftpd-hpa where files >2GB work.
>
> I think other tftp servers begin to make problems when the 16bit
> block
> counter overflows, so with working 2GiB files you are lucky already
> ;)
man page says that the tftp server also support rollover for such a
case. But this is non standard. And transferring big files with tftp is
not much fun anyway.
Teresa
>
> Sascha
>
> --------------------------------------8<-----------------------------
> -----
>
> From bf3de3391c958c9c44fcfa54b2c1a6a29e68a5a4 Mon Sep 17 00:00:00
> 2001
> From: Sascha Hauer <s.hauer@pengutronix.de>
> Date: Fri, 16 Nov 2018 08:24:06 +0100
> Subject: [PATCH] fs: tftp: Make filesize a 64bit type
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> ---
> fs/tftp.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/fs/tftp.c b/fs/tftp.c
> index 0d9ee6effd..8131ab27b3 100644
> --- a/fs/tftp.c
> +++ b/fs/tftp.c
> @@ -80,7 +80,7 @@ struct file_priv {
> int state;
> int err;
> char *filename;
> - int filesize;
> + loff_t filesize;
> uint64_t resend_timeout;
> uint64_t progress_timeout;
> struct kfifo *fifo;
> @@ -136,7 +136,7 @@ static int tftp_send(struct file_priv *priv)
> "timeout%c"
> "%d%c"
> "tsize%c"
> - "%d%c"
> + "%lld%c"
> "blksize%c"
> "1432",
> priv->filename + 1, 0,
> @@ -235,7 +235,7 @@ static void tftp_parse_oack(struct file_priv
> *priv, unsigned char *pkt, int len)
> if (val > s + len)
> return;
> if (!strcmp(opt, "tsize"))
> - priv->filesize = simple_strtoul(val, NULL,
> 10);
> + priv->filesize = simple_strtoull(val, NULL,
> 10);
> if (!strcmp(opt, "blksize"))
> priv->blocksize = simple_strtoul(val, NULL,
> 10);
> pr_debug("OACK opt: %s val: %s\n", opt, val);
> @@ -658,7 +658,7 @@ static struct dentry *tftp_lookup(struct inode
> *dir, struct dentry *dentry,
> struct fs_device_d *fsdev = container_of(sb, struct
> fs_device_d, sb);
> struct inode *inode;
> struct file_priv *priv;
> - int filesize;
> + loff_t filesize;
>
> priv = tftp_do_open(&fsdev->dev, O_RDONLY, dentry);
> if (IS_ERR(priv))
> --
> 2.19.1
>
>
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
next prev parent reply other threads:[~2018-11-20 13:46 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-15 15:24 Transferring files over tftp Teresa Remmet
2018-11-16 7:32 ` Sascha Hauer
2018-11-20 13:46 ` Teresa Remmet [this message]
2018-11-29 8:14 ` Teresa Remmet
2018-11-29 11:02 ` Sascha Hauer
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=1542721602.2913.11.camel@phytec.de \
--to=t.remmet@phytec.de \
--cc=barebox@lists.infradead.org \
--cc=s.hauer@pengutronix.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 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.