[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Z72JYW0y7fUBSWll@gmail.com>
Date: Tue, 25 Feb 2025 10:12:01 +0100
From: Ingo Molnar <mingo@...nel.org>
To: Michael Jeanson <mjeanson@...icios.com>
Cc: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
Peter Zijlstra <peterz@...radead.org>,
"Paul E. McKenney" <paulmck@...nel.org>,
Boqun Feng <boqun.feng@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] rseq: update kernel fields in lockstep with
CONFIG_DEBUG_RSEQ
* Michael Jeanson <mjeanson@...icios.com> wrote:
> >> I always find it odd that the "source" argument comes first and
> >> the "destination" argument comes second in all put_user() APIs,
> >> compared to memcpy, WRITE_ONCE() and all assignments (e.g.
> >> operator "=" LHS vs RHS). Choosing a different argument order
> >> therefore made sense with a naming different from "*put_user", but
> >> not so much if we use a derived naming.
> >
> > Yeah, put_user()'s oddity is a random historic idiosyncrasy that we
> > want to preserve in derived naming to reduce the potential for
> > confusion.
>
> Would that be ok?
>
> rseq_unsafe_put_user(t, value, field, error_label)
Yeah, I think so.
Thanks,
Ingo
Powered by blists - more mailing lists