Skip to content

L
linux
Switch branch/tag
  1. 27 Jul, 2023 2 commits
  3. 25 Jul, 2023 1 commit
  5. 24 Jul, 2023 4 commits
  7. 21 Jul, 2023 3 commits
    • Mauricio Faria de Oliveira's avatar
      loop: do not enforce max_loop hard limit by (new) default · bb5faa99
      Mauricio Faria de Oliveira authored 
      Problem:

The max_loop parameter is used for 2 different purposes:

1) initial number of loop devices to pre-create on init
2) maximum number of loop devices to add on access/open()

Historically, its default value (zero) caused 1) to create non-zero
number of devices (CONFIG_BLK_DEV_LOOP_MIN_COUNT), and no hard limit on
2) to add devices with autoloading.

However, the default value changed in commit 85c50197 ("loop: Fix
the max_loop commandline argument treatment when it is set to 0") to
CONFIG_BLK_DEV_LOOP_MIN_COUNT, for max_loop=0 not to pre-create devices.

That does improve 1), but unfortunately it breaks 2), as the default
behavior changed from no-limit to hard-limit.

Example:

For example, this userspace code broke for N >= CONFIG, if the user
relied on the default value 0 for max_loop:

    mknod("/dev/loopN");
    open("/dev/loopN");  // now fails with ENXIO

Though affected users may "fix" it with (loop.)max_loop=0, this means to
require a kernel parameter change on stable kernel update (that commit
Fixes: an old commit in stable).

Solution:

The original semantics for the default value in 2) can be applied if the
parameter is not set (ie, default behavior).

This still keeps the intended function in 1) and 2) if set, and that
commit's intended improvement in 1) if max_loop=0.

Before 85c50197:
  - default:     1) CONFIG devices   2) no limit
  - max_loop=0:  1) CONFIG devices   2) no limit
  - max_loop=X:  1) X devices        2) X limit

After 85c50197:
  - default:     1) CONFIG devices   2) CONFIG limit (*)
  - max_loop=0:  1) 0 devices (*)    2) no limit
  - max_loop=X:  1) X devices        2) X limit

This commit:
  - default:     1) CONFIG devices   2) no limit (*)
  - max_loop=0:  1) 0 devices        2) no limit
  - max_loop=X:  1) X devices        2) X limit

Future:

The issue/regression from that commit only affects code under the
CONFIG_BLOCK_LEGACY_AUTOLOAD deprecation guard, thus the fix too is
contained under it.

Once that deprecated functionality/code is removed, the purpose 2) of
max_loop (hard limit) is no longer in use, so the module parameter
description can be changed then.

Tests:

Linux 6.4-rc7
CONFIG_BLK_DEV_LOOP_MIN_COUNT=8
CONFIG_BLOCK_LEGACY_AUTOLOAD=y

- default (original)

	# ls -1 /dev/loop*
	/dev/loop-control
	/dev/loop0
	...
	/dev/loop7

	# ./test-loop
	open: /dev/loop8: No such device or address

- default (patched)

	# ls -1 /dev/loop*
	/dev/loop-control
	/dev/loop0
	...
	/dev/loop7

	# ./test-loop
	#

- max_loop=0 (original & patched):

	# ls -1 /dev/loop*
	/dev/loop-control

	# ./test-loop
	#

- max_loop=8 (original & patched):

	# ls -1 /dev/loop*
	/dev/loop-control
	/dev/loop0
	...
	/dev/loop7

	# ./test-loop
	open: /dev/loop8: No such device or address

- max_loop=0 (patched; CONFIG_BLOCK_LEGACY_AUTOLOAD is not set)

	# ls -1 /dev/loop*
	/dev/loop-control

	# ./test-loop
	open: /dev/loop8: No such device or address

