linux-kernel - Re: [GIT PULL] Btrfs updates for 5.13

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Mon, 26 Apr 2021 22:07:30 +0100
From:   Matthew Wilcox <willy@...radead.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     David Sterba <dsterba@...e.com>, David Sterba <dsterba@...e.cz>,
        linux-btrfs <linux-btrfs@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] Btrfs updates for 5.13

On Mon, Apr 26, 2021 at 01:55:03PM -0700, Linus Torvalds wrote:
> I've pulled this, but:
> 
> On Mon, Apr 26, 2021 at 1:01 PM David Sterba <dsterba@...e.com> wrote:
> >
> > Matthew Wilcox (Oracle) (1):
> >       btrfs: add and use readahead_batch_length
> 
> This one is buggy, or at least questionable.
> 
> Yes, yes, the function looks trivial. That doesn't make it right:
> 
>   static inline loff_t readahead_batch_length(struct readahead_control *rac)
>   {
>           return rac->_batch_count * PAGE_SIZE;
>   }
> 
> the above does not get the types right, and silently does different
> typecasting than the code clearly intends from the return type of the
> function.
> 
> It may not matter much in practice, but it's still wrong.

Thanks.  You're right that it doesn't matter in practice (because a
batch length is always much, much less than 4GB), but I'll fix it to
return a size_t (which is just the obvious s/loff_t/size_t/, because
PAGE_SIZE is an unsigned long).