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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHk-=wj1KRvb=hie1VUTGo1D_ckD+Suo0-M2Nh5Kek1Wu=2Ppw@mail.gmail.com>
Date:   Mon, 26 Apr 2021 13:55:03 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     David Sterba <dsterba@...e.com>,
        "Matthew Wilcox (Oracle)" <willy@...radead.org>
Cc:     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

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.

               Linus