Skip to content
  1. May 27, 2023
  2. May 26, 2023
    • Linus Torvalds's avatar
      Merge tag '6.4-rc3-smb3-client-fixes' of git://git.samba.org/sfrench/cifs-2.6 · 0d85b27b
      Linus Torvalds authored
      Pull smb directory moves and client fixes from Steve French:
       "Four smb3 client fixes (three of which marked for stable) and three
        patches to move of fs/cifs and fs/ksmbd to a new common "fs/smb"
        parent directory
      
         - Move the client and server source directories to a common parent
           directory:
      
             fs/cifs -> fs/smb/client
             fs/ksmbd -> fs/smb/server
             fs/smbfs_common -> fs/smb/common
      
         - important readahead fix
      
         - important fix for SMB1 regression
      
         - fix for missing mount option ("mapchars") in mount API conversion
      
         - minor debugging improvement"
      
      * tag '6.4-rc3-smb3-client-fixes' of git://git.samba.org/sfrench/cifs-2.6:
        smb3: move Documentation/filesystems/cifs to Documentation/filesystems/smb
        cifs: correct references in Documentation to old fs/cifs path
        smb: move client and server files to common directory fs/smb
        cifs: mapchars mount option ignored
        smb3: display debug information better for encryption
        cifs: fix smb1 mount regression
        cifs: Fix cifs_limit_bvec_subset() to correctly check the maxmimum size
      0d85b27b
    • Linus Torvalds's avatar
      Merge tag 'parisc-for-6.4-3' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux · 192fe71c
      Linus Torvalds authored
      Pull parisc architecture fixes from Helge Deller:
       "Quite a bunch of real bugfixes in here and most of them are tagged for
        backporting: A fix for cache flushing from irq context, a kprobes &
        kgdb breakpoint handling fix, and a fix in the alternative code
        patching function to take care of CPU hotplugging.
      
        parisc now provides LOCKDEP support and comes with a lightweight
        spinlock check. Both features helped me to find the cache flush bug.
      
        Additionally writing the AGP gatt has been fixed, the machine allows
        the user to reboot after a system halt and arch_sync_dma_for_cpu() has
        been optimized for PCXL PCUs.
      
        Summary:
      
         - Fix flush_dcache_page() for usage from irq context
      
         - Handle kprobes breakpoints only in kernel context
      
         - Handle kgdb breakpoints only in kernel context
      
         - Use num_present_cpus() in alternative patching code
      
         - Enable LOCKDEP support
      
         - Add lightweight spinlock checks
      
         - Flush AGP gatt writes and adjust gatt mask in parisc_agp_mask_memory()
      
         - Allow to reboot machine after system halt
      
         - Improve cache flushing for PCXL in arch_sync_dma_for_cpu()"
      
      * tag 'parisc-for-6.4-3' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
        parisc: Fix flush_dcache_page() for usage from irq context
        parisc: Handle kgdb breakpoints only in kernel context
        parisc: Handle kprobes breakpoints only in kernel context
        parisc: Allow to reboot machine after system halt
        parisc: Enable LOCKDEP support
        parisc: Add lightweight spinlock checks
        parisc: Use num_present_cpus() in alternative patching code
        parisc: Flush gatt writes and adjust gatt mask in parisc_agp_mask_memory()
        parisc: Improve cache flushing for PCXL in arch_sync_dma_for_cpu()
      192fe71c
    • Linus Torvalds's avatar
      module: error out early on concurrent load of the same module file · 9828ed3f
      Linus Torvalds authored
      It turns out that udev under certain circumstances will concurrently try
      to load the same modules over-and-over excessively.  This isn't a kernel
      bug, but it ends up affecting the kernel, to the point that under
      certain circumstances we can fail to boot, because the kernel uses a lot
      of memory to read all the module data all at once.
      
      Note that it isn't a memory leak, it's just basically a thundering herd
      problem happening at bootup with a lot of CPUs, with the worst cases
      then being pretty bad.
      
      Admittedly the worst situations are somewhat contrived: lots and lots of
      CPUs, not a lot of memory, and KASAN enabled to make it all slower and
      as such (unintentionally) exacerbate the problem.
      
      Luis explains: [1]
      
       "My best assessment of the situation is that each CPU in udev ends up
        triggering a load of duplicate set of modules, not just one, but *a
        lot*. Not sure what heuristics udev uses to load a set of modules per
        CPU."
      
      Petr Pavlu chimes in: [2]
      
       "My understanding is that udev workers are forked. An initial kmod
        context is created by the main udevd process but no sharing happens
        after the fork. It means that the mentioned memory pool logic doesn't
        really kick in.
      
        Multiple parallel load requests come from multiple udev workers, for
        instance, each handling an udev event for one CPU device and making
        the exactly same requests as all others are doing at the same time.
      
        The optimization idea would be to recognize these duplicate requests
        at the udevd/kmod level and converge them"
      
      Note that module loading has tried to mitigate this issue before, see
      for example commit 064f4536 ("module: avoid allocation if module is
      already present and ready"), which has a few ASCII graphs on memory use
      due to this same issue.
      
      However, while that noticed that the module was already loaded, and
      exited with an error early before spending any more time on setting up
      the module, it didn't handle the case of multiple concurrent module
      loads all being active - but not complete - at the same time.
      
      Yes, one of them will eventually win the race and finalize its copy, and
      the others will then notice that the module already exists and error
      out, but while this all happens, we have tons of unnecessary concurrent
      work being done.
      
      Again, the real fix is for udev to not do that (maybe it should use
      threads instead of fork, and have actual shared data structures and not
      cause duplicate work). That real fix is apparently not trivial.
      
      But it turns out that the kernel already has a pretty good model for
      dealing with concurrent access to the same file: the i_writecount of the
      inode.
      
      In fact, the module loading already indirectly uses 'i_writecount' ,
      because 'kernel_file_read()' will in fact do
      
      	ret = deny_write_access(file);
      	if (ret)
      		return ret;
      	...
      	allow_write_access(file);
      
      around the read of the file data.  We do not allow concurrent writes to
      the file, and return -ETXTBUSY if the file was open for writing at the
      same time as the module data is loaded from it.
      
      And the solution to the reader concurrency problem is to simply extend
      this "no concurrent writers" logic to simply be "exclusive access".
      
      Note that "exclusive" in this context isn't really some absolute thing:
      it's only exclusion from writers and from other "special readers" that
      do this writer denial.  So we simply introduce a variation of that
      "deny_write_access()" logic that not only denies write access, but also
      requires that this is the _only_ such access that denies write access.
      
      Which means that you can't start loading a module that is already being
      loaded as a module by somebody else, or you will get the same -ETXTBSY
      error that you would get if there were writers around.
      
      [ It also means that you can't try to load a currently executing
        executable as a module, for the same reason: executables do that same
        "deny_write_access()" thing, and that's obviously where the whole
        ETXTBSY logic traditionally came from.
      
        This is not a problem for kernel modules, since the set of normal
        executable files and kernel module files is entirely disjoint. ]
      
      This new function is called "exclusive_deny_write_access()", and the
      implementation is trivial, in that it's just an atomic decrement of
      i_writecount if it was 0 before.
      
      To use that new exclusivity check, all we then do is wrap the module
      loading with that exclusive_deny_write_access()() / allow_write_access()
      pair.  The actual patch is a bit bigger than that, because we want to
      surround not just the "load file data" part, but the whole module setup,
      to get maximum exclusion.
      
      So this ends up splitting up "finit_module()" into a few helper
      functions to make it all very clear and legible.
      
      In Luis' test-case (bringing up 255 vcpu's in a virtual machine [3]),
      the "wasted vmalloc" space (ie module data read into a vmalloc'ed area
      in order to be loaded as a module, but then discarded because somebody
      else loaded the same module instead) dropped from 1.8GiB to 474kB.  Yes,
      that's gigabytes to kilobytes.
      
      It doesn't drop completely to zero, because even with this change, you
      can still end up having completely serial pointless module loads, where
      one udev process has loaded a module fully (and thus the kernel has
      released that exclusive lock on the module file), and then another udev
      process tries to load the same module again.
      
      So while we cannot fully get rid of the fundamental bug in user space,
      we _can_ get rid of the excessive concurrent thundering herd effect.
      
      A couple of final side notes on this all:
      
       - This tweak only affects the "finit_module()" system call, which gives
         the kernel a file descriptor with the module data.
      
         You can also just feed the module data as raw data from user space
         with "init_module()" (note the lack of 'f' at the beginning), and
         obviously for that case we do _not_ have any "exclusive read" logic.
      
         So if you absolutely want to do things wrong in user space, and try
         to load the same module multiple times, and error out only later when
         the kernel ends up saying "you can't load the same module name
         twice", you can still do that.
      
         And in fact, some distros will do exactly that, because they will
         uncompress the kernel module data in user space before feeding it to
         the kernel (mainly because they haven't started using the new kernel
         side decompression yet).
      
         So this is not some absolute "you can't do concurrent loads of the
         same module". It's literally just a very simple heuristic that will
         catch it early in case you try to load the exact same module file at
         the same time, and in that case avoid a potentially nasty situation.
      
       - There is another user of "deny_write_access()": the verity code that
         enables fs-verity on a file (the FS_IOC_ENABLE_VERITY ioctl).
      
         If you use fs-verity and you care about verifying the kernel modules
         (which does make sense), you should do it *before* loading said
         kernel module. That may sound obvious, but now the implementation
         basically requires it. Because if you try to do it concurrently, the
         kernel may refuse to load the module file that is being set up by the
         fs-verity code.
      
       - This all will obviously mean that if you insist on loading the same
         module in parallel, only one module load will succeed, and the others
         will return with an error.
      
         That was true before too, but what is different is that the -ETXTBSY
         error can be returned *before* the success case of another process
         fully loading and instantiating the module.
      
         Again, that might sound obvious, and it is indeed the whole point of
         the whole change: we are much quicker to notice the whole "you're
         already in the process of loading this module".
      
         So it's very much intentional, but it does mean that if you just
         spray the kernel with "finit_module()", and expect that the module is
         immediately loaded afterwards without checking the return value, you
         are doing something horribly horribly wrong.
      
         I'd like to say that that would never happen, but the whole _reason_
         for this commit is that udev is currently doing something horribly
         horribly wrong, so ...
      
      Link: https://lore.kernel.org/all/ZEGopJ8VAYnE7LQ2@bombadil.infradead.org/ [1]
      Link: https://lore.kernel.org/all/23bd0ce6-ef78-1cd8-1f21-0e706a00424a@suse.com/ [2]
      Link: https://lore.kernel.org/lkml/ZG%2Fa+nrt4%2FAAUi5z@bombadil.infradead.org/
      
       [3]
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Lucas De Marchi <lucas.demarchi@intel.com>
      Cc: Petr Pavlu <petr.pavlu@suse.com>
      Tested-by: default avatarLuis Chamberlain <mcgrof@kernel.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      9828ed3f
    • Linus Torvalds's avatar
      Merge tag 'vfs/v6.4-rc3/misc.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs · 9db89859
      Linus Torvalds authored
      Pull vfs fixes from Christian Brauner:
      
       - During the acl rework we merged this cycle the generic_listxattr()
         helper had to be modified in a way that in principle it would allow
         for POSIX ACLs to be reported. At least that was the impression we
         had initially. Because before the acl rework POSIX ACLs would be
         reported if the filesystem did have POSIX ACL xattr handlers in
         sb->s_xattr. That logic changed and now we can simply check whether
         the superblock has SB_POSIXACL set and if the inode has
         inode->i_{default_}acl set report the appropriate POSIX ACL name.
      
         However, we didn't realize that generic_listxattr() was only ever
         used by two filesystems. Both of them don't support POSIX ACLs via
         sb->s_xattr handlers and so never reported POSIX ACLs via
         generic_listxattr() even if they raised SB_POSIXACL and did contain
         inodes which had acls set. The example here is nfs4.
      
         As a result, generic_listxattr() suddenly started reporting POSIX
         ACLs when it wouldn't have before. Since SB_POSIXACL implies that the
         umask isn't stripped in the VFS nfs4 can't just drop SB_POSIXACL from
         the superblock as it would also alter umask handling for them.
      
         So just have generic_listxattr() not report POSIX ACLs as it never
         did anyway. It's documented as such.
      
       - Our SB_* flags currently use a signed integer and we shift the last
         bit causing UBSAN to complain about undefined behavior. Switch to
         using unsigned. While the original patch used an explicit unsigned
         bitshift it's now pretty common to rely on the BIT() macro in a lot
         of headers nowadays. So the patch has been adjusted to use that.
      
       - Add Namjae as ntfs reviewer. They're already active this cycle so
         let's make it explicit right now.
      
      * tag 'vfs/v6.4-rc3/misc.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs:
        ntfs: Add myself as a reviewer
        fs: don't call posix_acl_listxattr in generic_listxattr
        fs: fix undefined behavior in bit shift for SB_NOUSER
      9db89859
    • Linus Torvalds's avatar
      Merge tag 'net-6.4-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net · 50fb587e
      Linus Torvalds authored
      Pull networking fixes from Paolo Abeni:
       "Including fixes from bluetooth and bpf.
      
        Current release - regressions:
      
         - net: fix skb leak in __skb_tstamp_tx()
      
         - eth: mtk_eth_soc: fix QoS on DSA MAC on non MTK_NETSYS_V2 SoCs
      
        Current release - new code bugs:
      
         - handshake:
            - fix sock->file allocation
            - fix handshake_dup() ref counting
      
         - bluetooth:
            - fix potential double free caused by hci_conn_unlink
            - fix UAF in hci_conn_hash_flush
      
        Previous releases - regressions:
      
         - core: fix stack overflow when LRO is disabled for virtual
           interfaces
      
         - tls: fix strparser rx issues
      
         - bpf:
            - fix many sockmap/TCP related issues
            - fix a memory leak in the LRU and LRU_PERCPU hash maps
            - init the offload table earlier
      
         - eth: mlx5e:
            - do as little as possible in napi poll when budget is 0
            - fix using eswitch mapping in nic mode
            - fix deadlock in tc route query code
      
        Previous releases - always broken:
      
         - udplite: fix NULL pointer dereference in __sk_mem_raise_allocated()
      
         - raw: fix output xfrm lookup wrt protocol
      
         - smc: reset connection when trying to use SMCRv2 fails
      
         - phy: mscc: enable VSC8501/2 RGMII RX clock
      
         - eth: octeontx2-pf: fix TSOv6 offload
      
         - eth: cdc_ncm: deal with too low values of dwNtbOutMaxSize"
      
      * tag 'net-6.4-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (79 commits)
        udplite: Fix NULL pointer dereference in __sk_mem_raise_allocated().
        net: phy: mscc: enable VSC8501/2 RGMII RX clock
        net: phy: mscc: remove unnecessary phydev locking
        net: phy: mscc: add support for VSC8501
        net: phy: mscc: add VSC8502 to MODULE_DEVICE_TABLE
        net/handshake: Enable the SNI extension to work properly
        net/handshake: Unpin sock->file if a handshake is cancelled
        net/handshake: handshake_genl_notify() shouldn't ignore @flags
        net/handshake: Fix uninitialized local variable
        net/handshake: Fix handshake_dup() ref counting
        net/handshake: Remove unneeded check from handshake_dup()
        ipv6: Fix out-of-bounds access in ipv6_find_tlv()
        net: ethernet: mtk_eth_soc: fix QoS on DSA MAC on non MTK_NETSYS_V2 SoCs
        docs: netdev: document the existence of the mail bot
        net: fix skb leak in __skb_tstamp_tx()
        r8169: Use a raw_spinlock_t for the register locks.
        page_pool: fix inconsistency for page_pool_ring_[un]lock()
        bpf, sockmap: Test progs verifier error with latest clang
        bpf, sockmap: Test FIONREAD returns correct bytes in rx buffer with drops
        bpf, sockmap: Test FIONREAD returns correct bytes in rx buffer
        ...
      50fb587e
    • Linus Torvalds's avatar
      Merge tag 'for-v6.4-rc' of git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply · eb03e318
      Linus Torvalds authored
      Pull power supply fixes from Sebastian Reichel:
      
       - Fix power_supply_get_battery_info for devices without parent devices
         resulting in NULL pointer dereference
      
       - Fix desktop systems reporting to run on battery once a power-supply
         device with device scope appears (e.g. a HID keyboard with a battery)
      
       - Ratelimit debug print about driver not providing data
      
       - Fix race condition related to external_power_changed in multiple
         drivers (ab8500, axp288, bq25890, sc27xx, bq27xxx)
      
       - Fix LED trigger switching from blinking to solid-on when charging
         finishes
      
       - Fix multiple races in bq27xxx battery driver
      
       - mt6360: handle potential ENOMEM from devm_work_autocancel
      
       - sbs-charger: Fix SBS_CHARGER_STATUS_CHARGE_INHIBITED bit
      
       - rt9467: avoid passing 0 to dev_err_probe
      
      * tag 'for-v6.4-rc' of git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply: (21 commits)
        power: supply: Fix logic checking if system is running from battery
        power: supply: mt6360: add a check of devm_work_autocancel in mt6360_charger_probe
        power: supply: sbs-charger: Fix INHIBITED bit for Status reg
        power: supply: rt9467: Fix passing zero to 'dev_err_probe'
        power: supply: Ratelimit no data debug output
        power: supply: Fix power_supply_get_battery_info() if parent is NULL
        power: supply: bq24190: Call power_supply_changed() after updating input current
        power: supply: bq25890: Call power_supply_changed() after updating input current or voltage
        power: supply: bq27xxx: Use mod_delayed_work() instead of cancel() + schedule()
        power: supply: bq27xxx: After charger plug in/out wait 0.5s for things to stabilize
        power: supply: bq27xxx: Ensure power_supply_changed() is called on current sign changes
        power: supply: bq27xxx: Move bq27xxx_battery_update() down
        power: supply: bq27xxx: Add cache parameter to bq27xxx_battery_current_and_status()
        power: supply: bq27xxx: Fix poll_interval handling and races on remove
        power: supply: bq27xxx: Fix I2C IRQ race on remove
        power: supply: bq27xxx: Fix bq27xxx_battery_update() race condition
        power: supply: leds: Fix blink to LED on transition
        power: supply: sc27xx: Fix external_power_changed race
        power: supply: bq25890: Fix external_power_changed race
        power: supply: axp288_fuel_gauge: Fix external_power_changed race
        ...
      eb03e318
    • Linus Torvalds's avatar
      Merge tag 'sound-6.4-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound · 029c77f8
      Linus Torvalds authored
      Pull sound fixes from Takashi Iwai:
       "A collection of small fixes:
      
         - HD-audio runtime PM bug fix
      
         - A couple of HD-audio quirks
      
         - Fix series of ASoC Intel AVS drivers
      
         - ASoC DPCM fix for a bug found on new Intel systems
      
         - A few other ASoC device-specific small fixes"
      
      * tag 'sound-6.4-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
        ALSA: hda/realtek: Enable headset onLenovo M70/M90
        ASoC: dwc: move DMA init to snd_soc_dai_driver probe()
        ASoC: cs35l41: Fix default regmap values for some registers
        ALSA: hda: Fix unhandled register update during auto-suspend period
        ASoC: dt-bindings: tlv320aic32x4: Fix supply names
        ASoC: Intel: avs: Add missing checks on FE startup
        ASoC: Intel: avs: Fix avs_path_module::instance_id size
        ASoC: Intel: avs: Account for UID of ACPI device
        ASoC: Intel: avs: Fix declaration of enum avs_channel_config
        ASoC: Intel: Skylake: Fix declaration of enum skl_ch_cfg
        ASoC: Intel: avs: Access path components under lock
        ASoC: Intel: avs: Fix module lookup
        ALSA: hda/ca0132: add quirk for EVGA X299 DARK
        ASoC: soc-pcm: test if a BE can be prepared
        ASoC: rt5682: Disable jack detection interrupt during suspend
        ASoC: lpass: Fix for KASAN use_after_free out of bounds
      029c77f8
    • Linus Torvalds's avatar
      Merge tag 'platform-drivers-x86-v6.4-3' of... · ecea3ba2
      Linus Torvalds authored
      Merge tag 'platform-drivers-x86-v6.4-3' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86
      
      Pull x86 platform driver fixes from Hans de Goede:
       "Nothing special to report just a few small fixes"
      
      * tag 'platform-drivers-x86-v6.4-3' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86:
        platform/x86/intel/ifs: Annotate work queue on stack so object debug does not complain
        platform/x86: ISST: Remove 8 socket limit
        platform/mellanox: mlxbf-pmc: fix sscanf() error checking
        platform/x86/amd/pmf: Fix CnQF and auto-mode after resume
        platform/x86: asus-wmi: Ignore WMI events with codes 0x7B, 0xC0
      ecea3ba2
    • Linus Torvalds's avatar
      Merge tag 'm68k-for-v6.4-tag2' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k · 5566051f
      Linus Torvalds authored
      Pull m68k fix from Geert Uytterhoeven:
      
       - Fix signal frame issue causing user-space crashes on 68020/68030
      
      * tag 'm68k-for-v6.4-tag2' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k:
        m68k: Move signal frame following exception on 68020/030
      5566051f
  3. May 25, 2023