1. 19 Mar, 2023 17 commits
  2. 18 Mar, 2023 4 commits
    • Sakari Ailus's avatar
      media: v4l: subdev: Make link validation safer · 55f1ecb1
      Sakari Ailus authored
      Link validation currently accesses invalid pointers if the link passed to
      it is not between two sub-devices. This is of course a driver bug.
      
      Ignore the error but print a warning message, as this is how it used to
      work previously.
      
      Fixes: a6b995ed ("media: subdev: use streams in v4l2_subdev_link_validate()")
      Reported-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarSakari Ailus <sakari.ailus@linux.intel.com>
      Tested-by: default avatarHans de Goede <hdegoede@redhat.com>
      Reviewed-by: default avatarTomi Valkeinen <tomi.valkeinen@ideasonboard.com>
      Reviewed-by: default avatarLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@kernel.org>
      55f1ecb1
    • Tomi Valkeinen's avatar
      media: subdev: Fix validation state lockdep issue · 53077915
      Tomi Valkeinen authored
      The new subdev state code has a possible deadlock scenario during link
      validation when the pipeline contains subdevs that support state and
      that do not support state.
      
      The current code locks the states of the subdevs on both ends of the
      link when starting the link validation, locking the sink side first,
      then the source. If either (or both) of the subdevs does not support
      state, nothing is done for that subdev at this point, and instead the
      locking is handled the old way, i.e. the subdev's ops do the locking
      internally.
      
      The issue arises when the sink doesn't support state, but source does,
      so the validation code locks the source for the duration of the
      validation, and then the sink is locked only when the get_fmt op is
      called. So lockdep sees the source locked first, then the sink.
      
      Later, when the streaming is started, the sink's s_stream op is called,
      which probably takes the subdev's lock. The op then calls the source's
      s_stream, which takes the source's lock. So, the sink is locked first,
      then the source.
      
      Note that link validation and stream starting is not done at the same
      time, so an actual deadlock should never happen. However, it's still a
      clear bug.
      
      Fix this by locking the subdev states only if both subdevs support
      state. In other words, we have two scenarios:
      
      1. Both subdevs support state. Lock sink first, then source, and keep
         the locks while validating the link.
      2. At least one of the subdevs do not support state. Take the lock only
         for the duration of the operation (get_fmt or looking at the
         routing), and release after the op is done.
      
      Obviously 1. is better, as we have a more consistent view of the states
      of the subdevs during validation. 2. is how it has been so far, so it's
      no worse than this used to be.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ideasonboard.com>
      Signed-off-by: default avatarSakari Ailus <sakari.ailus@linux.intel.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@kernel.org>
      53077915
    • Arnd Bergmann's avatar
      media: i2c: imx290: fix conditional function definitions · b928db94
      Arnd Bergmann authored
      The runtime suspend/resume functions are only referenced from the
      dev_pm_ops, but they use the old SET_RUNTIME_PM_OPS() helper
      that requires a __maybe_unused annotation to avoid a warning:
      
      drivers/media/i2c/imx290.c:1082:12: error: unused function 'imx290_runtime_resume' [-Werror,-Wunused-function]
      static int imx290_runtime_resume(struct device *dev)
                 ^
      drivers/media/i2c/imx290.c:1090:12: error: unused function 'imx290_runtime_suspend' [-Werror,-Wunused-function]
      static int imx290_runtime_suspend(struct device *dev)
                 ^
      
      Convert this to the new RUNTIME_PM_OPS() helper that so this
      is not required. To improve this further, also use the pm_ptr()
      helper that lets the dev_pm_ops get dropped entirely when
      CONFIG_PM is disabled.
      
      A related mistake happened in the of_match_ptr() macro here, which
      like SET_RUNTIME_PM_OPS() requires the match table to be marked
      as __maybe_unused, though I could not reproduce building this without
      CONFIG_OF. Remove the of_match_ptr() here as there is no point in
      dropping the match table in configurations without CONFIG_OF.
      
      Fixes: 02852c01 ("media: i2c: imx290: Initialize runtime PM before subdev")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Signed-off-by: default avatarSakari Ailus <sakari.ailus@linux.intel.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@kernel.org>
      b928db94
    • Javier Martinez Canillas's avatar
      media: Revert "venus: firmware: Correct non-pix start and end addresses" · b0d944bc
      Javier Martinez Canillas authored
      This reverts commit a837e516, which broke
      probing of the venus driver, at least on the SC7180 SoC HP X2 Chromebook:
      
        [   11.455782] qcom-venus aa00000.video-codec: Adding to iommu group 11
        [   11.506980] qcom-venus aa00000.video-codec: non legacy binding
        [   12.143432] qcom-venus aa00000.video-codec: failed to reset venus core
        [   12.156440] qcom-venus: probe of aa00000.video-codec failed with error -110
      
      Matthias Kaehlcke also reported that the same change caused a regression in
      SC7180 and sc7280, that prevents AOSS from entering sleep mode during system
      suspend. So let's revert this commit for now to fix both issues.
      
      Fixes: a837e516 ("venus: firmware: Correct non-pix start and end addresses")
      Reported-by: default avatarMatthias Kaehlcke <mka@chromium.org>
      Signed-off-by: default avatarJavier Martinez Canillas <javierm@redhat.com>
      Signed-off-by: default avatarStanimir Varbanov <stanimir.k.varbanov@gmail.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@kernel.org>
      b0d944bc
  3. 12 Mar, 2023 12 commits
    • Linus Torvalds's avatar
      Linux 6.3-rc2 · eeac8ede
      Linus Torvalds authored
      eeac8ede
    • Hector Martin's avatar
      wifi: cfg80211: Partial revert "wifi: cfg80211: Fix use after free for wext" · 79d1ed5c
      Hector Martin authored
      This reverts part of commit 015b8cc5 ("wifi: cfg80211: Fix use after
      free for wext")
      
      This commit broke WPA offload by unconditionally clearing the crypto
      modes for non-WEP connections. Drop that part of the patch.
      Signed-off-by: default avatarHector Martin <marcan@marcan.st>
      Reported-by: default avatarIlya <me@0upti.me>
      Reported-and-tested-by: default avatarJanne Grunau <j@jannau.net>
      Reviewed-by: default avatarEric Curtin <ecurtin@redhat.com>
      Fixes: 015b8cc5 ("wifi: cfg80211: Fix use after free for wext")
      Cc: stable@kernel.org
      Link: https://lore.kernel.org/linux-wireless/ZAx0TWRBlGfv7pNl@kroah.com/T/#m11e6e0915ab8fa19ce8bc9695ab288c0fe018edfSigned-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      79d1ed5c
    • Linus Torvalds's avatar
      Merge tag 'tpm-v6.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd · c4ecd87f
      Linus Torvalds authored
      Pull tpm fixes from Jarkko Sakkinen:
       "Two additional bug fixes for v6.3"
      
      * tag 'tpm-v6.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd:
        tpm: disable hwrng for fTPM on some AMD designs
        tpm/eventlog: Don't abort tpm_read_log on faulty ACPI address
      c4ecd87f
    • Mario Limonciello's avatar
      tpm: disable hwrng for fTPM on some AMD designs · f1324bbc
      Mario Limonciello authored
      AMD has issued an advisory indicating that having fTPM enabled in
      BIOS can cause "stuttering" in the OS.  This issue has been fixed
      in newer versions of the fTPM firmware, but it's up to system
      designers to decide whether to distribute it.
      
      This issue has existed for a while, but is more prevalent starting
      with kernel 6.1 because commit b006c439 ("hwrng: core - start
      hwrng kthread also for untrusted sources") started to use the fTPM
      for hwrng by default. However, all uses of /dev/hwrng result in
      unacceptable stuttering.
      
      So, simply disable registration of the defective hwrng when detecting
      these faulty fTPM versions.  As this is caused by faulty firmware, it
      is plausible that such a problem could also be reproduced by other TPM
      interactions, but this hasn't been shown by any user's testing or reports.
      
      It is hypothesized to be triggered more frequently by the use of the RNG
      because userspace software will fetch random numbers regularly.
      
      Intentionally continue to register other TPM functionality so that users
      that rely upon PCR measurements or any storage of data will still have
      access to it.  If it's found later that another TPM functionality is
      exacerbating this problem a module parameter it can be turned off entirely
      and a module parameter can be introduced to allow users who rely upon
      fTPM functionality to turn it on even though this problem is present.
      
      Link: https://www.amd.com/en/support/kb/faq/pa-410
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=216989
      Link: https://lore.kernel.org/all/20230209153120.261904-1-Jason@zx2c4.com/
      Fixes: b006c439 ("hwrng: core - start hwrng kthread also for untrusted sources")
      Cc: stable@vger.kernel.org
      Cc: Jarkko Sakkinen <jarkko@kernel.org>
      Cc: Thorsten Leemhuis <regressions@leemhuis.info>
      Cc: James Bottomley <James.Bottomley@hansenpartnership.com>
      Tested-by: reach622@mailcuk.com
      Tested-by: default avatarBell <1138267643@qq.com>
      Co-developed-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Signed-off-by: default avatarMario Limonciello <mario.limonciello@amd.com>
      Reviewed-by: default avatarJarkko Sakkinen <jarkko@kernel.org>
      Signed-off-by: default avatarJarkko Sakkinen <jarkko@kernel.org>
      f1324bbc
    • Morten Linderud's avatar
      tpm/eventlog: Don't abort tpm_read_log on faulty ACPI address · 80a6c216
      Morten Linderud authored
      tpm_read_log_acpi() should return -ENODEV when no eventlog from the ACPI
      table is found. If the firmware vendor includes an invalid log address
      we are unable to map from the ACPI memory and tpm_read_log() returns -EIO
      which would abort discovery of the eventlog.
      
      Change the return value from -EIO to -ENODEV when acpi_os_map_iomem()
      fails to map the event log.
      
      The following hardware was used to test this issue:
          Framework Laptop (Pre-production)
          BIOS: INSYDE Corp, Revision: 3.2
          TPM Device: NTC, Firmware Revision: 7.2
      
      Dump of the faulty ACPI TPM2 table:
          [000h 0000   4]                    Signature : "TPM2"    [Trusted Platform Module hardware interface Table]
          [004h 0004   4]                 Table Length : 0000004C
          [008h 0008   1]                     Revision : 04
          [009h 0009   1]                     Checksum : 2B
          [00Ah 0010   6]                       Oem ID : "INSYDE"
          [010h 0016   8]                 Oem Table ID : "TGL-ULT"
          [018h 0024   4]                 Oem Revision : 00000002
          [01Ch 0028   4]              Asl Compiler ID : "ACPI"
          [020h 0032   4]        Asl Compiler Revision : 00040000
      
          [024h 0036   2]               Platform Class : 0000
          [026h 0038   2]                     Reserved : 0000
          [028h 0040   8]              Control Address : 0000000000000000
          [030h 0048   4]                 Start Method : 06 [Memory Mapped I/O]
      
          [034h 0052  12]            Method Parameters : 00 00 00 00 00 00 00 00 00 00 00 00
          [040h 0064   4]           Minimum Log Length : 00010000
          [044h 0068   8]                  Log Address : 000000004053D000
      
      Fixes: 0cf577a0 ("tpm: Fix handling of missing event log")
      Tested-by: default avatarErkki Eilonen <erkki@bearmetal.eu>
      Signed-off-by: default avatarMorten Linderud <morten@linderud.pw>
      Reviewed-by: default avatarJarkko Sakkinen <jarkko@kernel.org>
      Signed-off-by: default avatarJarkko Sakkinen <jarkko@kernel.org>
      80a6c216
    • Linus Torvalds's avatar
      Merge tag 'xfs-6.3-fixes-1' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux · 2e545d69
      Linus Torvalds authored
      Pull xfs fixes from Darrick Wong:
      
       - Fix a crash if mount time quotacheck fails when there are inodes
         queued for garbage collection.
      
       - Fix an off by one error when discarding folios after writeback
         failure.
      
      * tag 'xfs-6.3-fixes-1' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux:
        xfs: fix off-by-one-block in xfs_discard_folio()
        xfs: quotacheck failure can race with background inode inactivation
      2e545d69
    • Linus Torvalds's avatar
      Merge tag 'staging-6.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging · 13423166
      Linus Torvalds authored
      Pull staging driver fixes and removal from Greg KH:
       "Here are four small staging driver fixes, and one big staging driver
        deletion for 6.3-rc2.
      
        The fixes are:
      
         - rtl8192e driver fixes for where the driver was attempting to
           execute various programs directly from the disk for unknown reasons
      
         - rtl8723bs driver fixes for issues found by Hans in testing
      
        The deleted driver is the removal of the r8188eu wireless driver as
        now in 6.3-rc1 we have a "real" wifi driver for one that includes
        support for many many more devices than this old driver did. So it's
        time to remove it as it is no longer needed. The maintainers of this
        driver all have acked its removal. Many thanks to them over the years
        for working to clean it up and keep it working while the real driver
        was being developed.
      
        All of these have been in linux-next this week with no reported
        problems"
      
      * tag 'staging-6.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging:
        staging: r8188eu: delete driver
        staging: rtl8723bs: Pass correct parameters to cfg80211_get_bss()
        staging: rtl8723bs: Fix key-store index handling
        staging: rtl8192e: Remove call_usermodehelper starting RadioPower.sh
        staging: rtl8192e: Remove function ..dm_check_ac_dc_power calling a script
      13423166
    • Linus Torvalds's avatar
      Merge tag 'x86_urgent_for_v6.3_rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · d3d0cac6
      Linus Torvalds authored
      Pull x86 fix from Borislav Petkov:
       "A single erratum fix for AMD machines:
      
         - Disable XSAVES on AMD Zen1 and Zen2 machines due to an erratum. No
           impact to anything as those machines will fallback to XSAVEC which
           is equivalent there"
      
      * tag 'x86_urgent_for_v6.3_rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        x86/CPU/AMD: Disable XSAVES on AMD family 0x17
      d3d0cac6
    • Linus Torvalds's avatar
      Merge tag 'kernel.fork.v6.3-rc2' of gitolite.kernel.org:pub/scm/linux/kernel/git/brauner/linux · f5eded1f
      Linus Torvalds authored
      Pull clone3 fix from Christian Brauner:
       "A simple fix for the clone3() system call.
      
        The CLONE_NEWTIME allows the creation of time namespaces. The flag
        reuses a bit from the CSIGNAL bits that are used in the legacy clone()
        system call to set the signal that gets sent to the parent after the
        child exits.
      
        The clone3() system call doesn't rely on CSIGNAL anymore as it uses a
        dedicated .exit_signal field in struct clone_args. So we blocked all
        CSIGNAL bits in clone3_args_valid(). When CLONE_NEWTIME was introduced
        and reused a CSIGNAL bit we forgot to adapt clone3_args_valid()
        causing CLONE_NEWTIME with clone3() to be rejected. Fix this"
      
      * tag 'kernel.fork.v6.3-rc2' of gitolite.kernel.org:pub/scm/linux/kernel/git/brauner/linux:
        selftests/clone3: test clone3 with CLONE_NEWTIME
        fork: allow CLONE_NEWTIME in clone3 flags
      f5eded1f
    • Linus Torvalds's avatar
      Merge tag 'vfs.misc.v6.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/idmapping · 3b11717f
      Linus Torvalds authored
      Pull vfs fixes from Christian Brauner:
      
       - When allocating pages for a watch queue failed, we didn't return an
         error causing userspace to proceed even though all subsequent
         notifcations would be lost. Make sure to return an error.
      
       - Fix a misformed tree entry for the idmapping maintainers entry.
      
       - When setting file leases from an idmapped mount via
         generic_setlease() we need to take the idmapping into account
         otherwise taking a lease would fail from an idmapped mount.
      
       - Remove two redundant assignments, one in splice code and the other in
         locks code, that static checkers complained about.
      
      * tag 'vfs.misc.v6.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/idmapping:
        filelocks: use mount idmapping for setlease permission check
        fs/locks: Remove redundant assignment to cmd
        splice: Remove redundant assignment to ret
        MAINTAINERS: repair a malformed T: entry in IDMAPPED MOUNTS
        watch_queue: fix IOC_WATCH_QUEUE_SET_SIZE alloc error paths
      3b11717f
    • Linus Torvalds's avatar
      Merge tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 · 40d0c090
      Linus Torvalds authored
      Pull ext4 fixes from Ted Ts'o:
       "Bug fixes and regressions for ext4, the most serious of which is a
        potential deadlock during directory renames that was introduced during
        the merge window discovered by a combination of syzbot and lockdep"
      
      * tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4:
        ext4: zero i_disksize when initializing the bootloader inode
        ext4: make sure fs error flag setted before clear journal error
        ext4: commit super block if fs record error when journal record without error
        ext4, jbd2: add an optimized bmap for the journal inode
        ext4: fix WARNING in ext4_update_inline_data
        ext4: move where set the MAY_INLINE_DATA flag is set
        ext4: Fix deadlock during directory rename
        ext4: Fix comment about the 64BIT feature
        docs: ext4: modify the group desc size to 64
        ext4: fix another off-by-one fsmap error on 1k block filesystems
        ext4: fix RENAME_WHITEOUT handling for inline directories
        ext4: make kobj_type structures constant
        ext4: fix cgroup writeback accounting with fs-layer encryption
      40d0c090
    • Linus Torvalds's avatar
      cpumask: relax sanity checking constraints · e7304080
      Linus Torvalds authored
      The cpumask_check() was unnecessarily tight, and causes problems for the
      users of cpumask_next().
      
      We have a number of users that take the previous return value of one of
      the bit scanning functions and subtract one to keep it in "range".  But
      since the scanning functions end up returning up to 'small_cpumask_bits'
      instead of the tighter 'nr_cpumask_bits', the range really needs to be
      using that widened form.
      
      [ This "previous-1" behavior is also the reason we have all those
        comments about /* -1 is a legal arg here. */ and separate checks for
        that being ok.  So we could have just made "small_cpumask_bits-1"
        be a similar special "don't check this" value.
      
        Tetsuo Handa even suggested a patch that only does that for
        cpumask_next(), since that seems to be the only actual case that
        triggers, but that all makes it even _more_ magical and special. So
        just relax the check ]
      
      One example of this kind of pattern being the 'c_start()' function in
      arch/x86/kernel/cpu/proc.c, but also duplicated in various forms on
      other architectures.
      
      Reported-by: syzbot+96cae094d90877641f32@syzkaller.appspotmail.com
      Link: https://syzkaller.appspot.com/bug?extid=96cae094d90877641f32Reported-by: default avatarTetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
      Link: https://lore.kernel.org/lkml/c1f4cc16-feea-b83c-82cf-1a1f007b7eb9@I-love.SAKURA.ne.jp/
      Fixes: 596ff4a0 ("cpumask: re-introduce constant-sized cpumask optimizations")
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      e7304080
  4. 11 Mar, 2023 7 commits
    • Linus Torvalds's avatar
      Merge tag 'i2c-for-6.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux · 81ff8554
      Linus Torvalds authored
      Pull i2c updates from Wolfram Sang:
       "This marks the end of a transition to let I2C have the same probe
        semantics as other subsystems. Uwe took care that no drivers in the
        current tree nor in -next use the deprecated .probe call. So, it is a
        good time to switch to the new, standard semantics now.
      
        There is also a regression fix:
      
         - regression fix for the notifier handling of the I2C core
      
         - final coversions of drivers away from deprecated .probe
      
         - make .probe_new the standard probe and convert I2C core to use it
      
      * tag 'i2c-for-6.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux:
        i2c: dev: Fix bus callback return values
        i2c: Convert drivers to new .probe() callback
        i2c: mux: Convert all drivers to new .probe() callback
        i2c: Switch .probe() to not take an id parameter
        media: i2c: ov2685: convert to i2c's .probe_new()
        media: i2c: ov5695: convert to i2c's .probe_new()
        w1: ds2482: Convert to i2c's .probe_new()
        serial: sc16is7xx: Convert to i2c's .probe_new()
        mtd: maps: pismo: Convert to i2c's .probe_new()
        misc: ad525x_dpot-i2c: Convert to i2c's .probe_new()
      81ff8554
    • Richard Weinberger's avatar
      ubi: block: Fix missing blk_mq_end_request · e25c54d1
      Richard Weinberger authored
      Switching to BLK_MQ_F_BLOCKING wrongly removed the call to
      blk_mq_end_request(). Add it back to have our IOs finished
      
      Fixes: 91cc8fbc ("ubi: block: set BLK_MQ_F_BLOCKING")
      Analyzed-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Reported-by: default avatarDaniel Palmer <daniel@0x0f.com>
      Link: https://lore.kernel.org/linux-mtd/CAHk-=wi29bbBNh3RqJKu3PxzpjDN5D5K17gEVtXrb7-6bfrnMQ@mail.gmail.com/Signed-off-by: default avatarRichard Weinberger <richard@nod.at>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Tested-by: default avatarDaniel Palmer <daniel@0x0f.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      e25c54d1
    • Zhihao Cheng's avatar
      ext4: zero i_disksize when initializing the bootloader inode · f5361da1
      Zhihao Cheng authored
      If the boot loader inode has never been used before, the
      EXT4_IOC_SWAP_BOOT inode will initialize it, including setting the
      i_size to 0.  However, if the "never before used" boot loader has a
      non-zero i_size, then i_disksize will be non-zero, and the
      inconsistency between i_size and i_disksize can trigger a kernel
      warning:
      
       WARNING: CPU: 0 PID: 2580 at fs/ext4/file.c:319
       CPU: 0 PID: 2580 Comm: bb Not tainted 6.3.0-rc1-00004-g703695902cfa
       RIP: 0010:ext4_file_write_iter+0xbc7/0xd10
       Call Trace:
        vfs_write+0x3b1/0x5c0
        ksys_write+0x77/0x160
        __x64_sys_write+0x22/0x30
        do_syscall_64+0x39/0x80
      
      Reproducer:
       1. create corrupted image and mount it:
             mke2fs -t ext4 /tmp/foo.img 200
             debugfs -wR "sif <5> size 25700" /tmp/foo.img
             mount -t ext4 /tmp/foo.img /mnt
             cd /mnt
             echo 123 > file
       2. Run the reproducer program:
             posix_memalign(&buf, 1024, 1024)
             fd = open("file", O_RDWR | O_DIRECT);
             ioctl(fd, EXT4_IOC_SWAP_BOOT);
             write(fd, buf, 1024);
      
      Fix this by setting i_disksize as well as i_size to zero when
      initiaizing the boot loader inode.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=217159
      Cc: stable@kernel.org
      Signed-off-by: default avatarZhihao Cheng <chengzhihao1@huawei.com>
      Link: https://lore.kernel.org/r/20230308032643.641113-1-chengzhihao1@huawei.comSigned-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      f5361da1
    • Ye Bin's avatar
      ext4: make sure fs error flag setted before clear journal error · f57886ca
      Ye Bin authored
      Now, jounral error number maybe cleared even though ext4_commit_super()
      failed. This may lead to error flag miss, then fsck will miss to check
      file system deeply.
      Signed-off-by: default avatarYe Bin <yebin10@huawei.com>
      Reviewed-by: default avatarJan Kara <jack@suse.cz>
      Link: https://lore.kernel.org/r/20230307061703.245965-3-yebin@huaweicloud.com
      f57886ca
    • Ye Bin's avatar
      ext4: commit super block if fs record error when journal record without error · eee00237
      Ye Bin authored
      Now, 'es->s_state' maybe covered by recover journal. And journal errno
      maybe not recorded in journal sb as IO error. ext4_update_super() only
      update error information when 'sbi->s_add_error_count' large than zero.
      Then 'EXT4_ERROR_FS' flag maybe lost.
      To solve above issue just recover 'es->s_state' error flag after journal
      replay like error info.
      Signed-off-by: default avatarYe Bin <yebin10@huawei.com>
      Reviewed-by: default avatarBaokun Li <libaokun1@huawei.com>
      Reviewed-by: default avatarJan Kara <jack@suse.cz>
      Link: https://lore.kernel.org/r/20230307061703.245965-2-yebin@huaweicloud.com
      eee00237
    • Theodore Ts'o's avatar
      ext4, jbd2: add an optimized bmap for the journal inode · 62913ae9
      Theodore Ts'o authored
      The generic bmap() function exported by the VFS takes locks and does
      checks that are not necessary for the journal inode.  So allow the
      file system to set a journal-optimized bmap function in
      journal->j_bmap.
      
      Reported-by: syzbot+9543479984ae9e576000@syzkaller.appspotmail.com
      Link: https://syzkaller.appspot.com/bug?id=e4aaa78795e490421c79f76ec3679006c8ff4cf0Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      62913ae9
    • Ye Bin's avatar
      ext4: fix WARNING in ext4_update_inline_data · 2b96b4a5
      Ye Bin authored
      Syzbot found the following issue:
      EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 without journal. Quota mode: none.
      fscrypt: AES-256-CTS-CBC using implementation "cts-cbc-aes-aesni"
      fscrypt: AES-256-XTS using implementation "xts-aes-aesni"
      ------------[ cut here ]------------
      WARNING: CPU: 0 PID: 5071 at mm/page_alloc.c:5525 __alloc_pages+0x30a/0x560 mm/page_alloc.c:5525
      Modules linked in:
      CPU: 1 PID: 5071 Comm: syz-executor263 Not tainted 6.2.0-rc1-syzkaller #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
      RIP: 0010:__alloc_pages+0x30a/0x560 mm/page_alloc.c:5525
      RSP: 0018:ffffc90003c2f1c0 EFLAGS: 00010246
      RAX: ffffc90003c2f220 RBX: 0000000000000014 RCX: 0000000000000000
      RDX: 0000000000000028 RSI: 0000000000000000 RDI: ffffc90003c2f248
      RBP: ffffc90003c2f2d8 R08: dffffc0000000000 R09: ffffc90003c2f220
      R10: fffff52000785e49 R11: 1ffff92000785e44 R12: 0000000000040d40
      R13: 1ffff92000785e40 R14: dffffc0000000000 R15: 1ffff92000785e3c
      FS:  0000555556c0d300(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007f95d5e04138 CR3: 00000000793aa000 CR4: 00000000003506f0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       <TASK>
       __alloc_pages_node include/linux/gfp.h:237 [inline]
       alloc_pages_node include/linux/gfp.h:260 [inline]
       __kmalloc_large_node+0x95/0x1e0 mm/slab_common.c:1113
       __do_kmalloc_node mm/slab_common.c:956 [inline]
       __kmalloc+0xfe/0x190 mm/slab_common.c:981
       kmalloc include/linux/slab.h:584 [inline]
       kzalloc include/linux/slab.h:720 [inline]
       ext4_update_inline_data+0x236/0x6b0 fs/ext4/inline.c:346
       ext4_update_inline_dir fs/ext4/inline.c:1115 [inline]
       ext4_try_add_inline_entry+0x328/0x990 fs/ext4/inline.c:1307
       ext4_add_entry+0x5a4/0xeb0 fs/ext4/namei.c:2385
       ext4_add_nondir+0x96/0x260 fs/ext4/namei.c:2772
       ext4_create+0x36c/0x560 fs/ext4/namei.c:2817
       lookup_open fs/namei.c:3413 [inline]
       open_last_lookups fs/namei.c:3481 [inline]
       path_openat+0x12ac/0x2dd0 fs/namei.c:3711
       do_filp_open+0x264/0x4f0 fs/namei.c:3741
       do_sys_openat2+0x124/0x4e0 fs/open.c:1310
       do_sys_open fs/open.c:1326 [inline]
       __do_sys_openat fs/open.c:1342 [inline]
       __se_sys_openat fs/open.c:1337 [inline]
       __x64_sys_openat+0x243/0x290 fs/open.c:1337
       do_syscall_x64 arch/x86/entry/common.c:50 [inline]
       do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
       entry_SYSCALL_64_after_hwframe+0x63/0xcd
      
      Above issue happens as follows:
      ext4_iget
         ext4_find_inline_data_nolock ->i_inline_off=164 i_inline_size=60
      ext4_try_add_inline_entry
         __ext4_mark_inode_dirty
            ext4_expand_extra_isize_ea ->i_extra_isize=32 s_want_extra_isize=44
               ext4_xattr_shift_entries
      	 ->after shift i_inline_off is incorrect, actually is change to 176
      ext4_try_add_inline_entry
        ext4_update_inline_dir
          get_max_inline_xattr_value_size
            if (EXT4_I(inode)->i_inline_off)
      	entry = (struct ext4_xattr_entry *)((void *)raw_inode +
      			EXT4_I(inode)->i_inline_off);
              free += EXT4_XATTR_SIZE(le32_to_cpu(entry->e_value_size));
      	->As entry is incorrect, then 'free' may be negative
         ext4_update_inline_data
            value = kzalloc(len, GFP_NOFS);
            -> len is unsigned int, maybe very large, then trigger warning when
               'kzalloc()'
      
      To resolve the above issue we need to update 'i_inline_off' after
      'ext4_xattr_shift_entries()'.  We do not need to set
      EXT4_STATE_MAY_INLINE_DATA flag here, since ext4_mark_inode_dirty()
      already sets this flag if needed.  Setting EXT4_STATE_MAY_INLINE_DATA
      when it is needed may trigger a BUG_ON in ext4_writepages().
      
      Reported-by: syzbot+d30838395804afc2fa6f@syzkaller.appspotmail.com
      Cc: stable@kernel.org
      Signed-off-by: default avatarYe Bin <yebin10@huawei.com>
      Reviewed-by: default avatarJan Kara <jack@suse.cz>
      Link: https://lore.kernel.org/r/20230307015253.2232062-3-yebin@huaweicloud.comSigned-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      2b96b4a5