* Linux 5.10-rc1
@ 2020-10-25 22:40 Linus Torvalds
2020-10-25 23:43 ` linux-next: stats Stephen Rothwell
2020-10-27 6:48 ` problems with splice from /proc (was Linux 5.10-rc1) Greg KH
0 siblings, 2 replies; 15+ messages in thread
From: Linus Torvalds @ 2020-10-25 22:40 UTC (permalink / raw)
To: Linux Kernel Mailing List
Two weeks have passed, and the merge window is over. I've tagged and
pushed out 5.10-rc1, and everything looks fairly normal.
This looks to be a bigger release than I expected, and while the merge
window is smaller than the one for 5.8 was, it's not a *lot* smaller.
And 5.8 was our biggest release ever.
I'm not entirely sure whether this is just a general upward trend (we
did seem to plateau for a while there), or just a fluke, or perhaps
due to 5.9 dragging out an extra week. We will see, I guess.
That said, things seem to have gone fairly smoothly. I don't see any
huge red flags, and the merge window didn't cause any unusual issues
for me. Famous last words..
The most interesting - to me - change here is Christoph's setf_fs()
removal (it got merged through Al Viro, as you can see in my mergelog
below). It's not a _huge_ change, but it's interesting because the
whole model of set_fs() to specify whether a userspace copy actually
goes to user space or kernel space goes back to pretty much the
original release of Linux, and while the name is entirely historic (it
hasn't used the %fs segment register in a long time), the concept has
remained. Until now.
We still do have "set_fs()" around, and not every architecture has
been converted to the new world order, but x86, powerpc, s390 and
RISC-V have had the address space overrides removed, and all the core
work is done. Other architectures will hopefully get converted away
from that very historic model too, but it might take a while to get
rid of it all.
Anyway, to most people that all shouldn't matter at all, and it's
mainly a small historical footnote that 5.10 no longer relies on the
whole set_fs() model. Most of the actual changes are - as usual -
driver updates, but there are changes all over. I think the merge log
below gives some kind of flavor of what's been going on on a high
level, but if you're interested in the details go look at the git
tree. As mentioned, it's a big merge window, with almost 14k commits
(*) by closer to 1700 people.
Please go test,
Linus
(*) closer to 15k commits if you count merges.
---
Al Viro (6):
copy_and_csum cleanups
compat iovec cleanups
compat quotactl cleanups
compat mount cleanups
initial set_fs() removal
misc vfs updates
Alex Williamson (1):
VFIO updates
Alexandre Belloni (1):
RTC updates
Andreas Gruenbacher (1):
gfs2 updates
Andrew Morton (3):
misc updates
more updates
yet more updates
Anna Schumaker (1):
NFS client updates
Arnaldo Carvalho de Melo (1):
perf tools updates
Benson Leung (1):
chrome platform updates
Bjorn Andersson (2):
remoteproc updates
rpmsg updates
Bjorn Helgaas (1):
PCI updates
Boris Brezillon (1):
i3c updates
Borislav Petkov (14):
EDAC updates
RAS updates
x86 cpu updates
x86 platform updates
x86 PASID updates
x86 fsgsbase updates
x86 fpu updates
x86 cleanups
x86 cache resource control updates
x86 fix
x86 fixes
x86 asm updates
x86 SEV-ES support
x86 SEV-ES fixes
Bruce Fields (1):
nfsd updates
Casey Schaufler (1):
smack updates
Christian Brauner (2):
kernel_clone() updates
pidfd updates
Christoph Hellwig (3):
dma-mapping updates
configfs updates
dma-mapping fixes
Corey Minyard (1):
IPMI updates
Damien Le Moal (1):
zonefs updates
Daniel Lezcano (1):
thermal updates
Daniel Thompson (1):
kgdb updates
Darrick Wong (5):
iomap updates
xfs updates
more xfs updates
clone/dedupe/remap code refactoring
xfs fixes
Dave Airlie (3):
drm updates
drm fixes
more drm fixes
David Howells (1):
afs updates
David Sterba (1):
btrfs updates
David Teigland (1):
dlm updates
Dmitry Torokhov (1):
input updates
Dominique Martinet (1):
9p updates
Eric Biggers (1):
fscrypt updates
Gao Xiang (1):
erofs updates
Geert Uytterhoeven (1):
m68k updates
Greg KH (6):
tty/serial updates
driver core updates
SPDX updates
staging / IIO driver updates
USB/PHY/Thunderbolt driver updates
char/misc driver updates
Greg Ungerer (1):
m68knommu updates
Guenter Roeck (1):
hwmon updates
Hans de Goede (1):
x86 platform driver updates
Helge Deller (2):
parisc updates
more parisc updates
Herbert Xu (1):
crypto updates
Ilya Dryomov (1):
ceph updates
Ingo Molnar (14):
scheduler updates
locking updates
EFI changes
orphan section checking
static call support
performance events updates
perf/kprobes updates
x86 kaslr updates
x86 mm updates
x86 build update
x86 paravirt cleanup
x86 Hyper-V update
objtool updates
RCU changes
Jaegeuk Kim (1):
f2fs updates
Jakub Kicinski (2):
networking updates
networking fixes
James Bottomley (2):
SCSI updates
more SCSI updates
Jan Kara (2):
UDF, reiserfs, ext2, quota fixes
direct-io fix
Jarkko Sakkinen (1):
tpm updates
Jason Gunthorpe (1):
rdma updates
Jassi Brar (1):
mailbox updates
Jean Delvare (1):
dmi update
Jeff Layton (1):
file locking fix
Jens Axboe (9):
block updates
io_uring updates
libata updates
block driver updates
io_uring updates
arch task_work cleanups
libata fixes
io_uring fixes
block fixes
Jessica Yu (1):
modules updates
Jiri Kosina (3):
livepatching update
HID updates
trivial updates
Joerg Roedel (2):
iommu updates
iommu fix
Jon Mason (1):
NTB fixes
Jonathan Corbet (2):
documentation updates
documentation fixes
Juergen Gross (3):
xen updates
more xen updates
more xen updates
Julia Lawall (1):
coccinelle updates
Kees Cook (2):
seccomp updates
overflow update
Konrad Rzeszutek Wilk (1):
swiotlb updates
Lee Jones (2):
MFD updates
backlight updates
Linus Walleij (2):
GPIO updates
pin control updates
Mark Brown (3):
regmap updates
regulator updates
spi updates
Masahiro Yamada (2):
Kbuild updates
Kconfig updates
Matthew Wilcox (1):
XArray updates
Mauro Carvalho Chehab (2):
media updates
documentation updates
Micah Morton (1):
SafeSetID updates
Michael Ellerman (2):
powerpc updates
powerpc fixes
Michael Tsirkin (1):
virtio updates
Michal Simek (1):
Microblaze build warning fix
Mike Snitzer (1):
device mapper updates
Miklos Szeredi (2):
overlayfs updates
fuse updates
Mimi Zohar (1):
integrity updates
Namjae Jeon (1):
exfat updates
Olof Johansson (5):
ARM SoC fixes
ARM SoC platform updates
ARM SoC-related driver updates
ARM Devicetree updates
ARM SoC defconfig updates
Palmer Dabbelt (2):
RISC-V updates
more RISC-V updates
Paolo Bonzini (2):
KVM updates
KVM fixes
Paul Moore (2):
audit updates
selinux updates
Pavel Machek (1):
LED updates
Petr Mladek (2):
printk updates
printk fix
Rafael Wysocki (5):
power management updates
ACPI updates
PNP updates
more power management updates
more ACPI updates
Richard Weinberger (4):
MTD updates
ubifs updates
more ubi and ubifs updates
UML updates
Rob Herring (1):
devicetree updates
Russell King (1):
ARM updates
Sebastian Reichel (1):
power supply and reset updates
Shuah Khan (4):
kselftest updates
kselftest updates
Kunit updates
more Kunit updates
Stephen Boyd (1):
clk updates
Steve French (2):
cifs updates
more cifs updates
Steven Rostedt (3):
tracing updates
tracing fix
tracing ring-buffer fix
Takashi Iwai (2):
sound updates
sound fixes
Ted Ts'o (1):
ext4 updates
Tejun Heo (1):
cgroup updates
Tetsuo HandaL
(1):
tomoyo fix
Thierry Reding (1):
pwm updates
Thomas Bogendoerfer (1):
MIPS updates
Thomas Gleixner (9):
debugobjects updates
timekeeping updates
irq updates
x86 irq updates
x86 entry code updates
locking fix
perf fix
scheduler fixes
timer fixes
Tony Luck (1):
ia64 updates
Ulf Hansson (1):
MMC updates
Vasily Gorbik (1):
s390 updates
Vineet Gupta (2):
ARC updates
ARC fix
Vinod Koul (1):
dmaengine updates
Wei Liu (2):
Hyper-V updates
another Hyper-V update
Will Deacon (2):
arm64 updates
more arm64 updates
Willy Tarreau (1):
random32 updates
Wim Van Sebroeck (1):
watchdog updates
Wolfram Sang (2):
i2c updates
i2c fix
^ permalink raw reply [flat|nested] 15+ messages in thread* linux-next: stats
2020-10-25 22:40 Linux 5.10-rc1 Linus Torvalds
@ 2020-10-25 23:43 ` Stephen Rothwell
2020-10-27 6:48 ` problems with splice from /proc (was Linux 5.10-rc1) Greg KH
1 sibling, 0 replies; 15+ messages in thread
From: Stephen Rothwell @ 2020-10-25 23:43 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 2640 bytes --]
Hi all,
As usual, the executive friendly graph is at
http://neuling.org/linux-next-size.html :-)
(No merge commits counted, next-20201009 was the first linux-next after
the merge window opened.)
Commits in v5.10-rc1 (relative to v5.9): 13903
Commits in next-20201009: 13046
Commits with the same SHA1: 11911
Commits with the same patch_id: 563 (1)
Commits with the same subject line: 46 (1)
(1) not counting those in the lines above.
So commits in -rc1 that were in next-20201009: 12520 90%
Some breakdown of the list of extra commits (relative to next-20201009)
in -rc1:
Top ten first word of commit summary:
158 kvm
112 perf
77 net
53 docs
43 io_uring
43 drm
32 bpf
31 dt-bindings
30 clk
28 nfsd
Top ten authors:
77 mchehab+huawei@kernel.org
64 sean.j.christopherson@intel.com
28 asml.silence@gmail.com
20 bgardon@google.com
19 axboe@kernel.dk
18 jgross@suse.com
17 stfrench@microsoft.com
17 chuck.lever@oracle.com
16 namhyung@kernel.org
16 moshe@mellanox.com
Top ten commiters:
165 kuba@kernel.org
163 pbonzini@redhat.com
113 acme@redhat.com
81 axboe@kernel.dk
75 mchehab+huawei@kernel.org
43 bfields@redhat.com
35 sboyd@kernel.org
29 rafael.j.wysocki@intel.com
27 stfrench@microsoft.com
27 idryomov@gmail.com
There are also 526 commits in next-20201009 that didn't make it into
v5.10-rc1.
Top ten first word of commit summary:
81 drm
45 arm
32 tools
21 soc
19 bus
16 mm
13 dt-bindings
13 arm64
12 rcu
9 x86
Top ten authors:
64 paulmck@kernel.org
32 ray.huang@amd.com
16 akpm@linux-foundation.org
14 gustavoars@kernel.org
13 tglx@linutronix.de
13 olof@lixom.net
12 bbhatt@codeaurora.org
11 ysato@users.sourceforge.jp
10 joel@jms.id.au
9 jhubbard@nvidia.com
Some of Andrew's patches are fixes for other patches in his tree (and
have been merged into those).
Top ten commiters:
103 paulmck@kernel.org
83 sfr@canb.auug.org.au
71 alexander.deucher@amd.com
26 maxime@cerno.tech
19 manivannan.sadhasivam@linaro.org
17 joel@jms.id.au
15 gregory.clement@bootlin.com
14 ysato@users.sourceforge.jp
14 davem@davemloft.net
13 olof@lixom.net
Those commits by me are from Andrew's mmotm tree.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread* problems with splice from /proc (was Linux 5.10-rc1)
2020-10-25 22:40 Linux 5.10-rc1 Linus Torvalds
2020-10-25 23:43 ` linux-next: stats Stephen Rothwell
@ 2020-10-27 6:48 ` Greg KH
2020-10-27 7:49 ` Christoph Hellwig
1 sibling, 1 reply; 15+ messages in thread
From: Greg KH @ 2020-10-27 6:48 UTC (permalink / raw)
To: Linus Torvalds, Christoph Hellwig; +Cc: Al Viro, Linux Kernel Mailing List
On Sun, Oct 25, 2020 at 03:40:27PM -0700, Linus Torvalds wrote:
> The most interesting - to me - change here is Christoph's setf_fs()
> removal (it got merged through Al Viro, as you can see in my mergelog
> below). It's not a _huge_ change, but it's interesting because the
> whole model of set_fs() to specify whether a userspace copy actually
> goes to user space or kernel space goes back to pretty much the
> original release of Linux, and while the name is entirely historic (it
> hasn't used the %fs segment register in a long time), the concept has
> remained. Until now.
I told Al this yesterday, but figured I would mention it here for others
to see.
Commit 36e2c7421f02 ("fs: don't allow splice read/write without explicit
ops") from this patch series, is breaking the bionic test suite that
does the following to verify that splice is working:
int in = open("/proc/cpuinfo", O_RDONLY);
ASSERT_NE(in, -1);
TemporaryFile tf;
ssize_t bytes_read = splice(in, nullptr, pipe_fds[1], nullptr, 8*1024, SPLICE_F_MORE | SPLICE_F_MOVE);
ASSERT_NE(bytes_read, -1);
Before this change, all works well but now splice fails on /proc files
(and I'm guessing other virtual filesystems).
I'll ask the bionic developers if they can change their test to some
other file, but this is a regression and might show up in other "test
platforms" as well. Using /proc for this is just so simple because
these files are "always there" and don't require any housekeeping for
test suites to worry about .
thanks,
greg k-h
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: problems with splice from /proc (was Linux 5.10-rc1)
2020-10-27 6:48 ` problems with splice from /proc (was Linux 5.10-rc1) Greg KH
@ 2020-10-27 7:49 ` Christoph Hellwig
2020-10-27 7:55 ` Greg KH
0 siblings, 1 reply; 15+ messages in thread
From: Christoph Hellwig @ 2020-10-27 7:49 UTC (permalink / raw)
To: Greg KH
Cc: Linus Torvalds, Christoph Hellwig, Al Viro, Linux Kernel Mailing List
On Tue, Oct 27, 2020 at 07:48:32AM +0100, Greg KH wrote:
> On Sun, Oct 25, 2020 at 03:40:27PM -0700, Linus Torvalds wrote:
> > The most interesting - to me - change here is Christoph's setf_fs()
> > removal (it got merged through Al Viro, as you can see in my mergelog
> > below). It's not a _huge_ change, but it's interesting because the
> > whole model of set_fs() to specify whether a userspace copy actually
> > goes to user space or kernel space goes back to pretty much the
> > original release of Linux, and while the name is entirely historic (it
> > hasn't used the %fs segment register in a long time), the concept has
> > remained. Until now.
>
> I told Al this yesterday, but figured I would mention it here for others
> to see.
>
> Commit 36e2c7421f02 ("fs: don't allow splice read/write without explicit
> ops") from this patch series, is breaking the bionic test suite that
> does the following to verify that splice is working:
>
> int in = open("/proc/cpuinfo", O_RDONLY);
> ASSERT_NE(in, -1);
>
> TemporaryFile tf;
> ssize_t bytes_read = splice(in, nullptr, pipe_fds[1], nullptr, 8*1024, SPLICE_F_MORE | SPLICE_F_MOVE);
> ASSERT_NE(bytes_read, -1);
>
> Before this change, all works well but now splice fails on /proc files
> (and I'm guessing other virtual filesystems).
>
> I'll ask the bionic developers if they can change their test to some
> other file, but this is a regression and might show up in other "test
> platforms" as well. Using /proc for this is just so simple because
> these files are "always there" and don't require any housekeeping for
> test suites to worry about .
Is this just a test or a real application? I already have the
infrastructure to support read_iter/write_iter on procfs and seq_files,
but due to the intrusiveness we decided to only fix instances on an as
needed basis. So we'll have everything ready once we pull the trigger.
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: problems with splice from /proc (was Linux 5.10-rc1)
2020-10-27 7:49 ` Christoph Hellwig
@ 2020-10-27 7:55 ` Greg KH
2020-10-27 8:07 ` Christoph Hellwig
0 siblings, 1 reply; 15+ messages in thread
From: Greg KH @ 2020-10-27 7:55 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Linus Torvalds, Al Viro, Linux Kernel Mailing List
On Tue, Oct 27, 2020 at 07:49:11AM +0000, Christoph Hellwig wrote:
> On Tue, Oct 27, 2020 at 07:48:32AM +0100, Greg KH wrote:
> > On Sun, Oct 25, 2020 at 03:40:27PM -0700, Linus Torvalds wrote:
> > > The most interesting - to me - change here is Christoph's setf_fs()
> > > removal (it got merged through Al Viro, as you can see in my mergelog
> > > below). It's not a _huge_ change, but it's interesting because the
> > > whole model of set_fs() to specify whether a userspace copy actually
> > > goes to user space or kernel space goes back to pretty much the
> > > original release of Linux, and while the name is entirely historic (it
> > > hasn't used the %fs segment register in a long time), the concept has
> > > remained. Until now.
> >
> > I told Al this yesterday, but figured I would mention it here for others
> > to see.
> >
> > Commit 36e2c7421f02 ("fs: don't allow splice read/write without explicit
> > ops") from this patch series, is breaking the bionic test suite that
> > does the following to verify that splice is working:
> >
> > int in = open("/proc/cpuinfo", O_RDONLY);
> > ASSERT_NE(in, -1);
> >
> > TemporaryFile tf;
> > ssize_t bytes_read = splice(in, nullptr, pipe_fds[1], nullptr, 8*1024, SPLICE_F_MORE | SPLICE_F_MOVE);
> > ASSERT_NE(bytes_read, -1);
> >
> > Before this change, all works well but now splice fails on /proc files
> > (and I'm guessing other virtual filesystems).
> >
> > I'll ask the bionic developers if they can change their test to some
> > other file, but this is a regression and might show up in other "test
> > platforms" as well. Using /proc for this is just so simple because
> > these files are "always there" and don't require any housekeeping for
> > test suites to worry about .
>
> Is this just a test or a real application? I already have the
> infrastructure to support read_iter/write_iter on procfs and seq_files,
> but due to the intrusiveness we decided to only fix instances on an as
> needed basis. So we'll have everything ready once we pull the trigger.
This is just a test, part of the bionic test suite to verify that bionic
is working properly, and is run on new kernels as a verification that
nothing functional broke in the kernel update.
I don't know about "real applications" yet.
Do you have to implement this on a per-proc-file-basis, or will it work
for the whole filesystem?
And are the patches public anywhere that I could test them out?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: problems with splice from /proc (was Linux 5.10-rc1)
2020-10-27 7:55 ` Greg KH
@ 2020-10-27 8:07 ` Christoph Hellwig
2020-10-27 8:14 ` Greg KH
0 siblings, 1 reply; 15+ messages in thread
From: Christoph Hellwig @ 2020-10-27 8:07 UTC (permalink / raw)
To: Greg KH
Cc: Christoph Hellwig, Linus Torvalds, Al Viro, Linux Kernel Mailing List
On Tue, Oct 27, 2020 at 08:55:41AM +0100, Greg KH wrote:
> This is just a test, part of the bionic test suite to verify that bionic
> is working properly, and is run on new kernels as a verification that
> nothing functional broke in the kernel update.
>
> I don't know about "real applications" yet.
>
> Do you have to implement this on a per-proc-file-basis, or will it work
> for the whole filesystem?
>
> And are the patches public anywhere that I could test them out?
This all branch has the last posted version:
http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/set_fs-rw.2
with tthe proc:, sysctl: and seq_file: patches related to it. It did
switch over all seq_file instances, but non-seq_file instances and write
operations will need manual per-instance work.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: problems with splice from /proc (was Linux 5.10-rc1)
2020-10-27 8:07 ` Christoph Hellwig
@ 2020-10-27 8:14 ` Greg KH
2020-10-27 8:14 ` Christoph Hellwig
2020-10-27 9:17 ` Greg KH
0 siblings, 2 replies; 15+ messages in thread
From: Greg KH @ 2020-10-27 8:14 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Linus Torvalds, Al Viro, Linux Kernel Mailing List
On Tue, Oct 27, 2020 at 08:07:45AM +0000, Christoph Hellwig wrote:
> On Tue, Oct 27, 2020 at 08:55:41AM +0100, Greg KH wrote:
> > This is just a test, part of the bionic test suite to verify that bionic
> > is working properly, and is run on new kernels as a verification that
> > nothing functional broke in the kernel update.
> >
> > I don't know about "real applications" yet.
> >
> > Do you have to implement this on a per-proc-file-basis, or will it work
> > for the whole filesystem?
> >
> > And are the patches public anywhere that I could test them out?
>
> This all branch has the last posted version:
>
> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/set_fs-rw.2
>
> with tthe proc:, sysctl: and seq_file: patches related to it. It did
> switch over all seq_file instances, but non-seq_file instances and write
> operations will need manual per-instance work.
Luckily /proc/cpuinfo seems to use the seq_file interface, so this
series would work for that.
What's the odds of this series getting into 5.10-final? I'll go run it
through the Android build system right now to see if it fixes the issue
or not...
thanks,
greg k-h
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: problems with splice from /proc (was Linux 5.10-rc1)
2020-10-27 8:14 ` Greg KH
@ 2020-10-27 8:14 ` Christoph Hellwig
2020-10-27 9:17 ` Greg KH
1 sibling, 0 replies; 15+ messages in thread
From: Christoph Hellwig @ 2020-10-27 8:14 UTC (permalink / raw)
To: Greg KH
Cc: Christoph Hellwig, Linus Torvalds, Al Viro, Linux Kernel Mailing List
On Tue, Oct 27, 2020 at 09:14:20AM +0100, Greg KH wrote:
> Luckily /proc/cpuinfo seems to use the seq_file interface, so this
> series would work for that.
>
> What's the odds of this series getting into 5.10-final? I'll go run it
> through the Android build system right now to see if it fixes the issue
> or not...
It contained a few bits people didn't like too much, and we had no
practical need for it. I'll try to respin it to be a little more
palatable, and will update you once I have results.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: problems with splice from /proc (was Linux 5.10-rc1)
2020-10-27 8:14 ` Greg KH
2020-10-27 8:14 ` Christoph Hellwig
@ 2020-10-27 9:17 ` Greg KH
2020-10-27 16:32 ` Christoph Hellwig
1 sibling, 1 reply; 15+ messages in thread
From: Greg KH @ 2020-10-27 9:17 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Linus Torvalds, Al Viro, Linux Kernel Mailing List
On Tue, Oct 27, 2020 at 09:14:20AM +0100, Greg KH wrote:
> On Tue, Oct 27, 2020 at 08:07:45AM +0000, Christoph Hellwig wrote:
> > On Tue, Oct 27, 2020 at 08:55:41AM +0100, Greg KH wrote:
> > > This is just a test, part of the bionic test suite to verify that bionic
> > > is working properly, and is run on new kernels as a verification that
> > > nothing functional broke in the kernel update.
> > >
> > > I don't know about "real applications" yet.
> > >
> > > Do you have to implement this on a per-proc-file-basis, or will it work
> > > for the whole filesystem?
> > >
> > > And are the patches public anywhere that I could test them out?
> >
> > This all branch has the last posted version:
> >
> > http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/set_fs-rw.2
> >
> > with tthe proc:, sysctl: and seq_file: patches related to it. It did
> > switch over all seq_file instances, but non-seq_file instances and write
> > operations will need manual per-instance work.
>
> Luckily /proc/cpuinfo seems to use the seq_file interface, so this
> series would work for that.
>
> What's the odds of this series getting into 5.10-final? I'll go run it
> through the Android build system right now to see if it fixes the issue
> or not...
Ok, I couldn't get a clean merge of that old branch on top of your
5.10-rc1 tree, so I can't give it a run-through. If you have an updated
series you want me to test, I'll be glad to do so.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: problems with splice from /proc (was Linux 5.10-rc1)
2020-10-27 9:17 ` Greg KH
@ 2020-10-27 16:32 ` Christoph Hellwig
2020-10-27 17:43 ` Greg KH
2020-10-28 16:00 ` Greg KH
0 siblings, 2 replies; 15+ messages in thread
From: Christoph Hellwig @ 2020-10-27 16:32 UTC (permalink / raw)
To: Greg KH
Cc: Christoph Hellwig, Linus Torvalds, Al Viro, Linux Kernel Mailing List
On Tue, Oct 27, 2020 at 10:17:25AM +0100, Greg KH wrote:
> Ok, I couldn't get a clean merge of that old branch on top of your
> 5.10-rc1 tree, so I can't give it a run-through. If you have an updated
> series you want me to test, I'll be glad to do so.
Can you give this branch a spin?
http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/set_fs-proc
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: problems with splice from /proc (was Linux 5.10-rc1)
2020-10-27 16:32 ` Christoph Hellwig
@ 2020-10-27 17:43 ` Greg KH
2020-10-28 16:00 ` Greg KH
1 sibling, 0 replies; 15+ messages in thread
From: Greg KH @ 2020-10-27 17:43 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Linus Torvalds, Al Viro, Linux Kernel Mailing List
On Tue, Oct 27, 2020 at 04:32:13PM +0000, Christoph Hellwig wrote:
> On Tue, Oct 27, 2020 at 10:17:25AM +0100, Greg KH wrote:
> > Ok, I couldn't get a clean merge of that old branch on top of your
> > 5.10-rc1 tree, so I can't give it a run-through. If you have an updated
> > series you want me to test, I'll be glad to do so.
>
> Can you give this branch a spin?
>
> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/set_fs-proc
Will do so in the morning, thanks!
greg k-h
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: problems with splice from /proc (was Linux 5.10-rc1)
2020-10-27 16:32 ` Christoph Hellwig
2020-10-27 17:43 ` Greg KH
@ 2020-10-28 16:00 ` Greg KH
2020-10-28 18:33 ` Greg KH
1 sibling, 1 reply; 15+ messages in thread
From: Greg KH @ 2020-10-28 16:00 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Linus Torvalds, Al Viro, Linux Kernel Mailing List
On Tue, Oct 27, 2020 at 04:32:13PM +0000, Christoph Hellwig wrote:
> On Tue, Oct 27, 2020 at 10:17:25AM +0100, Greg KH wrote:
> > Ok, I couldn't get a clean merge of that old branch on top of your
> > 5.10-rc1 tree, so I can't give it a run-through. If you have an updated
> > series you want me to test, I'll be glad to do so.
>
> Can you give this branch a spin?
>
> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/set_fs-proc
Sorry for the delay, took a while to get results due to other testing
errors...
Anyway, yes, this worked!
So feel free to add:
Tested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If you send those out.
Now I ran into a fnctl test that is failing when reading trying to run
splice on /proc/version (crazy tests), let me go see if I can do the
same thing you did for cpuinfo for all proc "single data" files...
thanks,
greg k-h
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: problems with splice from /proc (was Linux 5.10-rc1)
2020-10-28 16:00 ` Greg KH
@ 2020-10-28 18:33 ` Greg KH
2020-10-28 18:34 ` Christoph Hellwig
2020-10-28 18:35 ` [PATCH] proc "single files": switch to ->read_iter Greg Kroah-Hartman
0 siblings, 2 replies; 15+ messages in thread
From: Greg KH @ 2020-10-28 18:33 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Linus Torvalds, Al Viro, Linux Kernel Mailing List
On Wed, Oct 28, 2020 at 05:00:11PM +0100, Greg KH wrote:
> On Tue, Oct 27, 2020 at 04:32:13PM +0000, Christoph Hellwig wrote:
> > On Tue, Oct 27, 2020 at 10:17:25AM +0100, Greg KH wrote:
> > > Ok, I couldn't get a clean merge of that old branch on top of your
> > > 5.10-rc1 tree, so I can't give it a run-through. If you have an updated
> > > series you want me to test, I'll be glad to do so.
> >
> > Can you give this branch a spin?
> >
> > http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/set_fs-proc
>
> Sorry for the delay, took a while to get results due to other testing
> errors...
>
> Anyway, yes, this worked!
>
> So feel free to add:
>
> Tested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> If you send those out.
>
> Now I ran into a fnctl test that is failing when reading trying to run
> splice on /proc/version (crazy tests), let me go see if I can do the
> same thing you did for cpuinfo for all proc "single data" files...
That worked too, I'll send a patch for this for the top of your branch
to resolve this issue as a response to this email.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: problems with splice from /proc (was Linux 5.10-rc1)
2020-10-28 18:33 ` Greg KH
@ 2020-10-28 18:34 ` Christoph Hellwig
2020-10-28 18:35 ` [PATCH] proc "single files": switch to ->read_iter Greg Kroah-Hartman
1 sibling, 0 replies; 15+ messages in thread
From: Christoph Hellwig @ 2020-10-28 18:34 UTC (permalink / raw)
To: Greg KH
Cc: Christoph Hellwig, Linus Torvalds, Al Viro, Linux Kernel Mailing List
On Wed, Oct 28, 2020 at 07:33:59PM +0100, Greg KH wrote:
> That worked too, I'll send a patch for this for the top of your branch
> to resolve this issue as a response to this email.
In the old branch I had a scripted conversion of all proc_read instances
that point to seq_read to use seq_read_iter. I can probably do that
as well here.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH] proc "single files": switch to ->read_iter
2020-10-28 18:33 ` Greg KH
2020-10-28 18:34 ` Christoph Hellwig
@ 2020-10-28 18:35 ` Greg Kroah-Hartman
1 sibling, 0 replies; 15+ messages in thread
From: Greg Kroah-Hartman @ 2020-10-28 18:35 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Linus Torvalds, Al Viro, Linux Kernel Mailing List
Implement ->read_iter for all proc "single files" so that more bionic
tests cases can pass when they call splice() on other fun files like
/proc/version
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/proc/generic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/proc/generic.c b/fs/proc/generic.c
index 2f9fa179194d..f81327673f49 100644
--- a/fs/proc/generic.c
+++ b/fs/proc/generic.c
@@ -621,7 +621,7 @@ static int proc_single_open(struct inode *inode, struct file *file)
static const struct proc_ops proc_single_ops = {
/* not permanent -- can call into arbitrary ->single_show */
.proc_open = proc_single_open,
- .proc_read = seq_read,
+ .proc_read_iter = seq_read_iter,
.proc_lseek = seq_lseek,
.proc_release = single_release,
};
--
2.29.1
^ permalink raw reply related [flat|nested] 15+ messages in thread
end of thread, other threads:[~2020-10-29 2:11 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-10-25 22:40 Linux 5.10-rc1 Linus Torvalds
2020-10-25 23:43 ` linux-next: stats Stephen Rothwell
2020-10-27 6:48 ` problems with splice from /proc (was Linux 5.10-rc1) Greg KH
2020-10-27 7:49 ` Christoph Hellwig
2020-10-27 7:55 ` Greg KH
2020-10-27 8:07 ` Christoph Hellwig
2020-10-27 8:14 ` Greg KH
2020-10-27 8:14 ` Christoph Hellwig
2020-10-27 9:17 ` Greg KH
2020-10-27 16:32 ` Christoph Hellwig
2020-10-27 17:43 ` Greg KH
2020-10-28 16:00 ` Greg KH
2020-10-28 18:33 ` Greg KH
2020-10-28 18:34 ` Christoph Hellwig
2020-10-28 18:35 ` [PATCH] proc "single files": switch to ->read_iter Greg Kroah-Hartman
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).