All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Kees Cook <keescook@chromium.org>
Cc: "Gustavo A . R . Silva" <gustavoars@kernel.org>,
	"Keith Packard" <keithp@keithp.com>,
	"Francis Laniel" <laniel_francis@privacyrequired.com>,
	"Daniel Axtens" <dja@axtens.net>,
	"Dan Williams" <dan.j.williams@intel.com>,
	"Vincenzo Frascino" <vincenzo.frascino@arm.com>,
	"Guenter Roeck" <linux@roeck-us.net>,
	"Daniel Vetter" <daniel.vetter@ffwll.ch>,
	"Tadeusz Struk" <tadeusz.struk@linaro.org>,
	"Alexei Starovoitov" <ast@kernel.org>,
	alsa-devel@alsa-project.org, "Al Viro" <viro@zeniv.linux.org.uk>,
	"Andrew Gabbasov" <andrew_gabbasov@mentor.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Andy Gross" <agross@kernel.org>,
	"Andy Lavr" <andy.lavr@gmail.com>,
	"Arend van Spriel" <aspriel@gmail.com>,
	"Baowen Zheng" <baowen.zheng@corigine.com>,
	"Bjorn Andersson" <bjorn.andersson@linaro.org>,
	"Boris Ostrovsky" <boris.ostrovsky@oracle.com>,
	"Bradley Grove" <linuxdrivers@attotech.com>,
	brcm80211-dev-list.pdl@broadcom.com,
	"Christian Brauner" <brauner@kernel.org>,
	"Christian Göttsche" <cgzones@googlemail.com>,
	"Christian Lamparter" <chunkeey@googlemail.com>,
	"Chris Zankel" <chris@zankel.net>,
	"Cong Wang" <cong.wang@bytedance.com>,
	"David Gow" <davidgow@google.com>,
	"David Howells" <dhowells@redhat.com>,
	"David S. Miller" <davem@davemloft.net>,
	"Dennis Dalessandro" <dennis.dalessandro@cornelisnetworks.com>,
	devicetree@vger.kernel.org, "Dexuan Cui" <decui@microsoft.com>,
	"Dmitry Kasatkin" <dmitry.kasatkin@gmail.com>,
	"Eli Cohen" <elic@nvidia.com>,
	"Eric Dumazet" <edumazet@google.com>,
	"Eric Paris" <eparis@parisplace.org>,
	"Eugeniu Rosca" <erosca@de.adit-jv.com>,
	"Felipe Balbi" <balbi@kernel.org>,
	"Frank Rowand" <frowand.list@gmail.com>,
	"Franky Lin" <franky.lin@broadcom.com>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Gregory Greenman" <gregory.greenman@intel.com>,
	"Haiyang Zhang" <haiyangz@microsoft.com>,
	"Hante Meuleman" <hante.meuleman@broadcom.com>,
	"Herbert Xu" <herbert@gondor.apana.org.au>,
	"Hulk Robot" <hulkci@huawei.com>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"James E.J. Bottomley" <jejb@linux.ibm.com>,
	"James Morris" <jmorris@namei.org>,
	"Jarkko Sakkinen" <jarkko@kernel.org>,
	"Jaroslav Kysela" <perex@perex.cz>,
	"Jason Gunthorpe" <jgg@ziepe.ca>, "Jens Axboe" <axboe@kernel.dk>,
	"Johan Hedberg" <johan.hedberg@gmail.com>,
	"John Keeping" <john@metanate.com>,
	"Juergen Gross" <jgross@suse.com>,
	"Kalle Valo" <kvalo@kernel.org>,
	keyrings@vger.kernel.org, kunit-dev@googlegroups.com,
	"Kuniyuki Iwashima" <kuniyu@amazon.co.jp>,
	"K. Y. Srinivasan" <kys@microsoft.com>,
	"Lars-Peter Clausen" <lars@metafoo.de>,
	"Lee Jones" <lee.jones@linaro.org>,
	"Leon Romanovsky" <leon@kernel.org>,
	"Liam Girdwood" <lgirdwood@gmail.com>,
	linux1394-devel@lists.sourceforge.net,
	linux-afs@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org,
	linux-arm-msm@vger.kernel.org, linux-bluetooth@vger.kernel.org,
	linux-hardening@vger.kernel.org, linux-hyperv@vger.kernel.org,
	linux-integrity@vger.kernel.org, linux-rdma@vger.kernel.org,
	linux-scsi@vger.kernel.org,
	linux-security-module@vger.kernel.org, linux-usb@vger.kernel.org,
	linux-wireless@vger.kernel.org, linux-xtensa@linux-xtensa.org,
	llvm@lists.linux.dev, "Loic Poulain" <loic.poulain@linaro.org>,
	"Louis Peens" <louis.peens@corigine.com>,
	"Luca Coelho" <luciano.coelho@intel.com>,
	"Luiz Augusto von Dentz" <luiz.dentz@gmail.com>,
	"Marc Dionne" <marc.dionne@auristor.com>,
	"Marcel Holtmann" <marcel@holtmann.org>,
	"Mark Brown" <broonie@kernel.org>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	"Max Filippov" <jcmvbkbc@gmail.com>,
	"Mimi Zohar" <zohar@linux.ibm.com>,
	"Muchun Song" <songmuchun@bytedance.com>,
	"Nathan Chancellor" <nathan@kernel.org>,
	netdev@vger.kernel.org,
	"Nick Desaulniers" <ndesaulniers@google.com>,
	"Nuno Sá" <nuno.sa@analog.com>, "Paolo Abeni" <pabeni@redhat.com>,
	"Paul Moore" <paul@paul-moore.com>,
	"Rich Felker" <dalias@aerifal.cx>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Russell King" <linux@armlinux.org.uk>,
	selinux@vger.kernel.org, "Serge E. Hallyn" <serge@hallyn.com>,
	SHA-cyfmac-dev-list@infineon.com,
	"Simon Horman" <simon.horman@corigine.com>,
	"Stefano Stabellini" <sstabellini@kernel.org>,
	"Stefan Richter" <stefanr@s5r6.in-berlin.de>,
	"Steffen Klassert" <steffen.klassert@secunet.com>,
	"Stephen Hemminger" <sthemmin@microsoft.com>,
	"Stephen Smalley" <stephen.smalley.work@gmail.com>,
	"Takashi Iwai" <tiwai@suse.com>, "Tom Rix" <trix@redhat.com>,
	"Udipto Goswami" <quic_ugoswami@quicinc.com>,
	wcn36xx@lists.infradead.org, "Wei Liu" <wei.liu@kernel.org>,
	xen-devel@lists.xenproject.org,
	"Xiu Jianfeng" <xiujianfeng@huawei.com>,
	"Yang Yingliang" <yangyingliang@huawei.com>
