From: Pete Zaitcev <zaitcev@redhat.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: "Diego Elio Pettenò" <flameeyes@flameeyes.com>,
linux-usb@vger.kernel.org, "Paolo Abeni" <pabeni@redhat.com>,
"Kris Katterjohn" <katterjohn@gmail.com>,
zaitcev@redhat.com
Subject: Re: [PATCH v2] usbmon: expose the usbmon structures and constants as an UAPI header.
Date: Mon, 6 Jul 2020 11:15:09 -0500 [thread overview]
Message-ID: <20200706111509.5958d95b@suzdal.zaitcev.lan> (raw)
In-Reply-To: <20200706124943.GA2270456@kroah.com>
On Mon, 6 Jul 2020 14:49:43 +0200
Greg KH <gregkh@linuxfoundation.org> wrote:
> > +struct mon_bin_get {
> > + struct mon_bin_hdr __user *hdr; /* Can be 48 bytes or 64. */
> > + void __user *data;
> > + size_t alloc; /* Length of data (can be zero) */
>
> is size_t a value we can pass across user/kernel boundry? Are you sure
> this isn't __kernel_size_t?
Sorry, it was my fault letting that one through.
Since currently the definitions are separate, userland uses their size_t,
and kernel uses in-kernel size_t. We have a set of MON_IOCX_GET and
MON_IOCX_GET32 with the same base number 6, but using mon_bin_get32,
so the resulting ioctl number magically matched what 32- and 64-bit
applications used. We don't even need an adaptation layer that
re-encodes the argument structure.
Not sure how to resolve this properly once we attempt to export the
structures. Something for the patch submitter to work out, I suppose.
-- Pere
next prev parent reply other threads:[~2020-07-06 16:15 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-05 15:02 [PATCH] usbmon: expose the usbmon structures and constants as an UAPI header Diego Elio Pettenò
2020-07-06 3:51 ` Pete Zaitcev
2020-07-06 8:32 ` Diego Elio Pettenò
2020-07-06 15:01 ` Pete Zaitcev
2020-07-06 5:46 ` kernel test robot
2020-07-06 5:46 ` kernel test robot
2020-07-06 10:30 ` Greg KH
2020-07-06 12:21 ` Diego Elio Pettenò
2020-07-06 12:15 ` [PATCH v2] " Diego Elio Pettenò
2020-07-06 12:49 ` Greg KH
2020-07-06 13:10 ` Diego Elio Pettenò
2020-07-06 16:15 ` Pete Zaitcev [this message]
2020-07-06 13:10 ` [PATCH v3 1/2] Remove documentation line that adds nothing and sounds condescending Diego Elio Pettenò
2020-07-06 13:10 ` [PATCH v3 2/2] usbmon: expose the usbmon structures and constants as an UAPI header Diego Elio Pettenò
2020-07-06 16:35 ` Greg KH
2020-07-06 16:34 ` [PATCH v3 1/2] Remove documentation line that adds nothing and sounds condescending Greg KH
2020-07-06 22:44 ` [PATCH v4 " Diego Elio Pettenò
2020-07-06 22:44 ` [PATCH v4 2/2] usbmon: expose the usbmon structures and constants as an UAPI header Diego Elio Pettenò
2020-07-09 16:04 ` Greg KH
2020-07-11 13:14 ` kernel test robot
2020-07-11 13:14 ` kernel test robot
2020-07-09 16:03 ` [PATCH v4 1/2] Remove documentation line that adds nothing and sounds condescending Greg KH
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=20200706111509.5958d95b@suzdal.zaitcev.lan \
--to=zaitcev@redhat.com \
--cc=flameeyes@flameeyes.com \
--cc=gregkh@linuxfoundation.org \
--cc=katterjohn@gmail.com \
--cc=linux-usb@vger.kernel.org \
--cc=pabeni@redhat.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 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.