From: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
To: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
Cc: linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Sean Young <sean-hENCXIMQXOg@public.gmane.org>,
linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Daniel Vetter <daniel.vetter-/w4YWyX8dFk@public.gmane.org>,
linux-pci <linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
dri-devel
<dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
Bjorn Andersson
<bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
sparclinux <sparclinux-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Mauro Carvalho Chehab
<mchehab+samsung-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
driverdevel
<devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b@public.gmane.org>,
linux-scsi <linux-scsi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org,
y2038 Mailman List
<y2038-cunTk1MwBs8s++Sfvej+rw@public.gmane.org>,
qat-linux-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
Jason Gunthorpe <jgg-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>,
"open list:HID CORE LAYER"
<linux-input-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Darren Hart <dvhart-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>,
Linux Media Mailing List
<linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
linux-remoteproc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linaro-mm-sig-cunTk1MwBs8s++Sfvej+rw@public.gmane.org,
Al Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>,
Jonathan Cameron <Jonathan.Cameron@h>
Subject: Re: [PATCH v3 12/26] compat_ioctl: move more drivers to compat_ptr_ioctl
Date: Fri, 26 Apr 2019 09:46:13 +0200 [thread overview]
Message-ID: <CAK8P3a3CzKLvpUiVV_k__kkaZ=wg2fqnFEzWYL9qNwBfxMKZ9w@mail.gmail.com> (raw)
In-Reply-To: <5511420228cb38d08a67c0f6a614b7671d7d23d4.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
On Thu, Apr 25, 2019 at 11:25 PM Johannes Berg
<johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> wrote:
> On Thu, 2019-04-25 at 17:55 +0200, Arnd Bergmann wrote:
> > On Thu, Apr 25, 2019 at 5:35 PM Al Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org> wrote:
> > >
> > > On Thu, Apr 25, 2019 at 12:21:53PM -0300, Mauro Carvalho Chehab wrote:
> > >
> > > > If I understand your patch description well, using compat_ptr_ioctl
> > > > only works if the driver is not for s390, right?
> > >
> > > No; s390 is where "oh, just set ->compat_ioctl same as ->unlocked_ioctl
> > > and be done with that; compat_ptr() is a no-op anyway" breaks. IOW,
> > > s390 is the reason for having compat_ptr_ioctl() in the first place;
> > > that thing works on all biarch architectures, as long as all stuff
> > > handled by ->ioctl() takes pointer to arch-independent object as
> > > argument. IOW,
> > > argument ignored => OK
> > > any arithmetical type => no go, compat_ptr() would bugger it
> > > pointer to int => OK
> > > pointer to string => OK
> > > pointer to u64 => OK
> > > pointer to struct {u64 addr; char s[11];} => OK
> >
> > To be extra pedantic, the 'struct {u64 addr; char s[11];} '
> > case is also broken on x86, because sizeof (obj) is smaller
> > on i386, even though the location of the members are
> > the same. i.e. you can copy_from_user() this
>
> Actually, you can't even do that because the struct might sit at the end
> of a page and then you'd erroneously fault in this case.
>
> We had this a while ago with struct ifreq, see commit 98406133dd and its
> parents.
Yes, you are right. Very rare to hit with real-life code, but easily
reproduced by intentionally hitting it and clearly a bug.
As the saying goes
| the difference between "always works" and "almost always works"
| is called data corruption
here the difference is an -EFAULT.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: Al Viro <viro@zeniv.linux.org.uk>,
Mauro Carvalho Chehab <mchehab+samsung@kernel.org>,
Linux FS-devel Mailing List <linux-fsdevel@vger.kernel.org>,
y2038 Mailman List <y2038@lists.linaro.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Jason Gunthorpe <jgg@mellanox.com>,
Daniel Vetter <daniel.vetter@ffwll.ch>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
David Sterba <dsterba@suse.com>,
Darren Hart <dvhart@infradead.org>,
Jonathan Cameron <Jonathan.Cameron@huawei.com>,
Bjorn Andersson <bjorn.andersson@linaro.org>,
driverdevel <devel@driverdev.osuosl.org>,
qat-linux@intel.com,
"open list:HARDWARE RANDOM NUMBER GENERATOR CORE"
<linux-crypto@vger.kernel.org>,
Linux Media Mailing List <linux-media@vger.kernel.org>,
dri-devel <dri-devel@lists.freedesktop.org>,
linaro-mm-sig@lists.linaro.org, amd-gfx@lists.freedesktop.org,
"open list:HID CORE LAYER" <linux-input@vger.kernel.org>,
linux-iio@vger.kernel.org,
linux-rdma <linux-rdma@vger.kernel.org>,
linux-nvdimm@lists.01.org, linux-nvme@lists.infradead.org,
linux-pci <linux-pci@vger.kernel.org>,
Platform Driver <platform-driver-x86@vger.kernel.org>,
linux-remoteproc@vger.kernel.org,
sparclinux <sparclinux@vger.kernel.org>,
linux-scsi <linux-scsi@vger.kernel.org>,
USB list <linux-usb@vger.kernel.org>,
linux-btrfs <linux-btrfs@vger.kernel.org>,
ceph-devel <ceph-devel@vger.kernel.org>,
linux-wireless <linux-wireless@vger.kernel.org>,
Networking <netdev@vger.kernel.org>, Sean Young <sean@mess.org>
Subject: Re: [PATCH v3 12/26] compat_ioctl: move more drivers to compat_ptr_ioctl
Date: Fri, 26 Apr 2019 09:46:13 +0200 [thread overview]
Message-ID: <CAK8P3a3CzKLvpUiVV_k__kkaZ=wg2fqnFEzWYL9qNwBfxMKZ9w@mail.gmail.com> (raw)
In-Reply-To: <5511420228cb38d08a67c0f6a614b7671d7d23d4.camel@sipsolutions.net>
On Thu, Apr 25, 2019 at 11:25 PM Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Thu, 2019-04-25 at 17:55 +0200, Arnd Bergmann wrote:
> > On Thu, Apr 25, 2019 at 5:35 PM Al Viro <viro@zeniv.linux.org.uk> wrote:
> > >
> > > On Thu, Apr 25, 2019 at 12:21:53PM -0300, Mauro Carvalho Chehab wrote:
> > >
> > > > If I understand your patch description well, using compat_ptr_ioctl
> > > > only works if the driver is not for s390, right?
> > >
> > > No; s390 is where "oh, just set ->compat_ioctl same as ->unlocked_ioctl
> > > and be done with that; compat_ptr() is a no-op anyway" breaks. IOW,
> > > s390 is the reason for having compat_ptr_ioctl() in the first place;
> > > that thing works on all biarch architectures, as long as all stuff
> > > handled by ->ioctl() takes pointer to arch-independent object as
> > > argument. IOW,
> > > argument ignored => OK
> > > any arithmetical type => no go, compat_ptr() would bugger it
> > > pointer to int => OK
> > > pointer to string => OK
> > > pointer to u64 => OK
> > > pointer to struct {u64 addr; char s[11];} => OK
> >
> > To be extra pedantic, the 'struct {u64 addr; char s[11];} '
> > case is also broken on x86, because sizeof (obj) is smaller
> > on i386, even though the location of the members are
> > the same. i.e. you can copy_from_user() this
>
> Actually, you can't even do that because the struct might sit at the end
> of a page and then you'd erroneously fault in this case.
>
> We had this a while ago with struct ifreq, see commit 98406133dd and its
> parents.
Yes, you are right. Very rare to hit with real-life code, but easily
reproduced by intentionally hitting it and clearly a bug.
As the saying goes
| the difference between "always works" and "almost always works"
| is called data corruption
here the difference is an -EFAULT.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: Al Viro <viro@zeniv.linux.org.uk>,
Mauro Carvalho Chehab <mchehab+samsung@kernel.org>,
Linux FS-devel Mailing List <linux-fsdevel@vger.kernel.org>,
y2038 Mailman List <y2038@lists.linaro.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Jason Gunthorpe <jgg@mellanox.com>,
Daniel Vetter <daniel.vetter@ffwll.ch>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
David Sterba <dsterba@suse.com>,
Darren Hart <dvhart@infradead.org>,
Jonathan Cameron <Jonathan.Cameron@huawei.com>,
Bjorn Andersson <bjorn.andersson@linaro.org>,
driverdevel <devel@driverdev.osuosl.org>,
qat-linux@intel.com,
"open list:HARDWARE RANDOM NUMBER GENERATOR CORE"
<linux-crypto@vger.kernel.org>,
Linux Media Mailing List <linux-media@vger.kernel.org>,
dri-devel <dri-devel@lists.freedesktop.org>,
linaro-mm-sig@lists.linaro.org, amd-gfx@lists.freedesktop.org,
"open list:HID CORE LAYER" <linux-input@vger.kernel.org>,
linux-iio@vger.kernel.org,
linux-rdma <linux-rdma@vger.kernel.org>,
linux-nvdimm@lists.01.org, linux-nvme@lists.infradead.org,
linux-pci <linux-pci@vger.kernel.org>,
Platform Driver <platform-driver-x86@vger.kernel.org>,
linux-remoteproc@vger.kernel.org,
sparclinux <sparclinux@vger.kernel.org>,
linux-scsi <linux-scsi@vger.kernel.org>,
USB list <linux-usb@vger.kernel.org>,
linux-btrfs <linux-btrfs@vger.kernel.org>,
ceph-devel <ceph-devel@vger.kernel.org>,
linux-wireless <linux-wireless@vger.kernel.org>,
Networking <netdev@vger.kernel.org>, Sean Young <sean@mess.org>
Subject: Re: [PATCH v3 12/26] compat_ioctl: move more drivers to compat_ptr_ioctl
Date: Fri, 26 Apr 2019 09:46:13 +0200 [thread overview]
Message-ID: <CAK8P3a3CzKLvpUiVV_k__kkaZ=wg2fqnFEzWYL9qNwBfxMKZ9w@mail.gmail.com> (raw)
In-Reply-To: <5511420228cb38d08a67c0f6a614b7671d7d23d4.camel@sipsolutions.net>
On Thu, Apr 25, 2019 at 11:25 PM Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Thu, 2019-04-25 at 17:55 +0200, Arnd Bergmann wrote:
> > On Thu, Apr 25, 2019 at 5:35 PM Al Viro <viro@zeniv.linux.org.uk> wrote:
> > >
> > > On Thu, Apr 25, 2019 at 12:21:53PM -0300, Mauro Carvalho Chehab wrote:
> > >
> > > > If I understand your patch description well, using compat_ptr_ioctl
> > > > only works if the driver is not for s390, right?
> > >
> > > No; s390 is where "oh, just set ->compat_ioctl same as ->unlocked_ioctl
> > > and be done with that; compat_ptr() is a no-op anyway" breaks. IOW,
> > > s390 is the reason for having compat_ptr_ioctl() in the first place;
> > > that thing works on all biarch architectures, as long as all stuff
> > > handled by ->ioctl() takes pointer to arch-independent object as
> > > argument. IOW,
> > > argument ignored => OK
> > > any arithmetical type => no go, compat_ptr() would bugger it
> > > pointer to int => OK
> > > pointer to string => OK
> > > pointer to u64 => OK
> > > pointer to struct {u64 addr; char s[11];} => OK
> >
> > To be extra pedantic, the 'struct {u64 addr; char s[11];} '
> > case is also broken on x86, because sizeof (obj) is smaller
> > on i386, even though the location of the members are
> > the same. i.e. you can copy_from_user() this
>
> Actually, you can't even do that because the struct might sit at the end
> of a page and then you'd erroneously fault in this case.
>
> We had this a while ago with struct ifreq, see commit 98406133dd and its
> parents.
Yes, you are right. Very rare to hit with real-life code, but easily
reproduced by intentionally hitting it and clearly a bug.
As the saying goes
| the difference between "always works" and "almost always works"
| is called data corruption
here the difference is an -EFAULT.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: Al Viro <viro@zeniv.linux.org.uk>,
Mauro Carvalho Chehab <mchehab+samsung@kernel.org>,
Linux FS-devel Mailing List <linux-fsdevel@vger.kernel.org>,
y2038 Mailman List <y2038@lists.linaro.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Jason Gunthorpe <jgg@mellanox.com>,
Daniel Vetter <daniel.vetter@ffwll.ch>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
David Sterba <dsterba@suse.com>,
Darren Hart <dvhart@infradead.org>,
Jonathan Cameron <Jonathan.Cameron@huawei.com>,
Bjorn Andersson <bjorn.andersson@linaro.org>,
driverdevel <devel@driverdev.osuosl.org>,
qat-linux@intel.com,
"open list:HARDWARE RANDOM NUMBER GENERATOR CORE"
<linux-crypto@vger.kernel.org>,
Linux Media Mailing List <linux-media@vger.kernel.org>,
dri-devel <dri-devel@lists.freedesktop.org>,
linaro-mm-sig@lists.linaro.org, amd-gfx@lists.freedesktop.org,
"open list:HID CORE LAYER" <linux-input@vger.kernel.org>,
linux-iio@vger.kernel.org,
linux-rdma <linux-rdma@vger.kernel.org>,
linux-nvdimm@lists.01.org, linux-nvme@lists.infradead.org,
linux-pci <linux-pci@vger.kernel.org>,
Platform Driver <platform-driver-x86@vger.kernel.org>,
linux-remoteproc@vger.kernel.org,
sparclinux <sparclinux@vger.kernel.org>,
linux-scsi <linux-scsi@vger.kernel.org>,
USB list <linux-usb@vger.kernel.org>,
linux-btrfs <linux-btrfs@vger.kernel.org>,
ceph-devel <ceph-devel@vger.kernel.org>,
linux-wireless <linux-wireless@vger.kernel.org>,
Networking <netdev@vger.kernel.org>, Sean Young <sean@mess.org>
Subject: [v3,12/26] compat_ioctl: move more drivers to compat_ptr_ioctl
Date: Fri, 26 Apr 2019 09:46:13 +0200 [thread overview]
Message-ID: <CAK8P3a3CzKLvpUiVV_k__kkaZ=wg2fqnFEzWYL9qNwBfxMKZ9w@mail.gmail.com> (raw)
On Thu, Apr 25, 2019 at 11:25 PM Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Thu, 2019-04-25 at 17:55 +0200, Arnd Bergmann wrote:
> > On Thu, Apr 25, 2019 at 5:35 PM Al Viro <viro@zeniv.linux.org.uk> wrote:
> > >
> > > On Thu, Apr 25, 2019 at 12:21:53PM -0300, Mauro Carvalho Chehab wrote:
> > >
> > > > If I understand your patch description well, using compat_ptr_ioctl
> > > > only works if the driver is not for s390, right?
> > >
> > > No; s390 is where "oh, just set ->compat_ioctl same as ->unlocked_ioctl
> > > and be done with that; compat_ptr() is a no-op anyway" breaks. IOW,
> > > s390 is the reason for having compat_ptr_ioctl() in the first place;
> > > that thing works on all biarch architectures, as long as all stuff
> > > handled by ->ioctl() takes pointer to arch-independent object as
> > > argument. IOW,
> > > argument ignored => OK
> > > any arithmetical type => no go, compat_ptr() would bugger it
> > > pointer to int => OK
> > > pointer to string => OK
> > > pointer to u64 => OK
> > > pointer to struct {u64 addr; char s[11];} => OK
> >
> > To be extra pedantic, the 'struct {u64 addr; char s[11];} '
> > case is also broken on x86, because sizeof (obj) is smaller
> > on i386, even though the location of the members are
> > the same. i.e. you can copy_from_user() this
>
> Actually, you can't even do that because the struct might sit at the end
> of a page and then you'd erroneously fault in this case.
>
> We had this a while ago with struct ifreq, see commit 98406133dd and its
> parents.
Yes, you are right. Very rare to hit with real-life code, but easily
reproduced by intentionally hitting it and clearly a bug.
As the saying goes
| the difference between "always works" and "almost always works"
| is called data corruption
here the difference is an -EFAULT.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
Cc: linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Sean Young <sean-hENCXIMQXOg@public.gmane.org>,
linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Daniel Vetter <daniel.vetter-/w4YWyX8dFk@public.gmane.org>,
linux-pci <linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
dri-devel
<dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
Bjorn Andersson
<bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
sparclinux <sparclinux-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Mauro Carvalho Chehab
<mchehab+samsung-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
driverdevel
<devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b@public.gmane.org>,
linux-scsi <linux-scsi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org,
y2038 Mailman List
<y2038-cunTk1MwBs8s++Sfvej+rw@public.gmane.org>,
qat-linux-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
Jason Gunthorpe <jgg-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>,
"open list:HID CORE LAYER"
<linux-input-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Darren Hart <dvhart-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>,
Linux Media Mailing List
<linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
linux-remoteproc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linaro-mm-sig-cunTk1MwBs8s++Sfvej+rw@public.gmane.org,
Al Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>,
Jonathan Cameron <Jonathan.Cameron@h>
Subject: Re: [PATCH v3 12/26] compat_ioctl: move more drivers to compat_ptr_ioctl
Date: Fri, 26 Apr 2019 07:46:13 +0000 [thread overview]
Message-ID: <CAK8P3a3CzKLvpUiVV_k__kkaZ=wg2fqnFEzWYL9qNwBfxMKZ9w@mail.gmail.com> (raw)
In-Reply-To: <5511420228cb38d08a67c0f6a614b7671d7d23d4.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
On Thu, Apr 25, 2019 at 11:25 PM Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Thu, 2019-04-25 at 17:55 +0200, Arnd Bergmann wrote:
> > On Thu, Apr 25, 2019 at 5:35 PM Al Viro <viro@zeniv.linux.org.uk> wrote:
> > >
> > > On Thu, Apr 25, 2019 at 12:21:53PM -0300, Mauro Carvalho Chehab wrote:
> > >
> > > > If I understand your patch description well, using compat_ptr_ioctl
> > > > only works if the driver is not for s390, right?
> > >
> > > No; s390 is where "oh, just set ->compat_ioctl same as ->unlocked_ioctl
> > > and be done with that; compat_ptr() is a no-op anyway" breaks. IOW,
> > > s390 is the reason for having compat_ptr_ioctl() in the first place;
> > > that thing works on all biarch architectures, as long as all stuff
> > > handled by ->ioctl() takes pointer to arch-independent object as
> > > argument. IOW,
> > > argument ignored => OK
> > > any arithmetical type => no go, compat_ptr() would bugger it
> > > pointer to int => OK
> > > pointer to string => OK
> > > pointer to u64 => OK
> > > pointer to struct {u64 addr; char s[11];} => OK
> >
> > To be extra pedantic, the 'struct {u64 addr; char s[11];} '
> > case is also broken on x86, because sizeof (obj) is smaller
> > on i386, even though the location of the members are
> > the same. i.e. you can copy_from_user() this
>
> Actually, you can't even do that because the struct might sit at the end
> of a page and then you'd erroneously fault in this case.
>
> We had this a while ago with struct ifreq, see commit 98406133dd and its
> parents.
Yes, you are right. Very rare to hit with real-life code, but easily
reproduced by intentionally hitting it and clearly a bug.
As the saying goes
| the difference between "always works" and "almost always works"
| is called data corruption
here the difference is an -EFAULT.
Arnd
next prev parent reply other threads:[~2019-04-26 7:46 UTC|newest]
Thread overview: 160+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-16 20:19 [PATCH v3 00/26] compat_ioctl: cleanups Arnd Bergmann
2019-04-16 20:19 ` Arnd Bergmann
2019-04-16 20:19 ` Arnd Bergmann
2019-04-16 20:19 ` Arnd Bergmann
2019-04-16 20:19 ` Arnd Bergmann
2019-04-16 20:19 ` Arnd Bergmann
2019-04-16 20:19 ` [PATCH v3 01/26] compat_ioctl: pppoe: fix PPPOEIOCSFWD handling Arnd Bergmann
2019-04-16 20:19 ` [PATCH v3 02/26] compat_ioctl: move simple ppp command handling into driver Arnd Bergmann
2019-04-16 20:19 ` Arnd Bergmann
2019-04-17 21:13 ` Al Viro
2019-04-17 21:13 ` Al Viro
2019-04-17 22:03 ` Arnd Bergmann
2019-04-17 22:03 ` Arnd Bergmann
2019-04-17 23:53 ` Al Viro
2019-04-17 23:53 ` Al Viro
2019-04-18 5:57 ` Al Viro
2019-04-18 5:57 ` Al Viro
2019-04-18 15:14 ` Arnd Bergmann
2019-04-18 15:14 ` Arnd Bergmann
2019-04-16 20:19 ` [PATCH v3 03/26] compat_ioctl: avoid unused function warning for do_ioctl Arnd Bergmann
2019-04-16 20:19 ` [PATCH v3 04/26] compat_ioctl: move PPPIOCSCOMPRESS32 to ppp-generic.c Arnd Bergmann
2019-04-16 20:19 ` Arnd Bergmann
2019-04-17 21:16 ` Al Viro
2019-04-17 21:16 ` Al Viro
2019-04-17 21:44 ` Arnd Bergmann
2019-04-17 21:44 ` Arnd Bergmann
2019-04-16 20:19 ` [PATCH v3 05/26] compat_ioctl: move PPPIOCSPASS32/PPPIOCSACTIVE32 to ppp_generic.c Arnd Bergmann
2019-04-16 20:19 ` Arnd Bergmann
2019-04-16 20:19 ` [PATCH v3 06/26] compat_ioctl: handle PPPIOCGIDLE for 64-bit time_t Arnd Bergmann
2019-04-16 20:19 ` Arnd Bergmann
2019-04-16 20:19 ` [PATCH v3 07/26] compat_ioctl: move rtc handling into rtc-dev.c Arnd Bergmann
2019-04-16 20:19 ` [PATCH v3 08/26] compat_ioctl: add compat_ptr_ioctl() Arnd Bergmann
2019-04-17 21:19 ` Al Viro
2019-04-17 21:34 ` Arnd Bergmann
2019-04-16 20:19 ` [PATCH v3 09/26] compat_ioctl: move drivers to compat_ptr_ioctl Arnd Bergmann
2019-04-16 20:19 ` Arnd Bergmann
2019-04-16 20:19 ` Arnd Bergmann
2019-04-16 20:19 ` Arnd Bergmann
2019-04-16 20:19 ` [v3,09/26] " Arnd Bergmann
2019-04-16 20:19 ` [PATCH v3 09/26] " Arnd Bergmann
2019-04-16 20:31 ` Jiri Kosina
2019-04-16 20:31 ` Jiri Kosina
2019-04-16 20:31 ` Jiri Kosina
2019-04-16 20:31 ` Jiri Kosina
2019-04-16 20:31 ` [v3,09/26] " Jiri Kosina
2019-04-16 20:31 ` [PATCH v3 09/26] " Jiri Kosina
2019-04-18 11:10 ` Stefan Hajnoczi
2019-04-18 11:10 ` Stefan Hajnoczi
2019-04-18 11:10 ` Stefan Hajnoczi
2019-04-18 11:10 ` Stefan Hajnoczi
2019-04-18 11:10 ` [v3,09/26] " Stefan Hajnoczi
2019-04-18 11:10 ` [PATCH v3 09/26] " Stefan Hajnoczi
2019-04-19 23:16 ` Michael S. Tsirkin
2019-04-19 23:16 ` Michael S. Tsirkin
2019-04-19 23:16 ` Michael S. Tsirkin
2019-04-19 23:16 ` Michael S. Tsirkin
2019-04-19 23:16 ` [v3,09/26] " Michael S. Tsirkin
2019-04-19 23:16 ` [PATCH v3 09/26] " Michael S. Tsirkin
2019-04-20 8:03 ` Winkler, Tomas
2019-04-20 8:03 ` Winkler, Tomas
2019-04-20 8:03 ` Winkler, Tomas
2019-04-20 8:03 ` Winkler, Tomas
2019-04-16 20:19 ` [PATCH v3 10/26] compat_ioctl: use correct compat_ptr() translation in drivers Arnd Bergmann
2019-04-16 20:19 ` Arnd Bergmann
2019-04-16 20:19 ` Arnd Bergmann
2019-04-16 20:19 ` [v3,10/26] " Arnd Bergmann
2019-04-17 21:21 ` [PATCH v3 10/26] " Al Viro
2019-04-17 21:21 ` Al Viro
2019-04-17 21:21 ` Al Viro
2019-04-17 21:21 ` [v3,10/26] " Al Viro
2019-04-16 20:19 ` [PATCH v3 11/26] ceph: fix compat_ioctl for ceph_dir_operations Arnd Bergmann
2019-04-17 21:23 ` Al Viro
2019-04-17 21:31 ` Arnd Bergmann
[not found] ` <20190416202013.4034148-1-arnd-r2nGTMty4D4@public.gmane.org>
2019-04-16 20:25 ` [PATCH v3 12/26] compat_ioctl: move more drivers to compat_ptr_ioctl Arnd Bergmann
2019-04-16 20:25 ` Arnd Bergmann
2019-04-16 20:25 ` [v3,12/26] " Arnd Bergmann
2019-04-16 20:25 ` [PATCH v3 12/26] " Arnd Bergmann
2019-04-16 20:25 ` [PATCH v3 13/26] compat_ioctl: move tape handling into drivers Arnd Bergmann
2019-04-16 20:25 ` [PATCH v3 14/26] compat_ioctl: move ATYFB_CLK handling to atyfb driver Arnd Bergmann
2019-04-16 20:25 ` Arnd Bergmann
2019-04-17 21:27 ` Al Viro
2019-04-17 21:27 ` Al Viro
2019-04-17 21:28 ` Al Viro
2019-04-17 21:28 ` Al Viro
2019-05-06 13:37 ` Bartlomiej Zolnierkiewicz
2019-05-06 13:37 ` Bartlomiej Zolnierkiewicz
2019-05-06 13:37 ` Bartlomiej Zolnierkiewicz
2019-04-16 20:25 ` [PATCH v3 15/26] compat_ioctl: move isdn/capi ioctl translation into driver Arnd Bergmann
2019-04-16 20:25 ` [PATCH v3 16/26] compat_ioctl: move rfcomm handlers " Arnd Bergmann
2019-04-16 20:25 ` [PATCH v3 17/26] compat_ioctl: move hci_sock " Arnd Bergmann
2019-04-16 20:25 ` [PATCH v3 18/26] compat_ioctl: remove HCIUART handling Arnd Bergmann
2019-04-16 20:25 ` [PATCH v3 19/26] compat_ioctl: remove HIDIO translation Arnd Bergmann
2019-04-17 9:46 ` [PATCH v3 12/26] compat_ioctl: move more drivers to compat_ptr_ioctl Marc Gonzalez
2019-04-25 15:21 ` Mauro Carvalho Chehab
2019-04-25 15:21 ` Mauro Carvalho Chehab
2019-04-25 15:21 ` [v3,12/26] " Mauro Carvalho Chehab
2019-04-25 15:21 ` [PATCH v3 12/26] " Mauro Carvalho Chehab
2019-04-25 15:32 ` Arnd Bergmann
2019-04-25 15:32 ` Arnd Bergmann
2019-04-25 15:32 ` [v3,12/26] " Arnd Bergmann
2019-04-25 15:32 ` [PATCH v3 12/26] " Arnd Bergmann
2019-04-25 15:32 ` Arnd Bergmann
2019-04-25 15:35 ` Al Viro
2019-04-25 15:35 ` Al Viro
2019-04-25 15:35 ` [v3,12/26] " Al Viro
2019-04-25 15:35 ` [PATCH v3 12/26] " Al Viro
2019-04-25 15:53 ` Mauro Carvalho Chehab
2019-04-25 15:53 ` Mauro Carvalho Chehab
2019-04-25 15:53 ` [v3,12/26] " Mauro Carvalho Chehab
2019-04-25 15:53 ` [PATCH v3 12/26] " Mauro Carvalho Chehab
[not found] ` <20190425153534.GS2217-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
2019-04-25 15:55 ` Arnd Bergmann
2019-04-25 15:55 ` Arnd Bergmann
2019-04-25 15:55 ` [v3,12/26] " Arnd Bergmann
2019-04-25 15:55 ` [PATCH v3 12/26] " Arnd Bergmann
2019-04-25 15:55 ` Arnd Bergmann
2019-04-25 16:42 ` Al Viro
2019-04-25 16:42 ` Al Viro
2019-04-25 16:42 ` [v3,12/26] " Al Viro
2019-04-25 16:42 ` [PATCH v3 12/26] " Al Viro
2019-04-25 16:42 ` Al Viro
[not found] ` <CAK8P3a2HmiYQJ2FV2FgLiFsD8M9UKteC9Jetx7ja06PQVZWYfA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-04-25 21:25 ` Johannes Berg
2019-04-25 21:25 ` Johannes Berg
2019-04-25 21:25 ` [v3,12/26] " Johannes Berg
2019-04-25 21:25 ` [PATCH v3 12/26] " Johannes Berg
[not found] ` <5511420228cb38d08a67c0f6a614b7671d7d23d4.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2019-04-26 7:46 ` Arnd Bergmann [this message]
2019-04-26 7:46 ` Arnd Bergmann
2019-04-26 7:46 ` [v3,12/26] " Arnd Bergmann
2019-04-26 7:46 ` [PATCH v3 12/26] " Arnd Bergmann
2019-04-26 7:46 ` Arnd Bergmann
2019-04-16 20:28 ` [PATCH v3 20/26] compat_ioctl: remove translation for sound ioctls Arnd Bergmann
2019-04-16 20:28 ` Arnd Bergmann
2019-04-16 20:28 ` [PATCH v3 21/26] compat_ioctl: remove IGNORE_IOCTL() Arnd Bergmann
2019-04-16 20:28 ` [PATCH v3 22/26] compat_ioctl: remove /dev/random commands Arnd Bergmann
2019-04-16 20:28 ` [PATCH v3 23/26] compat_ioctl: remove joystick ioctl translation Arnd Bergmann
2019-04-16 20:28 ` [PATCH v3 24/26] compat_ioctl: remove PCI " Arnd Bergmann
2019-04-16 20:28 ` [PATCH v3 25/26] compat_ioctl: remove /dev/raw " Arnd Bergmann
2019-04-16 20:28 ` [PATCH v3 26/26] compat_ioctl: remove last RAID handling code Arnd Bergmann
2019-04-17 8:05 ` [PATCH v3 20/26] compat_ioctl: remove translation for sound ioctls Takashi Iwai
2019-04-17 8:05 ` Takashi Iwai
2019-04-17 8:05 ` Takashi Iwai
2019-04-29 7:05 ` Takashi Iwai
2019-04-29 7:05 ` Takashi Iwai
2019-04-29 7:05 ` Takashi Iwai
2019-04-29 12:43 ` Arnd Bergmann
2019-04-29 12:43 ` Arnd Bergmann
2019-04-16 22:33 ` [PATCH v3 00/26] compat_ioctl: cleanups Douglas Gilbert
2019-04-16 22:33 ` Douglas Gilbert
2019-04-16 22:33 ` Douglas Gilbert
2019-04-16 22:33 ` Douglas Gilbert
2019-04-16 22:33 ` Douglas Gilbert
2019-04-16 22:33 ` Douglas Gilbert
2019-04-17 9:26 ` Arnd Bergmann
2019-04-17 9:26 ` Arnd Bergmann
2019-04-17 9:26 ` Arnd Bergmann
2019-04-17 9:26 ` Arnd Bergmann
2019-05-06 9:03 ` Andy Shevchenko
2019-05-06 9:03 ` Andy Shevchenko
2019-05-06 9:03 ` Andy Shevchenko
2019-05-06 9:03 ` Andy Shevchenko
2019-05-06 9:03 ` 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='CAK8P3a3CzKLvpUiVV_k__kkaZ=wg2fqnFEzWYL9qNwBfxMKZ9w@mail.gmail.com' \
--to=arnd-r2ngtmty4d4@public.gmane.org \
--cc=Jonathan.Cameron@h \
--cc=amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=daniel.vetter-/w4YWyX8dFk@public.gmane.org \
--cc=devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b@public.gmane.org \
--cc=dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=dvhart-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org \
--cc=jgg-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org \
--cc=johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org \
--cc=linaro-mm-sig-cunTk1MwBs8s++Sfvej+rw@public.gmane.org \
--cc=linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-input-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org \
--cc=linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-remoteproc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-scsi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mchehab+samsung-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=qat-linux-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=sean-hENCXIMQXOg@public.gmane.org \
--cc=sparclinux-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org \
--cc=y2038-cunTk1MwBs8s++Sfvej+rw@public.gmane.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.