Subject: Re: [PATCH 02/32] Introduce flexible array struct memcpy() helpers
Date: Thu, 05 May 2022 15:16:19 +0200	[thread overview]
Message-ID: <970a674df04271b5fd1971b495c6b11a996c20c2.camel@sipsolutions.net> (raw)
In-Reply-To: <202205040819.DEA70BD@keescook>

On Wed, 2022-05-04 at 08:38 -0700, Kees Cook wrote:
> 
> It seemed like requiring a structure be rearranged to take advantage of
> the "automatic layout introspection" wasn't very friendly. On the other
> hand, looking at the examples, most of them are already neighboring
> members. Hmmm.

A lot of them are, and many could be, though not all.

> > or so? The long and duplicated DECLARE_FLEX_ARRAY_ELEMENTS_COUNT and
> > DECLARE_FLEX_ARRAY_ELEMENTS seems a bit tedious to me, at least in cases
> > where the struct layout is not the most important thing (or it's already
> > at the end anyway).
> 
> The names aren't great, but I wanted to distinguish "elements" as the
> array not the count. Yay naming.

:-)

> However, perhaps the solution is to have _both_. i.e using
> BOUNDED_FLEX_ARRAY(count_type, count_name, array_type, array_name) for
> the "neighboring" case, and the DECLARE...{ELEMENTS,COUNT} for the
> "split" case.