Fixes: 85c50197 ("loop: Fix the max_loop commandline argument treatment when it is set to 0")
Signed-off-by: default avatarMauricio Faria de Oliveira <mfo@canonical.com>
Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
Link: https://lore.kernel.org/r/20230720143033.841001-3-mfo@canonical.comSigned-off-by: default avatarJens Axboe <axboe@kernel.dk>
      bb5faa99
    • Mauricio Faria de Oliveira's avatar
      loop: deprecate autoloading callback loop_probe() · 23881aec
      Mauricio Faria de Oliveira authored 
      The 'probe' callback in __register_blkdev() is only used under the
CONFIG_BLOCK_LEGACY_AUTOLOAD deprecation guard.

The loop_probe() function is only used for that callback, so guard it
too, accordingly.

See commit fbdee71b ("block: deprecate autoloading based on dev_t").
Signed-off-by: default avatarMauricio Faria de Oliveira <mfo@canonical.com>
Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
Link: https://lore.kernel.org/r/20230720143033.841001-2-mfo@canonical.comSigned-off-by: default avatarJens Axboe <axboe@kernel.dk>
      23881aec
    • David Jeffery's avatar
      sbitmap: fix batching wakeup · 10639737
      David Jeffery authored 
      Current code supposes that it is enough to provide forward progress by
just waking up one wait queue after one completion batch is done.

Unfortunately this way isn't enough, cause waiter can be added to wait
queue just after it is woken up.

Follows one example(64 depth, wake_batch is 8)

1) all 64 tags are active

2) in each wait queue, there is only one single waiter

3) each time one completion batch(8 completions) wakes up just one
   waiter in each wait queue, then immediately one new sleeper is added
   to this wait queue

4) after 64 completions, 8 waiters are wakeup, and there are still 8
   waiters in each wait queue

5) after another 8 active tags are completed, only one waiter can be
   wakeup, and the other 7 can't be waken up anymore.

Turns out it isn't easy to fix this problem, so simply wakeup enough
waiters for single batch.

Cc: Kemeng Shi <shikemeng@huaweicloud.com>
Cc: Chengming Zhou <zhouchengming@bytedance.com>
Cc: Jan Kara <jack@suse.cz>
Signed-off-by: default avatarDavid Jeffery <djeffery@redhat.com>
Signed-off-by: default avatarMing Lei <ming.lei@redhat.com>
Reviewed-by: default avatarGabriel Krisman Bertazi <krisman@suse.de>
Reviewed-by: default avatarKeith Busch <kbusch@kernel.org>
Link: https://lore.kernel.org/r/20230721095715.232728-1-ming.lei@redhat.comSigned-off-by: default avatarJens Axboe <axboe@kernel.dk>
      10639737
  9. 20 Jul, 2023 2 commits
  11. 14 Jul, 2023 2 commits
  13. 13 Jul, 2023 4 commits
    • Jens Axboe's avatar
      Merge tag 'nvme-6.5-2023-07-13' of git://git.infradead.org/nvme into block-6.5 · 90b46229
      Jens Axboe authored 
      Pull NVMe fixes from Keith:

"nvme fixes for Linux 6.5

 - Don't require quirk to use duplicate namespace identifiers
   (Christoph, Sagi)
 - One more BOGUS_NID quirk (Pankaj)
 - IO timeout and error hanlding fixes for PCI (Keith)
 - Enhanced metadata format mask fix (Ankit)
 - Association race condition fix for fibre channel (Michael)
 - Correct debugfs error checks (Minjie)
 - Use PAGE_SECTORS_SHIFT where needed (Damien)
 - Reduce kernel logs for legacy nguid attribute (Keith)
 - Use correct dma direction when unmapping metadata (Ming)"

