From: David Miller <davem@davemloft.net>
To: David.Laight@ACULAB.COM
Cc: cernekee@chromium.org, steffen.klassert@secunet.com,
herbert@gondor.apana.org.au, paul@paul-moore.com,
sds@tycho.nsa.gov, eparis@parisplace.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
selinux@tycho.nsa.gov, fw@strlen.de, fan.du@windriver.com,
dianders@chromium.org, dtor@chromium.org
Subject: Re: [PATCH 0/4] Make xfrm usable by 32-bit programs
Date: Mon, 23 Jan 2017 11:57:22 -0500 (EST) [thread overview]
Message-ID: <20170123.115722.2044116177906799668.davem@davemloft.net> (raw)
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6DB026BC58@AcuExch.aculab.com>
From: David Laight <David.Laight@ACULAB.COM>
Date: Mon, 23 Jan 2017 16:45:39 +0000
> Provided you've got the length of the user's buffer the compat code
> ought to be trivial (if tedious).
Wireless guys had to deal with a similar problem with nl80211.
You don't know who is going to get the message when you build it,
because you can't possibly know what applications are listening
on the netlink sockets for notifications and even if you did
that set changes dynamically and could be different by the time
the notification is delivered.
The long and short of it is that you must always generate both the
native 64-bit as well as the 32-bit compat version of every message,
then at delivery time you enqueue the appropriate one to each
receiving socket.
This is how nl80211 solved the problem, and it's what XFRM should do
as well.
prev parent reply other threads:[~2017-01-23 16:57 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-21 0:05 [PATCH 0/4] Make xfrm usable by 32-bit programs Kevin Cernekee
2017-01-21 0:05 ` [PATCH 1/4] xfrm: Constify xfrm_user arguments and xfrm_mgr callback APIs Kevin Cernekee
2017-01-21 0:05 ` [PATCH 2/4] xfrm_user: Allow common functions to be called from another file Kevin Cernekee
2017-01-21 0:05 ` [PATCH 3/4] xfrm_user: Initial commit of xfrm_user_legacy.c Kevin Cernekee
2017-01-21 0:05 ` [PATCH 4/4] xfrm_user: Add new 32/64-agnostic netlink messages Kevin Cernekee
2017-01-21 8:21 ` kbuild test robot
2017-01-23 9:35 ` [PATCH 0/4] Make xfrm usable by 32-bit programs Steffen Klassert
2017-01-23 15:47 ` David Miller
2017-01-23 16:45 ` David Laight
2017-01-23 16:57 ` David Miller [this message]
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=20170123.115722.2044116177906799668.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=David.Laight@ACULAB.COM \
--cc=cernekee@chromium.org \
--cc=dianders@chromium.org \
--cc=dtor@chromium.org \
--cc=eparis@parisplace.org \
--cc=fan.du@windriver.com \
--cc=fw@strlen.de \
--cc=herbert@gondor.apana.org.au \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=paul@paul-moore.com \
--cc=sds@tycho.nsa.gov \
--cc=selinux@tycho.nsa.gov \
--cc=steffen.klassert@secunet.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;
as well as URLs for NNTP newsgroup(s).