Skip to content

L
linux
Switch branch/tag
  1. 23 Jul, 2023 26 commits
  3. 22 Jul, 2023 8 commits
    • Steve French's avatar
      cifs: update internal module version number for cifs.ko · ba61a03a
      Steve French authored 
      From 2.43 to 2.44
Signed-off-by: default avatarSteve French <stfrench@microsoft.com>
      ba61a03a
    • Shyam Prasad N's avatar
      cifs: allow dumping keys for directories too · b3edef6b
      Shyam Prasad N authored 
      Dumping the enc/dec keys is a session wide operation.
And it should not matter if the ioctl was run on
a regular file or a directory.

Currently, we obtain the tcon pointer from the
cifs file handle. But since there's no dir open call
in cifs, this is not populated for dirs.

This change allows dumping of session keys using ioctl
even for directories. To do this, we'll now get the
tcon pointer from the superblock, and not from the file
handle.
Signed-off-by: default avatarShyam Prasad N <sprasad@microsoft.com>
Signed-off-by: default avatarSteve French <stfrench@microsoft.com>
      b3edef6b
    • Linus Torvalds's avatar
      Merge tag 's390-6.5-3' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux · 295e1388
      Linus Torvalds authored 
      Pull s390 fixes from Heiko Carstens:

 - Fix per vma lock fault handling: add missing !(fault & VM_FAULT_ERROR)
   check to fault handler to prevent error handling for return values
   that don't indicate an error

 - Use kfree_sensitive() instead of kfree() in paes crypto code to clear
   memory that may contain keys before freeing it

 - Fix reply buffer size calculation for CCA replies in zcrypt device
   driver

* tag 's390-6.5-3' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
  s390/zcrypt: fix reply buffer calculations for CCA replies
  s390/crypto: use kfree_sensitive() instead of kfree()
  s390/mm: fix per vma lock fault handling
      295e1388
    • Linus Torvalds's avatar
      Merge tag 'block-6.5-2023-07-21' of git://git.kernel.dk/linux · f036d67c
      Linus Torvalds authored 
      Pull block fixes from Jens Axboe:

 - Fix for loop regressions (Mauricio)

 - Fix a potential stall with batched wakeups in sbitmap (David)

 - Fix for stall with recursive plug flushes (Ross)

 - Skip accounting of empty requests for blk-iocost (Chengming)

 - Remove a dead field in struct blk_mq_hw_ctx (Chengming)

* tag 'block-6.5-2023-07-21' of git://git.kernel.dk/linux:
  loop: do not enforce max_loop hard limit by (new) default
  loop: deprecate autoloading callback loop_probe()
  sbitmap: fix batching wakeup
  blk-iocost: skip empty flush bio in iocost
  blk-mq: delete dead struct blk_mq_hw_ctx->queued field
  blk-mq: Fix stall due to recursive flush plug
      f036d67c
    • Linus Torvalds's avatar
      Merge tag 'io_uring-6.5-2023-07-21' of git://git.kernel.dk/linux · bdd1d82e
      Linus Torvalds authored 
      Pull io_uring fixes from Jens Axboe:

 - Fix for io-wq not always honoring REQ_F_NOWAIT, if it was set and
   punted directly (eg via DRAIN) (me)

 - Capability check fix (Ondrej)

 - Regression fix for the mmap changes that went into 6.4, which
   apparently broke IA64 (Helge)

* tag 'io_uring-6.5-2023-07-21' of git://git.kernel.dk/linux:
  ia64: mmap: Consider pgoff when searching for free mapping
  io_uring: Fix io_uring mmap() by using architecture-provided get_unmapped_area()
  io_uring: treat -EAGAIN for REQ_F_NOWAIT as final for io-wq
  io_uring: don't audit the capability check in io_uring_create()
      bdd1d82e
    • Linus Torvalds's avatar
      Merge tag 'devicetree-fixes-for-6.5-1' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux · 725d444d
      Linus Torvalds authored 
      Pull devicetree fixes from Rob Herring:

 - Fix moortec,mr75203 schema usage of 'multipleOf' keyword

 - Fix regression in systems depending on "of-display" device name

 - Build fix for s390 with CONFIG_PCI=n and OF_EARLY_FLATTREE=y

 - Drop two obsolete serial .txt bindings

