linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: Omar Sandoval <osandov@osandov.com>
Cc: linux-btrfs@vger.kernel.org, kernel-team@fb.com,
	Nikolay Borisov <nborisov@suse.com>,
	Filipe Manana <fdmanana@suse.com>
Subject: Re: [PATCH v2 2/2] Btrfs: get rid of pointless wtag variable in async-thread.c
Date: Mon, 19 Aug 2019 19:24:13 +0200	[thread overview]
Message-ID: <20190819172413.GL24086@twin.jikos.cz> (raw)
In-Reply-To: <d4fa1870ffce027ada265a67f4e00d397b683241.1565717248.git.osandov@fb.com>

On Tue, Aug 13, 2019 at 10:33:44AM -0700, Omar Sandoval wrote:
> From: Omar Sandoval <osandov@fb.com>
> 
> Commit ac0c7cf8be00 ("btrfs: fix crash when tracepoint arguments are
> freed by wq callbacks") added a void pointer, wtag, which is passed into
> trace_btrfs_all_work_done() instead of the freed work item. This is
> silly for a few reasons:
> 
> 1. The freed work item still has the same address.
> 2. work is still in scope after it's freed, so assigning wtag doesn't
>    stop anyone from using it.
> 3. The tracepoint has always taken a void * argument, so assigning wtag
>    doesn't actually make things any more type-safe. (Note that the
>    original bug in commit bc074524e123 ("btrfs: prefix fsid to all trace
>    events") was that the void * was implicitly casted when it was passed
>    to btrfs_work_owner() in the trace point itself).

I'd argue that the patch did it the way to prevent silly errors like
reusing 'work' because see it's passed to the tracepoint so it's fine to
use any time later as well. The value of the pointer was just something
to grep for not meant to be used in any other way.


> Instead, let's add some clearer warnings as comments.
> 
> Reviewed-by: Nikolay Borisov <nborisov@suse.com>
> Reviewed-by: Filipe Manana <fdmanana@suse.com>
> Signed-off-by: Omar Sandoval <osandov@fb.com>
> ---
>  fs/btrfs/async-thread.c      | 21 ++++++++-------------
>  include/trace/events/btrfs.h |  6 +++---
>  2 files changed, 11 insertions(+), 16 deletions(-)
> 
> diff --git a/fs/btrfs/async-thread.c b/fs/btrfs/async-thread.c
> index d105d3df6fa6..60319075b781 100644
> --- a/fs/btrfs/async-thread.c
> +++ b/fs/btrfs/async-thread.c
> @@ -226,7 +226,6 @@ static void run_ordered_work(struct btrfs_work *self)
>  	struct btrfs_work *work;
>  	spinlock_t *lock = &wq->list_lock;
>  	unsigned long flags;
> -	void *wtag;
>  	bool free_self = false;
>  
>  	while (1) {
> @@ -281,21 +280,19 @@ static void run_ordered_work(struct btrfs_work *self)
>  		} else {
>  			/*
>  			 * We don't want to call the ordered free functions with
> -			 * the lock held though. Save the work as tag for the
> -			 * trace event, because the callback could free the
> -			 * structure.
> +			 * the lock held.
>  			 */
> -			wtag = work;
>  			work->ordered_free(work);
> -			trace_btrfs_all_work_done(wq->fs_info, wtag);
> +			/* NB: work must not be dereferenced past this point. */
> +			trace_btrfs_all_work_done(wq->fs_info, work);

I hope that programmers read code and comments so what you do is fine
too and we don't have to reset work to NULL at this point, though this
would make it really hard to miss.

  reply	other threads:[~2019-08-19 17:23 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-13 17:33 [PATCH v2 0/2] Btrfs: workqueue cleanups Omar Sandoval
2019-08-13 17:33 ` [PATCH v2 1/2] Btrfs: get rid of unique workqueue helper functions Omar Sandoval
2019-08-13 17:33 ` [PATCH v2 2/2] Btrfs: get rid of pointless wtag variable in async-thread.c Omar Sandoval
2019-08-19 17:24   ` David Sterba [this message]
2019-08-19 17:28 ` [PATCH v2 0/2] Btrfs: workqueue cleanups David Sterba
2019-08-21 13:20 ` David Sterba
2019-08-21 13:24   ` David Sterba
2019-08-21 14:14     ` David Sterba
2019-08-21 15:18       ` Josef Bacik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190819172413.GL24086@twin.jikos.cz \
    --to=dsterba@suse.cz \
    --cc=fdmanana@suse.com \
    --cc=kernel-team@fb.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=nborisov@suse.com \
    --cc=osandov@osandov.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).