aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-07-24ipv6 addrconf: fix bug where deleting a mngtmpaddr can create a new ↵Maciej Żenczykowski1-4/+10
temporary address currently on 6.4 net/main: # ip link add dummy1 type dummy # echo 1 > /proc/sys/net/ipv6/conf/dummy1/use_tempaddr # ip link set dummy1 up # ip -6 addr add 2000::1/64 mngtmpaddr dev dummy1 # ip -6 addr show dev dummy1 11: dummy1: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000 inet6 2000::44f3:581c:8ca:3983/64 scope global temporary dynamic valid_lft 604800sec preferred_lft 86172sec inet6 2000::1/64 scope global mngtmpaddr valid_lft forever preferred_lft forever inet6 fe80::e8a8:a6ff:fed5:56d4/64 scope link valid_lft forever preferred_lft forever # ip -6 addr del 2000::44f3:581c:8ca:3983/64 dev dummy1 (can wait a few seconds if you want to, the above delete isn't [directly] the problem) # ip -6 addr show dev dummy1 11: dummy1: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000 inet6 2000::1/64 scope global mngtmpaddr valid_lft forever preferred_lft forever inet6 fe80::e8a8:a6ff:fed5:56d4/64 scope link valid_lft forever preferred_lft forever # ip -6 addr del 2000::1/64 mngtmpaddr dev dummy1 # ip -6 addr show dev dummy1 11: dummy1: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000 inet6 2000::81c9:56b7:f51a:b98f/64 scope global temporary dynamic valid_lft 604797sec preferred_lft 86169sec inet6 fe80::e8a8:a6ff:fed5:56d4/64 scope link valid_lft forever preferred_lft forever This patch prevents this new 'global temporary dynamic' address from being created by the deletion of the related (same subnet prefix) 'mngtmpaddr' (which is triggered by there already being no temporary addresses). Cc: Jiri Pirko <[email protected]> Fixes: 53bd67491537 ("ipv6 addrconf: introduce IFA_F_MANAGETEMPADDR to tell kernel to manage temporary addresses") Reported-by: Xiao Ma <[email protected]> Signed-off-by: Maciej Żenczykowski <[email protected]> Reviewed-by: David Ahern <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-07-24ethernet: atheros: fix return value check in atl1e_tso_csum()Yuanjun Gong1-2/+5
in atl1e_tso_csum, it should check the return value of pskb_trim(), and return an error code if an unexpected value is returned by pskb_trim(). Fixes: a6a5325239c2 ("atl1e: Atheros L1E Gigabit Ethernet driver") Signed-off-by: Yuanjun Gong <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-07-24atheros: fix return value check in atl1_tso()Yuanjun Gong1-2/+5
in atl1_tso(), it should check the return value of pskb_trim(), and return an error code if an unexpected value is returned by pskb_trim(). Fixes: 401c0aabec4b ("atl1: simplify tx packet descriptor") Signed-off-by: Yuanjun Gong <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-07-24Merge tag 'scsi-fixes' of ↵Linus Torvalds1-3/+4
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi Pull SCSI fix from James Bottomley: "A single fix for a potential regression over a misunderstanding of the blk_get_queue() api" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: sg: Fix checking return value of blk_get_queue()
2023-07-24ASoC: wm8904: Fill the cache for WM8904_ADC_TEST_0 registerMark Brown1-0/+3
The WM8904_ADC_TEST_0 register is modified as part of updating the OSR controls but does not have a cache default, leading to errors when we try to modify these controls in cache only mode with no prior read: wm8904 3-001a: ASoC: error at snd_soc_component_update_bits on wm8904.3-001a for register: [0x000000c6] -16 Add a read of the register to probe() to fill the cache and avoid both the error messages and the misconfiguration of the chip which will result. Acked-by: Charles Keepax <[email protected]> Signed-off-by: Mark Brown <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/20230723-asoc-fix-wm8904-adc-test-read-v1-1-2cdf2edd83fd@kernel.org Signed-off-by: Mark Brown <[email protected]>
2023-07-24ASoC: da7219: Patches related to a spurious AAD IRQMark Brown1-3/+9
Merge series from Dmytro Maluka <[email protected]>: This series includes 2 patches related to (but not fixing) the following I2C failure which occurs sometimes during system suspend or resume and indicates a problem with a spurious DA7219 interrupt: [ 355.876211] i2c_designware i2c_designware.3: Transfer while suspended [ 355.876245] WARNING: CPU: 2 PID: 3576 at drivers/i2c/busses/i2c-designware-master.c:570 i2c_dw_xfer+0x411/0x440 ... [ 355.876462] Call Trace: [ 355.876468] <TASK> [ 355.876475] ? update_load_avg+0x1b3/0x615 [ 355.876484] __i2c_transfer+0x101/0x1d8 [ 355.876494] i2c_transfer+0x74/0x10d [ 355.876504] regmap_i2c_read+0x6a/0x9c [ 355.876513] _regmap_raw_read+0x179/0x223 [ 355.876521] regmap_raw_read+0x1e1/0x28e [ 355.876527] regmap_bulk_read+0x17d/0x1ba [ 355.876532] ? __wake_up+0xed/0x1bb [ 355.876542] da7219_aad_irq_thread+0x54/0x2c9 [snd_soc_da7219 5fb8ebb2179cf2fea29af090f3145d68ed8e2184] [ 355.876556] irq_thread+0x13c/0x231 [ 355.876563] ? irq_forced_thread_fn+0x5f/0x5f [ 355.876570] ? irq_thread_fn+0x4d/0x4d [ 355.876576] kthread+0x13a/0x152 [ 355.876581] ? synchronize_irq+0xc3/0xc3 [ 355.876587] ? kthread_blkcg+0x31/0x31 [ 355.876592] ret_from_fork+0x1f/0x30 [ 355.876601] </TASK> This log shows that DA7219 AAD interrupt handler da7219_aad_irq_thread() is unexpectedly running when DA7219 is suspended and should not generate interrupts. As a result, the IRQ handler is trying to read AAD IRQ event status over I2C and is hitting the I2C driver "Transfer while suspended" failure. Patch #1 adds synchronize_irq() when suspending DA7219, to prevent the IRQ handler from running after suspending if there is a pending IRQ generated before suspending. With this patch the above failure is still reproducible, so this patch does not fix any real observed issue so far, but at least is useful for confirming that the above issue is not caused by a pending IRQ but rather looks like a DA7219 hardware issue with an unexpectedly generated IRQ. Patch #2 does not fix the above issue either, but it prevents its potentially harmful side effects. With the existing code, if the issue occurs and the IRQ handler fails to read the AAD IRQ events status over I2C, it does not check that and tries to use the garbage uninitialized value of the events status, potentially reporting bogus events. This patch fixes that by adding missing error checking. In fact I'm sending these patches not only to submit them for review but also to ask Renesas folks for any hints on a possible cause of the described DA7219 issue (AAD interrupts spuriously firing after jack detection is already disabled) or how to debug it further.
2023-07-24s390/dasd: print copy pair message only for the correct errorStefan Haberland1-1/+1
The DASD driver has certain types of requests that might be rejected by the storage server or z/VM because they are not supported. Since the missing support of the command is not a real issue there is no user visible kernel error message for this. For copy pair setups there is a specific error that IO is not allowed on secondary devices. This error case is explicitly handled and an error message is printed. The code checking for the error did use a bitwise 'and' that is used to check for specific bits. But in this case the whole sense byte has to match. This leads to the problem that the copy pair related error message is erroneously printed for other error cases that are usually not reported. This might heavily confuse users and lead to follow on actions that might disrupt application processing. Fix by checking the sense byte for the exact value and not single bits. Cc: [email protected] # 6.1+ Fixes: 1fca631a1185 ("s390/dasd: suppress generic error messages for PPRC secondary devices") Signed-off-by: Stefan Haberland <[email protected]> Reviewed-by: Jan Hoeppner <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]>
2023-07-24s390/dasd: fix hanging device after request requeueStefan Haberland1-77/+48
The DASD device driver has a function to requeue requests to the blocklayer. This function is used in various cases when basic settings for the device have to be changed like High Performance Ficon related parameters or copy pair settings. The functions iterates over the device->ccw_queue and also removes the requests from the block->ccw_queue. In case the device is started on an alias device instead of the base device it might be removed from the block->ccw_queue without having it canceled properly before. This might lead to a hanging device since the request is no longer on a queue and can not be handled properly. Fix by iterating over the block->ccw_queue instead of the device->ccw_queue. This will take care of all blocklayer related requests and handle them on all associated DASD devices. Signed-off-by: Stefan Haberland <[email protected]> Reviewed-by: Jan Hoeppner <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]>
2023-07-24s390/dasd: use correct number of retries for ERP requestsStefan Haberland1-1/+1
If a DASD request fails an error recovery procedure (ERP) request might be built as a copy of the original request to do error recovery. The ERP request gets a number of retries assigned. This number is always 256 no matter what other value might have been set for the original request. This is not what is expected when a user specifies a certain amount of retries for the device via sysfs. Correctly use the number of retries of the original request for ERP requests. Signed-off-by: Stefan Haberland <[email protected]> Reviewed-by: Jan Hoeppner <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]>
2023-07-24s390/dasd: fix hanging device after quiesce/resumeStefan Haberland1-0/+1
Quiesce and resume are functions that tell the DASD driver to stop/resume issuing I/Os to a specific DASD. On resume dasd_schedule_block_bh() is called to kick handling of IO requests again. This does unfortunately not cover internal requests which are used for path verification for example. This could lead to a hanging device when a path event or anything else that triggers internal requests occurs on a quiesced device. Fix by also calling dasd_schedule_device_bh() which triggers handling of internal requests on resume. Fixes: 8e09f21574ea ("[S390] dasd: add hyper PAV support to DASD device driver, part 1") Cc: [email protected] Signed-off-by: Stefan Haberland <[email protected]> Reviewed-by: Jan Hoeppner <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]>
2023-07-24io_uring: gate iowait schedule on having pending requestsJens Axboe1-6/+17
A previous commit made all cqring waits marked as iowait, as a way to improve performance for short schedules with pending IO. However, for use cases that have a special reaper thread that does nothing but wait on events on the ring, this causes a cosmetic issue where we know have one core marked as being "busy" with 100% iowait. While this isn't a grave issue, it is confusing to users. Rather than always mark us as being in iowait, gate setting of current->in_iowait to 1 by whether or not the waiting task has pending requests. Cc: [email protected] Link: https://lore.kernel.org/io-uring/CAMEGJJ2RxopfNQ7GNLhr7X9=bHXKo+G5OOe0LUq=+UgLXsv1Xg@mail.gmail.com/ Link: https://bugzilla.kernel.org/show_bug.cgi?id=217699 Link: https://bugzilla.kernel.org/show_bug.cgi?id=217700 Reported-by: Oleksandr Natalenko <[email protected]> Reported-by: Phil Elwell <[email protected]> Tested-by: Andres Freund <[email protected]> Fixes: 8a796565cec3 ("io_uring: Use io_schedule* in cqring wait") Signed-off-by: Jens Axboe <[email protected]>
2023-07-24file: always lock position for FMODE_ATOMIC_POSChristian Brauner1-4/+2
The pidfd_getfd() system call allows a caller with ptrace_may_access() abilities on another process to steal a file descriptor from this process. This system call is used by debuggers, container runtimes, system call supervisors, networking proxies etc. So while it is a special interest system call it is used in common tools. That ability ends up breaking our long-time optimization in fdget_pos(), which "knew" that if we had exclusive access to the file descriptor nobody else could access it, and we didn't need the lock for the file position. That check for file_count(file) was always fairly subtle - it depended on __fdget() not incrementing the file count for single-threaded processes and thus included that as part of the rule - but it did mean that we didn't need to take the lock in all those traditional unix process contexts. So it's sad to see this go, and I'd love to have some way to re-instate the optimization. At the same time, the lock obviously isn't ever contended in the case we optimized, so all we were optimizing away is the atomics and the cacheline dirtying. Let's see if anybody even notices that the optimization is gone. Link: https://lore.kernel.org/linux-fsdevel/[email protected]/ Fixes: 8649c322f75c ("pid: Implement pidfd_getfd syscall") Cc: [email protected] Signed-off-by: Christian Brauner <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2023-07-24Merge tag 'media/v6.5-2' of ↵Linus Torvalds15-137/+116
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media Pull media fixes from Mauro Carvalho Chehab: - some warning fixes - verisilicon: an excessive usage of stack fix and changes at reg access - amphion: use dev_err_probe - pulse8-cec: handle possible ping error - imx-jpeg: Support to assign slot for encoder/decoder - amphion: Fix firmware path to match linux-firmware - pci: cx23885: fix error handling for cx23885 ATSC boards - staging: atomisp: select V4L2_FWNODE - mediatek: vcodec: fix cancel_work_sync fail with fluster test * tag 'media/v6.5-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: media: verisilicon: change confusingly named relaxed register access media: verisilicon: fix excessive stack usage media: mediatek: vcodec: fix cancel_work_sync fail with fluster test media: pci: cx23885: fix error handling for cx23885 ATSC boards media: pulse8-cec: handle possible ping error media: mtk_jpeg_core: avoid unused-variable warning media: imx-jpeg: Support to assign slot for encoder/decoder media: amphion: Fix firmware path to match linux-firmware media: amphion: use dev_err_probe media: staging: atomisp: select V4L2_FWNODE media: tc358746: Address compiler warnings
2023-07-24btrfs: check if the transaction was aborted at btrfs_wait_for_commit()Filipe Manana1-0/+1
At btrfs_wait_for_commit() we wait for a transaction to finish and then always return 0 (success) without checking if it was aborted, in which case the transaction didn't happen due to some critical error. Fix this by checking if the transaction was aborted. Fixes: 462045928bda ("Btrfs: add START_SYNC, WAIT_SYNC ioctls") CC: [email protected] # 4.19+ Reviewed-by: Qu Wenruo <[email protected]> Signed-off-by: Filipe Manana <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]>
2023-07-24btrfs: remove BUG_ON()'s in add_new_free_space()Filipe Manana3-26/+53
At add_new_free_space() we have these BUG_ON()'s that are there to deal with any failure to add free space to the in memory free space cache. Such failures are mostly -ENOMEM that should be very rare. However there's no need to have these BUG_ON()'s, we can just return any error to the caller and all callers and their upper call chain are already dealing with errors. So just make add_new_free_space() return any errors, while removing the BUG_ON()'s, and returning the total amount of added free space to an optional u64 pointer argument. Reported-by: [email protected] Link: https://lore.kernel.org/linux-btrfs/[email protected]/ Signed-off-by: Filipe Manana <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]>
2023-07-24Merge tag 'x86_bugs_zenbleed' of ↵Linus Torvalds5-72/+133
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull Zen 2 errata fix from Borislav Petkov: "Fix an issue on AMD Zen2 processors called Zenbleed. The bug manifests itself as a data corruption issue when executing VZEROUPPER under certain microarchitectural conditions" * tag 'x86_bugs_zenbleed' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/cpu/amd: Add a Zenbleed fix x86/cpu/amd: Move the errata checking functionality up
2023-07-24hwmon: (nct7802) Fix for temp6 (PECI1) processed even if PECI1 disabledGilles Buloz1-1/+1
Because of hex value 0x46 used instead of decimal 46, the temp6 (PECI1) temperature is always declared visible and then displayed even if disabled in the chip Signed-off-by: Gilles Buloz <[email protected]> Link: https://lore.kernel.org/r/DU0PR10MB62526435ADBC6A85243B90E08002A@DU0PR10MB6252.EURPRD10.PROD.OUTLOOK.COM Fixes: fcdc5739dce03 ("hwmon: (nct7802) add temperature sensor type attribute") Cc: [email protected] Signed-off-by: Guenter Roeck <[email protected]>
2023-07-24m68k: Fix invalid .section syntaxBen Hutchings3-6/+6
gas supports several different forms for .section for ELF targets, including: .section NAME [, "FLAGS"[, @TYPE[,FLAG_SPECIFIC_ARGUMENTS]]] and: .section "NAME"[, #FLAGS...] In several places we use a mix of these two forms: .section NAME, #FLAGS... A current development snapshot of binutils (2.40.50.20230611) treats this mixed syntax as an error. Change to consistently use: .section NAME, "FLAGS" as is used elsewhere in the kernel. Link: https://buildd.debian.org/status/fetch.php?pkg=linux&arch=m68k&ver=6.4%7Erc6-1%7Eexp1&stamp=1686907300&raw=1 Signed-off-by: Ben Hutchings <[email protected]> Tested-by: Jan-Benedict Glaw <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]>
2023-07-24ceph: never send metrics if disable_send_metrics is setXiubo Li1-1/+1
Even the 'disable_send_metrics' is true so when the session is being opened it will always trigger to send the metric for the first time. Cc: [email protected] Signed-off-by: Xiubo Li <[email protected]> Reviewed-by: Venky Shankar <[email protected]> Reviewed-by: Jeff Layton <[email protected]> Signed-off-by: Ilya Dryomov <[email protected]>
2023-07-24phy: hisilicon: Fix an out of bounds check in hisi_inno_phy_probe()Harshit Mogalapalli1-1/+1
The size of array 'priv->ports[]' is INNO_PHY_PORT_NUM. In the for loop, 'i' is used as the index for array 'priv->ports[]' with a check (i > INNO_PHY_PORT_NUM) which indicates that INNO_PHY_PORT_NUM is allowed value for 'i' in the same loop. This > comparison needs to be changed to >=, otherwise it potentially leads to an out of bounds write on the next iteration through the loop Fixes: ba8b0ee81fbb ("phy: add inno-usb2-phy driver for hi3798cv200 SoC") Reported-by: Dan Carpenter <[email protected]> Signed-off-by: Harshit Mogalapalli <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]>
2023-07-24Merge branch 'vxlan-gro-fixes'David S. Miller1-45/+97
Jiri Benc says: ==================== vxlan: fix GRO with VXLAN-GPE The first patch generalizes code for the second patch, which is a fix for broken VXLAN-GPE GRO. Thanks to Paolo for noticing the bug. ==================== Signed-off-by: David S. Miller <[email protected]>
2023-07-24vxlan: fix GRO with VXLAN-GPEJiri Benc1-15/+69
In VXLAN-GPE, there may not be an Ethernet header following the VXLAN header. But in GRO, the vxlan driver calls eth_gro_receive unconditionally, which means the following header is incorrectly parsed as Ethernet. Introduce GPE specific GRO handling. For better performance, do not check for GPE during GRO but rather install a different set of functions at setup time. Fixes: e1e5314de08ba ("vxlan: implement GPE") Reported-by: Paolo Abeni <[email protected]> Signed-off-by: Jiri Benc <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-07-24vxlan: generalize vxlan_parse_gpe_hdr and remove unused argsJiri Benc1-30/+28
The vxlan_parse_gpe_hdr function extracts the next protocol value from the GPE header and marks GPE bits as parsed. In order to be used in the next patch, split the function into protocol extraction and bit marking. The bit marking is meaningful only in vxlan_rcv; move it directly there. Rename the function to vxlan_parse_gpe_proto to reflect what it now does. Remove unused arguments skb and vxflags. Move the function earlier in the file to allow it to be called from more places in the next patch. Signed-off-by: Jiri Benc <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-07-24ethernet: atheros: fix return value check in atl1c_tso_csum()Yuanjun Gong1-2/+5
in atl1c_tso_csum, it should check the return value of pskb_trim(), and return an error code if an unexpected value is returned by pskb_trim(). Signed-off-by: Yuanjun Gong <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-07-24vxlan: calculate correct header length for GPEJiri Benc3-18/+20
VXLAN-GPE does not add an extra inner Ethernet header. Take that into account when calculating header length. This causes problems in skb_tunnel_check_pmtu, where incorrect PMTU is cached. In the collect_md mode (which is the only mode that VXLAN-GPE supports), there's no magic auto-setting of the tunnel interface MTU. It can't be, since the destination and thus the underlying interface may be different for each packet. So, the administrator is responsible for setting the correct tunnel interface MTU. Apparently, the administrators are capable enough to calculate that the maximum MTU for VXLAN-GPE is (their_lower_MTU - 36). They set the tunnel interface MTU to 1464. If you run a TCP stream over such interface, it's then segmented according to the MTU 1464, i.e. producing 1514 bytes frames. Which is okay, this still fits the lower MTU. However, skb_tunnel_check_pmtu (called from vxlan_xmit_one) uses 50 as the header size and thus incorrectly calculates the frame size to be 1528. This leads to ICMP too big message being generated (locally), PMTU of 1450 to be cached and the TCP stream to be resegmented. The fix is to use the correct actual header size, especially for skb_tunnel_check_pmtu calculation. Fixes: e1e5314de08ba ("vxlan: implement GPE") Signed-off-by: Jiri Benc <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-07-24Merge branch 'hns3-fixes'David S. Miller8-16/+110
Jijie Shao says: ==================== There are some bugfix for the HNS3 ethernet driver There are some bugfix for the HNS3 ethernet driver ==================== Reviewed-by: Simon Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-07-24net: hns3: fix wrong bw weight of disabled tc issueJijie Shao2-4/+16
In dwrr mode, the default bandwidth weight of disabled tc is set to 0. If the bandwidth weight is 0, the mode will change to sp. Therefore, disabled tc default bandwidth weight need changed to 1, and 0 is returned when query the bandwidth weight of disabled tc. In addition, driver need stop configure bandwidth weight if tc is disabled. Fixes: 848440544b41 ("net: hns3: Add support of TX Scheduler & Shaper to HNS3 driver") Signed-off-by: Jie Wang <[email protected]> Signed-off-by: Jijie Shao <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-07-24net: hns3: fix wrong tc bandwidth weight data issueJijie Shao1-2/+1
Currently, the weight saved by the driver is used as the query result, which may be different from the actual weight in the register. Therefore, the register value read from the firmware is used as the query result Fixes: 0e32038dc856 ("net: hns3: refactor dump tc of debugfs") Signed-off-by: Jijie Shao <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-07-24net: hns3: add tm flush when setting tmHao Lan7-6/+73
When the tm module is configured with traffic, traffic may be abnormal. This patch fixes this problem. Before the tm module is configured, traffic processing should be stopped. After the tm module is configured, traffic processing is enabled. Signed-off-by: Hao Lan <[email protected]> Signed-off-by: Jijie Shao <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-07-24net: hns3: fix the imp capability bit cannot exceed 32 bits issueHao Lan2-4/+20
Current only the first 32 bits of the capability flag bit are considered. When the matching capability flag bit is greater than 31 bits, it will get an error bit.This patch use bitmap to solve this issue. It can handle each capability bit whitout bit width limit. Fixes: da77aef9cc58 ("net: hns3: create common cmdq resource allocate/free/query APIs") Signed-off-by: Hao Lan <[email protected]> Signed-off-by: Jijie Shao <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-07-24Merge tag 'irqchip-fixes-6.5-1' of ↵Thomas Gleixner4-40/+117
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/urgent Pull irqchip fixes from Marc Zyngier: - Work around an erratum on GIC700, where a race between a CPU handling a wake-up interrupt, a change of affinity, and another CPU going to sleep can result in a lack of wake-up event on the next interrupt. - Fix the locking required on a VPE for GICv4 - Enable Rockchip 3588001 erratum workaround for RK3588S - Fix the irq-bcm6345-l1 assumtions of the boot CPU always be the first CPU in the system Link: https://lore.kernel.org/lkml/[email protected]
2023-07-24serial: qcom-geni: drop bogus runtime pm state updateJohan Hovold1-7/+0
The runtime PM state should not be changed by drivers that do not implement runtime PM even if it happens to work around a bug in PM core. With the wake irq arming now fixed, drop the bogus runtime PM state update which left the device in active state (and could potentially prevent a parent device from suspending). Fixes: f3974413cf02 ("tty: serial: qcom_geni_serial: Wakeup IRQ cleanup") Cc: 5.6+ <[email protected]> # 5.6+ Signed-off-by: Johan Hovold <[email protected]> Reviewed-by: Tony Lindgren <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2023-07-24PM: sleep: wakeirq: drop unused enable helpersJohan Hovold2-59/+0
Drop the wake-irq enable and disable helpers which have not been used since commit bed570307ed7 ("PM / wakeirq: Fix dedicated wakeirq for drivers not using autosuspend"). Note that these functions are essentially just leftovers from the first iteration of the wake-irq implementation where device drivers were supposed to call these functions themselves instead of PM core (as is also indicated by the bogus kernel doc comments). Signed-off-by: Johan Hovold <[email protected]> Reviewed-by: Tony Lindgren <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2023-07-24PM: sleep: wakeirq: fix wake irq armingJohan Hovold2-4/+9
The decision whether to enable a wake irq during suspend can not be done based on the runtime PM state directly as a driver may use wake irqs without implementing runtime PM. Such drivers specifically leave the state set to the default 'suspended' and the wake irq is thus never enabled at suspend. Add a new wake irq flag to track whether a dedicated wake irq has been enabled at runtime suspend and therefore must not be enabled at system suspend. Note that pm_runtime_enabled() can not be used as runtime PM is always disabled during late suspend. Fixes: 69728051f5bf ("PM / wakeirq: Fix unbalanced IRQ enable for wakeirq") Cc: 4.16+ <[email protected]> # 4.16+ Signed-off-by: Johan Hovold <[email protected]> Reviewed-by: Tony Lindgren <[email protected]> Tested-by: Tony Lindgren <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2023-07-24thermal: of: fix double-free on unregistrationAhmad Fatoum1-21/+6
Since commit 3d439b1a2ad3 ("thermal/core: Alloc-copy-free the thermal zone parameters structure"), thermal_zone_device_register() allocates a copy of the tzp argument and frees it when unregistering, so thermal_of_zone_register() now ends up leaking its original tzp and double-freeing the tzp copy. Fix this by locating tzp on stack instead. Fixes: 3d439b1a2ad3 ("thermal/core: Alloc-copy-free the thermal zone parameters structure") Signed-off-by: Ahmad Fatoum <[email protected]> Acked-by: Daniel Lezcano <[email protected]> Cc: 6.4+ <[email protected]> # 6.4+: 8bcbb18c61d6: thermal: core: constify params in thermal_zone_device_register Signed-off-by: Rafael J. Wysocki <[email protected]>
2023-07-24thermal: core: constify params in thermal_zone_device_registerAhmad Fatoum2-5/+5
Since commit 3d439b1a2ad3 ("thermal/core: Alloc-copy-free the thermal zone parameters structure"), thermal_zone_device_register() allocates a copy of the tzp argument and callers need not explicitly manage its lifetime. This means the function no longer cares about the parameter being mutable, so constify it. No functional change. Signed-off-by: Ahmad Fatoum <[email protected]> Acked-by: Daniel Lezcano <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2023-07-24mm,memblock: reset memblock.reserved to system init state to prevent UAFRik van Riel1-0/+4
The memblock_discard function frees the memblock.reserved.regions array, which is good. However, if a subsequent memblock_free (or memblock_phys_free) comes in later, from for example ima_free_kexec_buffer, that will result in a use after free bug in memblock_isolate_range. When running a kernel with CONFIG_KASAN enabled, this will cause a kernel panic very early in boot. Without CONFIG_KASAN, there is a chance that memblock_isolate_range might scribble on memory that is now in use by somebody else. Avoid those issues by making sure that memblock_discard points memblock.reserved.regions back at the static buffer. If memblock_free is called after memblock memory is discarded, that will print a warning in memblock_remove_region. Signed-off-by: Rik van Riel <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mike Rapoport (IBM) <[email protected]>
2023-07-23regulator: mt6358: Fix incorrect VCN33 sync error messageChen-Yu Tsai1-1/+1
After syncing the enable status of VCN33_WIFI to VCN33_BT, the driver will disable VCN33_WIFI. If it fails it will error out with a message. However the error message incorrectly refers to VCN33_BT. Fix the error message so that it correctly refers to VCN33_WIFI. Suggested-by: Fei Shao <[email protected]> Fixes: 65bae54e08c1 ("regulator: mt6358: Merge VCN33_* regulators") Signed-off-by: Chen-Yu Tsai <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2023-07-23regulator: mt6358: Sync VCN33_* enable status after checking IDChen-Yu Tsai1-4/+4
Syncing VCN33_* enable status should be done after checking the PMIC's ID, to avoid setting random bits on other PMICs. Suggested-by: AngeloGioacchino Del Regno <[email protected]> Fixes: 65bae54e08c1 ("regulator: mt6358: Merge VCN33_* regulators") Signed-off-by: Chen-Yu Tsai <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2023-07-23ASoC: nau8821: Add DMI quirk mechanism for active-high jack-detectEdson Juliano Drosdeck1-0/+41
Add a quirk mechanism to allow specifying that active-high jack-detection should be used on platforms where this info is not available in devicetree. And add an entry for the Positivo CW14Q01P-V2 to the DMI table, so that jack-detection will work properly on this laptop. Signed-off-by: Edson Juliano Drosdeck <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2023-07-23ASoC: da7219: Check for failure reading AAD IRQ eventsDmytro Maluka1-3/+7
When handling an AAD interrupt, if IRQ events read failed (for example, due to i2c "Transfer while suspended" failure, i.e. when attempting to read it while DA7219 is suspended, which may happen due to a spurious AAD interrupt), the events array contains garbage uninitialized values. So instead of trying to interprete those values and doing any actions based on them (potentially resulting in misbehavior, e.g. reporting bogus events), refuse to handle the interrupt. Signed-off-by: Dmytro Maluka <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2023-07-23ASoC: da7219: Flush pending AAD IRQ when suspendingDmytro Maluka1-0/+2
da7219_aad_suspend() disables jack detection, which should prevent generating new interrupts by DA7219 while suspended. However, there is a theoretical possibility that there is a pending interrupt generated just before suspending DA7219 and not handled yet, so the IRQ handler may still run after DA7219 is suspended. To prevent that, wait until the pending IRQ handling is done. This patch arose as an attempt to fix the following I2C failure occurring sometimes during system suspend or resume: [ 355.876211] i2c_designware i2c_designware.3: Transfer while suspended [ 355.876245] WARNING: CPU: 2 PID: 3576 at drivers/i2c/busses/i2c-designware-master.c:570 i2c_dw_xfer+0x411/0x440 ... [ 355.876462] Call Trace: [ 355.876468] <TASK> [ 355.876475] ? update_load_avg+0x1b3/0x615 [ 355.876484] __i2c_transfer+0x101/0x1d8 [ 355.876494] i2c_transfer+0x74/0x10d [ 355.876504] regmap_i2c_read+0x6a/0x9c [ 355.876513] _regmap_raw_read+0x179/0x223 [ 355.876521] regmap_raw_read+0x1e1/0x28e [ 355.876527] regmap_bulk_read+0x17d/0x1ba [ 355.876532] ? __wake_up+0xed/0x1bb [ 355.876542] da7219_aad_irq_thread+0x54/0x2c9 [snd_soc_da7219 5fb8ebb2179cf2fea29af090f3145d68ed8e2184] [ 355.876556] irq_thread+0x13c/0x231 [ 355.876563] ? irq_forced_thread_fn+0x5f/0x5f [ 355.876570] ? irq_thread_fn+0x4d/0x4d [ 355.876576] kthread+0x13a/0x152 [ 355.876581] ? synchronize_irq+0xc3/0xc3 [ 355.876587] ? kthread_blkcg+0x31/0x31 [ 355.876592] ret_from_fork+0x1f/0x30 [ 355.876601] </TASK> which indicates that the AAD IRQ handler is unexpectedly running when DA7219 is suspended, and as a result, is trying to read data from DA7219 over I2C and is hitting the I2C driver "Transfer while suspended" failure. However, with this patch the above failure is still reproducible. So this patch does not fix any real observed issue so far, but at least is useful for confirming that the above issue is not caused by a pending IRQ but rather looks like a DA7219 hardware issue with an IRQ unexpectedly generated after jack detection is already disabled. Signed-off-by: Dmytro Maluka <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2023-07-23ASoC: Merge up fixes from mainlineMark Brown315-2060/+3457
There's several things here that will really help my CI.
2023-07-23Linux 6.5-rc3Linus Torvalds1-1/+1
2023-07-23Merge tag 'trace-v6.5-rc2' of ↵Linus Torvalds4-7/+17
git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace Pull tracing fixes from Steven Rostedt: - Swapping the ring buffer for snapshotting (for things like irqsoff) can crash if the ring buffer is being resized. Disable swapping when this happens. The missed swap will be reported to the tracer - Report error if the histogram fails to be created due to an error in adding a histogram variable, in event_hist_trigger_parse() - Remove unused declaration of tracing_map_set_field_descr() * tag 'trace-v6.5-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace: tracing/histograms: Return an error if we fail to add histogram to hist_vars list ring-buffer: Do not swap cpu_buffer during resize process tracing: Remove unused extern declaration tracing_map_set_field_descr()
2023-07-23Merge tag 'kbuild-fixes-v6.5' of ↵Linus Torvalds5-15/+31
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild Pull Kbuild fixes from Masahiro Yamada: - Fix stale help text in gconfig - Support *.S files in compile_commands.json - Flatten KBUILD_CFLAGS - Fix external module builds with Rust so that temporary files are created in the modules directories instead of the kernel tree * tag 'kbuild-fixes-v6.5' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: kbuild: rust: avoid creating temporary files kbuild: flatten KBUILD_CFLAGS gen_compile_commands: add assembly files to compilation database kconfig: gconfig: correct program name in help text kconfig: gconfig: drop the Show Debug Info help text
2023-07-24kbuild: rust: avoid creating temporary filesMiguel Ojeda2-2/+9
`rustc` outputs by default the temporary files (i.e. the ones saved by `-Csave-temps`, such as `*.rcgu*` files) in the current working directory when `-o` and `--out-dir` are not given (even if `--emit=x=path` is given, i.e. it does not use those for temporaries). Since out-of-tree modules are compiled from the `linux` tree, `rustc` then tries to create them there, which may not be accessible. Thus pass `--out-dir` explicitly, even if it is just for the temporary files. Similarly, do so for Rust host programs too. Reported-by: Raphael Nestler <[email protected]> Closes: https://github.com/Rust-for-Linux/linux/issues/1015 Reported-by: Andrea Righi <[email protected]> Tested-by: Raphael Nestler <[email protected]> # non-hostprogs Tested-by: Andrea Righi <[email protected]> # non-hostprogs Fixes: 295d8398c67e ("kbuild: specify output names separately for each emission type from rustc") Cc: [email protected] Signed-off-by: Miguel Ojeda <[email protected]> Tested-by: Martin Rodriguez Reboredo <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>
2023-07-23Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds17-72/+140
Pull kvm fixes from Paolo Bonzini: "ARM: - Avoid pKVM finalization if KVM initialization fails - Add missing BTI instructions in the hypervisor, fixing an early boot failure on BTI systems - Handle MMU notifiers correctly for non hugepage-aligned memslots - Work around a bug in the architecture where hypervisor timer controls have UNKNOWN behavior under nested virt - Disable preemption in kvm_arch_hardware_enable(), fixing a kernel BUG in cpu hotplug resulting from per-CPU accessor sanity checking - Make WFI emulation on GICv4 systems robust w.r.t. preemption, consistently requesting a doorbell interrupt on vcpu_put() - Uphold RES0 sysreg behavior when emulating older PMU versions - Avoid macro expansion when initializing PMU register names, ensuring the tracepoints pretty-print the sysreg s390: - Two fixes for asynchronous destroy x86 fixes will come early next week" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: KVM: s390: pv: fix index value of replaced ASCE KVM: s390: pv: simplify shutdown and fix race KVM: arm64: Fix the name of sys_reg_desc related to PMU KVM: arm64: Correctly handle RES0 bits PMEVTYPER<n>_EL0.evtCount KVM: arm64: vgic-v4: Make the doorbell request robust w.r.t preemption KVM: arm64: Add missing BTI instructions KVM: arm64: Correctly handle page aging notifiers for unaligned memslot KVM: arm64: Disable preemption in kvm_arch_hardware_enable() KVM: arm64: Handle kvm_arm_init failure correctly in finalize_pkvm KVM: arm64: timers: Use CNTHCTL_EL2 when setting non-CNTKCTL_EL1 bits
2023-07-23Merge tag 'ext4_for_linus-6.5-rc3' of ↵Linus Torvalds7-263/+262
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 Pull ext4 fixes from Ted Ts'o: "Bug and regression fixes for 6.5-rc3 for ext4's mballoc and jbd2's checkpoint code" * tag 'ext4_for_linus-6.5-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4: ext4: fix rbtree traversal bug in ext4_mb_use_preallocated ext4: fix off by one issue in ext4_mb_choose_next_group_best_avail() ext4: correct inline offset when handling xattrs in inode body jbd2: remove __journal_try_to_free_buffer() jbd2: fix a race when checking checkpoint buffer busy jbd2: Fix wrongly judgement for buffer head removing while doing checkpoint jbd2: remove journal_clean_one_cp_list() jbd2: remove t_checkpoint_io_list jbd2: recheck chechpointing non-dirty buffer
2023-07-23Merge tag '6.5-rc2-smb3-client-fixes-ver2' of ↵Linus Torvalds2-6/+15
git://git.samba.org/sfrench/cifs-2.6 Pull smb client fix from Steve French: "Add minor debugging improvement. The change improves ability to read a network trace to debug problems on encrypted connections which are very common (e.g. using wireshark or tcpdump). That works today with tools like 'smbinfo keys /mnt/file' but requires passing in a filename on the mount (see e.g. [1]), but it often makes more sense to just pass in the mount point path (ie a directory not a filename). So this fix was needed to debug some types of problems (an obvious example is on an encrypted connection failing operations on an empty share or with no files in the root of the directory) - so you can simply pass in the 'smbinfo keys <mntpoint>' and get the information that wireshark needs" Link: https://wiki.samba.org/index.php/Wireshark_Decryption [1] * tag '6.5-rc2-smb3-client-fixes-ver2' of git://git.samba.org/sfrench/cifs-2.6: cifs: update internal module version number for cifs.ko cifs: allow dumping keys for directories too
Powered by cgit, Gruvboxed by Blaster4385.