From: Takashi Iwai <tiwai@suse.de>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Mark Brown <broonie@kernel.org>,
alsa-devel@alsa-project.org,
Andrey Utkin <andrey_utkin@fastmail.com>,
Anton Sviridenko <anton@corp.bluecherry.net>,
Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>,
Banajit Goswami <bgoswami@quicinc.com>,
Bluecherry Maintainers <maintainers@bluecherrydvr.com>,
Claudiu Beznea <claudiu.beznea@microchip.com>,
Ismael Luceno <ismael@iodev.co.uk>,
Lars-Peter Clausen <lars@metafoo.de>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>,
Olivier Moysan <olivier.moysan@foss.st.com>,
Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
linux-media@vger.kernel.org, xen-devel@lists.xenproject.org
Subject: Re: [PATCH 00/24] ALSA: Generic PCM copy ops using sockptr_t
Date: Mon, 07 Aug 2023 17:22:18 +0200 [thread overview]
Message-ID: <87pm3yj2s5.wl-tiwai@suse.de> (raw)
In-Reply-To: <ZMlGKy7ibjkQ6ii7@smile.fi.intel.com>
On Tue, 01 Aug 2023 19:51:39 +0200,
Andy Shevchenko wrote:
>
> On Tue, Aug 01, 2023 at 02:54:45PM +0200, Takashi Iwai wrote:
> > On Mon, 31 Jul 2023 21:40:20 +0200,
> > Mark Brown wrote:
> > > On Mon, Jul 31, 2023 at 09:30:29PM +0200, Takashi Iwai wrote:
> > > > Mark Brown wrote:
> > >
> > > > > It really feels like we ought to rename, or add an alias for, the type
> > > > > if we're going to start using it more widely - it's not helping to make
> > > > > the code clearer.
> > >
> > > > That was my very first impression, too, but I changed my mind after
> > > > seeing the already used code. An alias might work, either typedef or
> > > > define genptr_t or such as sockptr_t. But we'll need to copy the
> > > > bunch of helper functions, too...
> > >
> > > I would predict that if the type becomes more widely used that'll happen
> > > eventually and the longer it's left the more work it'll be.
> >
> > That's true. The question is how more widely it'll be used, then.
> >
> > Is something like below what you had in mind, too?
>
> I agree with your proposal (uniptr_t also works for me), but see below.
>
> ...
>
> > +#include <linux/slab.h>
> > +#include <linux/uaccess.h>
>
> But let make the list of the headers right this time.
>
> It seems to me that
>
> err.h
> minmax.h // maybe not, see a remark at the bottom
> string.h
> types.h
>
> are missing.
OK, makes sense to add them.
>
> More below.
>
> ...
>
> > + void *p = kmalloc_track_caller(len, GFP_USER | __GFP_NOWARN);
> > +
> > + if (!p)
> > + return ERR_PTR(-ENOMEM);
>
> This can use cleanup.h.
Hm, I don't think it can be replaced with that.
There may be more use of cleanup.h, but it's no direct alternative for
kmalloc_track_caller()...
> > + if (copy_from_uniptr(p, src, len)) {
> > + kfree(p);
> > + return ERR_PTR(-EFAULT);
> > + }
> > + return p;
> > +}
> > +
> > +static inline void *memdup_uniptr_nul(uniptr_t src, size_t len)
> > +{
> > + char *p = kmalloc_track_caller(len + 1, GFP_KERNEL);
>
> Ditto.
>
> > + if (!p)
> > + return ERR_PTR(-ENOMEM);
> > + if (copy_from_uniptr(p, src, len)) {
> > + kfree(p);
> > + return ERR_PTR(-EFAULT);
> > + }
> > + p[len] = '\0';
> > + return p;
> > +}
>
> ...
>
> > +static inline long strncpy_from_uniptr(char *dst, uniptr_t src, size_t count)
> > +{
> > + if (uniptr_is_kernel(src)) {
> > + size_t len = min(strnlen(src.kernel, count - 1) + 1, count);
>
> I didn't get why do we need min()? To check the count == 0 case?
>
> Wouldn't
>
> size_t len;
>
> len = strnlen(src.kernel, count);
> if (len == 0)
> return 0;
>
> /* Copy a trailing NUL if found */
> if (len < count)
> len++;
>
> be a good equivalent?
A good question. I rather wonder why it can't be simple strncpy().
> > + memcpy(dst, src.kernel, len);
> > + return len;
> > + }
> > + return strncpy_from_user(dst, src.user, count);
> > +}
>
> ...
>
> > +static inline int check_zeroed_uniptr(uniptr_t src, size_t offset, size_t size)
> > +{
> > + if (!uniptr_is_kernel(src))
>
> Why not to align all the functions to use same conditional (either always
> positive or negative)?
A different person, a different taste :) But it's trivial to fix.
> > + return check_zeroed_user(src.user + offset, size);
> > + return memchr_inv(src.kernel + offset, 0, size) == NULL;
> > +}
>
> ...
>
> Taking all remarks into account I would rather go with sockptr.h being
> untouched for now, just a big
>
> /* DO NOT USE, it's obsolete, use uniptr.h instead! */
>
> to be added.
Possibly that's a safer choice. But the biggest question is whether
we want a generic type or not. Let's try to ask it first.
Interestingly, this file doesn't belong to any subsystem in
MAINTAINERS, so I'm not sure who to be Cc'ed. Chirstoph as the
original author and net dev, maybe.
thanks,
Takashi
next prev parent reply other threads:[~2023-08-07 15:23 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-31 15:46 [PATCH 00/24] ALSA: Generic PCM copy ops using sockptr_t Takashi Iwai
2023-07-31 15:46 ` [PATCH 01/24] ALSA: pcm: Add copy ops with universal sockptr_t Takashi Iwai
2023-07-31 15:46 ` [PATCH 02/24] ALSA: core: Add memory copy helpers between sockptr and iomem Takashi Iwai
2023-07-31 15:46 ` [PATCH 03/24] ALSA: dummy: Convert to generic PCM copy ops Takashi Iwai
2023-07-31 15:46 ` [PATCH 04/24] ALSA: gus: " Takashi Iwai
2023-07-31 15:46 ` [PATCH 05/24] ALSA: emu8000: " Takashi Iwai
2023-07-31 15:47 ` [PATCH 06/24] ALSA: es1938: " Takashi Iwai
2023-07-31 15:47 ` [PATCH 07/24] ALSA: korg1212: " Takashi Iwai
2023-07-31 15:47 ` [PATCH 08/24] ALSA: nm256: " Takashi Iwai
2023-07-31 15:47 ` [PATCH 09/24] ALSA: rme32: " Takashi Iwai
2023-07-31 15:47 ` [PATCH 10/24] ALSA: rme96: " Takashi Iwai
2023-07-31 15:47 ` [PATCH 11/24] ALSA: hdsp: " Takashi Iwai
2023-07-31 15:47 ` [PATCH 12/24] ALSA: rme9652: " Takashi Iwai
2023-07-31 15:47 ` [PATCH 13/24] ALSA: sh: " Takashi Iwai
2023-07-31 15:47 ` [PATCH 14/24] ALSA: xen: " Takashi Iwai
2023-07-31 15:47 ` [PATCH 15/24] ALSA: pcmtest: Update comment about " Takashi Iwai
2023-07-31 15:47 ` [PATCH 16/24] media: solo6x10: Convert to generic " Takashi Iwai
2023-07-31 15:47 ` [PATCH 17/24] ASoC: component: Add " Takashi Iwai
2023-07-31 15:47 ` [PATCH 18/24] ASoC: mediatek: Convert to " Takashi Iwai
2023-07-31 15:47 ` [PATCH 19/24] ASoC: qcom: " Takashi Iwai
2023-07-31 15:47 ` [PATCH 20/24] ASoC: dmaengine: " Takashi Iwai
2023-07-31 15:47 ` [PATCH 21/24] ASoC: dmaengine: Use sockptr_t for process callback, too Takashi Iwai
2023-07-31 15:47 ` [PATCH 22/24] ALSA: doc: Update description for the new PCM copy ops Takashi Iwai
2023-07-31 15:47 ` [PATCH 23/24] ASoC: pcm: Drop obsoleted PCM copy_user ops Takashi Iwai
2023-07-31 15:47 ` [PATCH 24/24] ALSA: pcm: Drop obsoleted PCM copy_user and copy_kernel ops Takashi Iwai
2023-07-31 17:20 ` [PATCH 00/24] ALSA: Generic PCM copy ops using sockptr_t Mark Brown
2023-07-31 19:30 ` Takashi Iwai
2023-07-31 19:40 ` Mark Brown
2023-08-01 12:54 ` Takashi Iwai
2023-08-01 14:04 ` Mark Brown
2023-08-01 17:51 ` Andy Shevchenko
2023-08-07 15:22 ` Takashi Iwai [this message]
2023-08-07 16:00 ` Andy Shevchenko
2023-08-01 13:57 ` Andy Shevchenko
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=87pm3yj2s5.wl-tiwai@suse.de \
--to=tiwai@suse.de \
--cc=alsa-devel@alsa-project.org \
--cc=andrey_utkin@fastmail.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=anton@corp.bluecherry.net \
--cc=arnaud.pouliquen@foss.st.com \
--cc=bgoswami@quicinc.com \
--cc=broonie@kernel.org \
--cc=claudiu.beznea@microchip.com \
--cc=ismael@iodev.co.uk \
--cc=lars@metafoo.de \
--cc=linux-media@vger.kernel.org \
--cc=maintainers@bluecherrydvr.com \
--cc=mchehab@kernel.org \
--cc=oleksandr_andrushchenko@epam.com \
--cc=olivier.moysan@foss.st.com \
--cc=srinivas.kandagatla@linaro.org \
--cc=xen-devel@lists.xenproject.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.