-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEn51F/lCuNhUwmDeSxycdCkmxi6cFAmTfSHAACgkQxycdCkmx
i6eK6g/+KQbOmERuZo9mpv02eM8f8zZsKZqwsQ9NkLGLbMXnVCzUuaFe6PtviSRY
GyIsMIiO1gQJ8N/67BskmJHJjrszK/hieoTT0gvyibK4sFfe0Bw6S2naOS2z8nTk
oTUykT9L2FPIAHlK8noVXDJWMiaoofSXkAaHKHYodESJqy7ZjA4h3CDLF4asO3Ze
cd5Mfyxc9Q3vlJRpsuPfOuYDCVXFxMJz83vyp2y4eKJ7z+IjD/Zxk+FS1aMS68c/
0/p8Qcda4kf6DEfM9cwZIWlY21JnsFBE0BzVfA/Sbol+MccO++xQr57/LblTXCQt
xOxq7tfEC6WdJLPAm8XKn6hXX+48DhIWSKsu0I6bfVzHSw3b/Wfe1IidgYD5zMbq
ecLrLx7AqJAc7UrMKHXoQz+8OZZZ8qb5VE3zamEWtNAGiJFmjhGfLvw+j/FQ49/W
lDuYzvH9fTkm8ebGKF0z7KA5fBOSzei9IdOIuFNjPORVACcmhNi0FfQfhjeqOimy
y+gYa60M/5APIywDiJkFdLw+2puolf/VvNyxrGehMdfZUi1HCPyxjjab9OgzczU8
hz5xj5q3/BUCma9CVBCJ/6rY3KHOdJTItm4q5IuAC4nUGTFA/IbZtR40ULWz+Qoz
yPPEmnyZEd6tWsRm+Gh1Qzgb/mPJ8mdmcB+4QnwmAJkkukp7MLI=
=1DNA
-----END PGP SIGNATURE-----
Merge tag 'v6.5-p3' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6
Pull crypto fixes from Herbert Xu:
"Fix a regression in the caam driver and af_alg"
* tag 'v6.5-p3' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
crypto: fix uninit-value in af_alg_free_resources
Revert "crypto: caam - adjust RNG timing to support more devices"
This might_sleep() goes back a long time: it was originally introduced
way back when by commit 010060741a ("x86: add might_sleep() to
do_page_fault()"), and made it into the generic VM code when the x86
fault path got re-organized and generalized in commit c2508ec5a5 ("mm:
introduce new 'lock_mm_and_find_vma()' page fault helper").
However, it turns out that the placement of that might_sleep() has
always been rather questionable simply because it's not only a debug
statement to warn about sleeping in contexts that shouldn't sleep (which
was the original reason for adding it), but it also implies a voluntary
scheduling point.
That, in turn, is less than desirable for two reasons:
(a) it ends up being done after we successfully got the mmap_lock, so
just as we got the lock we will now eagerly schedule away and
increase lock contention
and
(b) this is all very possibly part of the "oops, things went horribly
wrong" path and we just haven't figured that out yet
After all, the whole _reason_ for having that get_mmap_lock_carefully()
rather than just doing the obvious mmap_read_lock() is because this code
wants to deal somewhat gracefully with potential kernel wild pointer
bugs.
So then a voluntary scheduling point here is simply not a good idea.
We could certainly turn the 'might_sleep()' into a '__might_sleep()' and
make it be just the debug check that it was originally intended to be.
But even that seems questionable in the wild kernel pointer case - which
again is part of the whole point of this code. The problem wouldn't be
about the _sleeping_ part of the page fault, but about a bad kernel
access. The fact that that bad kernel access might happen in a section
that you shouldn't sleep in is secondary.
So it really ends up being the case that this is simply entirely the
wrong place to do this debug check and related scheduling point at all.
So let's just remove the check entirely. It's been around for over a
decade, it has served its purpose.
The re-schedule will happen at return to user space anyway for the
normal case, and the warning - if we even need it - might be better off
done as a special case for "page fault from kernel mode" once we've
dealt with any potential kernel oopses where the oops is the relevant
thing, not some artificial "scheduling while atomic" test.
Reported-by: Mateusz Guzik <mjguzik@gmail.com>
Link: https://lore.kernel.org/lkml/20230820104303.2083444-1-mjguzik@gmail.com/
Cc: Matthew Wilcox <willy@infradead.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
There isn't any reason to not support REQ_OP_ZONE_RESET_ALL given everything
is actually handled in userspace, not mention it is pretty easy to support
RESET_ALL.
So enable REQ_OP_ZONE_RESET_ALL and let userspace handle it.
Verified by 'tools/zbc_reset_zone -all /dev/ublkb0' in libzbc[1] with
libublk-rs based ublk-zoned target prototype[2], follows command line
for creating ublk-zoned:
cargo run --example zoned -- add -1 1024 # add $dev_id $DEV_SIZE
[1] https://github.com/westerndigitalcorporation/libzbc
[2] https://github.com/ming1/libublk-rs/tree/zoned.v2
Cc: Niklas Cassel <Niklas.Cassel@wdc.com>
Cc: Damien Le Moal <dlemoal@kernel.org>
Cc: Andreas Hindborg <a.hindborg@samsung.com>
Signed-off-by: Ming Lei <ming.lei@redhat.com>
Link: https://lore.kernel.org/r/20230810124326.321472-1-ming.lei@redhat.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Fix one occurrences of the checkpatch.pl error:
ERROR: "foo __init bar" should be "foo __init bar"
Signed-off-by: Xingwei He <hexingwei001@208suo.com>
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
The PCI core supplies a weak pcibios_setup() implementation that is
identical to the m68k implementation. Remove the m68k version since it is
unnecessary.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
The behavior of 'rustup override' is not very well known. Add a small
note about what it does, so users have a better understanding of how it
affects their system toolchain (i.e., it does not affect system
toolchain and only sets a directory-specific override).
Signed-off-by: Trevor Gross <tmgross@umich.edu>
Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Link: https://lore.kernel.org/r/20230803060437.12157-3-tmgross@umich.edu
[ Undid the `:` to `::` change. ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Add scripts for generating initramfs to KBUILD, to prevent idling of
patches for usr/.
Signed-off-by: Nicolas Schier <n.schier@avm.de>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
The source for Rust's 'core' library is needed to build the kernel with
Rust support. This sometimes needs to be obtained by hand when using a
standalone version of 'rustc' not managed by 'rustup'. Currently, the
documentation suggests cloning the 'rust' repository to obtain these
sources, but this is quite slow (on the order of a multiple minutes).
Change this documentation to suggest using the source tarball instead.
The tarball includes only needed files (<5M) and is significantly faster
to download; this is more in line with what 'rustup' does.
Also simplify wording of the relevant section.
Link: https://github.com/Rust-for-Linux/linux/pull/1024
Signed-off-by: Trevor Gross <tmgross@umich.edu>
Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Link: https://lore.kernel.org/r/20230803060437.12157-2-tmgross@umich.edu
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Clang warns about exceeded stack frame size
fs/smb/client/smb2ops.c:2973:12: warning: stack frame size (1336)
exceeds limit (1024) in 'smb2_query_reparse_point'
[-Wframe-larger-than]
Fix this by allocating a structure that will hold most of the large
variables.
Signed-off-by: Paulo Alcantara (SUSE) <pc@manguebit.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
Clang warns about exceeded stack frame size
fs/smb/client/smb2ops.c:2521:1: warning: stack frame size (1336)
exceeds limit (1024) in 'smb2_query_info_compound'
[-Wframe-larger-than]
Fix this by allocating a structure that will hold most of the large
variables.
Signed-off-by: Paulo Alcantara (SUSE) <pc@manguebit.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
Clang warns about exceeded stack frame size
fs/smb/client/smb2ops.c:1080:1: warning: stack frame size (1432)
exceeds limit (1024) in 'smb2_set_ea' [-Wframe-larger-than]
Fix this by allocating a structure that will hold most of the large
variables.
Signed-off-by: Paulo Alcantara (SUSE) <pc@manguebit.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
Clang warns about exceeded stack frame size
fs/smb/client/transport.c:420:1: warning: stack frame size (1048)
exceeds limit (1024) in 'smb_send_rqst' [-Wframe-larger-than]
Fix this by allocating a structure that will hold transform header and
compound requests.
Signed-off-by: Paulo Alcantara (SUSE) <pc@manguebit.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
Clang warns about exceeded stack frame size
fs/smb/client/connect.c:1109:1: warning: stack frame size (1048)
exceeds limit (1024) in 'cifs_demultiplex_thread'
[-Wframe-larger-than]
It turns out that clean_demultiplex_info() got inlined into
cifs_demultiplex_thread(), so mark it as noinline_for_stack to save
some stack space.
Signed-off-by: Paulo Alcantara (SUSE) <pc@manguebit.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
Clang warns about exceeded stack frame size
fs/smb/client/sess.c:160:5: warning: stack frame size (1368) exceeds
limit (1024) in 'cifs_try_adding_channels' [-Wframe-larger-than]
It turns out that cifs_ses_add_channel() got inlined into
cifs_try_adding_channels() which had a stack-allocated variable @ctx
of 624 bytes in size. Fix this by making it heap-allocated.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202307270640.5ODmPwDl-lkp@intel.com/
Signed-off-by: Paulo Alcantara (SUSE) <pc@manguebit.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
Enable the client to query reparse points in SMB2+.
Signed-off-by: Paulo Alcantara (SUSE) <pc@manguebit.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
Save a roundtrip by getting the reparse point tag and buffer at once
in ->query_reparse_point() and then pass the buffer down to
->query_symlink().
Signed-off-by: Paulo Alcantara (SUSE) <pc@manguebit.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
Check for reparse point flag on query info calls as specified in
MS-SMB2 2.2.14.
Signed-off-by: Paulo Alcantara (SUSE) <pc@manguebit.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
Make namespace.c being built without requiring
CONFIG_CIFS_DFS_UPCALL=y by moving set_dest_addr() to dfs.c and call
it at the beginning of dfs_mount_share() so it can chase the DFS link
starting from the correct server in @ctx->dstaddr.
Signed-off-by: Paulo Alcantara (SUSE) <pc@manguebit.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
Automount code will handle both DFS links and reparse mount points.
Also, get rid of BUG_ON() in cifs_release_automount_timer() while
we're at it.
Signed-off-by: Paulo Alcantara (SUSE) <pc@manguebit.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
The automount code will handle both DFS links and reparse files that
are mount points.
Signed-off-by: Paulo Alcantara (SUSE) <pc@manguebit.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
If @out_iov and @out_buftype are passed, then return compounded
responses regardless whether the request failed or not. This will be
useful for detecting reparse points on SMB2_CREATE responses as
specified in MS-SMB2 2.2.14.
No functional changes.
Signed-off-by: Paulo Alcantara (SUSE) <pc@manguebit.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
Instead of passing @adjust_tz and some reparse point related fields as
parameters in ->query_path_info() and
{smb311_posix,cifs}_info_to_fattr() calls, move them to
cifs_open_info_data structure as they can be easily accessed through
@data.
No functional changes.
Signed-off-by: Paulo Alcantara (SUSE) <pc@manguebit.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
With current implementation, when a nested DFS link is found during
mount(2), the client follows the referral and then try to connect to
all of its targets. If all targets failed, the client bails out
rather than retrying remaining targets from previous referral.
Fix this by stacking all referrals and targets so the client can retry
remaining targets from previous referrals in case all targets of
current referral have failed.
Thanks to samba, this can be easily tested like below
* Run the following under dfs folder in samba server
$ ln -s "msdfs:srv\\bad-share" link1
$ ln -s "msdfs:srv\\dfs\\link1,srv\\good-share" link0
* Before patch
$ mount.cifs //srv/dfs/link0 /mnt -o ...
mount error(2): No such file or directory
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)...
* After patch
$ mount.cifs //srv/dfs/link0 /mnt -o ...
# ls /mnt
bar fileshare1 sub
Signed-off-by: Paulo Alcantara (SUSE) <pc@manguebit.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
Add new helper which declares and initialises target list of a DFS
referral rather having to do both separately.
No functional changes.
Signed-off-by: Paulo Alcantara (SUSE) <pc@manguebit.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
Both `core` and `alloc` have their `cfgs` (such as `no_rc`) missing
in `rust-project.json`.
To remedy this, pass the flags to `generate_rust_analyzer.py` for
them to be added to a dictionary where each key corresponds to
a crate and each value to a list of `cfg`s. The dictionary is then
used to pass the `cfg`s to each crate in the generated file (for
`core` and `alloc` only).
Signed-off-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com>
Link: https://lore.kernel.org/r/20230804171448.54976-1-yakoyoku@gmail.com
[ Removed `Suggested-by` as discussed in mailing list. ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
The usage of page table locks in TLB fault handler is usually
only needed when debugging the kernel. So make this configuration
option dependend on DEBUG_KERNEL.
Signed-off-by: Helge Deller <deller@gmx.de>
If an fsverity builtin signature is given for a file but the
".fs-verity" keyring is empty, there's no real reason to run the PKCS#7
parser. Skip this to avoid the PKCS#7 attack surface when builtin
signature support is configured into the kernel but is not being used.
This is a hardening improvement, not a fix per se, but I've added
Fixes and Cc stable to get it out to more users.
Fixes: 432434c9f8 ("fs-verity: support builtin file signatures")
Cc: stable@vger.kernel.org
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Link: https://lore.kernel.org/r/20230820173237.2579-1-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
1. XGMAC Core does not have hash_filter definition, it uses
vlhash(VLAN Hash Filtering) instead, skip hash_filter when XGMAC.
2. Show exact size of Hash Table instead of raw register value.
3. Show full description of safety features defined by Synopsys Databook.
4. When safety feature is configured with no parity, or ECC only,
keep FSM Parity Checking disabled.
Signed-off-by: Furong Xu <0x1207@gmail.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Hangbin Liu says:
====================
ipv6: update route when delete source address
Currently, when remove an address, the IPv6 route will not remove the
prefer source address when the address is bond to other device. Fix this
issue and add related tests as Ido and David suggested.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Add a test case for IPv6 source address delete.
As David suggested, add tests:
- Single device using src address
- Two devices with the same source address
- VRF with single device using src address
- VRF with two devices using src address
As Ido points out, in IPv6, the preferred source address is looked up in
the same VRF as the first nexthop device. This will give us similar results
to IPv4 if the route is installed in the same VRF as the nexthop device, but
not when the nexthop device is enslaved to a different VRF. So add tests:
- src address and nexthop dev in same VR
- src address and nexthop device in different VRF
The link local address delete logic is different from the global address.
It should only affect the associate device it bonds to. So add tests cases
for link local address testing.
Here is the test result:
IPv6 delete address route tests
Single device using src address
TEST: Prefsrc removed when src address removed on other device [ OK ]
Two devices with the same source address
TEST: Prefsrc not removed when src address exist on other device [ OK ]
TEST: Prefsrc removed when src address removed on all devices [ OK ]
VRF with single device using src address
TEST: Prefsrc removed when src address removed on other device [ OK ]
VRF with two devices using src address
TEST: Prefsrc not removed when src address exist on other device [ OK ]
TEST: Prefsrc removed when src address removed on all devices [ OK ]
src address and nexthop dev in same VRF
TEST: Prefsrc removed from VRF when source address deleted [ OK ]
TEST: Prefsrc in default VRF not removed [ OK ]
TEST: Prefsrc not removed from VRF when source address exist [ OK ]
TEST: Prefsrc in default VRF removed [ OK ]
src address and nexthop device in different VRF
TEST: Prefsrc not removed from VRF when nexthop dev in diff VRF [ OK ]
TEST: Prefsrc not removed in default VRF [ OK ]
TEST: Prefsrc removed from VRF when nexthop dev in diff VRF [ OK ]
TEST: Prefsrc removed in default VRF [ OK ]
Table ID 0
TEST: Prefsrc removed from default VRF when source address deleted [ OK ]
Link local source route
TEST: Prefsrc not removed when delete ll addr from other dev [ OK ]
TEST: Prefsrc removed when delete ll addr [ OK ]
TEST: Prefsrc not removed when delete ll addr from other dev [ OK ]
TEST: Prefsrc removed even ll addr still exist on other dev [ OK ]
Tests passed: 19
Tests failed: 0
Suggested-by: Ido Schimmel <idosch@idosch.org>
Suggested-by: David Ahern <dsahern@kernel.org>
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
After deleting an IPv6 address on an interface and cleaning up the
related preferred source entries, it is important to ensure that all
routes associated with the deleted address are properly cleared. The
current implementation of rt6_remove_prefsrc() only checks the preferred
source addresses bound to the current device. However, there may be
routes that are bound to other devices but still utilize the same
preferred source address.
To address this issue, it is necessary to also delete entries that are
bound to other interfaces but share the same source address with the
current device. Failure to delete these entries would leave routes that
are bound to the deleted address unclear. Here is an example reproducer
(I have omitted unrelated routes):
+ ip link add dummy1 type dummy
+ ip link add dummy2 type dummy
+ ip link set dummy1 up
+ ip link set dummy2 up
+ ip addr add 1:2:3:4::5/64 dev dummy1
+ ip route add 7:7:7:0::1 dev dummy1 src 1:2:3:4::5
+ ip route add 7:7:7:0::2 dev dummy2 src 1:2:3:4::5
+ ip -6 route show
1:2:3:4::/64 dev dummy1 proto kernel metric 256 pref medium
7:7:7::1 dev dummy1 src 1:2:3:4::5 metric 1024 pref medium
7:7:7::2 dev dummy2 src 1:2:3:4::5 metric 1024 pref medium
+ ip addr del 1:2:3:4::5/64 dev dummy1
+ ip -6 route show
7:7:7::1 dev dummy1 metric 1024 pref medium
7:7:7::2 dev dummy2 src 1:2:3:4::5 metric 1024 pref medium
As Ido reminds, in IPv6, the preferred source address is looked up in
the same VRF as the first nexthop device, which is different with IPv4.
So, while removing the device checking, we also need to add an
ipv6_chk_addr() check to make sure the address does not exist on the other
devices of the rt nexthop device's VRF.
After fix:
+ ip addr del 1:2:3:4::5/64 dev dummy1
+ ip -6 route show
7:7:7::1 dev dummy1 metric 1024 pref medium
7:7:7::2 dev dummy2 metric 1024 pref medium
Reported-by: Thomas Haller <thaller@redhat.com>
Closes: https://bugzilla.redhat.com/show_bug.cgi?id=2170513
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
As the initial commit 1a01727676 ("selftests: Add VRF route leaking
tests") said, the IPv6 MTU test fails as source address selection
picking ::1. Every time we run the selftest this one report failed.
There seems not much meaning to keep reporting a failure for 3 years
that no one plan to fix/update. Let't just skip this one first. We can
add it back when the issue fixed.
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
addrconf_prefix_rcv returned early without releasing the inet6_dev
pointer when the PIO lifetime is less than accept_ra_min_lft.
Fixes: 5027d54a9c ("net: change accept_ra_min_rtr_lft to affect all RA lifetimes")
Cc: Maciej Żenczykowski <maze@google.com>
Cc: Lorenzo Colitti <lorenzo@google.com>
Cc: David Ahern <dsahern@kernel.org>
Cc: Simon Horman <horms@kernel.org>
Reviewed-by: Simon Horman <horms@kernel.org>
Reviewed-by: Maciej Żenczykowski <maze@google.com>
Signed-off-by: Patrick Rohr <prohr@google.com>
Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Setting IP_RECVERR and IPV6_RECVERR options to zero currently
purges the socket error queue, which was probably not expected
for zerocopy and tx_timestamp users.
I discovered this issue while preparing commit 6b5f43ea08
("inet: move inet->recverr to inet->inet_flags"), I presume this
change does not need to be backported to stable kernels.
Add skb_errqueue_purge() helper to purge error messages only.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Willem de Bruijn <willemb@google.com>
Cc: Soheil Hassas Yeganeh <soheil@google.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Update .gitignore to untrack tools directory and log.txt. "tools" is
generated in "selftests/net/Makefile" and log.txt is generated in
"selftests/net/gro.sh" when executing run_all_tests.
Signed-off-by: Anh Tuan Phan <tuananhlfc@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Ruan Jinjie says:
====================
net: Return PTR_ERR() for fixed_phy_register()
fixed_phy_register() returns not only -EIO or -ENODEV, but also
-EPROBE_DEFER, -EINVAL and -EBUSY. The Best practice is to return these
error codes with PTR_ERR().
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
fixed_phy_register() returns -EPROBE_DEFER, -EINVAL and -EBUSY,
etc, in addition to -EIO. The Best practice is to return these
error codes with PTR_ERR().
Signed-off-by: Ruan Jinjie <ruanjinjie@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
fixed_phy_register() returns -EPROBE_DEFER, -EINVAL and -EBUSY,
etc, in addition to -ENODEV. The Best practice is to return these
error codes with PTR_ERR().
Signed-off-by: Ruan Jinjie <ruanjinjie@huawei.com>
Acked-by: Doug Berger <opendmb@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
fixed_phy_register() returns -EPROBE_DEFER, -EINVAL and -EBUSY,
etc, in addition to -ENODEV. The best practice is to return
these error codes with PTR_ERR().
Signed-off-by: Ruan Jinjie <ruanjinjie@huawei.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
UDP sendmsg() is lockless, so ip_select_ident_segs()
can very well be run from multiple cpus [1]
Convert inet->inet_id to an atomic_t, but implement
a dedicated path for TCP, avoiding cost of a locked
instruction (atomic_add_return())
Note that this patch will cause a trivial merge conflict
because we added inet->flags in net-next tree.
v2: added missing change in
drivers/net/ethernet/chelsio/inline_crypto/chtls/chtls_cm.c
(David Ahern)
[1]
BUG: KCSAN: data-race in __ip_make_skb / __ip_make_skb
read-write to 0xffff888145af952a of 2 bytes by task 7803 on cpu 1:
ip_select_ident_segs include/net/ip.h:542 [inline]
ip_select_ident include/net/ip.h:556 [inline]
__ip_make_skb+0x844/0xc70 net/ipv4/ip_output.c:1446
ip_make_skb+0x233/0x2c0 net/ipv4/ip_output.c:1560
udp_sendmsg+0x1199/0x1250 net/ipv4/udp.c:1260
inet_sendmsg+0x63/0x80 net/ipv4/af_inet.c:830
sock_sendmsg_nosec net/socket.c:725 [inline]
sock_sendmsg net/socket.c:748 [inline]
____sys_sendmsg+0x37c/0x4d0 net/socket.c:2494
___sys_sendmsg net/socket.c:2548 [inline]
__sys_sendmmsg+0x269/0x500 net/socket.c:2634
__do_sys_sendmmsg net/socket.c:2663 [inline]
__se_sys_sendmmsg net/socket.c:2660 [inline]
__x64_sys_sendmmsg+0x57/0x60 net/socket.c:2660
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
read to 0xffff888145af952a of 2 bytes by task 7804 on cpu 0:
ip_select_ident_segs include/net/ip.h:541 [inline]
ip_select_ident include/net/ip.h:556 [inline]
__ip_make_skb+0x817/0xc70 net/ipv4/ip_output.c:1446
ip_make_skb+0x233/0x2c0 net/ipv4/ip_output.c:1560
udp_sendmsg+0x1199/0x1250 net/ipv4/udp.c:1260
inet_sendmsg+0x63/0x80 net/ipv4/af_inet.c:830
sock_sendmsg_nosec net/socket.c:725 [inline]
sock_sendmsg net/socket.c:748 [inline]
____sys_sendmsg+0x37c/0x4d0 net/socket.c:2494
___sys_sendmsg net/socket.c:2548 [inline]
__sys_sendmmsg+0x269/0x500 net/socket.c:2634
__do_sys_sendmmsg net/socket.c:2663 [inline]
__se_sys_sendmmsg net/socket.c:2660 [inline]
__x64_sys_sendmmsg+0x57/0x60 net/socket.c:2660
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
value changed: 0x184d -> 0x184e
Reported by Kernel Concurrency Sanitizer on:
CPU: 0 PID: 7804 Comm: syz-executor.1 Not tainted 6.5.0-rc6-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/26/2023
==================================================================
Fixes: 23f57406b8 ("ipv4: avoid using shared IP generator for connected sockets")
Reported-by: syzbot <syzkaller@googlegroups.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
veth and vxcan need to make sure the ifindexes of the peer
are not negative, core does not validate this.
Using iproute2 with user-space-level checking removed:
Before:
# ./ip link add index 10 type veth peer index -1
# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
link/ether 52:54:00:74:b2:03 brd ff:ff:ff:ff:ff:ff
10: veth1@veth0: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 8a:90:ff:57:6d:5d brd ff:ff:ff:ff:ff:ff
-1: veth0@veth1: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether ae:ed:18:e6:fa:7f brd ff:ff:ff:ff:ff:ff
Now:
$ ./ip link add index 10 type veth peer index -1
Error: ifindex can't be negative.
This problem surfaced in net-next because an explicit WARN()
was added, the root cause is older.
Fixes: e6f8f1a739 ("veth: Allow to create peer link with given ifindex")
Fixes: a8f820a380 ("can: add Virtual CAN Tunnel driver (vxcan)")
Reported-by: syzbot+5ba06978f34abb058571@syzkaller.appspotmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