* tag 'nvme-6.5-2023-07-13' of git://git.infradead.org/nvme:
  nvme-pci: fix DMA direction of unmapping integrity data
  nvme: don't reject probe due to duplicate IDs for single-ported PCIe devices
  nvme: ensure disabling pairs with unquiesce
  nvme-fc: fix race between error recovery and creating association
  nvme-fc: return non-zero status code when fails to create association
  nvme: fix parameter check in nvme_fault_inject_init()
  nvme: warn only once for legacy uuid attribute
  nvme: fix the NVME_ID_NS_NVM_STS_MASK definition
  nvmet: use PAGE_SECTORS_SHIFT
  nvme: add BOGUS_NID quirk for Samsung SM953
      90b46229
    • Chengming Zhou's avatar
      blk-mq: fix start_time_ns and alloc_time_ns for pre-allocated rq · 5c17f45e
      Chengming Zhou authored 
      The iocost rely on rq start_time_ns and alloc_time_ns to tell saturation
state of the block device. Most of the time request is allocated after
rq_qos_throttle() and its alloc_time_ns or start_time_ns won't be affected.

But for plug batched allocation introduced by the commit 47c122e3
("block: pre-allocate requests if plug is started and is a batch"), we can
rq_qos_throttle() after the allocation of the request. This is what the
blk_mq_get_cached_request() does.

In this case, the cached request alloc_time_ns or start_time_ns is much
ahead if blocked in any qos ->throttle().

Fix it by setting alloc_time_ns and start_time_ns to now when the allocated
request is actually used.
Signed-off-by: default avatarChengming Zhou <zhouchengming@bytedance.com>
Acked-by: default avatarTejun Heo <tj@kernel.org>
Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
Link: https://lore.kernel.org/r/20230710105516.2053478-1-chengming.zhou@linux.devSigned-off-by: default avatarJens Axboe <axboe@kernel.dk>
      5c17f45e
    • Ming Lei's avatar
      nvme-pci: fix DMA direction of unmapping integrity data · b8f6446b
      Ming Lei authored 
      DMA direction should be taken in dma_unmap_page() for unmapping integrity
data.

Fix this DMA direction, and reported in Guangwu's test.
Reported-by: default avatarGuangwu Zhang <guazhang@redhat.com>
Fixes: 4aedb705 ("nvme-pci: split metadata handling from nvme_map_data / nvme_unmap_data")
Signed-off-by: default avatarMing Lei <ming.lei@redhat.com>
Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
Signed-off-by: default avatarKeith Busch <kbusch@kernel.org>
      b8f6446b
    • Christoph Hellwig's avatar
      nvme: don't reject probe due to duplicate IDs for single-ported PCIe devices · ac522fc6
      Christoph Hellwig authored 
      While duplicate IDs are still very harmful, including the potential to easily
see changing devices in /dev/disk/by-id, it turn out they are extremely
common for cheap end user NVMe devices.

Relax our check for them for so that it doesn't reject the probe on
single-ported PCIe devices, but prints a big warning instead.  In doubt
we'd still like to see quirk entries to disable the potential for
changing supposed stable device identifier links, but this will at least
allow users how have two (or more) of these devices to use them without
having to manually add a new PCI ID entry with the quirk through sysfs or
by patching the kernel.

Fixes: 2079f41e ("nvme: check that EUI/GUID/UUID are globally unique")
Cc: stable@vger.kernel.org # 6.0+
Co-developed-by: default avatarSagi Grimberg <sagi@grimberg.me>
Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
Signed-off-by: default avatarKeith Busch <kbusch@kernel.org>
      ac522fc6
  15. 12 Jul, 2023 6 commits
  17. 10 Jul, 2023 4 commits
  19. 05 Jul, 2023 3 commits
    • Eric Biggers's avatar
      blk-crypto: use dynamic lock class for blk_crypto_profile::lock · 2fb48d88
      Eric Biggers authored 
      When a device-mapper device is passing through the inline encryption
support of an underlying device, calls to blk_crypto_evict_key() take
the blk_crypto_profile::lock of the device-mapper device, then take the
blk_crypto_profile::lock of the underlying device (nested).  This isn't
a real deadlock, but it causes a lockdep report because there is only
one lock class for all instances of this lock.

Lockdep subclasses don't really work here because the hierarchy of block
devices is dynamic and could have more than 2 levels.

