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] [thread-next>] [day] [month] [year] [list]
Message-ID: <934c62d1-c800-4b31-9774-1e9dfe661877@pankajraghav.com>
Date: Fri, 12 Dec 2025 05:23:24 +0530
From: Pankaj Raghav <kernel@...kajraghav.com>
To: Damien Le Moal <dlemoal@...nel.org>, sw.prabhu6@...il.com,
 James.Bottomley@...senPartnership.com, martin.petersen@...cle.com,
 linux-scsi@...r.kernel.org
Cc: bvanassche@....org, linux-kernel@...r.kernel.org, mcgrof@...nel.org,
 stable@...r.kernel.org, Swarna Prabhu <s.prabhu@...sung.com>,
 Pankaj Raghav <p.raghav@...sung.com>
Subject: Re: [PATCH 1/2] scsi: sd: fix write_same(16/10) to enable sector size
 > PAGE_SIZE


On 12/10/25 07:22, Damien Le Moal wrote:
> On 2025/12/09 17:41, sw.prabhu6@...il.com wrote:
>> From: Swarna Prabhu <sw.prabhu6@...il.com>
>>
>> The WRITE SAME(16) and WRITE SAME(10) scsi commands uses
>> a page from a dedicated mempool('sd_page_pool') for its
>> payload. This pool was initialized to allocate single
>> pages, which was sufficient as long as the device sector
>> size did not exceed the PAGE_SIZE.
>>
>> Given that block layer now supports block size upto
>> 64K ie beyond PAGE_SIZE, adapt sd_set_special_bvec()
>> to accommodate that.
>>
>> With the above fix, enable sector sizes > PAGE_SIZE in
>> scsi sd driver.
>>
>> Cc: stable@...r.kernel.org
>> Signed-off-by: Swarna Prabhu <s.prabhu@...sung.com>
>> Co-developed-by: Pankaj Raghav <p.raghav@...sung.com>
>> Signed-off-by: Pankaj Raghav <p.raghav@...sung.com>
>> ---
>> Note: We are allocating pages of order aligned to 
>> BLK_MAX_BLOCK_SIZE for the mempool page allocator
>> 'sd_page_pool' all the time. This is because we only
>> know that a bigger sector size device is attached at
>> sd_probe and it might be too late to reallocate mempool
>> with order >0.
> 
> That is a lot heavier on the memory for the vast majority of devices which are
> 512B or 4K block size... It may be better to have the special "large block"
> mempool attached to the scsi disk struct and keep the default single page
> mempool for all other regular devices.
> 

We had the same feeling as well and we mentioned it in the 1st RFC.

But when will you initialize the mempool for the large block devices? I don't think it
makes sense to unconditionally initialize it in init_sd.
Do we do it during the sd_probe() when we first encounter a large block device? That way
we may not waste any memory if no large block devices are attached.

--
Pankaj


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