From: Sascha Hauer <s.hauer@pengutronix.de>
To: Andrey Smirnov <andrew.smirnov@gmail.com>
Cc: barebox@lists.infradead.org
Subject: Re: [PATCH 6/7] fs: Add support for files larger than MAX_LFS_FILESIZE
Date: Thu, 24 Jan 2019 09:48:06 +0100 [thread overview]
Message-ID: <20190124084806.2c2mymykqmrwg5xs@pengutronix.de> (raw)
In-Reply-To: <20190123011338.32517-7-andrew.smirnov@gmail.com>
On Tue, Jan 22, 2019 at 05:13:37PM -0800, Andrey Smirnov wrote:
> On 64-bit platforms /dev/mem exceeds the size supported by loff_t and
> needs special treatment within the rest of FS API. Specifically
> lseek() needs to be modified to make sure it does the right thing.
>
> Prievious attempt at fixing this issue by using IS_ERR_VALUE()
>
> e10efc5080 ("fs: fix memory access via /dev/mem for MIPS64")
>
> doesn't really work 100% on 64-bit platforms, becuase it still leaves
> out a number of perfectly valid offsets (e.g. "md 0xffffffffffffff00"
> doesn't work) . Moreso it breaks lseek() on 32-bit platforms, since
> IS_ERR_VALUE will retrurn true for any offset that is >= (unsigned
> long) -MAX_ERRNO.
>
> In order to fix this issue on both 32 and 64 bit platforms, introduce
> DEVFS_UNBOUNDED flag that cdevs can use to denote that they span all
> 64-bit address space and effectively have not limits. To propagate
> that info to FS layer, add "unbounded" boolean to FILE. As a last step
> modify lseek() to be aware of that field and do the right checks in
> that case.
>
> Note, that since loff_t has no problem covering all of address space
> on 32-bit platforms, DEVFS_UNBOUNDED is defined to expand into 0 and
> not be settable there.
>
> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
> @@ -422,20 +422,41 @@ loff_t lseek(int fildes, loff_t offset, int whence)
lseek takes a signed loff_t argument. We store the file size in an also
signed variable. An lseek to the end of a file covering the whole 64bit
address space (0xffffffffffffffff) will always return an error as
(loff_t)-1 is both the position and the error code.
I think instead of casting loff_t to an unsigned type whenever we find
it convenient and then still not having enough bits for storing the
filesize of 0x10000000000000000 we should rather face the fact that our
maximum filesize is only half of the 64bit address space.
To put it differently we should think about creating a second /dev/mem
for the upper half of the 64bit address space.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
next prev parent reply other threads:[~2019-01-24 8:48 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-23 1:13 [PATCH 0/7] 32-bit lseek and /dev/mem fixes/improvements Andrey Smirnov
2019-01-23 1:13 ` [PATCH 1/7] commands: Move mem_parse_options() to lib/misc.c Andrey Smirnov
2019-01-23 1:13 ` [PATCH 2/7] commands: Get rid of mem_rw_buf Andrey Smirnov
2019-01-23 1:13 ` [PATCH 3/7] commands: Move /dev/mem driver to drivers/misc Andrey Smirnov
2019-01-23 1:13 ` [PATCH 4/7] fs: Change error checking logic for fsdrv->lseek() call Andrey Smirnov
2019-01-24 7:44 ` Sascha Hauer
2019-01-24 19:19 ` Andrey Smirnov
2019-01-23 1:13 ` [PATCH 5/7] fs: Calculate new position before validtiy check in lseek() Andrey Smirnov
2019-01-24 7:52 ` Sascha Hauer
2019-01-24 19:37 ` Andrey Smirnov
2019-01-23 1:13 ` [PATCH 6/7] fs: Add support for files larger than MAX_LFS_FILESIZE Andrey Smirnov
2019-01-24 8:48 ` Sascha Hauer [this message]
2019-01-24 19:43 ` Andrey Smirnov
2019-01-23 1:13 ` [PATCH 7/7] misc: mem: Set correct size for /dev/mem Andrey Smirnov
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=20190124084806.2c2mymykqmrwg5xs@pengutronix.de \
--to=s.hauer@pengutronix.de \
--cc=andrew.smirnov@gmail.com \
--cc=barebox@lists.infradead.org \
/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