Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Sat, 20 Aug 2022 23:29:05 -0700
From:   hch <hch@infradead.org>
To:     Siddh Raman Pant <code@siddh.me>
Cc:     Matthew Wilcox <willy@infradead.org>, david <david@fromorbit.com>,
        djwong <djwong@kernel.org>, fgheet255t <fgheet255t@gmail.com>,
        hch <hch@infradead.org>, linux-ext4 <linux-ext4@vger.kernel.org>,
        linux-fsdevel <linux-fsdevel@vger.kernel.org>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        linux-xfs <linux-xfs@vger.kernel.org>,
        riteshh <riteshh@linux.ibm.com>,
        syzbot+a8e049cd3abd342936b6 
        <syzbot+a8e049cd3abd342936b6@syzkaller.appspotmail.com>,
        syzkaller-bugs <syzkaller-bugs@googlegroups.com>
Subject: Re: [syzbot] WARNING in iomap_iter
Message-ID: <YwHQsbH/aYtH5pVs@infradead.org>
References: <20220818110031.89467-1-code@siddh.me>
 <20220818111117.102681-1-code@siddh.me>
 <Yv5RmsUvRh+RKpXH@casper.infradead.org>
 <182b18b5d92.7a2e2b1623166.1514589417142553905@siddh.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <182b18b5d92.7a2e2b1623166.1514589417142553905@siddh.me>
Precedence: bulk

On Thu, Aug 18, 2022 at 08:51:16PM +0530, Siddh Raman Pant wrote:
> On Thu, 18 Aug 2022 20:20:02 +0530  Matthew Wilcox  wrote:
> > I don't think changing these from u64 to s64 is the right way to go.
> 
> Why do you think so? Is there somnething I overlooked?
> 
> I think it won't intorduce regression, since if something is working,
> it will continue to work. If something does break, then they were
> relying on overflows, which is anyways an incorrect way to go about.

Well, for example userspace code expecting unsignedness of these
types could break.  So if we really think changing the types is so
much preferred we'd need to audit common userspace first.  Because
of that I think the version proposed by willy is generally preferred.

> Also, it seems even the 32-bit compatibility structure uses signed
> types.

We should probably fix that as well.