Christoph Hellwig <hch@lst.de> says:
Currently iomap defers all write completions to interrupt context. This
was based on my assumption that no one cares about the latency of those
to simplify the code vs the old direct-io.c. It turns out someone cared,
as Avi reported a lot of context switches with ScyllaDB, which at least
in older kernels with workqueue scheduling issues caused really high
tail latencies.
Fortunately allowing the direct completions is pretty easy with all the
other iomap changes we had since.
While doing this I've also found dead code which gets removed (patch 1)
and an incorrect assumption in zonefs that read completions are called
in user context, which it assumes for it's error handling. Fix this by
always calling error completions from user context (patch 2).
Against the vfs-6.19.iomap branch.
* patches from https://patch.msgid.link/20251113170633.1453259-1-hch@lst.de:
iomap: invert the polarity of IOMAP_DIO_INLINE_COMP
iomap: support write completions from interrupt context
iomap: rework REQ_FUA selection
iomap: always run error completions in user context
fs, iomap: remove IOCB_DIO_CALLER_COMP
Link: https://patch.msgid.link/20251113170633.1453259-1-hch@lst.de
Signed-off-by: Christian Brauner <brauner@kernel.org>
Replace IOMAP_DIO_INLINE_COMP with a flag to indicate that the
completion should be offloaded. This removes a tiny bit of boilerplate
code, but more importantly just makes the code easier to follow as this
new flag gets set most of the time and only cleared in one place, while
it was the inverse for the old version.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Link: https://patch.msgid.link/20251113170633.1453259-6-hch@lst.de
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Christian Brauner <brauner@kernel.org>
Completions for pure overwrites don't need to be deferred to a workqueue
as there is no work to be done, or at least no work that needs a user
context. Set the IOMAP_DIO_INLINE_COMP by default for writes like we
already do for reads, and the clear it for all the cases that actually
do need a user context for completions to update the inode size or
record updates to the logical to physical mapping.
I've audited all users of the ->end_io callback, and they only require
user context for I/O that involves unwritten extents, COW, size
extensions, or error handling and all those are still run from workqueue
context.
This restores the behavior of the old pre-iomap direct I/O code.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Link: https://patch.msgid.link/20251113170633.1453259-5-hch@lst.de
Signed-off-by: Christian Brauner <brauner@kernel.org>
The way how iomap_dio_can_use_fua and the caller is structured is
a bit confusing, as the main guarding condition is hidden in the
helper, and the secondary conditions are split between caller and
callee.
Refactor the code, so that iomap_dio_bio_iter itself tracks if a write
might need metadata updates based on the iomap type and flags, and
then have a condition based on that to use the FUA flag.
Note that this also moves the REQ_OP_WRITE assignment to the end of
the branch to improve readability a bit.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Link: https://patch.msgid.link/20251113170633.1453259-4-hch@lst.de
Signed-off-by: Christian Brauner <brauner@kernel.org>
At least zonefs expects error completions to be able to sleep. Because
error completions aren't performance critical, just defer them to workqueue
context unconditionally.
Fixes: 8dcc1a9d90 ("fs: New zonefs file system")
Signed-off-by: Christoph Hellwig <hch@lst.de>
Link: https://patch.msgid.link/20251113170633.1453259-3-hch@lst.de
Reviewed-by: Jan Kara <jack@suse.cz>
Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com>
Signed-off-by: Christian Brauner <brauner@kernel.org>
This was added by commit 099ada2c87 ("io_uring/rw: add write support
for IOCB_DIO_CALLER_COMP") and disabled a little later by commit
838b35bb6a ("io_uring/rw: disable IOCB_DIO_CALLER_COMP") because it
didn't work. Remove all the related code that sat unused for 2 years.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Link: https://patch.msgid.link/20251113170633.1453259-2-hch@lst.de
Reviewed-by: Jan Kara <jack@suse.cz>
Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com>
Reviewed-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Christian Brauner <brauner@kernel.org>
This series contains several fixes and cleanups:
* Renaming bytes_pending/bytes_accounted to
bytes_submitted/bytes_not_submitted for improved code clarity
* Accounting for unaligned end offsets when truncating read ranges
* Adding documentation for iomap_finish_folio_write() requirements
* Optimizing pending async writeback accounting logic
* Simplifying error handling in ->read_folio_range() for read operations
* Streamlining logic for skipping reads during write operations
* Replacing manual bitmap scanning with find_next_bit() for both dirty
and uptodate bitmaps, improving performance
* patches from https://patch.msgid.link/20251111193658.3495942-1-joannelkoong@gmail.com:
iomap: use find_next_bit() for uptodate bitmap scanning
iomap: use find_next_bit() for dirty bitmap scanning
iomap: simplify when reads can be skipped for writes
iomap: simplify ->read_folio_range() error handling for reads
iomap: optimize pending async writeback accounting
docs: document iomap writeback's iomap_finish_folio_write() requirement
iomap: account for unaligned end offsets when truncating read range
iomap: rename bytes_pending/bytes_accounted to bytes_submitted/bytes_not_submitted
Link: https://patch.msgid.link/20251111193658.3495942-1-joannelkoong@gmail.com
Signed-off-by: Christian Brauner <brauner@kernel.org>
Use find_next_bit()/find_next_zero_bit() for iomap uptodate bitmap
scanning. This uses __ffs() internally and is more efficient for
finding the next uptodate or non-uptodate bit than iterating through the
the bitmap range testing every bit.
Signed-off-by: Joanne Koong <joannelkoong@gmail.com>
Link: https://patch.msgid.link/20251111193658.3495942-10-joannelkoong@gmail.com
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Suggested-by: Christoph Hellwig <hch@infradead.org>
Signed-off-by: Christian Brauner <brauner@kernel.org>
Use find_next_bit()/find_next_zero_bit() for iomap dirty bitmap
scanning. This uses __ffs() internally and is more efficient for
finding the next dirty or clean bit than iterating through the bitmap
range testing every bit.
Signed-off-by: Joanne Koong <joannelkoong@gmail.com>
Link: https://patch.msgid.link/20251111193658.3495942-9-joannelkoong@gmail.com
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Suggested-by: Christoph Hellwig <hch@infradead.org>
Signed-off-by: Christian Brauner <brauner@kernel.org>
1. ChipID driver: Add support for identifying Exynos8890 and Exynos9610.
2. PMU driver: Allow specifying list of valid registers for the custom
regmap used on Google GS101 SoC. The PMU (Power Management Unit) on
that SoC uses more complex access to registers than simple MMIO and
invalid registers trigger aborts halting the system.
3. Few minor cleanups.
4. Several new bindings for compatible devices.
-----BEGIN PGP SIGNATURE-----
iQJEBAABCgAuFiEE3dJiKD0RGyM7briowTdm5oaLg9cFAmkR0ggQHGtyemtAa2Vy
bmVsLm9yZwAKCRDBN2bmhouD19GdD/47OlRvdAeqrLA4SShMPJZ0/YItO1K1Veyv
SiiH6bn9qAzUGrNFVsQ3vxkZd+Fnt1Bpwv1IY8tnc/xI39eZrGzR2VoemcePPsxs
28MqMos94A4xiqzRScD2i95Axo+92r7p64UAfO9ff/5ZNgZl6Ksxn7cU9OkVtQDf
OrtYimJuJWXXvb0Pu8NV/BJv3ybOUa4v4JcPie6PGMU5GJVrF+nlTyWIz03PUE0j
uJWO6+VzlxXStLXFC13ADMu1boJv0ABzspOKrccGCLoNNUpNcmz+oKn4npfQRZ8L
fEeITtdkEJ+CwmVRaBF/2yvZR7M5xt9W1Jml1jPry5vig9IAv3uzt5aX/cEmHOJF
Uqtwaqn/3JOu4MYQikIWnMH8fta/3g8l8LtOsj9a4rWujuGsDxIsV4ICSQCTclYF
yDo/3QPXWLlnFc2xmgvKl2VXpTEK4D97VmTZqmTyju1mbemCbXALwWb/VhY9wWPP
f50PVyrAmsl4tA/M+wFQyVDEbU4EMRqBun49b9mVkXxgQ9nubpkmhszHLwNXQ+7V
pHGaH7P82V/T+7YT28xh+PMrpi0sdVa7I6z9Bp+2jr+vM4mPW+a5jFPSh+/o02o8
7zvqhDFqFIXTrmDGtTzCTpOTNIIH0BLEqmxRWvga/69kNYJngkM+PnfTdSV47sfn
oMHdRw35LQ==
=hX5T
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmkldUIACgkQmmx57+YA
GNkS0w/8CEbE0WGWGYPXcG7a5lg7Hbbn3I060xCFc2YATdtymRTS0PoD4cNt5ts7
6YFg0JR+zUjN0ZCM5wY+CzbAsrGzjlY/CtqeYYAKyso3vj6ujKuUmsobELhlnEeN
RQzUR/sOok6EvGavFTkDAR33bLyW2Mg+vXt5sMtF186eGk7qDecxkpp0joJaZEPj
1Rbd8TnHDNfvi6VAWHpQOmiroLAC15aTwa5flruvsu+RvhfsOIcccCRjVpmHNSvL
6nS162lnXFntFr66/Hnm2JCy4rggDRGM1akCRlI25iAZBvFNPFE5rifAZsh060yo
QMcqphhEAvy5DpA7GClbt7BdyinjqbV8RL8qAgdXGXxX1rgAd0f6bmnPc3S4CDS8
dkBtTViXOxqU7dD/lsy5OnO+g9td055c4KsPv+Y3MTRpNIDH8jVuvoNT1c+LTzQS
KzKEMxghfdSQNZQVaCs5vzs3ticapUHcf5sfdNJwmOIYdEURctI0MNc1/GXw+GZ3
frNM6YNyYZUoTU3WK9sGQhzms0ucR/mFeJCHyNLxPpBnZ414OuOhag2lJjbfyvlA
46kKAa7T8GlYG2zoTj74Cmabrin5Q4eOeUBS/APOpp2zMYHN+06zkthQrZeGgOmu
zoK4OHZS3+6qIhhlGoPPlVnaj7yBECg6hhYdj1RgvjNR6Q05jCg=
=VGfE
-----END PGP SIGNATURE-----
Merge tag 'samsung-drivers-6.19' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux into soc/drivers
Samsung SoC drivers for v6.19
1. ChipID driver: Add support for identifying Exynos8890 and Exynos9610.
2. PMU driver: Allow specifying list of valid registers for the custom
regmap used on Google GS101 SoC. The PMU (Power Management Unit) on
that SoC uses more complex access to registers than simple MMIO and
invalid registers trigger aborts halting the system.
3. Few minor cleanups.
4. Several new bindings for compatible devices.
* tag 'samsung-drivers-6.19' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux:
dt-bindings: soc: samsung: exynos-pmu: allow mipi-phy subnode for Exynos7870 PMU
soc: samsung: exynos-chipid: use a local dev variable
dt-bindings: soc: samsung: exynos-sysreg: add gs101 hsi0 and misc compatibles
dt-bindings: soc: samsung: exynos-sysreg: add power-domains
soc: samsung: gs101-pmu: implement access tables for read and write
soc: samsung: exynos-pmu: move some gs101 related code into new file
soc: samsung: exynos-pmu: allow specifying read & write access tables for secure regmap
dt-bindings: samsung: exynos-sysreg: add exynos7870 sysregs
soc: samsung: exynos-chipid: add exynos8890 SoC support
dt-bindings: hwinfo: samsung,exynos-chipid: add exynos8890-chipid compatible
dt-bindings: soc: samsung: exynos-pmu: add exynos8890 compatible
soc: samsung: exynos-pmu: Annotate online/offline functions with __must_hold
soc: samsung: exynos-chipid: Add exynos9610 SoC support
dt-bindings: hwinfo: samsung,exynos-chipid: add exynos9610 compatible
dt-bindings: soc: samsung: exynos-sysreg: Add Exynos990 PERIC0/1 compatibles
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
In order to work around the existence of a vmap symbol in libpcap, the
UML makefile unconditionally redefines vmap to kernel_vmap. However,
this not only affects the actual vmap symbol, but also anything else
named vmap, including a number of struct members in DRM.
This would not be too much of a problem, since all uses are also
updated, except we now have Rust DRM bindings, which expect the
corresponding Rust structs to have 'vmap' names. Since the redefinition
applies in bindgen, but not to Rust code, we end up with errors such as:
error[E0560]: struct `drm_gem_object_funcs` has no fields named `vmap`
--> rust/kernel/drm/gem/mod.rs:210:9
Since libpcap support was removed in commit 12b8e7e69a ("um: Remove
obsolete pcap driver"), remove the, now unnecessary, define as well.
We also take this opportunity to update the comment.
Signed-off-by: David Gow <davidgow@google.com>
Acked-by: Miguel Ojeda <ojeda@kernel.org>
Link: https://patch.msgid.link/20251122083213.3996586-1-davidgow@google.com
Fixes: 12b8e7e69a ("um: Remove obsolete pcap driver")
[adjust commmit message a bit]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
In a recent commit, I inadvertently changed a comparison from being an
unsigned comparison (on 64-bit systems) to being a signed comparison
(which it had always been on 32-bit systems). This led to a sporadic
fstests failure.
To make sure this comparison is always unsigned, introduce a new type,
uoff_t which is the unsigned version of loff_t. Generally file sizes
are restricted to being a signed integer, but in these two places it is
convenient to pass -1 to indicate "up to the end of the file".
Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Link: https://patch.msgid.link/20251123220518.1447261-1-willy@infradead.org
Signed-off-by: Christian Brauner <brauner@kernel.org>
Otherwise it gets inlined notably in walk_component(), which convinces
the compiler to push/pop additional registers in the fast path to
accomodate existence of the inlined version.
Shortens the fast path of that routine from 87 to 71 bytes.
Signed-off-by: Mateusz Guzik <mjguzik@gmail.com>
Link: https://patch.msgid.link/20251119144930.2911698-1-mjguzik@gmail.com
Signed-off-by: Christian Brauner <brauner@kernel.org>
Stats from nd->depth usage during the venerable kernel build collected like so:
bpftrace -e 'kprobe:terminate_walk,kprobe:walk_component,kprobe:legitimize_links
{ @[probe] = lhist(((struct nameidata *)arg0)->depth, 0, 8, 1); }'
@[kprobe:legitimize_links]:
[0, 1) 6554906 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@|
[1, 2) 3534 | |
@[kprobe:terminate_walk]:
[0, 1) 12153664 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@|
@[kprobe:walk_component]:
[0, 1) 53075749 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@|
[1, 2) 971421 | |
[2, 3) 84946 | |
Additionally a custom probe was added for depth within link_path_walk():
bpftrace -e 'kprobe:link_path_walk_probe { @[probe] = lhist(arg0, 0, 8, 1); }'
@[kprobe:link_path_walk_probe]:
[0, 1) 7528231 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@|
[1, 2) 407905 |@@ |
Given these results:
1. terminate_walk() is called towards the end of the lookup and in this
test it never had any links to clean up.
2. legitimize_links() is also called towards the end of lookup and most
of the time there s 0 depth. Patch consumers to avoid calling into it
in that case.
3. walk_component() is typically called with WALK_MORE and zero depth,
checked in that order. Check depth first and predict it is 0.
4. link_path_walk() also does not deal with a symlink most of the time
when !*name
Signed-off-by: Mateusz Guzik <mjguzik@gmail.com>
Link: https://patch.msgid.link/20251119142954.2909394-1-mjguzik@gmail.com
Signed-off-by: Christian Brauner <brauner@kernel.org>
Add clock definitions for XSPI0/1 to both R9A09G077 and R9A09G087 SoCs.
These definitions are required for describing XSPI devices in DT
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20251028165127.991351-5-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
lookup_mnt_ns() already takes a reference on mnt_ns.
grab_requested_mnt_ns() doesn't need to take an extra reference.
Fixes: 78f0e33cd6 ("fs/namespace: correctly handle errors returned by grab_requested_mnt_ns")
Signed-off-by: Andrei Vagin <avagin@google.com>
Link: https://patch.msgid.link/20251122071953.3053755-1-avagin@google.com
Signed-off-by: Christian Brauner <brauner@kernel.org>
1. Tegra drivers: Several cleanups (dev_err_probe(), error messages).
2. Renesas RPC IF: Add system suspend support.
-----BEGIN PGP SIGNATURE-----
iQJEBAABCgAuFiEE3dJiKD0RGyM7briowTdm5oaLg9cFAmkhyLoQHGtyemtAa2Vy
bmVsLm9yZwAKCRDBN2bmhouD18WSD/4ks7F1aAMhd/jjPW7Zzkl99LSPnwUgpYYn
CR/kf78AMVLYh3z/zIGUJNanjF7huqcI/uJ5YZSDIXMHQDFfTNbomOY5O6VesGTn
aNAU2D0Isn2Afb3f10b/RYQNyLIMiNhvZLTxqpduNpAfWVp2/gZzEpf9Lrspt6Ni
J5uzzGrqvnlbjsEc23WlxK0zBgTzrJHcD/Tv+SQwRsy6QSZTeugesey48sqw84wo
bAj3kYTxDXajQgLt/Ricb8ZgVMH7XUdXxAr7EnRD3ZXoODWoJKQotp5HaV9d2Nac
e7YMf8kqEX0qyO11mAnrYCNTxRItb4Ks0mqoMSSeg1kfIy/WsDyK7e3XyFl1MKCj
E3j+Vty17PZHU2Tq35zgnk/P+PVAg0juyEV5pllW20Ky7fQQj5jFNzjeaVbZ0o6F
1KKAIgsDnHnrsKqYDlvBMCoU5ZYvY85/8MTxOfPUcTNCoAxdgJ/ORMbcNAm2rzzJ
9cfTZXlHoMuL9sm8TnDvpV1S8YzN6uKLSoDW3wj0HsFHE4QQ4crGETFOnVygJu60
FIb27/wrwzOxu1dvUvR8RPfwxFa3yfR6EGKqVQEXFXOvkfUp/AxHDPSNhFuCAgJh
+mVwqWAubNrko0uALNkqzj68NyejXnKOE0wsFVXv6U8ZxwMugNflDcptTLRvzmTP
M3H3af+Pqw==
=eiGr
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmklZ8IACgkQmmx57+YA
GNmZRw//fRJxilV+aSSSDI8buNOuu6VvBWHKh3ikj0j9RXeK54zoxeNjwWHyttD9
fq0QdFCSefRN2k1JS29z4rIo1KDbyaQtssNpmxsktoHofHYOVLmewI2dcrf5O6l/
WCKrnGdH1bzuXrBWrLeHeexx0Dl17DEq2Wid/dWL1uWfVNwpohNYjfPI4Z7dM8wb
3teCeNRTT/OLoXsezcDr/F3gPhEGBnH08SYgvn5JtVhnLOrm0sjTTViHQyinpuo2
GsmHX34OJJyehp5axzib2/dAyr99+C6fJh/rNQzRHlSs9vheThXDQEhH8jftxVtg
/wyJijbpTaea0NBB5zgeluiClgNI4sitsvOWUmRwDzbGbNGut+R7A59LHmaC+YO8
yjNfXmReBfWi51YUBdnIFjsXvsiOMcIayc9WX9izloi/i2IN0OG3kTCLNiqVU6mo
0bKvaDBSvXBv6ogodvlu99KX8PPfoD63hBfi5EDmqB0UUWKoHlwsVhWptwWlAk7Y
2l96TOYqrk3uJOC/T3epRWqXzFnnNL/QOHAcRHQmBJuF4GnGSdJKPyIueSKSbLtH
M8aOMeA2WKKvSu8f+DolFEgBXIkcAdSJAYl/jBxnrWyrvAlV3x6eb2DFhPXdiA37
1vnkjDTmH06NcA9k+KGubrWOe8qraYDCgx8A3amOXjkkJbhKxSw=
=5JHX
-----END PGP SIGNATURE-----
Merge tag 'memory-controller-drv-6.19-2' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl into soc/drivers
Memory controller drivers for v6.19
1. Tegra drivers: Several cleanups (dev_err_probe(), error messages).
2. Renesas RPC IF: Add system suspend support.
* tag 'memory-controller-drv-6.19-2' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl:
memory: tegra186-emc: Fix missing put_bpmp
memory: renesas-rpc-if: Add suspend/resume support
memory: tegra30-emc: Add the SoC model prefix to functions
memory: tegra20-emc: Add the SoC model prefix to functions
memory: tegra186-emc: Add the SoC model prefix to functions
memory: tegra124-emc: Add the SoC model prefix to functions
memory: tegra124-emc: Simplify and handle deferred probe with dev_err_probe()
memory: tegra186-emc: Simplify and handle deferred probe with dev_err_probe()
memory: tegra20-emc: Simplify and handle deferred probe with dev_err_probe()
memory: tegra30-emc: Simplify and handle deferred probe with dev_err_probe()
memory: tegra30-emc: Do not print error on icc_node_create() failure
memory: tegra20-emc: Do not print error on icc_node_create() failure
memory: tegra186-emc: Do not print error on icc_node_create() failure
memory: tegra124-emc: Do not print error on icc_node_create() failure
memory: tegra124-emc: Simplify return of emc_init()
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
- Keep the WDTRSTCR.RESBAR2S bit in the default state on R-Car Gen4.
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQQ9qaHoIs/1I4cXmEiKwlD9ZEnxcAUCaQSESQAKCRCKwlD9ZEnx
cHT9AQCDNPePCxys+cJiV7Z8vchZvIK4HhREtdZh5LVlrLx6WQEAh2Gk6QVa8ULs
ZFfoqcxPHV2NK1O/G+uFxUrm9VRNSQE=
=mCfo
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmklZ2sACgkQmmx57+YA
GNmY3A//eMPfIICzEc3Y5celWIa2IsRpU3T7LGdSTX2VzFN89GQyz2Yt3invRwbl
7EJXUsqHBc7Koeeet1zKfSCkFTLhmN+W88l7n6xEzcCINhw6SSvNmjRHL1l+jqxr
0u3YF57iXJ7t5pQ7ISqsUP6e9MwBBoWl8G2euWhDEwBARXEn/l6yjzXqPDeijeCB
d0/KK0Xf422UVIdAmBCXdNqg5po0GjIzBr4Ag55oXjAhYeAFjE9irtK1kpi7xkz5
jaPob1IBoNVT545Kb3J9hiE9z4EFNpbSa2KbtjTIXNBi9Yhb/JwiGmLrIh3dskcX
hev8rp0jKo6CNY4RFic6qFM94TELPJvY/d+OccAHNEA+HAHYnNHKUzQWpHSns3wq
WS9lBdIqnXDHPlkSq+HRiU8uNCsQbVrMhK8s8/CriZyf8dUZ8SNPcXT0k44eY0Qx
k3f/qRecdM+LhqQxOpzwXNXEW7qy816/EMqIs7si1Z6ERE9yT0u6wCsRYCzaD9K/
nS1I0RefopdZfUFEJHI6f55nMxhEsILux7Kps1h8MeGYLHBeRq+dEPRT4D62XJI7
IqGIKoh8PDIxcCRVSm6q1yDR5sHn5nkenz0yMO8mP73TcHl6XOIkjFicQKaroa2S
8uDFga/7k3AyFVXLmePY59LPRxyS/f4DwTYeZ18wWDqCkGzX2jg=
=wE3h
-----END PGP SIGNATURE-----
Merge tag 'renesas-drivers-for-v6.19-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into soc/drivers
Renesas driver updates for v6.19
- Keep the WDTRSTCR.RESBAR2S bit in the default state on R-Car Gen4.
* tag 'renesas-drivers-for-v6.19-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel:
soc: renesas: rcar-rst: Keep RESBAR2S in default state
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Make the enum name in kernel-doc match the code to prevent kernel-doc warnings:
Warning: include/linux/cc_platform.h:106 Enum value
'CC_ATTR_GUEST_SEV_SNP' not described in enum 'cc_attr'
Warning: include/linux/cc_platform.h:106 Excess enum value
'%CC_ATTR_SEV_SNP' description in 'cc_attr'
Fixes: f742b90e61 ("x86/mm: Extend cc_attr to include AMD SEV-SNP")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://patch.msgid.link/20251125022730.3163679-1-rdunlap@infradead.org
In kvm_vcpu_on_spin(), the loop counter 'i' is incorrectly written to
last_boosted_vcpu instead of the actual vCPU index 'idx'. This causes
last_boosted_vcpu to store the loop iteration count rather than the
vCPU index, leading to incorrect round-robin behavior in subsequent
directed yield operations.
Fix this by using 'idx' instead of 'i' in the assignment.
Signed-off-by: Wanpeng Li <wanpengli@tencent.com>
Reviewed-by: Sean Christopherson <seanjc@google.com>
Message-ID: <20251110033232.12538-7-kernellwp@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Asus Tinkerboard 3 + 3S.
Additional peripherals enabled on 100ASK DshanPi A1, Orange Pi 3B,
Indiedroid Nova, QNAP-TSx33 series + LED states on Radxa boards,
power-domains for the previously added RK3368 display components.
-----BEGIN PGP SIGNATURE-----
iQFEBAABCAAuFiEE7v+35S2Q1vLNA3Lx86Z5yZzRHYEFAmkk07cQHGhlaWtvQHNu
dGVjaC5kZQAKCRDzpnnJnNEdgSbNB/9Yp0zMIh32zhhsgOC6rjsFJFRDpriEogij
5YjZIHdYcScPcufMB9CfpwKzEXf40TP6x5xxkyaaEc6rZRTCBD+7XC5J4t2xBS0I
aIvl4RuRs1xb5MkWccoJP/xVXykWIaBju6I+Feqzt6O6KRoNJd+O/N4nkPazIF1F
6bvJrD5vLkl2vWBO1VCUBzGOMGiSwKUJf8uiUeTHHSuEn+O1xGLrQkvgUQOFrBnH
IC3OORMT0u3yQujblr1/B8KCaUeuQIRHlLH8IjEoJUvRv1ay5pNc7s0NYrgHrzRZ
H+DcT65hhwhq3pqA90rEusU9RBZp5MlQ6T1Jv7Z4M3GRXsTduW+1
=yhUe
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmklZT0ACgkQmmx57+YA
GNk6mhAAoy/vBNndqCNuRQqup8ApuAP+ojPEB7CvU6qE9IIfc9R4S0GRAj46PVw1
V3jLuU7uxv11EcwQ+AaGxREG8XtYV5tWAiNN0XlTZ9tEup4tZ0nshafgphVekI11
2CmJDiIOSvHVaVBFqdEft1rxZZN0M6+G6GNe14nbZM2VcRb7fnIBQfBs1Cf3HRlM
RaUZrXeHt6bvSBljGi7JXzHiEVxY+vIAboOlfIhzOWlsUd/EcILRa9BRMC0MiHUz
JkTWBSPxf2OmCpnD1nOIhk1KCExve7DPpJPpusi63pUkMSPi/PeYnuwevmvozJc9
IHBRXsk7ztuZbceYQ/6Md2ue+RoCFFeMATPE2DWOl4+pAjYmQMeqxqQdievcTbJX
Z9HBYxtuhZIujapgIEdGmIQ0eF1r7HUcvyZiuVUhrwg2rS03ss7NLsCsW+wih/Cl
peGPLqLUH0tDChyBXzt7eaMHbx7jixpkbrLUN58E4GCb7V3C/4kZ2DmbugiSdKjs
vKWpFeKymiYt3fEkwuhxwCR/j3W4r2JWhhT7qjj5yRAeOFdMj7hF0wyFd6bJFzXF
a/bu62eWtAuygC5ffzj1ifbDwcUTib22xkOe7vTSB1B63HE2PAueXpPGBDQ8kejn
Q1YPU53FZBZjX3GdWmcJr6PPfW+SQnM3i1EXtVgz5oFMpS9TOUk=
=xuz3
-----END PGP SIGNATURE-----
Merge tag 'v6.19-rockchip-dts64-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into soc/dt
New boards: QNAP TS233 (2-bay variant of the RK3568 NAS series) and
Asus Tinkerboard 3 + 3S.
Additional peripherals enabled on 100ASK DshanPi A1, Orange Pi 3B,
Indiedroid Nova, QNAP-TSx33 series + LED states on Radxa boards,
power-domains for the previously added RK3368 display components.
* tag 'v6.19-rockchip-dts64-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip: (22 commits)
arm64: dts: rockchip: enable RTC for 100ASK DshanPi A1
arm64: dts: rockchip: enable USB for 100ASK DshanPi A1
arm64: dts: rockchip: enable button for 100ASK DshanPi A1
arm64: dts: rockchip: add mmc aliases for 100ASK DshanPi A1
arm64: dts: rockchip: remove mmc max-frequency for 100ASK DshanPi A1
arm64: dts: rockchip: Enable i2c2 on Orange Pi 3B
arm64: dts: rockchip: Use default-state for power LED for Radxa boards
arm64: dts: rockchip: fix PCIe 3.3V regulator voltage on 9Tripod X3568 v4
arm64: dts: rockchip: Add power-domain to RK3368 VOP controller
arm64: dts: rockchip: Add power-domain to RK3368 DSI controller
arm64: dts: rockchip: Add host wake pin for wifi on Indiedroid Nova
arm64: dts: rockchip: Correct pinctrl for pcie for Indiedroid Nova
arm64: dts: rockchip: Define regulator for pcie2x1l2 on Indiedroid Nova
arm64: dts: rockchip: Add clk32k_in for Indiedroid Nova
arm64: dts: rockchip: Add Asus Tinker Board 3 and 3S device tree
dt-bindings: arm: rockchip: Add Asus Tinker Board 3/3S
dt-bindings: arm: rockchip: merge Asus Tinker and Tinker S
arm64: dts: rockchip: add QNAP TS233 devicetree
dt-bindings: arm: rockchip: add TS233 to RK3568-based QNAP NAS devices
arm64: dts: rockchip: move common qnap tsx33 parts to dtsi
...
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
The various "syscon" nodes in SC9860 are only referenced by clock
provider nodes in a 1:1 relationship, and nothing else references the
"syscon" nodes. There's no apparent reason for this split. The 2 nodes
can simply be merged into 1 node. The clock driver has supported using
either "reg" or "sprd,syscon" to access registers from the start, so
there shouldn't be any compatibility issues.
With this, DT schema warnings for missing a specific compatible with
"syscon" and non-MMIO devices on "simple-bus" are fixed.
Reviewed-by: Chunyan Zhang <zhang.lyra@gmail.com>
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://lore.kernel.org/r/20251124210031.767382-2-robh@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Protect vga_switcheroo_client_fb_set() with console lock. Avoids OOB
access in fbcon_remap_all(). Without holding the console lock the call
races with switching outputs.
VGA switcheroo calls fbcon_remap_all() when switching clients. The fbcon
function uses struct fb_info.node, which is set by register_framebuffer().
As the fb-helper code currently sets up VGA switcheroo before registering
the framebuffer, the value of node is -1 and therefore not a legal value.
For example, fbcon uses the value within set_con2fb_map() [1] as an index
into an array.
Moving vga_switcheroo_client_fb_set() after register_framebuffer() can
result in VGA switching that does not switch fbcon correctly.
Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(),
which already holds the console lock. Fbdev calls fbcon_fb_registered()
from within register_framebuffer(). Serializes the helper with VGA
switcheroo's call to fbcon_remap_all().
Although vga_switcheroo_client_fb_set() takes an instance of struct fb_info
as parameter, it really only needs the contained fbcon state. Moving the
call to fbcon initialization is therefore cleaner than before. Only amdgpu,
i915, nouveau and radeon support vga_switcheroo. For all other drivers,
this change does nothing.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://elixir.bootlin.com/linux/v6.17/source/drivers/video/fbdev/core/fbcon.c#L2942 # [1]
Fixes: 6a9ee8af34 ("vga_switcheroo: initial implementation (v15)")
Acked-by: Javier Martinez Canillas <javierm@redhat.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Cc: dri-devel@lists.freedesktop.org
Cc: nouveau@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
Cc: linux-fbdev@vger.kernel.org
Cc: <stable@vger.kernel.org> # v2.6.34+
Link: https://patch.msgid.link/20251105161549.98836-1-tzimmermann@suse.de
Restore the log client's output when the DRM core invokes the restore
callback. Follow the existing behavior of fbdev emulation wrt. the
value of the force parameter.
If force is false, acquire the DRM master lock and reprogram the
display. This is the case when the user-space compositor exits and
the DRM core transfers the display back to the in-kernel client. This
also enables drm_log output during reboot and shutdown.
If force is true, reprogram without considering the master lock. This
overrides the current compositor and prints the log to the screen. In
case of system malfunction, users can enter SysRq+v to invoke the
emergency error reporting. See Documentation/admin-guide/sysrq.rst for
more information.
v2:
- s/exists/exits/ in second paragraph of commit description
- fix grammar in commit description
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patch.msgid.link/20251110154616.539328-4-tzimmermann@suse.de
Move the sysrq functionality from DRM fbdev helpers to the DRM device
and in-kernel clients, so that it becomes available on all clients.
DRM fbdev helpers support emergency restoration of the console output
via a special key combination. Press SysRq+v to replace the current
compositor with the kernel's output on the framebuffer console. This
allows users to see the log messages during system emergencies.
By moving the functionality from fbdev helpers to the DRM device, any
in-kernel client can serve as emergency output. This can be used to
bring up drm_log, for example.
Each DRM device registers itself to the list of possible sysrq handlers.
On receiving SysRq+v, the DRM core goes over all registered devices and
restores an in-kernel DRM client for each of them.
See Documentation/admin-guide/sysrq.rst on how to invoke SysRq. Switch
VTs to bring back the user-space compositor.
v2:
- declare placeholders as 'static inline' (kernel test robot)
- fix grammar in commit description
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patch.msgid.link/20251110154616.539328-3-tzimmermann@suse.de
Add force parameter to client restore and pass value through the
layers. The only currently used value is false.
If force is true, the client should restore its display even if it
does not hold the DRM master lock. This is be required for emergency
output, such as sysrq.
While at it, inline drm_fb_helper_lastclose(), which is a trivial
wrapper around drm_fb_helper_restore_fbdev_mode_unlocked().
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patch.msgid.link/20251110154616.539328-2-tzimmermann@suse.de
Add support for the Onkyo SE-300PCIE, a Creative X-Fi CA20K2-based
sound card with a custom hardware implementation that differs
significantly from other CA20K2-based variants.
Changes:
- PCI quirk entry for OK0010
- Port 0x3 is utilized for dedicated RCA output (configured as I2S)
- Modified GPIO pin mappings and states
- 4-channel simultaneous ADC input support for line and microphone
capture without input switching (similar to SB1270)
- Simplified ADC initialization (no manual setup required)
Signed-off-by: Harin Lee <me@harin.net>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20251124180501.2760421-7-me@harin.net
Add feature to support switching between the dedicated RCA output and
the 7.1ch Front output. This is required for hardware that utilizes
separate DAC circuits for RCA and 7.1ch channels.
Changes:
- Add dedicated_rca capability flag
- Add "Analog Playback Route" mixer control
- Implement logic to swap DAO inputs between RCA and Front ports
Signed-off-by: Harin Lee <me@harin.net>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20251124180501.2760421-6-me@harin.net
Refactor atc_get_resources(), atc_connect_resources(), and
atc_release_resources() to allocate resources based on maximum type
definitions.
This allows specific resources to be conditionally skipped based on
capabilities. This is necessary for hardware variants where resource
allocations do not follow a sequential order.
Signed-off-by: Harin Lee <me@harin.net>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20251124180501.2760421-5-me@harin.net
Replace the index-based type check with an explicit output flag in
struct daio and struct daio_desc.
This allows handling DAIO resource types correctly regardless of their
index. This is necessary for hardware variants where resource types do
not follow a sequential order.
Signed-off-by: Harin Lee <me@harin.net>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20251124180501.2760421-4-me@harin.net
Add helper functions hw_adc_stop(), hw_adc_start(), and hw_adc_reset()
to encapsulate ADC reset sequence operations. These functions reduce
duplication by centralizing the GPIO-based ADC control logic.
Signed-off-by: Harin Lee <me@harin.net>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20251124180501.2760421-3-me@harin.net
Add a hw parameter to the daio_mgr_dao_init() function to provide
access to model-specific information. This is necessary for proper
configuration of S/PDIF and I2S output ports on different hardware
variants.
Signed-off-by: Harin Lee <me@harin.net>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20251124180501.2760421-2-me@harin.net
The maxpacksize field in struct audioformat represents the maximum number
of bytes per isochronous interval. The current implementation only
special-cases high-speed endpoints and does not account for the different
computations required for SuperSpeed, SuperSpeedPlus, or eUSB2. As a
result, USB audio class devices operating at these speeds may fail to
stream correctly. The issue was observed on a MOTU 16A (2025) interface,
which requires more than 1024 bytes per interval at SuperSpeed.
This patch replaces the existing logic with a helper that computes the
correct maximum bytes-per-interval for all USB speeds, borrowing the logic
used in drivers/usb/core/urb.c.
Signed-off-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://patch.msgid.link/20251124210518.90054-1-dylan_robinson@motu.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The PCIe IP available on the Renesas RZ/G3S complies with the PCI Express
Base Specification 4.0. It is designed for root complex applications and
features a single-lane (x1) implementation. Add binding documentation for
it.
Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20251119143523.977085-2-claudiu.beznea.uj@bp.renesas.com
Matthieu Baerts says:
====================
mptcp: memcg accounting for passive sockets & backlog processing
This series is split in two: the 4 first patches are linked to memcg
accounting for passive sockets, and the rest introduce the backlog
processing. They are sent together, because the first one appeared to be
needed to get the second one fully working.
The second part includes RX path improvement built around backlog
processing. The main goals are improving the RX performances _and_
increase the long term maintainability.
- Patches 1-3: preparation work to ease the introduction of the next
patch.
- Patch 4: fix memcg accounting for passive sockets. Note that this is a
(non-urgent) fix, but it depends on material that is currently only in
net-next, e.g. commit 4a997d49d9 ("tcp: Save lock_sock() for memcg
in inet_csk_accept().").
- Patches 5-6: preparation of the stack for backlog processing, removing
assumptions that will not hold true any more after the backlog
introduction.
- Patches 7,8,10,11,12 are more cleanups that will make the backlog
patch a little less huge.
- Patch 9: somewhat an unrelated cleanup, included here not to forget
about it.
- Patches 13-14: The real work is done by them. Patch 13 introduces the
helpers needed to manipulate the msk-level backlog, and the data
struct itself, without any actual functional change. Patch 14 finally
uses the backlog for RX skb processing. Note that MPTCP can't use the
sk_backlog, as the MPTCP release callback can also release and
re-acquire the msk-level spinlock and core backlog processing works
under the assumption that such event is not possible.
A relevant point is memory accounts for skbs in the backlog. It's
somewhat "original" due to MPTCP constraints. Such skbs use space from
the incoming subflow receive buffer, do not use explicitly any forward
allocated memory, as we can't update the msk fwd mem while enqueuing,
nor we want to acquire again the ssk socket lock while processing the
skbs. Instead the msk borrows memory from the subflow and reserve it
for the backlog, see patch 5 and 14 for the gory details.
====================
Link: https://patch.msgid.link/20251121-net-next-mptcp-memcg-backlog-imp-v1-0-1f34b6c1e0b1@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add missing temperature and fan sensors to Pro WS TRX50-SAGE WIFI
Also:
- Format VRM names to match the BIOS
- Fix swapped VRM_E and VRM_W entries
Signed-off-by: 小太 <nospam@kota.moe>
Signed-off-by: Eugene Shalygin <eugene.shalygin@gmail.com>
Link: https://lore.kernel.org/r/20251125040140.277756-1-eugene.shalygin@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
This reverts commit f43fdeb9a3, reversing
changes made to 2c6d792d4b.
There are concerns that doing inline submits can cause excessive
stack usage, particularly when going back into the filesystem. Revert
the loop dio nowait change for now.
Link: https://lore.kernel.org/linux-block/aSP3SG_KaROJTBHx@infradead.org/
Signed-off-by: Jens Axboe <axboe@kernel.dk>
When the msk socket is owned or the msk receive buffer is full,
move the incoming skbs in a msk level backlog list. This avoid
traversing the joined subflows and acquiring the subflow level
socket lock at reception time, improving the RX performances.
When processing the backlog, use the fwd alloc memory borrowed from
the incoming subflow. skbs exceeding the msk receive space are
not dropped; instead they are kept into the backlog until the receive
buffer is freed. Dropping packets already acked at the TCP level is
explicitly discouraged by the RFC and would corrupt the data stream
for fallback sockets.
Special care is needed to avoid adding skbs to the backlog of a closed
msk and to avoid leaving dangling references into the backlog
at subflow closing time.
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20251121-net-next-mptcp-memcg-backlog-imp-v1-14-1f34b6c1e0b1@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
We are soon using it for incoming data processing.
MPTCP can't leverage the sk_backlog, as the latter is processed
before the release callback, and such callback for MPTCP releases
and re-acquire the socket spinlock, breaking the sk_backlog processing
assumption.
Add a skb backlog list inside the mptcp sock struct, and implement
basic helper to transfer packet to and purge such list.
Packets in the backlog are memory accounted and still use the incoming
subflow receive memory, to allow back-pressure. The backlog size is
implicitly bounded to the sum of subflows rcvbuf.
When a subflow is closed, references from the backlog to such sock
are removed.
No packet is currently added to the backlog, so no functional changes
intended here.
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20251121-net-next-mptcp-memcg-backlog-imp-v1-13-1f34b6c1e0b1@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
In the MPTCP receive path, we release the subflow allocated fwd
memory just to allocate it again shortly after for the msk.
That could increases the failures chances, especially when we will
add backlog processing, with other actions could consume the just
released memory before the msk socket has a chance to do the
rcv allocation.
Replace the skb_orphan() call with an open-coded variant that
explicitly borrows, the fwd memory from the subflow socket instead
of releasing it.
The borrowed memory does not have PAGE_SIZE granularity; rounding to
the page size will make the fwd allocated memory higher than what is
strictly required and could make the incoming subflow fwd mem
consistently negative. Instead, keep track of the accumulated frag and
borrow the full page at subflow close time.
This allow removing the last drop in the TCP to MPTCP transition and
the associated, now unused, MIB.
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20251121-net-next-mptcp-memcg-backlog-imp-v1-12-1f34b6c1e0b1@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Currently, as soon as the PM closes a subflow, the msk stops accepting
data from it, even if the TCP socket could be still formally open in the
incoming direction, with the notable exception of the first subflow.
The root cause of such behavior is that code currently piggy back two
separate semantic on the subflow->disposable bit: the subflow context
must be released and that the subflow must stop accepting incoming
data.
The first subflow is never disposed, so it also never stop accepting
incoming data. Use a separate bit to mark the latter status and set such
bit in __mptcp_close_ssk() for all subflows.
Beyond making per subflow behaviour more consistent this will also
simplify the next patch.
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20251121-net-next-mptcp-memcg-backlog-imp-v1-11-1f34b6c1e0b1@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
It adds little clarity and there is a single user of such helper,
just inline it in the caller.
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Geliang Tang <geliang@kernel.org>
Tested-by: Geliang Tang <geliang@kernel.org>
Reviewed-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20251121-net-next-mptcp-memcg-backlog-imp-v1-10-1f34b6c1e0b1@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Such function is only used inside protocol.c, there is no need
to expose it to the whole stack.
Note that the function definition most be moved earlier to avoid
forward declaration.
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Geliang Tang <geliang@kernel.org>
Tested-by: Geliang Tang <geliang@kernel.org>
Reviewed-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20251121-net-next-mptcp-memcg-backlog-imp-v1-9-1f34b6c1e0b1@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The MPTCP protocol is not currently emitting the NL event when the first
subflow is closed before msk accept() time.
By replacing the in use close helper is such scenario, implicitly introduce
the missing notification. Note that in such scenario we want to be sure
that mptcp_close_ssk() will not trigger any PM work, move the msk state
change update earlier, so that the previous patch will offer such
guarantee.
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Geliang Tang <geliang@kernel.org>
Tested-by: Geliang Tang <geliang@kernel.org>
Reviewed-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20251121-net-next-mptcp-memcg-backlog-imp-v1-8-1f34b6c1e0b1@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The PM hooks can currently take place when the msk is already shutting
down. Subflow creation will fail, thanks to the existing check at join
time, but we can entirely avoid starting the to be failed operations.
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Geliang Tang <geliang@kernel.org>
Tested-by: Geliang Tang <geliang@kernel.org>
Reviewed-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20251121-net-next-mptcp-memcg-backlog-imp-v1-7-1f34b6c1e0b1@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
MPTCP currently access ack_seq outside the msk socket log scope to
generate the dummy mapping for fallback socket. Soon we are going
to introduce backlog usage and even for fallback socket the ack_seq
value will be significantly off outside of the msk socket lock scope.
Avoid relying on ack_seq for dummy mapping generation, using instead
the subflow sequence number. Note that in case of disconnect() and
(re)connect() we must ensure that any previous state is re-set.
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Geliang Tang <geliang@kernel.org>
Tested-by: Geliang Tang <geliang@kernel.org>
Reviewed-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20251121-net-next-mptcp-memcg-backlog-imp-v1-6-1f34b6c1e0b1@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
MPTCP currently generate a dummy data_fin for fallback socket
when the fallback subflow has completed data reception using
the current ack_seq.
We are going to introduce backlog usage for the msk soon, even
for fallback sockets: the ack_seq value will not match the most recent
sequence number seen by the fallback subflow socket, as it will ignore
data_seq sitting in the backlog.
Instead use the last map sequence number to set the data_fin,
as fallback (dummy) map sequences are always in sequence.
Reviewed-by: Geliang Tang <geliang@kernel.org>
Tested-by: Geliang Tang <geliang@kernel.org>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20251121-net-next-mptcp-memcg-backlog-imp-v1-5-1f34b6c1e0b1@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