Seems reasonable to me.

> And DECLARE_FLEX_ARRAY_ELEMENTS could actually be expanded to include
> the count_name too, so both methods could be "forward portable" to a
> future where C grew the syntax for bounded flex arrays.

I guess I don't see that happening :)

> > This seems rather awkward, having to set it to NULL, then checking rc
> > (and possibly needing a separate variable for it), etc.
> 
> I think the errno return is completely required. I had an earlier version
> of this that was much more like a drop-in replacement for memcpy that
> would just truncate or panic, 
> 

Oh, I didn't mean to imply it should truncate or panic or such - but if
it returns a pointer it can still be an ERR_PTR() or NULL instead of
having this separate indication, which even often confuses static type
checkers since they don't always see the "errno == 0 <=> ptr != NULL"
relation.

So not saying you shouldn't have any error return - clearly you need
that, just saying that I'm not sure that having the two separated is
great.


> Requiring instance to be NULL is debatable, but I feel pretty strongly
> about it because it does handle a class of mistakes (resource leaks),
> and it's not much of a burden to require a known-good starting state.

Yeah, dunno, I guess I'm slightly more on the side of not requiring it,
since we don't do the same for kmalloc() etc. and probably really
wouldn't want to add kmalloc_s() that does it ;-)

I mean, you _could_ go there:

int kmalloc_s(void **ptr, size_t size, gfp_t gfp)
{
  void *ret;

  if (*ptr)
    return -EINVAL;

  ret = kmalloc(size, gfp);
  if (!ret)
    return -ENOMEM;
  *ptr = ret;
  return 0;  
}

right? But we don't really do that, and I'm not sure it'd be a win if
done over the whole code base.

So I'm not really sure why this aspect here should need to be different,
except of course that you already need the input argument for the magic.

But we could still have (this prototype is theoretical, of course, it
cannot be implemented in C):

void *mem_to_flex_dup(void *ptr, const void *data, size_t elements,
                      gfp_t gfp);


which isn't really that much better though.

And btw, while I was writing it down I was looking to see if it should
be "size_t elements" or "size_t len" (like memcpy), it took me some time
to figure out, and I was looking at the examples:

 1) most of them actually use __u8 or some variant thereof, so you
    could probably add an even simpler macro like
       BOUNDED_FLEX_DATA(int, bytes, data)
    which has the u8 type internally.

 2) Unless I'm confusing myself, you got the firewire change wrong,
    because __mem_to_flex_dup takes the "elements_count", but the
    memcpy() there wasn't multiplied by the sizeof(element)? Or maybe
    the fact that it was declared as __u32 header[0] is wrong, and it
    should be __u8, but it's all very confusing, and I'm really not
    sure about this at all.



One "perhaps you'll laugh me out of the room" suggestion might be to
actually be able to initialize the whole thing too?


mydata = flex_struct_alloc(mydata, GFP_KERNEL,
                           variable_data, variable_len,
                           .member = 1,
                           .another = 2);

(the ordering can't really be otherwise since you have to use
__VA_ARGS__).

That might reduce some more code too, though I guess it's quite some
additional magic ... :)


> > but still, honestly, I don't like it. As APIs go, it feels a bit
> > cumbersome and awkward to use, and you really need everyone to use this,
> > and not say "uh what, I'll memcpy() instead".
> 
> Sure, and I have tried to get it down as small as possible. The earlier
> "just put all the member names in every call" version was horrid. :P

:-D

> I
> realize it's more work to check errno, but the memcpy() API we've all
> been trained to use is just plain dangerous. I don't think it's
> unreasonable to ask people to retrain themselves to avoid it. All that
> said, yes, I want it to be as friendly as possible.
> 
> > Maybe there should also be a realloc() version of it?
> 
> Sure! Seems reasonable. I'd like to see the code pattern for this
> though. Do you have any examples?

