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;
Date:   Mon, 26 Apr 2021 22:07:30 +0100
From:   Matthew Wilcox <willy@infradead.org>
To:     Linus Torvalds <torvalds@linux-foundation.org>
Cc:     David Sterba <dsterba@suse.com>, David Sterba <dsterba@suse.cz>,
        linux-btrfs <linux-btrfs@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL] Btrfs updates for 5.13
Message-ID: <20210426210730.GR235567@casper.infradead.org>
References: <cover.1619466460.git.dsterba@suse.com>
 <CAHk-=wj1KRvb=hie1VUTGo1D_ckD+Suo0-M2Nh5Kek1Wu=2Ppw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAHk-=wj1KRvb=hie1VUTGo1D_ckD+Suo0-M2Nh5Kek1Wu=2Ppw@mail.gmail.com>
Precedence: bulk

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@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.

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).