LKML Archive on lore.kernel.org
 help / color / Atom feed
* 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	[flat|nested] 15+ messages in thread

end of thread, back to index

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

LKML Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git
	git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git
	git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git
	git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git
	git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git
	git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git
	git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git
	git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git
	git clone --mirror https://lore.kernel.org/lkml/8 lkml/git/8.git
	git clone --mirror https://lore.kernel.org/lkml/9 lkml/git/9.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \
		linux-kernel@vger.kernel.org
	public-inbox-index lkml

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git