For error handling path in ubifs_symlink(), inode will be marked as
bad first, then iput() is invoked. If inode->i_link is initialized by
fscrypt_encrypt_symlink() in encryption scenario, inode->i_link won't
be freed by callchain ubifs_free_inode -> fscrypt_free_inode in error
handling path, because make_bad_inode() has changed 'inode->i_mode' as
'S_IFREG'.
Following kmemleak is easy to be reproduced by injecting error in
ubifs_jnl_update() when doing symlink in encryption scenario:
unreferenced object 0xffff888103da3d98 (size 8):
comm "ln", pid 1692, jiffies 4294914701 (age 12.045s)
backtrace:
kmemdup+0x32/0x70
__fscrypt_encrypt_symlink+0xed/0x1c0
ubifs_symlink+0x210/0x300 [ubifs]
vfs_symlink+0x216/0x360
do_symlinkat+0x11a/0x190
do_syscall_64+0x3b/0xe0
There are two ways fixing it:
1. Remove make_bad_inode() in error handling path. We can do that
because ubifs_evict_inode() will do same processes for good
symlink inode and bad symlink inode, for inode->i_nlink checking
is before is_bad_inode().
2. Free inode->i_link before marking inode bad.
Method 2 is picked, it has less influence, personally, I think.
Cc: stable@vger.kernel.org
Fixes: 2c58d548f5 ("fscrypt: cache decrypted symlink target in ->i_link")
Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
Suggested-by: Eric Biggers <ebiggers@kernel.org>
Reviewed-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
with preemption disabled. This removes some false positive splats a
number of users were seeing if their driver didn't have support for
atomic transfers. Also, fix a typo in the docs while we are here.
-----BEGIN PGP SIGNATURE-----
iQJDBAABCgAtFiEEOZGx6rniZ1Gk92RdFA3kzBSgKbYFAmWZUukPHHdzYUBrZXJu
ZWwub3JnAAoJEBQN5MwUoCm2XUMP/Rm/6oiH7ASUOKpmLi42a68llEJuBCkK8oPW
PmO/QmuTc6K1rDE6ehmBgTNeBQDkI7NdrUViu7xel1G0p57q5rZCdxl/BV7qmGjv
aq46Y3omw06UybqceVlmx8NJe9r7+HXh+qJJ0UXg/+uA9VKd0jaiGo40wQjR6AxA
Ow92+p6rUcFDGpEdXFRQJnov8p7GnCGRKumA593goju+sJRUVozjz0nifTVqdyA5
+L3V02j5INx285sAngTPSHSn2vd0arxwumXKYusehfUtytzkI0RmBWebfqxbg5QE
7WRnqtHe5aR78gr1RWWo/pI91yTtlfslGhj7uFQxcPpkKkyD57Z17N8rxS+u3rwH
xAwvYG7CiWygee+q2RTDFmz49FNxRCeB3O5cjPp1Imco6MVG5ZOwZjIjn3CkDyvi
CGQD8vXdiDfRBDSCI25XdORNsTBzrhSBAs412xGo3waflvgowtw076FYpXfNnAmZ
z79lIlrR+Hg7ynZBs3qcjVOXvaj8rzXiLkfFWrBihGfbzVOTJv9cfetEpYcOcSaw
Ae/wC3TKhvowdaFr43wYJrIsni93xdsCjHeIwQYozKbD6iiKWymwxzhWRDTM0cjP
eSifFBoa1mzVqUNzSVzCHFbdKV0nlhZqxpZGrsTKhUm2EU0934sb9hBvn8o1weaR
WRl0sHoU
=LZdW
-----END PGP SIGNATURE-----
Merge tag 'i2c-for-6.7-final' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux
Pull i2c fixes from Wolfram Sang:
"Improve the detection when to run atomic transfer handlers for kernels
with preemption disabled. This removes some false positive splats a
number of users were seeing if their driver didn't have support for
atomic transfers.
Also, fix a typo in the docs while we are here"
* tag 'i2c-for-6.7-final' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux:
i2c: core: Fix atomic xfer check for non-preempt config
Documentation/i2c: fix spelling error in i2c-address-translators
The error paths that follow calls to the devm_request_irq() functions
within the xilinx_pl_dma_pcie_setup_irq() reference an uninitialized
symbol each that also so happens to be incorrect.
Thus, fix this omission and reference the correct variable when invoking
a given dev_err() function following an error.
This problem was found using smatch via the 0-DAY CI Kernel Test service:
drivers/pci/controller/pcie-xilinx-dma-pl.c:638 xilinx_pl_dma_pcie_setup_irq() error: uninitialized symbol 'irq'.
drivers/pci/controller/pcie-xilinx-dma-pl.c:645 xilinx_pl_dma_pcie_setup_irq() error: uninitialized symbol 'irq'.
Fixes: 8d786149d7 ("PCI: xilinx-xdma: Add Xilinx XDMA Root Port driver")
Link: https://lore.kernel.org/oe-kbuild/202312120248.5DblxkBp-lkp@intel.com/
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
Closes: https://lore.kernel.org/r/202312120248.5DblxkBp-lkp@intel.com/
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Since commit aa49c90894 ("i2c: core: Run atomic i2c xfer when
!preemptible"), the whole reboot/power off sequence on non-preempt kernels
is using atomic i2c xfer, as !preemptible() always results to 1.
During device_shutdown(), the i2c might be used a lot and not all busses
have implemented an atomic xfer handler. This results in a lot of
avoidable noise, like:
[ 12.687169] No atomic I2C transfer handler for 'i2c-0'
[ 12.692313] WARNING: CPU: 6 PID: 275 at drivers/i2c/i2c-core.h:40 i2c_smbus_xfer+0x100/0x118
...
Fix this by allowing non-atomic xfer when the interrupts are enabled, as
it was before.
Link: https://lore.kernel.org/r/20231222230106.73f030a5@yea
Link: https://lore.kernel.org/r/20240102150350.3180741-1-mwalle@kernel.org
Link: https://lore.kernel.org/linux-i2c/13271b9b-4132-46ef-abf8-2c311967bb46@mailbox.org/
Fixes: aa49c90894 ("i2c: core: Run atomic i2c xfer when !preemptible")
Cc: stable@vger.kernel.org # v5.2+
Signed-off-by: Benjamin Bara <benjamin.bara@skidata.com>
Tested-by: Michael Walle <mwalle@kernel.org>
Tested-by: Tor Vic <torvic9@mailbox.org>
[wsa: removed a comment which needs more work, code is ok]
Signed-off-by: Wolfram Sang <wsa@kernel.org>
When building with clang 18 with the -Werror compiler option enabled,
the following error will be reported:
drivers/pci/controller/dwc/pcie-rcar-gen4.c:439:15: error: cast to smaller integer type 'enum dw_pcie_device_mode' from 'const void *' [-Werror,-Wvoid-pointer-to-enum-cast]
439 | rcar->mode = (enum dw_pcie_device_mode)of_device_get_match_data(&rcar->pdev->dev);
To fix this issue, cast the data the of_device_get_match_data() helper
returns to uintptr_t rather than the dw_pcie_device_mode enum.
[kwilczynski: commit log]
Link: https://lore.kernel.org/linux-pci/20231220053829.1921187-7-yoshihiro.shimoda.uh@renesas.com
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
When building with clang 18, the following warning will be reported:
drivers/pci/controller/pcie-iproc-platform.c:54:15: warning: cast to smaller integer type 'enum iproc_pcie_type' from 'const void *' [-Wvoid-pointer-to-enum-cast]
55 | pcie->type = (enum iproc_pcie_type) of_device_get_match_data(dev);
To fix this issue, cast the data the of_device_get_match_data() helper
returns to uintptr_t rather than the iproc_pcie_type enum.
[kwilczynski: commit log]
Link: https://lore.kernel.org/linux-pci/20231220053829.1921187-6-yoshihiro.shimoda.uh@renesas.com
Link: https://github.com/ClangBuiltLinux/linux/issues/1910
Reported-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Justin Stitt <justinstitt@google.com>
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
The current code calculated some dbi[2] registers' offset by calling
dw_pcie_ep_get_dbi[2]_offset() in each function. To improve the code
readability, add dw_pcie_ep_{read,write}_dbi[2} and some data-width
related helpers.
Link: https://lore.kernel.org/linux-pci/20231220053829.1921187-5-yoshihiro.shimoda.uh@renesas.com
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Since the struct member .func_conf_select makes the intentions behind it
difficult to ascertain from its name alone, rename it to .get_dbi_offset
to make the intended usage more obvious.
[kwilczynski: commmit log]
Suggested-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/linux-pci/20231220053829.1921187-4-yoshihiro.shimoda.uh@renesas.com
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
Since the name of the dw_pcie_ep_ops struct makes it obvious that it's
for the PCIe Endpoint, rename the struct member .ep_init to .init.
[kwilczynski: commit log]
Suggested-by: Serge Semin <fancer.lancer@gmail.com>
Suggested-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/linux-pci/20231220053829.1921187-3-yoshihiro.shimoda.uh@renesas.com
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
Reviewed-by: Srikanth Thokala <srikanth.thokala@intel.com>
Acked-by: Jesper Nilsson <jesper.nilsson@axis.com>
Acked-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Since the name of the dw_pcie_host_ops struct makes it obvious that it's
for the PCIe Host, drop the host prefix from the struct members.
[kwilczynski: commit log]
Suggested-by: Serge Semin <fancer.lancer@gmail.com>
Link: https://lore.kernel.org/linux-pci/20231220053829.1921187-2-yoshihiro.shimoda.uh@renesas.com
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
Reviewed-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Acked-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Jesper Nilsson <jesper.nilsson@axis.com>
Acked-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Acked-by: Lei Chuanhua <lchuanhua@maxlinear.com>
Acked-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp>
Use a unique test pattern for each BAR in. This makes it easier to
detect/debug address translation issues, since a developer can dump
the backing memory on the EP side, using e.g. devmem, to verify that
the address translation for each BAR is actually correct.
Link: https://lore.kernel.org/linux-pci/20231215105952.1531683-1-nks@flawful.org
Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
The J721E PCIe is hardware specific to TI SoC parts so add a dependency
on that so it's available for those SoC parts and for compile testing but
not necessarily everyone who enables the Cadence PCIe controller.
Link: https://lore.kernel.org/linux-pci/20240104213910.1426843-1-pbrobinson@gmail.com
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
new helpers:
- bch2_csum_to_text()
- bch2_csum_err_msg()
standardize our checksum error messages a bit, and print out the
checksums a bit more nicely.
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
this definitely should _not_ be 1, and we don't actually want any
concurrency limiting at all here - btree node read completions are
getting blocked behind btree node write submissions.
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
Seeing weird latency issues in the btree node read path - add one
bch2_btree_node_read_done().
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
Seeing strange performance issues that might be caused by memory
pressure causing prefetched nodes to be evicted before they're used.
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
BCH_FS_fsck_done -> BCH_FS_fsck_running; set when we might be fixing
fsck errors. Also; set fix_errors to ask by default when fsck is
running.
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
New flag so that triggers can distinguish whether we're running
transactional or atomic triggers (or gc) - unifying the callbacks.
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
Prep work for disk space accounting rewrite: we're going to want to use
a single callback for both of our current triggers, so we need to change
them to have the same type signature first.
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
