1. 23 Aug, 2021 1 commit
    • Jeff Layton's avatar
      fs: remove mandatory file locking support · f7e33bdb
      Jeff Layton authored
      We added CONFIG_MANDATORY_FILE_LOCKING in 2015, and soon after turned it
      off in Fedora and RHEL8. Several other distros have followed suit.
      
      I've heard of one problem in all that time: Someone migrated from an
      older distro that supported "-o mand" to one that didn't, and the host
      had a fstab entry with "mand" in it which broke on reboot. They didn't
      actually _use_ mandatory locking so they just removed the mount option
      and moved on.
      
      This patch rips out mandatory locking support wholesale from the kernel,
      along with the Kconfig option and the Documentation file. It also
      changes the mount code to ignore the "mand" mount option instead of
      erroring out, and to throw a big, ugly warning.
      Signed-off-by: default avatarJeff Layton <jlayton@kernel.org>
      f7e33bdb
  2. 21 Aug, 2021 11 commits
    • Desmond Cheong Zhi Xi's avatar
      fcntl: fix potential deadlock for &fasync_struct.fa_lock · 2f488f69
      Desmond Cheong Zhi Xi authored
      There is an existing lock hierarchy of
      &dev->event_lock --> &fasync_struct.fa_lock --> &f->f_owner.lock
      from the following call chain:
      
        input_inject_event():
          spin_lock_irqsave(&dev->event_lock,...);
          input_handle_event():
            input_pass_values():
              input_to_handler():
                evdev_events():
                  evdev_pass_values():
                    spin_lock(&client->buffer_lock);
                    __pass_event():
                      kill_fasync():
                        kill_fasync_rcu():
                          read_lock(&fa->fa_lock);
                          send_sigio():
                            read_lock_irqsave(&fown->lock,...);
      
      &dev->event_lock is HARDIRQ-safe, so interrupts have to be disabled
      while grabbing &fasync_struct.fa_lock, otherwise we invert the lock
      hierarchy. However, since kill_fasync which calls kill_fasync_rcu is
      an exported symbol, it may not necessarily be called with interrupts
      disabled.
      
      As kill_fasync_rcu may be called with interrupts disabled (for
      example, in the call chain above), we replace calls to
      read_lock/read_unlock on &fasync_struct.fa_lock in kill_fasync_rcu
      with read_lock_irqsave/read_unlock_irqrestore.
      Signed-off-by: default avatarDesmond Cheong Zhi Xi <desmondcheongzx@gmail.com>
      Signed-off-by: default avatarJeff Layton <jlayton@kernel.org>
      2f488f69
    • Desmond Cheong Zhi Xi's avatar
      fcntl: fix potential deadlocks for &fown_struct.lock · f671a691
      Desmond Cheong Zhi Xi authored
      Syzbot reports a potential deadlock in do_fcntl:
      
      ========================================================
      WARNING: possible irq lock inversion dependency detected
      5.12.0-syzkaller #0 Not tainted
      --------------------------------------------------------
      syz-executor132/8391 just changed the state of lock:
      ffff888015967bf8 (&f->f_owner.lock){.+..}-{2:2}, at: f_getown_ex fs/fcntl.c:211 [inline]
      ffff888015967bf8 (&f->f_owner.lock){.+..}-{2:2}, at: do_fcntl+0x8b4/0x1200 fs/fcntl.c:395
      but this lock was taken by another, HARDIRQ-safe lock in the past:
       (&dev->event_lock){-...}-{2:2}
      
      and interrupts could create inverse lock ordering between them.
      
      other info that might help us debug this:
      Chain exists of:
        &dev->event_lock --> &new->fa_lock --> &f->f_owner.lock
      
       Possible interrupt unsafe locking scenario:
      
             CPU0                    CPU1
             ----                    ----
        lock(&f->f_owner.lock);
                                     local_irq_disable();
                                     lock(&dev->event_lock);
                                     lock(&new->fa_lock);
        <Interrupt>
          lock(&dev->event_lock);
      
       *** DEADLOCK ***
      
      This happens because there is a lock hierarchy of
      &dev->event_lock --> &new->fa_lock --> &f->f_owner.lock
      from the following call chain:
      
        input_inject_event():
          spin_lock_irqsave(&dev->event_lock,...);
          input_handle_event():
            input_pass_values():
              input_to_handler():
                evdev_events():
                  evdev_pass_values():
                    spin_lock(&client->buffer_lock);
                    __pass_event():
                      kill_fasync():
                        kill_fasync_rcu():
                          read_lock(&fa->fa_lock);
                          send_sigio():
                            read_lock_irqsave(&fown->lock,...);
      
      However, since &dev->event_lock is HARDIRQ-safe, interrupts have to be
      disabled while grabbing &f->f_owner.lock, otherwise we invert the lock
      hierarchy.
      
      Hence, we replace calls to read_lock/read_unlock on &f->f_owner.lock,
      with read_lock_irq/read_unlock_irq.
      
      Reported-and-tested-by: syzbot+e6d5398a02c516ce5e70@syzkaller.appspotmail.com
      Signed-off-by: default avatarDesmond Cheong Zhi Xi <desmondcheongzx@gmail.com>
      Signed-off-by: default avatarJeff Layton <jlayton@kernel.org>
      f671a691
    • Linus Torvalds's avatar
      Merge tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux · 9ff50bf2
      Linus Torvalds authored
      Pull clk driver fixes from Stephen Boyd:
      
       - Make the regulator state match the GDSC power domain state at boot on
         Qualcomm SoCs so that the regulator isn't turned off inadvertently.
      
       - Fix earlycon on i.MX6Q SoCs
      
      * tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux:
        clk: qcom: gdsc: Ensure regulator init state matches GDSC state
        clk: imx6q: fix uart earlycon unwork
      9ff50bf2
    • Linus Torvalds's avatar
      Merge tag 'char-misc-5.14-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc · 9085423f
      Linus Torvalds authored
      Pull char/misc driver fixes from Greg KH:
       "Here are some small driver fixes for 5.14-rc7.
      
        They consist of:
      
         - revert for an interconnect patch that was found to have problems
      
         - ipack tpci200 driver fixes for reported problems
      
         - slimbus messaging and ngd fixes for reported problems
      
        All are small and have been in linux-next for a while with no reported
        issues"
      
      * tag 'char-misc-5.14-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc:
        ipack: tpci200: fix memory leak in the tpci200_register
        ipack: tpci200: fix many double free issues in tpci200_pci_probe
        slimbus: ngd: reset dma setup during runtime pm
        slimbus: ngd: set correct device for pm
        slimbus: messaging: check for valid transaction id
        slimbus: messaging: start transaction ids from 1 instead of zero
        Revert "interconnect: qcom: icc-rpmh: Add BCMs to commit list in pre_aggregate"
      9085423f
    • Linus Torvalds's avatar
      Merge tag 'usb-5.14-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb · f4ff9e6b
      Linus Torvalds authored
      Pull USB fix from Greg KH:
       "Here is a single USB typec tcpm fix for a reported problem for
        5.14-rc7. It showed up in 5.13 and resolves an issue that Hans found.
        It has been in linux-next this week with no reported problems"
      
      * tag 'usb-5.14-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
        usb: typec: tcpm: Fix VDMs sometimes not being forwarded to alt-mode drivers
      f4ff9e6b
    • Linus Torvalds's avatar
      Merge tag 'riscv-for-linus-5.14-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux · a09434f1
      Linus Torvalds authored
      Pull RISC-V fixes from Palmer Dabbelt:
      
       - fix the sifive-l2-cache device tree bindings for json-schema
         compatibility. This does not change the intended behavior of the
         binding.
      
       - avoid improperly freeing necessary resources during early boot.
      
      * tag 'riscv-for-linus-5.14-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux:
        riscv: Fix a number of free'd resources in init_resources()
        dt-bindings: sifive-l2-cache: Fix 'select' matching
      a09434f1
    • Linus Torvalds's avatar
      Merge tag 's390-5.14-5' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux · 5479a7fe
      Linus Torvalds authored
      Pull s390 fix from Vasily Gorbik:
      
       - fix use after free of zpci_dev in pci code
      
      * tag 's390-5.14-5' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
        s390/pci: fix use after free of zpci_dev
      5479a7fe
    • Linus Torvalds's avatar
      Merge tag 'locks-v5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/jlayton/linux · 15517c72
      Linus Torvalds authored
      Pull mandatory file locking deprecation warning from Jeff Layton:
       "As discussed on the list, this patch just adds a new warning for folks
        who still have mandatory locking enabled and actually mount with '-o
        mand'. I'd like to get this in for v5.14 so we can push this out into
        stable kernels and hopefully reach folks who have mounts with -o mand.
      
        For now, I'm operating under the assumption that we'll fully remove
        this support in v5.15, but we can move that out if any legitimate
        users of this facility speak up between now and then"
      
      * tag 'locks-v5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/jlayton/linux:
        fs: warn about impending deprecation of mandatory locks
      15517c72
    • Linus Torvalds's avatar
      Merge tag 'block-5.14-2021-08-20' of git://git.kernel.dk/linux-block · 002c0aef
      Linus Torvalds authored
      Pull block fixes from Jens Axboe:
       "Three fixes from Ming Lei that should go into 5.14:
      
         - Fix for a kernel panic when iterating over tags for some cases
           where a flush request is present, a regression in this cycle.
      
         - Request timeout fix
      
         - Fix flush request checking"
      
      * tag 'block-5.14-2021-08-20' of git://git.kernel.dk/linux-block:
        blk-mq: fix is_flush_rq
        blk-mq: fix kernel panic during iterating over flush request
        blk-mq: don't grab rq's refcount in blk_mq_check_expired()
      002c0aef
    • Linus Torvalds's avatar
      Merge tag 'io_uring-5.14-2021-08-20' of git://git.kernel.dk/linux-block · 1e6907d5
      Linus Torvalds authored
      Pull io_uring fixes from Jens Axboe:
       "A few small fixes that should go into this release:
      
         - Fix never re-assigning an initial error value for io_uring_enter()
           for SQPOLL, if asked to do nothing
      
         - Fix xa_alloc_cycle() return value checking, for cases where we have
           wrapped around
      
         - Fix for a ctx pin issue introduced in this cycle (Pavel)"
      
      * tag 'io_uring-5.14-2021-08-20' of git://git.kernel.dk/linux-block:
        io_uring: fix xa_alloc_cycle() error return value check
        io_uring: pin ctx on fallback execution
        io_uring: only assign io_uring_enter() SQPOLL error in actual error case
      1e6907d5
    • Jeff Layton's avatar
      fs: warn about impending deprecation of mandatory locks · fdd92b64
      Jeff Layton authored
      We've had CONFIG_MANDATORY_FILE_LOCKING since 2015 and a lot of distros
      have disabled it. Warn the stragglers that still use "-o mand" that
      we'll be dropping support for that mount option.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJeff Layton <jlayton@kernel.org>
      fdd92b64
  3. 20 Aug, 2021 26 commits
  4. 19 Aug, 2021 2 commits