Instead, register a dynamic lock class for each blk_crypto_profile, and
associate that with the lock.

This avoids false-positive lockdep reports like the following:

    ============================================
    WARNING: possible recursive locking detected
    6.4.0-rc5 #2 Not tainted
    --------------------------------------------
    fscryptctl/1421 is trying to acquire lock:
    ffffff80829ca418 (&profile->lock){++++}-{3:3}, at: __blk_crypto_evict_key+0x44/0x1c0

                   but task is already holding lock:
    ffffff8086b68ca8 (&profile->lock){++++}-{3:3}, at: __blk_crypto_evict_key+0xc8/0x1c0

                   other info that might help us debug this:
     Possible unsafe locking scenario:

           CPU0
           ----
      lock(&profile->lock);
      lock(&profile->lock);

                    *** DEADLOCK ***

     May be due to missing lock nesting notation

Fixes: 1b262839 ("block: Keyslot Manager for Inline Encryption")
Reported-by: default avatarBart Van Assche <bvanassche@acm.org>
Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
Reviewed-by: default avatarBart Van Assche <bvanassche@acm.org>
Link: https://lore.kernel.org/r/20230610061139.212085-1-ebiggers@kernel.orgSigned-off-by: default avatarJens Axboe <axboe@kernel.dk>
      2fb48d88
    • Michael Schmitz's avatar
      block/partition: fix signedness issue for Amiga partitions · 7eb1e476
      Michael Schmitz authored 
      Making 'blk' sector_t (i.e. 64 bit if LBD support is active) fails the
'blk>0' test in the partition block loop if a value of (signed int) -1 is
used to mark the end of the partition block list.

Explicitly cast 'blk' to signed int to allow use of -1 to terminate the
partition block linked list.

Fixes: b6f3f28f ("block: add overflow checks for Amiga partition support")
Reported-by: default avatarChristian Zigotzky <chzigotzky@xenosoft.de>
Link: https://lore.kernel.org/r/024ce4fa-cc6d-50a2-9aae-3701d0ebf668@xenosoft.deSigned-off-by: default avatarMichael Schmitz <schmitzmic@gmail.com>
Reviewed-by: default avatarMartin Steigerwald <martin@lichtvoll.de>
Tested-by: default avatarChristian Zigotzky <chzigotzky@xenosoft.de>
Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      7eb1e476
    • Linus Torvalds's avatar
      gup: make the stack expansion warning a bit more targeted · 6cd06ab1
      Linus Torvalds authored 
      I added a warning about about GUP no longer expanding the stack in