I was going to point to struct cfg80211_bss_ies, but I realize now
they're RCU-managed, so we never resize them anyway ... So maybe it's
less common than I thought it might be.

I suppose you know better since you converted a lot of stuff already :-)

johannes

  parent reply	other threads:[~2022-05-05 13:17 UTC|newest]

Thread overview: 71+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-04  1:44 [PATCH 00/32] " Kees Cook
2022-05-04  1:44 ` [PATCH 01/32] netlink: Avoid memcpy() across flexible array boundary Kees Cook
2022-05-04  3:12   ` Introduce flexible array struct memcpy() helpers bluez.test.bot
2022-05-04  3:31   ` [PATCH 01/32] netlink: Avoid memcpy() across flexible array boundary Gustavo A. R. Silva
2022-05-04  3:37     ` Kees Cook
2022-05-04  1:44 ` [PATCH 02/32] Introduce flexible array struct memcpy() helpers Kees Cook
2022-05-04  7:25   ` Johannes Berg
2022-05-04 15:38     ` Kees Cook
2022-05-04 16:08       ` David Laight
2022-05-05 13:16       ` Johannes Berg [this message]
2022-05-05 15:16         ` Keith Packard
2022-05-05 19:32           ` Kees Cook
2022-05-05 20:08             ` Keith Packard
2022-05-05 20:12               ` Johannes Berg
2022-05-06 11:15                 ` David Laight
2022-05-06 11:15                   ` David Laight
2022-05-05 19:27         ` Kees Cook
2022-05-04  1:44 ` [PATCH 03/32] flex_array: Add Kunit tests Kees Cook
2022-05-04  3:00   ` David Gow
2022-05-04 19:43     ` Kees Cook
2022-05-04 19:58   ` Daniel Latypov
2022-05-04  1:44 ` [PATCH 04/32] fortify: Add run-time WARN for cross-field memcpy() Kees Cook
2022-05-04  1:44 ` [PATCH 05/32] brcmfmac: Use mem_to_flex_dup() with struct brcmf_fweh_queue_item Kees Cook
2022-05-16 12:49   ` Arend van Spriel
2022-05-17  3:57     ` Kees Cook
2022-05-04  1:44 ` [PATCH 06/32] iwlwifi: calib: Prepare to use mem_to_flex_dup() Kees Cook
2022-05-04  1:44 ` [PATCH 07/32] iwlwifi: calib: Use mem_to_flex_dup() with struct iwl_calib_result Kees Cook
2022-05-04  1:44 ` [PATCH 08/32] iwlwifi: mvm: Use mem_to_flex_dup() with struct ieee80211_key_conf Kees Cook
2022-05-04  1:44 ` [PATCH 09/32] p54: Use mem_to_flex_dup() with struct p54_cal_database Kees Cook
2022-05-04  1:44 ` [PATCH 10/32] wcn36xx: Use mem_to_flex_dup() with struct wcn36xx_hal_ind_msg Kees Cook
2022-05-04  5:42   ` Kalle Valo
2022-05-04 15:08     ` Kees Cook
2022-05-04  1:44 ` [PATCH 11/32] nl80211: Use mem_to_flex_dup() with struct cfg80211_cqm_config Kees Cook
2022-05-04  1:44 ` [PATCH 12/32] cfg80211: Use mem_to_flex_dup() with struct cfg80211_bss_ies Kees Cook
2022-05-04  7:28   ` Johannes Berg
2022-05-04 15:13     ` Kees Cook
2022-05-04  1:44 ` [PATCH 13/32] mac80211: Use mem_to_flex_dup() with several structs Kees Cook
2022-05-04  1:44 ` [PATCH 14/32] af_unix: Use mem_to_flex_dup() with struct unix_address Kees Cook
2022-05-04  1:44 ` [PATCH 15/32] 802/garp: Use mem_to_flex_dup() with struct garp_attr Kees Cook
2022-05-04  1:44 ` [PATCH 16/32] 802/mrp: Use mem_to_flex_dup() with struct mrp_attr Kees Cook
2022-05-04  1:44 ` [PATCH 17/32] net/flow_offload: Use mem_to_flex_dup() with struct flow_action_cookie Kees Cook
2022-05-04  1:44 ` [PATCH 18/32] firewire: Use __mem_to_flex_dup() with struct iso_interrupt_event Kees Cook
2022-05-04  1:44 ` [PATCH 19/32] afs: Use mem_to_flex_dup() with struct afs_acl Kees Cook
2022-05-04  1:44 ` [PATCH 20/32] ASoC: sigmadsp: Use mem_to_flex_dup() with struct sigmadsp_data Kees Cook
2022-05-04 15:17   ` Mark Brown
2022-05-04  1:44 ` [PATCH 21/32] soc: qcom: apr: Use mem_to_flex_dup() with struct apr_rx_buf Kees Cook
2022-05-04  1:44 ` [PATCH 22/32] atags_proc: Use mem_to_flex_dup() with struct buffer Kees Cook
2022-05-04  1:44 ` [PATCH 23/32] Bluetooth: Use mem_to_flex_dup() with struct hci_op_configure_data_path Kees Cook
2022-05-04  1:44 ` [PATCH 24/32] IB/hfi1: Use mem_to_flex_dup() for struct tid_rb_node Kees Cook
2022-05-04  1:44 ` [PATCH 25/32] Drivers: hv: utils: Use mem_to_flex_dup() with struct cn_msg Kees Cook
2022-05-04  1:44 ` [PATCH 26/32] ima: Use mem_to_flex_dup() with struct modsig Kees Cook
2022-05-04  1:44 ` [PATCH 27/32] KEYS: Use mem_to_flex_dup() with struct user_key_payload Kees Cook
2022-05-04  1:44 ` [PATCH 28/32] selinux: Use mem_to_flex_dup() with xfrm and sidtab Kees Cook
2022-05-04 22:57   ` Paul Moore
2022-05-04 23:43     ` Gustavo A. R. Silva
2022-05-05  3:14       ` Paul Moore
2022-05-05 18:39         ` Kees Cook
2022-05-05 23:16           ` Paul Moore
2022-05-06  1:08             ` Gustavo A. R. Silva
2022-05-04  1:44 ` [PATCH 29/32] xtensa: Use mem_to_flex_dup() with struct property Kees Cook
2022-05-04 18:09   ` Rob Herring
2022-05-04 18:09     ` Rob Herring
2022-05-04  1:44 ` [PATCH 30/32] usb: gadget: f_fs: Use mem_to_flex_dup() with struct ffs_buffer Kees Cook
2022-05-04  1:44 ` [PATCH 31/32] xenbus: Use mem_to_flex_dup() with struct read_buffer Kees Cook
2022-05-04  1:44 ` [PATCH 32/32] esas2r: Use __mem_to_flex() with struct atto_ioctl Kees Cook
2022-05-12 21:41 ` [PATCH 19/32] afs: Use mem_to_flex_dup() with struct afs_acl David Howells
2022-05-12 21:41   ` David Howells
2022-05-13 15:44   ` Kees Cook
2022-05-13 15:44     ` Kees Cook
2022-05-12 21:47 ` [PATCH 00/32] Introduce flexible array struct memcpy() helpers David Howells
2022-05-12 21:47   ` David Howells

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=970a674df04271b5fd1971b495c6b11a996c20c2.camel@sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=SHA-cyfmac-dev-list@infineon.com \
    --cc=agross@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=andrew_gabbasov@mentor.com \
    --cc=andy.lavr@gmail.com \
    --cc=aspriel@gmail.com \
    --cc=ast@kernel.org \
    --cc=axboe@kernel.dk \
    --cc=balbi@kernel.org \
    --cc=baowen.zheng@corigine.com \
    --cc=bjorn.andersson@linaro.org \
    --cc=boris.ostrovsky@oracle.com \
    --cc=brauner@kernel.org \
    --cc=brcm80211-dev-list.pdl@broadcom.com \
    --cc=broonie@kernel.org \
    --cc=cgzones@googlemail.com \
    --cc=chris@zankel.net \
    --cc=chunkeey@googlemail.com \
    --cc=cong.wang@bytedance.com \
    --cc=dalias@aerifal.cx \
    --cc=dan.j.williams@intel.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=davem@davemloft.net \
    --cc=davidgow@google.com \
    --cc=decui@microsoft.com \
    --cc=dennis.dalessandro@cornelisnetworks.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dhowells@redhat.com \
    --cc=dja@axtens.net \
    --cc=dmitry.kasatkin@gmail.com \
    --cc=edumazet@google.com \
    --cc=elic@nvidia.com \
    --cc=eparis@parisplace.org \
    --cc=erosca@de.adit-jv.com \
    --cc=franky.lin@broadcom.com \
    --cc=frowand.list@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=gregory.greenman@intel.com \
    --cc=gustavoars@kernel.org \
    --cc=haiyangz@microsoft.com \
    --cc=hante.meuleman@broadcom.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=hulkci@huawei.com \
    --cc=jarkko@kernel.org \
    --cc=jcmvbkbc@gmail.com \
    --cc=jejb@linux.ibm.com \
    --cc=jgg@ziepe.ca \
    --cc=jgross@suse.com \
    --cc=jmorris@namei.org \
    --cc=johan.hedberg@gmail.com \
    --cc=john@metanate.com \
    --cc=keescook@chromium.org \
    --cc=keithp@keithp.com \
    --cc=keyrings@vger.kernel.org \
    --cc=kuba@kernel.org \
    --cc=kunit-dev@googlegroups.com \
    --cc=kuniyu@amazon.co.jp \
    --cc=kvalo@kernel.org \
    --cc=kys@microsoft.com \
    --cc=laniel_francis@privacyrequired.com \
    --cc=lars@metafoo.de \
    --cc=lee.jones@linaro.org \
    --cc=leon@kernel.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-afs@lists.infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-hyperv@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linux-xtensa@linux-xtensa.org \
    --cc=linux1394-devel@lists.sourceforge.net \
    --cc=linux@armlinux.org.uk \
    --cc=linux@roeck-us.net \
    --cc=linuxdrivers@attotech.com \
    --cc=llvm@lists.linux.dev \
    --cc=loic.poulain@linaro.org \
    --cc=louis.peens@corigine.com \
    --cc=luciano.coelho@intel.com \
    --cc=luiz.dentz@gmail.com \
    --cc=marc.dionne@auristor.com \
    --cc=marcel@holtmann.org \
    --cc=martin.petersen@oracle.com \
    --cc=nathan@kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=netdev@vger.kernel.org \
    --cc=nuno.sa@analog.com \
    --cc=pabeni@redhat.com \
    --cc=paul@paul-moore.com \
    --cc=perex@perex.cz \
    --cc=quic_ugoswami@quicinc.com \
    --cc=robh+dt@kernel.org \
    --cc=selinux@vger.kernel.org \
    --cc=serge@hallyn.com \
    --cc=simon.horman@corigine.com \
    --cc=songmuchun@bytedance.com \
    --cc=sstabellini@kernel.org \
    --cc=stefanr@s5r6.in-berlin.de \
    --cc=steffen.klassert@secunet.com \
    --cc=stephen.smalley.work@gmail.com \
    --cc=sthemmin@microsoft.com \
    --cc=tadeusz.struk@linaro.org \
    --cc=tiwai@suse.com \
    --cc=trix@redhat.com \
    --cc=vincenzo.frascino@arm.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=wcn36xx@lists.infradead.org \
    --cc=wei.liu@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    --cc=xiujianfeng@huawei.com \
    --cc=yangyingliang@huawei.com \
    --cc=zohar@linux.ibm.com \
    --subject='Re: [PATCH 02/32] Introduce flexible array struct memcpy() helpers' \
    /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

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.