linux-kernel - Re: [PATCH] btrfs: keep `priv` struct on stack for sync reads in `btrfs_encoded_read_regular_fill

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 for Android: free password hash cracker in your pocket

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

Message-ID: <9cca57da-3361-470d-83e5-0d78deffb673@wdc.com>
Date: Wed, 8 Jan 2025 12:42:23 +0000
From: Johannes Thumshirn <Johannes.Thumshirn@....com>
To: Daniel Vacek <neelx@...e.com>, Chris Mason <clm@...com>, Josef Bacik
	<josef@...icpanda.com>, David Sterba <dsterba@...e.com>
CC: "linux-btrfs@...r.kernel.org" <linux-btrfs@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] btrfs: keep `priv` struct on stack for sync reads in
 `btrfs_encoded_read_regular_fill_pages()`

On 08.01.25 12:44, Daniel Vacek wrote:
> Only allocate the `priv` struct from slab for asynchronous mode.
> 
> There's no need to allocate an object from slab in the synchronous mode. In
> such a case stack can be happily used as it used to be before 68d3b27e05c7
> ("btrfs: move priv off stack in btrfs_encoded_read_regular_fill_pages()")
> which was a preparation for the async mode.
> 
> While at it, fix the comment to reflect the atomic => refcount change in
> d29662695ed7 ("btrfs: fix use-after-free waiting for encoded read endios").


Generally I'm not a huge fan of conditional allocation/freeing. It just 
complicates matters. I get it in case of the bio's bi_inline_vecs where 
it's a optimization, but I fail to see why it would make a difference in 
this case.

If we're really going down that route, there should at least be a 
justification other than "no need" to.

>   struct btrfs_encoded_read_private {
> -	struct completion done;
> +	struct completion *sync_reads;
>   	void *uring_ctx;
> -	refcount_t pending_refs;
> +	refcount_t pending_reads;
>   	blk_status_t status;
>   };

These renames just make the diff harder to read (and yes I shouldn't 
have renamed pending to pending_refs but that at least also changed the 
type).


> -	if (refcount_dec_and_test(&priv->pending_refs)) {
> -		int err = blk_status_to_errno(READ_ONCE(priv->status));
> -
> +	if (refcount_dec_and_test(&priv->pending_reads)) {
>   		if (priv->uring_ctx) {
> +			int err = blk_status_to_errno(READ_ONCE(priv->status));

Missing newline after the declaration.

>   	unsigned long i = 0;
>   	struct btrfs_bio *bbio;
> -	int ret;

That seems unrelated.


> @@ -9155,25 +9159,23 @@ int btrfs_encoded_read_regular_fill_pages(struct btrfs_inode *inode,
>   		disk_io_size -= bytes;
>   	} while (disk_io_size);
>   
> -	refcount_inc(&priv->pending_refs);
> +	refcount_inc(&priv->pending_reads);
>   	btrfs_submit_bbio(bbio, 0);
>   
>   	if (uring_ctx) {
> -		if (refcount_dec_and_test(&priv->pending_refs)) {
> -			ret = blk_status_to_errno(READ_ONCE(priv->status));
> -			btrfs_uring_read_extent_endio(uring_ctx, ret);
> +		if (refcount_dec_and_test(&priv->pending_reads)) {
> +			int err = blk_status_to_errno(READ_ONCE(priv->status));
> +			btrfs_uring_read_extent_endio(uring_ctx, err);
>   			kfree(priv);

Missing newline after the declaration, but still why can't we just keep ret?