commit a425ac53 ("gup: add warning if some caller would seem to want
stack expansion"), but didn't really expect anybody to hit it.

And it's true that nobody seems to have hit a _real_ case yet, but we
certainly have a number of reports of false positives.  Which not only
causes extra noise in itself, but might also end up hiding any real
cases if they do exist.

So let's tighten up the warning condition, and replace the simplistic

	vma = find_vma(mm, start);
	if (vma && (start < vma->vm_start)) {
		WARN_ON_ONCE(vma->vm_flags & VM_GROWSDOWN);

with a

	vma = gup_vma_lookup(mm, start);

helper function which works otherwise like just "vma_lookup()", but with
some heuristics for when to warn about gup no longer causing stack
expansion.

In particular, don't just warn for "below the stack", but warn if it's
_just_ below the stack (with "just below" arbitrarily defined as 64kB,
because why not?).  And rate-limit it to at most once per hour, which
means that any false positives shouldn't completely hide subsequent
reports, but we won't be flooding the logs about it either.

The previous code triggered when some GUP user (chromium crashpad)
accessing past the end of the previous vma, for example.  That has never
expanded the stack, it just causes GUP to return early, and as such we
shouldn't be warning about it.

This is still going trigger the randomized testers, but to mitigate the
noise from that, use "dump_stack()" instead of "WARN_ON_ONCE()" to get
the kernel call chain.  We'll get the relevant information, but syzbot
shouldn't get too upset about it.

Also, don't even bother with the GROWSUP case, which would be using
different heuristics entirely, but only happens on parisc.
Reported-by: default avatarkernel test robot <oliver.sang@intel.com>
Reported-by: default avatarJohn Hubbard <jhubbard@nvidia.com>
Reported-by: syzbot+6cf44e127903fdf9d929@syzkaller.appspotmail.com
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      6cd06ab1
  21. 04 Jul, 2023 9 commits
    • Linus Torvalds's avatar
      Revert ".gitignore: ignore *.cover and *.mbx" · d5280145
      Linus Torvalds authored 
      This reverts commit 534066a9.

It's actively detrimental in that it hides files that shouldn't be
hidden.

If I have some b4 mbx file in my git directory, it either was already
applied with "git am" and is now stale, or maybe it's waiting for that
to happen.  In neither case is "ignore it" the right option.
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      d5280145
    • Linus Torvalds's avatar
      Merge tag 'core_guards_for_6.5_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue · 04f2933d
      Linus Torvalds authored 
      Pull scope-based resource management infrastructure from Peter Zijlstra:
 "These are the first few patches in the Scope-based Resource Management
  series that introduce the infrastructure but not any conversions as of
  yet.

  Adding the infrastructure now allows multiple people to start using
  them.

  Of note is that Sparse will need some work since it doesn't yet
  understand this attribute and might have decl-after-stmt issues"

* tag 'core_guards_for_6.5_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue:
  kbuild: Drop -Wdeclaration-after-statement
  locking: Introduce __cleanup() based infrastructure
  apparmor: Free up __cleanup() name
  dmaengine: ioat: Free up __cleanup() name
      04f2933d
    • David Howells's avatar
      afs: Fix accidental truncation when storing data · 03275585
      David Howells authored 
      When an AFS FS.StoreData RPC call is made, amongst other things it is
given the resultant file size to be.  On the server, this is processed
by truncating the file to new size and then writing the data.

Now, kafs has a lock (vnode->io_lock) that serves to serialise
operations against a specific vnode (ie.  inode), but the parameters for
the op are set before the lock is taken.  This allows two writebacks
(say sync and kswapd) to race - and if writes are ongoing the writeback
for a later write could occur before the writeback for an earlier one if
the latter gets interrupted.

Note that afs_writepages() cannot take i_mutex and only takes a shared
lock on vnode->validate_lock.

Also note that the server does the truncation and the write inside a
lock, so there's no problem at that end.

Fix this by moving the calculation for the proposed new i_size inside
the vnode->io_lock.  Also reset the iterator (which we might have read
from) and update the mtime setting there.

Fixes: bd80d8a8 ("afs: Use ITER_XARRAY for writing")
Reported-by: default avatarMarc Dionne <marc.dionne@auristor.com>
Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
Reviewed-by: default avatarJeffrey Altman <jaltman@auristor.com>
Reviewed-by: default avatarMarc Dionne <marc.dionne@auristor.com>
cc: linux-afs@lists.infradead.org
cc: linux-fsdevel@vger.kernel.org
Link: https://lore.kernel.org/r/3526895.1687960024@warthog.procyon.org.uk/Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      03275585
    • Linus Torvalds's avatar
      Merge tag 'ovl-update-6.5-2' of git://git.kernel.org/pub/scm/linux/kernel/git/overlayfs/vfs · 538140ca
      Linus Torvalds authored 
      Pull more overlayfs updates from Amir Goldstein:
 "This is a small 'move code around' followup by Christian to his work
  on porting overlayfs to the new mount api for 6.5. It makes things a
  bit cleaner and simpler for the next development cycle when I hand
  overlayfs back over to Miklos"

* tag 'ovl-update-6.5-2' of git://git.kernel.org/pub/scm/linux/kernel/git/overlayfs/vfs:
  ovl: move all parameter handling into params.{c,h}
      538140ca
    • Linus Torvalds's avatar
      Merge tag 'gfs2-v6.4-rc5-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2 · 94c76955
      Linus Torvalds authored 
      Pull gfs2 updates from Andreas Gruenbacher:

 - Move the freeze/thaw logic from glock callback context to process /
   worker thread context to prevent deadlocks

 - Fix a quota reference couting bug in do_qc()

 - Carry on deallocating inodes even when gfs2_rindex_update() fails

 - Retry filesystem-internal reads when they are interruped by a signal

 - Eliminate kmap_atomic() in favor of kmap_local_page() /
   memcpy_{from,to}_page()

 - Get rid of noop_direct_IO

 - And a few more minor fixes and cleanups

* tag 'gfs2-v6.4-rc5-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2: (23 commits)
  gfs2: Add quota_change type
  gfs2: Use memcpy_{from,to}_page where appropriate
  gfs2: Convert remaining kmap_atomic calls to kmap_local_page
  gfs2: Replace deprecated kmap_atomic with kmap_local_page
  gfs: Get rid of unnucessary locking in inode_go_dump
  gfs2: gfs2_freeze_lock_shared cleanup
  gfs2: Replace sd_freeze_state with SDF_FROZEN flag
  gfs2: Rework freeze / thaw logic
  gfs2: Rename SDF_{FS_FROZEN => FREEZE_INITIATOR}
  gfs2: Reconfiguring frozen filesystem already rejected
  gfs2: Rename gfs2_freeze_lock{ => _shared }
  gfs2: Rename the {freeze,thaw}_super callbacks
  gfs2: Rename remaining "transaction" glock references
  gfs2: retry interrupted internal reads
  gfs2: Fix possible data races in gfs2_show_options()
  gfs2: Fix duplicate should_fault_in_pages() call
  gfs2: set FMODE_CAN_ODIRECT instead of a dummy direct_IO method
  gfs2: Don't remember delete unless it's successful
  gfs2: Update rl_unlinked before releasing rgrp lock
  gfs2: Fix gfs2_qa_get imbalance in gfs2_quota_hold
  ...
      94c76955
    • Linus Torvalds's avatar
      Merge tag 'pm-6.5-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm · ccf46d85
      Linus Torvalds authored 
      Pull more power management updates from Rafael Wysocki:
 "These add support for new hardware (ap807 and AM62A7), fix several
  issues in cpufreq drivers and in the operating performance points
  (OPP) framework, fix up intel_idle after recent changes and add
  documentation.

  Specifics:

   - Add missing __init annotation to one function in the intel_idle
     drvier (Rafael Wysocki)

   - Make intel_pstate use a correct scaling factor when mapping HWP
     performance levels to frequency values on hybrid-capable systems
     with disabled E-cores (Srinivas Pandruvada)

   - Fix Kconfig dependencies of the cpufreq-dt-platform driver (Viresh
     Kumar)

   - Add support to build cpufreq-dt-platdev as a module (Zhipeng Wang)

   - Don't allocate Sparc's cpufreq_driver dynamically (Viresh Kumar)

   - Add support for TI's AM62A7 platform (Vibhore Vardhan)

   - Add support for Armada's ap807 platform (Russell King (Oracle))

   - Add support for StarFive JH7110 SoC (Mason Huo)

   - Fix voltage selection for Mediatek Socs (Daniel Golle)

   - Fix error handling in Tegra's cpufreq driver (Christophe JAILLET)

   - Document Qualcomm's IPQ8074 in DT bindings (Robert Marko)

   - Don't warn for disabling a non-existing frequency for imx6q cpufreq
     driver (Christoph Niedermaier)

   - Use dev_err_probe() in Qualcomm's cpufreq driver (Andrew Halaney)

   - Simplify performance state related logic in the OPP core (Viresh
     Kumar)

   - Fix use-after-free and improve locking around lazy_opp_tables
     (Viresh Kumar, Stephan Gerhold)

   - Minor cleanups - using dev_err_probe() and rate-limiting debug
     messages (Andrew Halaney, Adrián Larumbe)"

* tag 'pm-6.5-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (23 commits)
  cpufreq: intel_pstate: Fix scaling for hybrid-capable systems with disabled E-cores
  cpufreq: Make CONFIG_CPUFREQ_DT_PLATDEV depend on OF
  intel_idle: Add __init annotation to matchup_vm_state_with_baremetal()
  OPP: Properly propagate error along when failing to get icc_path
  OPP: Use dev_err_probe() when failing to get icc_path
  cpufreq: qcom-cpufreq-hw: Use dev_err_probe() when failing to get icc paths
  cpufreq: mediatek: correct voltages for MT7622 and MT7623
  cpufreq: armada-8k: add ap807 support
  OPP: Simplify the over-designed pstate <-> level dance
  OPP: pstate is only valid for genpd OPP tables
  OPP: don't drop performance constraint on OPP table removal
  OPP: Protect `lazy_opp_tables` list with `opp_table_lock`
  OPP: Staticize `lazy_opp_tables` in of.c
  cpufreq: dt-platdev: Support building as module
  opp: Fix use-after-free in lazy_opp_tables after probe deferral
  dt-bindings: cpufreq: qcom-cpufreq-nvmem: document IPQ8074
  cpufreq: dt-platdev: Blacklist ti,am62a7 SoC
  cpufreq: ti-cpufreq: Add support for AM62A7
  OPP: rate-limit debug messages when no change in OPP is required
  cpufreq: imx6q: don't warn for disabling a non-existing frequency
  ...
      ccf46d85
    • Linus Torvalds's avatar
      Merge tag 'clk-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux · b869e9f4
      Linus Torvalds authored 
      Pull more clk updates from Stephen Boyd:
 "Another set of clk driver updates and fixes for the merge window. The
  driver updates needed more time to bake in linux-next.

  Updates:
   - Support for more clk controllers in Qualcomm SoCs such as SM8350,
     SM8450, SDX75, SC8280XP, and IPQ9574
   - Runtime PM enablement of some more Qualcomm clk controllers
   - Various fixes to Qualcomm clk driver data to use correct clk_ops
     and to check halt bits properly
   - AT91 updates to modernize with clk_parent_data structures

  Fixes:
   - Remove 'syscon' from dt binding fix for ti,j721e-system-controller
   - Fix determine rate in the Tegra driver that got wrecked by the
     refactorting of muxes this merge window"

* tag 'clk-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux: (69 commits)
  clk: tegra: Avoid calling an uninitialized function
  dt-bindings: mfd: ti,j721e-system-controller: Remove syscon from example
  clk: at91: sama7g5: s/ep_chg_chg_id/ep_chg_id
  clk: at91: sama7g5: switch to parent_hw and parent_data
  clk: at91: sckc: switch to parent_data/parent_hw
  clk: at91: clk-sam9x60-pll: add support for parent_hw
  clk: at91: clk-utmi: add support for parent_hw
  clk: at91: clk-system: add support for parent_hw
  clk: at91: clk-programmable: add support for parent_hw
  clk: at91: clk-peripheral: add support for parent_hw
  clk: at91: clk-master: add support for parent_hw
  clk: at91: clk-generated: add support for parent_hw
  clk: at91: clk-main: add support for parent_data/parent_hw
  clk: qcom: gcc-sc8280xp: Add runtime PM
  clk: qcom: gpucc-sc8280xp: Add runtime PM
  clk: qcom: mmcc-msm8974: fix MDSS_GDSC power flags
  clk: qcom: gpucc-sm6375: Enable runtime pm
  dt-bindings: clock: sm6375-gpucc: Add VDD_GX
  clk: qcom: gcc-sm6115: Add missing PLL config properties
  clk: qcom: clk-alpha-pll: Add a way to update some bits of test_ctl(_hi)
  ...
      b869e9f4
    • Linus Torvalds's avatar
      Merge tag 'firewire-6.5-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394 · 406fb9eb
      Linus Torvalds authored 
      Pull firewire updates from Takashi Sakamoto:
 "This consist of three parts; UAPI update, OHCI driver update, and
  several bug fixes.

  Firstly, the 1394 OHCI specification defines method to retrieve
  hardware time stamps for asynchronous communication, which was
  previously unavailable in user space. This adds new events to the
  UAPI, allowing applications to retrieve the time when asynchronous
  packet are received and sent. The new events are tested in the
  bleeding edge of libhinawa and look to work well. The new version of
  libhinawa will be released after current merge window is closed:

    https://git.kernel.org/pub/scm/libs/ieee1394/libhinawa.git/

  Secondly, the FireWire stack includes a PCM device driver for 1394
  OHCI hardware, This change modernizes the driver by managed resource
  (devres) framework.

  Lastly, bug fixes for firewire-net and firewire-core"

* tag 'firewire-6.5-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394: (25 commits)
  firewire: net: fix use after free in fwnet_finish_incoming_packet()
  firewire: core: obsolete usage of GFP_ATOMIC at building node tree
  firewire: ohci: release buffer for AR req/resp contexts when managed resource is released
  firewire: ohci: use devres for content of configuration ROM
  firewire: ohci: use devres for IT, IR, AT/receive, and AT/request contexts
  firewire: ohci: use devres for list of isochronous contexts
  firewire: ohci: use devres for requested IRQ
  firewire: ohci: use devres for misc DMA buffer
  firewire: ohci: use devres for MMIO region mapping
  firewire: ohci: use devres for PCI-related resources
  firewire: ohci: use devres for memory object of ohci structure
  firewire: fix warnings to generate UAPI documentation
  firewire: fix build failure due to missing module license
  firewire: cdev: implement new event relevant to phy packet with time stamp
  firewire: cdev: add new event to notify phy packet with time stamp
  firewire: cdev: code refactoring to dispatch event for phy packet
  firewire: cdev: implement new event to notify response subaction with time stamp
  firewire: cdev: add new event to notify response subaction with time stamp
  firewire: cdev: code refactoring to operate event of response
  firewire: core: implement variations to send request and wait for response with time stamp
  ...
      406fb9eb
    • Linus Torvalds's avatar
      module: fix init_module_from_file() error handling · f1962207
      Linus Torvalds authored 
      Vegard Nossum pointed out two different problems with the error handling
in init_module_from_file():

 (a) the idempotent loading code didn't clean up properly in some error
     cases, leaving the on-stack 'struct idempotent' element still in
     the hash table

 (b) failure to read the module file would nonsensically update the
     'invalid_kread_bytes' stat counter with the error value

The first error is quite nasty, in that it can then cause subsequent
idempotent loads of that same file to access stale stack contents of the
previous failure.  The case may not happen in any normal situation
(explaining all the "Tested-by's on the original change), and requires
admin privileges, but syzkaller triggers random bad behavior as a
result:

    BUG: soft lockup in sys_finit_module
    BUG: unable to handle kernel paging request in init_module_from_file
    general protection fault in init_module_from_file
    INFO: task hung in init_module_from_file
    KASAN: out-of-bounds Read in init_module_from_file
    KASAN: slab-out-of-bounds Read in init_module_from_file
    ...

The second error is fairly benign and just leads to nonsensical stats
(and has been around since the debug stats were added).

Vegard also provided a patch for the idempotent loading issue, but I'd
rather re-organize the code and make it more legible using another level
of helper functions than add the usual "goto out" error handling.

Link: https://lore.kernel.org/lkml/20230704100852.23452-1-vegard.nossum@oracle.com/
Fixes: 9b9879fc ("modules: catch concurrent module loads, treat them as idempotent")
Reported-by: default avatarVegard Nossum <vegard.nossum@oracle.com>
Reported-by: default avatarHarshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
Reported-by: syzbot+9c2bdc9d24e4a7abe741@syzkaller.appspotmail.com
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      f1962207
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7