* tag 'devicetree-fixes-for-6.5-1' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux:
  dt-bindings: serial: Remove obsolete nxp,lpc1850-uart.txt
  dt-bindings: serial: Remove obsolete cavium-uart.txt
  dt-bindings: hwmon: moortec,mr75203: fix multipleOf for coefficients
  of: Preserve "of-display" device name for compatibility
  of: make OF_EARLY_FLATTREE depend on HAS_IOMEM
      725d444d
    • Linus Torvalds's avatar
      Merge tag 'regmap-fix-v6.5-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap · 39b14286
      Linus Torvalds authored 
      Pull regmap fixes from Mark Brown:
 "Three fixes here:

   - The issues with accounting for register and padding length on raw
     buses turn out to be quite widespread in custom buses.

     In order to avoid disturbing anything drop the initial fixes and
     fall back to a point fix in the SMBus code where the issue was
     originally noticed, a more substantial refactoring of the API which
     ensures that all buses make the same assumptions will follow.

   - The generic regcache code had been forcing on async I/O which did
     not work with the new maple tree sync code when used with SPI.

     Since that was mainly for the rbtree cache and the assumptions
     about hardware that drove the choice are probably not true any more
     fix this by pushing the enablement of async down into the rbtree
     code.

     This probably also makes cache syncs for systems faster though it's
     not the point.

   - The test code was triggering use of the rbtree and maple tree
     caches with dynamic allocation of nodes since all the testing is
     with RAM backed caches with no I/O performance issues.

     Just disable the locking in the tests to avoid triggering warnings
     when allocation debugging is turned on, it's not really what's
     being tested"

* tag 'regmap-fix-v6.5-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap:
  regmap: Disable locking for RBTREE and MAPLE unit tests
  regcache: Push async I/O request down into the rbtree cache
  regmap: Account for register length in SMBus I/O limits
  regmap: Drop initial version of maximum transfer length fixes
      39b14286
    • Linus Torvalds's avatar
      Merge tag 'gpio-fixes-for-v6.5-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux · c0842db5
      Linus Torvalds authored 
      Pull gpio fixes from Bartosz Golaszewski:

 - fix initial value handling for output-only pins in gpio-tps68470

 - fix two resource leaks in gpio-mvebu

* tag 'gpio-fixes-for-v6.5-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux:
  gpio: mvebu: fix irq domain leak
  gpio: mvebu: Make use of devm_pwmchip_add
  gpio: tps68470: Make tps68470_gpio_output() always set the initial value
      c0842db5
  5. 21 Jul, 2023 6 commits
    • Rob Herring's avatar
      dt-bindings: serial: Remove obsolete nxp,lpc1850-uart.txt · ffc59c64
      Rob Herring authored 
      nxp,lpc1850-uart.txt binding is already covered by 8250.yaml, so remove
it.
Reviewed-by: default avatarConor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20230707221607.1064888-1-robh@kernel.orgSigned-off-by: default avatarRob Herring <robh@kernel.org>
      ffc59c64
    • Rob Herring's avatar
      dt-bindings: serial: Remove obsolete cavium-uart.txt · 5921181c
      Rob Herring authored 
      cavium-uart.txt binding is already covered by 8250.yaml, so remove it.
Reviewed-by: default avatarConor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20230707221602.1063972-1-robh@kernel.orgSigned-off-by: default avatarRob Herring <robh@kernel.org>
      5921181c
    • 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
    • Linus Torvalds's avatar
      Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux · d192f538
      Linus Torvalds authored 
      Pull arm64 fixes from Will Deacon:
 "I've picked up a handful of arm64 fixes while Catalin's been away, so
  here they are. Below is the usual summary, but we have basically have
  two cleanups, a fix for an SME crash and a fix for hibernation:

   - Fix saving of SME state after SVE vector length is changed

   - Fix sparse warnings for missing vDSO function prototypes

   - Fix hibernation resume path when kfence is enabled

   - Fix field names for the HFGxTR_EL2 register"

* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
  arm64/fpsimd: Ensure SME storage is allocated after SVE VL changes
  arm64: vdso: Clear common make C=2 warnings
  arm64: mm: Make hibernation aware of KFENCE
  arm64: Fix HFGxTR_EL2 field naming
      d192f538
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7