From: "Arnd Bergmann" <arnd@arndb.de>
To: "Tariq Toukan" <ttoukan.linux@gmail.com>,
"Arnd Bergmann" <arnd@kernel.org>,
"Yishai Hadas" <yishaih@nvidia.com>,
"Jason Gunthorpe" <jgg@ziepe.ca>,
"Leon Romanovsky" <leon@kernel.org>
Cc: "David S . Miller" <davem@davemloft.net>,
"Eric Dumazet" <edumazet@google.com>,
"Jakub Kicinski" <kuba@kernel.org>,
"Paolo Abeni" <pabeni@redhat.com>,
linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org,
Netdev <netdev@vger.kernel.org>
Subject: Re: [PATCH 2/2] net/mlx4: avoid overloading user/kernel pointers
Date: Thu, 20 Apr 2023 10:51:58 +0200 [thread overview]
Message-ID: <b1d02aee-17cb-4461-8f02-b5bd513790ae@app.fastmail.com> (raw)
In-Reply-To: <9975669b-27bf-6903-f908-184946960c25@gmail.com>
On Wed, Apr 19, 2023, at 09:09, Tariq Toukan wrote:
> On 18/04/2023 14:47, Arnd Bergmann wrote:
>
> Now we should maintain the values of the two pointers before any call.
> I'm not sure this is less error-prune. One can mistakenly update
> kbuf_addr for example without nullifying ubuf_addr.
That would cause a compiler warning about the uninitialized variable.
> Also, I'm not a big fan of passing two pointers when exactly one of them
> is effectively used.
> We can think maybe of passing a union of both types, and a boolean
> indicating which pointer type is to be used.
This is basically what you have today. I've dropped this patch from
my randconfig tree and will ignore the problem.
Arnd
next prev parent reply other threads:[~2023-04-20 8:55 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-18 11:47 [PATCH 1/2] net/mlx4: fix build error from usercopy size check Arnd Bergmann
2023-04-18 11:47 ` [PATCH 2/2] net/mlx4: avoid overloading user/kernel pointers Arnd Bergmann
2023-04-19 7:09 ` Tariq Toukan
2023-04-20 8:51 ` Arnd Bergmann [this message]
2023-04-23 14:42 ` kernel test robot
2023-05-01 23:34 ` kernel test robot
2023-05-08 7:10 ` kernel test robot
2023-04-18 12:26 ` [PATCH 1/2] net/mlx4: fix build error from usercopy size check Tariq Toukan
2025-02-11 7:49 ` YinFengwei
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=b1d02aee-17cb-4461-8f02-b5bd513790ae@app.fastmail.com \
--to=arnd@arndb.de \
--cc=arnd@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=jgg@ziepe.ca \
--cc=kuba@kernel.org \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=ttoukan.linux@gmail.com \
--cc=yishaih@nvidia.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