[PATCH U-BOOT v3 25/30] fs: btrfs: Implement btrfs_file_read()
Tom Rini
trini at konsulko.com
Tue Sep 8 02:56:46 CEST 2020
On Tue, Sep 08, 2020 at 08:26:27AM +0800, Qu Wenruo wrote:
>
>
> On 2020/9/8 上午6:35, Tom Rini wrote:
> > On Wed, Jun 24, 2020 at 06:03:11PM +0200, Marek Behún wrote:
> >
> >> From: Qu Wenruo <wqu at suse.com>
> >>
> >> This version of btrfs_file_read() has the following new features:
> >> - Tries all mirrors
> >> - More handling on unaligned size
> >> - Better compressed extent handling
> >> The old implementation doesn't handle compressed extent with offset
> >> properly: we need to read out the whole compressed extent, then
> >> decompress the whole extent, and only then copy the requested part.
> >>
> >> Signed-off-by: Qu Wenruo <wqu at suse.com>
> >> Reviewed-by: Marek Behún <marek.behun at nic.cz>
> >
> > Note that this introduces a warning with LLVM-10:
> > fs/btrfs/btrfs.c:246:6: warning: variable 'real_size' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
> > if (!len) {
> > ^~~~
> > fs/btrfs/btrfs.c:255:12: note: uninitialized use occurs here
> > if (len > real_size - offset)
> > ^~~~~~~~~
> > fs/btrfs/btrfs.c:246:2: note: remove the 'if' if its condition is always true
> > if (!len) {
> > ^~~~~~~~~~
> > fs/btrfs/btrfs.c:228:18: note: initialize the variable 'real_size' to silence this warning
> > loff_t real_size;
> > ^
> > = 0
> > 1 warning generated.
> >
> > and I have silenced as suggested. I'm not 100% happy with that, but
> > leave fixing it here and in upstream btrfs-progs to the btrfs-experts.
>
> My bad. The warning is correct, and since the code is U-boot specific,
> it doesn't affect kernel (using page) nor btrfs-progs (not really do
> file read with offset).
>
> The fix is a little complex.
>
> In fact we need to always call btrfs_size() to grab the real_size, and
> then modify @len using real_size, either using real_size directly, or do
> some basic calculation.
Ah, thanks. I'll fold in your changes.
>
> BTW, I didn't see the btrfs rebuild work merged upstream. Is this
> planned or you just grab from some specific branch?
Yes, I'm testing them for -next right now.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200907/b3ec9d0b/attachment-0001.sig>
More information about the U-Boot
mailing list