linux-kernel - Re: [PATCH v4 6/6] block: use chunk_sectors when evaluating stacked atomic write limits

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <a59f21eb-e668-458d-ba01-e6b1a21a75ea@oracle.com>
Date: Tue, 8 Jul 2025 19:00:02 +0100
From: John Garry <john.g.garry@...cle.com>
To: Mikulas Patocka <mpatocka@...hat.com>, Nilay Shroff <nilay@...ux.ibm.com>
Cc: agk@...hat.com, snitzer@...nel.org, song@...nel.org, yukuai3@...wei.com,
        hch@....de, axboe@...nel.dk, cem@...nel.org, dm-devel@...ts.linux.dev,
        linux-kernel@...r.kernel.org, linux-raid@...r.kernel.org,
        linux-block@...r.kernel.org, ojaswin@...ux.ibm.com,
        martin.petersen@...cle.com, akpm@...ux-foundation.org,
        linux-xfs@...r.kernel.org, djwong@...nel.org
Subject: Re: [PATCH v4 6/6] block: use chunk_sectors when evaluating stacked
 atomic write limits

On 08/07/2025 17:59, Mikulas Patocka wrote:
>>> +
>>> +	/*
>>> +	 * If chunk sectors is so large that its value in bytes overflows
>>> +	 * UINT_MAX, then just shift it down so it definitely will fit.
>>> +	 * We don't support atomic writes of such a large size anyway.
>>> +	 */
>>> +	if ((unsigned long)chunk_sectors << SECTOR_SHIFT > UINT_MAX)
>>> +		chunk_bytes = chunk_sectors;
>>> +	else
>>> +		chunk_bytes = chunk_sectors << SECTOR_SHIFT;
> Why do we cast it to unsigned long? unsigned long is 32-bit on 32-bit
> machines, so the code will not detect the overflow in that case. We should
> cast it to unsigned long long (or uint64_t).

Right, I said earlier that I would use an unsigned long long, but didn't 
do it that way, which was unintentional.

Anyway, I will change this code as suggested by Nilay.

Thanks,
John