From: "Michael S. Tsirkin" <mst@redhat.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: "Eugenio Pérez" <eperezma@redhat.com>,
"Arnd Bergmann" <arnd@kernel.org>,
"Jason Wang" <jasowang@redhat.com>,
"Xie Yongji" <xieyongji@bytedance.com>,
"Xuan Zhuo" <xuanzhuo@linux.alibaba.com>,
"Anders Roxell" <anders.roxell@linaro.org>,
"Marco Crivellari" <marco.crivellari@suse.com>,
virtualization@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] vduse: fix compat handling for VDUSE_IOTLB_GET_FD/VDUSE_VQ_GET_INFO
Date: Tue, 3 Feb 2026 05:35:20 -0500 [thread overview]
Message-ID: <20260203053142-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <34d3ce77-84b2-476c-a678-e092831041ae@app.fastmail.com>
On Mon, Feb 02, 2026 at 11:54:17PM +0100, Arnd Bergmann wrote:
> On Mon, Feb 2, 2026, at 17:45, Michael S. Tsirkin wrote:
> > On Mon, Feb 02, 2026 at 12:59:03PM +0100, Arnd Bergmann wrote:
> >
> > I think .compat_ioctl would be cleaner frankly. Just look at
> > all the ifdefery. And who knows what broken-ness userspace
> > comes up with with this approach. Better use the standard approach.
>
> Sent now.
>
> I'm not sure it's much better because there is quite a bit of
> code duplication, and reducing that would be a larger rework.
yes but on the flip side, we can put it all inside ifdef CONFIG_COMPAT
(which this code did not do, but should IMHO).
> It may be best to hold off on patch 2 for the coming merge window
> since the compat ioctl code has apparently always been broken for
> x86 here.
And it needs testing.
> I hope we can at least get patch 1/2 merged along with the
> new code though, otherwise it would get a lot harder to sort
> it out properly, with the v2 struct members overlapping the
> old padding fields.
>
> Arnd
Along with it or no, surely before the release.
Given 32 on 64 with this apparently has been broken forever,
I will merge this just based on even you did not bother testing compat, I am
inclined to say I am merging this but not rebasing because
of this.
Oh and we got lucky this didn't leak kernel stack info.
Eugenio, note for the future: please help make sure UAPI
structs do not have hidden padding.
--
MST
next prev parent reply other threads:[~2026-02-03 10:35 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-02 9:59 [PATCH 1/2] vduse: avoid adding implicit padding Arnd Bergmann
2026-02-02 9:59 ` [PATCH 2/2] vduse: fix compat handling for VDUSE_IOTLB_GET_FD/VDUSE_VQ_GET_INFO Arnd Bergmann
2026-02-02 11:34 ` Eugenio Perez Martin
2026-02-02 11:59 ` Arnd Bergmann
2026-02-02 16:45 ` Michael S. Tsirkin
2026-02-02 22:54 ` Arnd Bergmann
2026-02-03 10:35 ` Michael S. Tsirkin [this message]
2026-02-03 14:13 ` Eugenio Perez Martin
2026-02-03 14:41 ` Arnd Bergmann
2026-02-03 15:03 ` Eugenio Perez Martin
2026-02-02 11:28 ` [PATCH 1/2] vduse: avoid adding implicit padding Eugenio Perez Martin
2026-02-02 11:50 ` Eugenio Perez Martin
2026-02-02 12:06 ` Arnd Bergmann
2026-02-03 7:00 ` Eugenio Perez Martin
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=20260203053142-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=anders.roxell@linaro.org \
--cc=arnd@arndb.de \
--cc=arnd@kernel.org \
--cc=eperezma@redhat.com \
--cc=jasowang@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=marco.crivellari@suse.com \
--cc=virtualization@lists.linux.dev \
--cc=xieyongji@bytedance.com \
--cc=xuanzhuo@linux.alibaba.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.