Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <cover.1619466460.git.dsterba@suse.com>
In-Reply-To: <cover.1619466460.git.dsterba@suse.com>
From:   Linus Torvalds <torvalds@linux-foundation.org>
Date:   Mon, 26 Apr 2021 13:55:03 -0700
Message-ID: <CAHk-=wj1KRvb=hie1VUTGo1D_ckD+Suo0-M2Nh5Kek1Wu=2Ppw@mail.gmail.com>
Subject: Re: [GIT PULL] Btrfs updates for 5.13
To:     David Sterba <dsterba@suse.com>,
        "Matthew Wilcox (Oracle)" <willy@infradead.org>
Cc:     David Sterba <dsterba@suse.cz>,
        linux-btrfs <linux-btrfs@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

I've pulled this, but:

On Mon, Apr 26, 2021 at 1:01 PM David Sterba <dsterba@suse.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