All of lore.kernel.org
 help / color / mirror / Atom feed
From: Beau Belgrave <beaub@linux.microsoft.com>
To: "Clément Léger" <cleger@rivosinc.com>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org
Subject: Re: [PATCH] tracing/user_events: align uaddr on unsigned long alignment
Date: Thu, 14 Sep 2023 09:42:18 -0700	[thread overview]
Message-ID: <20230914164218.GA450-beaub@linux.microsoft.com> (raw)
In-Reply-To: <20230914131102.179100-1-cleger@rivosinc.com>

On Thu, Sep 14, 2023 at 03:11:02PM +0200, Clément Léger wrote:
> enabler->uaddr can be aligned on 32 or 64 bits. If aligned on 32 bits,
> this will result in a misaligned access on 64 bits architectures since
> set_bit()/clear_bit() are expecting an unsigned long (aligned) pointer.
> On architecture that do not support misaligned access, this will crash
> the kernel. Align uaddr on unsigned long size to avoid such behavior.
> This bug was found while running kselftests on RISC-V.
> 
> Fixes: 7235759084a4 ("tracing/user_events: Use remote writes for event enablement")
> Signed-off-by: Clément Léger <cleger@rivosinc.com>

Thanks for fixing! I have a few comments on this.

I unfortunately do not have RISC-V hardware to validate this on.

> ---
>  kernel/trace/trace_events_user.c | 12 +++++++++---
>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/kernel/trace/trace_events_user.c b/kernel/trace/trace_events_user.c
> index 6f046650e527..580c0fe4b23e 100644
> --- a/kernel/trace/trace_events_user.c
> +++ b/kernel/trace/trace_events_user.c
> @@ -479,7 +479,7 @@ static int user_event_enabler_write(struct user_event_mm *mm,
>  				    bool fixup_fault, int *attempt)
>  {
>  	unsigned long uaddr = enabler->addr;
> -	unsigned long *ptr;
> +	unsigned long *ptr, bit_offset;
>  	struct page *page;
>  	void *kaddr;
>  	int ret;
> @@ -511,13 +511,19 @@ static int user_event_enabler_write(struct user_event_mm *mm,
>  	}
>  
>  	kaddr = kmap_local_page(page);
> +
> +	bit_offset = uaddr & (sizeof(unsigned long) - 1);
> +	if (bit_offset) {
> +		bit_offset *= 8;

I think for future readers of this code it would be more clear to use
BITS_PER_BYTE instead of the hardcoded 8. Given we always align on a
"natural" boundary, I believe the bit_offset will always be 32 bits.

A comment here might help clarify why we do this as well in case folks
don't see the change description.

> +		uaddr &= ~(sizeof(unsigned long) - 1);

Shouldn't this uaddr change be done before calling pin_user_pages_remote()
to ensure things cannot go bad? (I don't think they can, but it looks a
little odd).

Thanks,
-Beau

> +	}
>  	ptr = kaddr + (uaddr & ~PAGE_MASK);
>  
>  	/* Update bit atomically, user tracers must be atomic as well */
>  	if (enabler->event && enabler->event->status)
> -		set_bit(ENABLE_BIT(enabler), ptr);
> +		set_bit(ENABLE_BIT(enabler) + bit_offset, ptr);
>  	else
> -		clear_bit(ENABLE_BIT(enabler), ptr);
> +		clear_bit(ENABLE_BIT(enabler) + bit_offset, ptr);
>  
>  	kunmap_local(kaddr);
>  	unpin_user_pages_dirty_lock(&page, 1, true);
> -- 
> 2.40.1

  reply	other threads:[~2023-09-14 16:42 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-14 13:11 [PATCH] tracing/user_events: align uaddr on unsigned long alignment Clément Léger
2023-09-14 16:42 ` Beau Belgrave [this message]
2023-09-14 17:42   ` Clément Léger
2023-09-14 17:17 ` Steven Rostedt
2023-09-14 17:29   ` Steven Rostedt
2023-09-14 17:32     ` Clément Léger
2023-09-19 12:59     ` Clément Léger
2023-09-22 19:22       ` Beau Belgrave
2023-09-25  7:53         ` Clément Léger
2023-09-25 16:04           ` Beau Belgrave
2023-09-25 18:04             ` Clément Léger
2023-09-25 18:22               ` Clément Léger
2023-09-22 20:00       ` Beau Belgrave
2023-09-25  8:10         ` Clément Léger
2023-09-15  2:54 ` Masami Hiramatsu
2023-09-17 14:10   ` Clément Léger
2023-09-17 21:09 ` David Laight
2023-09-18  8:37   ` Clément Léger

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=20230914164218.GA450-beaub@linux.microsoft.com \
    --to=beaub@linux.microsoft.com \
    --cc=cleger@rivosinc.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=rostedt@goodmis.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.