[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFzJYXCNPXT8D91FmjU2AWOfvWMnx2BZE+0CLgBcqX3u1g@mail.gmail.com>
Date: Thu, 5 Oct 2017 18:31:29 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Al Viro <viro@...iv.linux.org.uk>
Cc: Sergey Klyaus <sergey.m.klyaus@...il.com>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Li Wang <liwang@...hat.com>,
Andreas Dilger <adilger@...ger.ca>,
Andi Kleen <andi.kleen@...el.com>
Subject: Re: [PATCH] vfs: fix statfs64() returning impossible EOVERFLOW for
64-bit f_files
On Thu, Oct 5, 2017 at 4:06 PM, Al Viro <viro@...iv.linux.org.uk> wrote:
>
> Just to make sure we are on the same page: out of kstatfs fields
> we have 5 u64 ones (see above; all of them are u64 is struct statfs64
> on all architectures), an opaque 64bit f_fsid and 5 fields that
> are long: f_type (magic numbers, all 32bit), f_namelen (max filename
> length), f_frsize (0 on most of filesystems, always fits into 32 bits),
> f_flags (guaranteed to be 32bit) and f_bsize.
Please just use that FITS_IN() kind of macro regardless.
If the sizes match, the compiler will optimize the test away.
If the sizes don't match, that FITS_IN() will do the right thing.
Do *not* manually go and say "these fields are ok, because..". The
whole bug was because people were confused about the field widths.
Linus
Powered by blists - more mailing lists