Select Git revision
Search by author
- Any Author
- authors
-
72162444 72162444 gaochangning
-
Aakash Dave aakash.dave
-
Aaron Kim akim
-
Aaron Kloc akloc
-
Aaron Lan aaron.lan
-
Aaron Nabil aaronna
-
Aaron Pohle aaron.pohle
-
Abbott Chung chung.abbott
-
Abdallah Omar abdallah_omar
-
Abdessamii Chalbi abdessamii.chalbi
-
Abdul Hussain Sirajudeen abdul.hussain
-
Abdullah Alghamdi a.alghamdi
-
Abdullah Elmarghany abdullah_elmarghany
-
Abel Fang abel_fang
-
Abel Vesa
abel.vesa
-
Abhijeet Badurkar abhijeet.badurkar
-
Abhijit Adsule adsule
-
Abhijit Murthy abhijit
-
Abhi Khanal akhanal
-
Abhilash Sahoo abhilashsahoo
- Dec 14, 2024
-
-
Oliver Neukum authored
[ Upstream commit 422dc0a4 ] chaoskey_open() takes the lock only to increase the counter of openings. That means that the mutual exclusion with chaoskey_disconnect() cannot prevent an increase of the counter and chaoskey_open() returning a success. If that race is hit, chaoskey_disconnect() will happily free all resources associated with the device after it has dropped the lock, as it has read the counter as zero. To prevent this race chaoskey_open() has to check the presence of the device under the lock. However, the current per device lock cannot be used, because it is a part of the data structure to be freed. Hence an additional global mutex is needed. The issue is as old as the driver. Signed-off-by:
Oliver Neukum <oneukum@suse.com> Reported-by:
<syzbot+422188bce66e76020e55@syzkaller.appspotmail.com> Closes: https://syzkaller.appspot.com/bug?extid=422188bce66e76020e55 Fixes: 66e3e591 ("usb: Add driver for Altus Metrum ChaosKey device (v2)") Rule: add Link: https://lore.kernel.org/stable/20241002132201.552578-1-oneukum%40suse.com Link: https://lore.kernel.org/r/20241002132201.552578-1-oneukum@suse.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Oliver Neukum authored
[ Upstream commit e0aa9614 ] The IO yurex_write() needs to wait for in order to have a device ready for writing again can take a long time time. Consequently the sleep is done in an interruptible state. Therefore others waiting for yurex_write() itself to finish should use mutex_lock_interruptible. Signed-off-by:
-
Jeongjun Park authored
[ Upstream commit 44feafba ] iowarrior_read() uses the iowarrior dev structure, but does not use any lock on the structure. This can cause various bugs including data-races, so it is more appropriate to use a mutex lock to safely protect the iowarrior dev structure. When using a mutex lock, you should split the branch to prevent blocking when the O_NONBLOCK flag is set. In addition, it is unnecessary to check for NULL on the iowarrior dev structure obtained by reading file->private_data. Therefore, it is better to remove the check. Fixes: 946b960d ("USB: add driver for iowarrior devices.") Signed-off-by:
Jeongjun Park <aha310510@gmail.com> Link: https://lore.kernel.org/r/20240919103403.3986-1-aha310510@gmail.com Signed-off-by:
-
Christophe JAILLET authored
[ Upstream commit a4b7064d ] If i2c_smbus_write_byte_data() fails in al3010_init(), al3010_set_pwr(false) is not called. In order to avoid such a situation, move the devm_add_action_or_reset() witch calls al3010_set_pwr(false) right after a successful al3010_set_pwr(true). Fixes: c36b5195 ("iio: light: add Dyna-Image AL3010 driver") Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://patch.msgid.link/ee5d10a2dd2b70f29772d5df33774d3974a80f30.1725993353.git.christophe.jaillet@wanadoo.fr Signed-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
-
Paolo Abeni authored
[ Upstream commit fc9c273d ] Similar to the previous patch, plumb the RCU lock inside the ipmr_get_table(), provided a lockless variant and apply the latter in the few spots were the lock is already held. Fixes: 709b46e8 ("net: Add compat ioctl support for the ipv4 multicast ioctl SIOCGETSGCNT") Fixes: f0ad0860 ("ipv4: ipmr: support multiple tables") Reviewed-by:
David Ahern <dsahern@kernel.org> Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit b96ef16d ] We can use standard rcu_read_lock(), to get rid of last read_lock(&mrt_lock) call points. Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Stable-dep-of: fc9c273d ("ipmr: fix tables suspicious RCU usage") Signed-off-by:
-
Saravanan Vajravel authored
[ Upstream commit 5311598f ] After successful PCIe AER recovery, FW will reset all resource reservations. If it is IF_UP, the driver will call bnxt_open() and all resources will be reserved again. It it is IF_DOWN, we should call bnxt_reserve_rings() so that we can reserve resources including RoCE resources to allow RoCE to resume after AER. Without this patch, RoCE fails to resume in this IF_DOWN scenario. Later, if it becomes IF_UP, bnxt_open() will see that resources have been reserved and will not reserve again. Fixes: fb1e6e56 ("bnxt_en: Fix AER recovery.") Reviewed-by:
Somnath Kotur <somnath.kotur@broadcom.com> Reviewed-by:
Pavan Chebbi <pavan.chebbi@broadcom.com> Reviewed-by:
Kashyap Desai <kashyap.desai@broadcom.com> Signed-off-by:
Saravanan Vajravel <saravanan.vajravel@broadcom.com> Signed-off-by:
Michael Chan <michael.chan@broadcom.com> Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit 9cfb5e7f ] Following sequence in hsr_init_sk() is invalid : skb_reset_mac_header(skb); skb_reset_mac_len(skb); skb_reset_network_header(skb); skb_reset_transport_header(skb); It is invalid because skb_reset_mac_len() needs the correct network header, which should be after the mac header. This patch moves the skb_reset_network_header() and skb_reset_transport_header() before the call to dev_hard_header(). As a result skb->mac_len is no longer set to a value close to 65535. Fixes: 48b491a5 ("net: hsr: fix mac_len checks") Signed-off-by:
-
Alexander Lobakin authored
[ Upstream commit 6f1c0ea1 ] Introduce a new netdev feature, NETIF_F_GRO_UDP_FWD, to allow user to turn UDP GRO on and off for forwarding. Defaults to off to not change current datapath. Suggested-by:
Alexander Lobakin <alobakin@pm.me> Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Stable-dep-of: 9cfb5e7f ("net: hsr: fix hsr_init_sk() vs network/transport headers.") Signed-off-by:
-
Csókás, Bence authored
[ Upstream commit 2ac40e6d ] `atmel_qspi_reg_name()` is used for pretty-printing register offsets for verbose logging of register accesses. However, due to a typo (likely a copy-paste error), QSPI_RD's offset prints as "MR", the name of the previous register. Fix this typo. Fixes: c528ecfb ("spi: atmel-quadspi: Add verbose debug facilities to monitor register accesses") Signed-off-by:
Csókás, Bence <csokas.bence@prolan.hu> Reviewed-by:
Alexander Dahl <ada@thorsis.com> Link: https://patch.msgid.link/20241122141302.2599636-1-csokas.bence@prolan.hu Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Maxime Chevallier authored
[ Upstream commit 407618d6 ] On DWMAC3 and later, there's a RX Watchdog interrupt that's used for interrupt coalescing. It's known to be buggy on some platforms, and dwmac-socfpga appears to be one of them. Changing the interrupt coalescing from ethtool doesn't appear to have any effect here. Without disabling RIWT (Received Interrupt Watchdog Timer, I believe...), we observe latencies while receiving traffic that amount to around ~0.4ms. This was discovered with NTP but can be easily reproduced with a simple ping. Without this patch : 64 bytes from 192.168.5.2: icmp_seq=1 ttl=64 time=0.657 ms With this patch : 64 bytes from 192.168.5.2: icmp_seq=1 ttl=64 time=0.254 ms Fixes: 801d233b ("net: stmmac: Add SOCFPGA glue driver") Signed-off-by:
Maxime Chevallier <maxime.chevallier@bootlin.com> Link: https://patch.msgid.link/20241122141256.764578-1-maxime.chevallier@bootlin.com Signed-off-by:
-
Vitalii Mordan authored
[ Upstream commit b032ae57 ] If the clock pep->clk was not enabled in pxa168_eth_probe, it should not be disabled in any path. Conversely, if it was enabled in pxa168_eth_probe, it must be disabled in all error paths to ensure proper cleanup. Use the devm_clk_get_enabled helper function to ensure proper call balance for pep->clk. Found by Linux Verification Center (linuxtesting.org) with Klever. Fixes: a49f37ee ("net: add Fast Ethernet driver for PXA168.") Signed-off-by:
Vitalii Mordan <mordan@ispras.ru> Link: https://patch.msgid.link/20241121200658.2203871-1-mordan@ispras.ru Signed-off-by:
-
Oleksij Rempel authored
[ Upstream commit e863ff80 ] Validate Wake-on-LAN (WoL) options in `lan78xx_set_wol` before calling `usb_autopm_get_interface`. This prevents USB autopm refcounting issues and ensures the adapter can properly enter autosuspend when invalid WoL options are provided. Fixes: eb9ad088 ("lan78xx: Check for supported Wake-on-LAN modes") Signed-off-by:
Oleksij Rempel <o.rempel@pengutronix.de> Acked-by:
Florian Fainelli <f.fainelli@gmail.com> Link: https://patch.msgid.link/20241118140351.2398166-1-o.rempel@pengutronix.de Signed-off-by:
-
Pavan Chebbi authored
[ Upstream commit 614f4d16 ] The hardware on Broadcom 1G chipsets have a known limitation where they cannot handle DMA addresses that cross over 4GB. When such an address is encountered, the hardware sets the address overflow error bit in the DMA status register and triggers a reset. However, BCM57766 hardware is setting the overflow bit and triggering a reset in some cases when there is no actual underlying address overflow. The hardware team analyzed the issue and concluded that it is happening when the status block update has an address with higher (b16 to b31) bits as 0xffff following a previous update that had lowest bits as 0xffff. To work around this bug in the BCM57766 hardware, set the coherent dma mask from the current 64b to 31b. This will ensure that upper bits of the status block DMA address are always at most 0x7fff, thus avoiding the improper overflow check described above. This work around is intended for only status block and ring memories and has no effect on TX and RX buffers as they do not require coherent memory. Fixes: 72f2afb8 ("[TG3]: Add DMA address workaround") Reported-by:
Salam Noureddine <noureddine@arista.com> Reviewed-by:
Kalesh AP <kalesh-anakkur.purayil@broadcom.com> Reviewed-by:
Michal Kubiak <michal.kubiak@intel.com> Link: https://patch.msgid.link/20241119055741.147144-1-pavan.chebbi@broadcom.com Signed-off-by:
-
Oleksij Rempel authored
[ Upstream commit ae7370e6 ] Add calls to `phy_device_free` after `fixed_phy_unregister` to fix a memory leak that occurs when the device is unplugged. This ensures proper cleanup of pseudo fixed-link PHYs. Fixes: 89b36fb5 ("lan78xx: Lan7801 Support for Fixed PHY") Cc: Raghuram Chary J <raghuramchary.jallipalli@microchip.com> Signed-off-by:
-
Barnabás Czémán authored
[ Upstream commit 34f99d3b ] Correct bq27426 registers, according to technical reference manual it does not have Design Capacity register so it is not register compatible with bq27421. Fixes: 5ef6a160 ("power: supply: bq27xxx: Add support for BQ27426") Signed-off-by:
Barnabás Czémán <barnabas.czeman@mainlining.org> Link: https://lore.kernel.org/r/20241016-fix_bq27426-v2-1-aa6c0f51a9f6@mainlining.org Signed-off-by:
Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by:
-
Hermes Zhang authored
[ Upstream commit 3ed510f0 ] Currently REG_NAC (nominal available capacity) is mapped to power-supply's CHARGE_NOW property. Some chips do not have REG_NAC and do not expose CHARGE_NOW at the moment. Some bq27xxx chips also have another register REG_RM (remaining capacity). The difference between REG_NAC and REG_RM is load compensation. This patch adds register information for REG_RM for all supported fuel gauges. On systems having REG_NAC it is ignored, so behaviour does not change. On systems without REG_NAC, REG_RM will be used to provide CHARGE_NOW functionality. As a result there are three more chips exposing CHARGE_NOW: bq27z561, bq28z610 and bq34z100 Signed-off-by:
Hermes Zhang <chenhuiz@axis.com> Signed-off-by:
-
Bart Van Assche authored
[ Upstream commit f6da4553 ] The put_device() call in power_supply_put() may call power_supply_dev_release(). The latter function does not sleep so power_supply_put() doesn't sleep either. Hence, remove the might_sleep() call from power_supply_put(). This patch suppresses false positive complaints about calling a sleeping function from atomic context if power_supply_put() is called from atomic context. Cc: Kyle Tso <kyletso@google.com> Cc: Krzysztof Kozlowski <krzk@kernel.org> Fixes: 1a352462 ("power_supply: Add power_supply_put for decrementing device reference counter") Signed-off-by:
Bart Van Assche <bvanassche@acm.org> Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20240917193914.47566-1-bvanassche@acm.org Signed-off-by:
-
Randy Dunlap authored
[ Upstream commit c66f7598 ] Add the missing 'name' parameter to the mount_api documentation for fs_validate_description(). Fixes: 96cafb9c ("fs_parser: remove fs_parameter_description name field") Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Link: https://lore.kernel.org/r/20241125215021.231758-1-rdunlap@infradead.org Cc: Eric Sandeen <sandeen@redhat.com> Cc: David Howells <dhowells@redhat.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Christian Brauner <brauner@kernel.org> Cc: Jan Kara <jack@suse.cz> Cc: Jonathan Corbet <corbet@lwn.net> Cc: linux-doc@vger.kernel.org Signed-off-by:
Christian Brauner <brauner@kernel.org> Signed-off-by:
-
Avihai Horon authored
[ Upstream commit fe4bf8d0b6716a423b16495d55b35d3fe515905d ] There are cases where a PCIe extended capability should be hidden from the user. For example, an unknown capability (i.e., capability with ID greater than PCI_EXT_CAP_ID_MAX) or a capability that is intentionally chosen to be hidden from the user. Hiding a capability is done by virtualizing and modifying the 'Next Capability Offset' field of the previous capability so it points to the capability after the one that should be hidden. The special case where the first capability in the list should be hidden is handled differently because there is no previous capability that can be modified. In this case, the capability ID and version are zeroed while leaving the next pointer intact. This hides the capability and leaves an anchor for the rest of the capability list. However, today, hiding the first capability in the list is not done properly if the capability is unknown, as struct vfio_pci_core_device->pci_config_map is set to the capability ID during initialization but the capability ID is not properly checked later when used in vfio_config_do_rw(). This leads to the following warning [1] and to an out-of-bounds access to ecap_perms array. Fix it by checking cap_id in vfio_config_do_rw(), and if it is greater than PCI_EXT_CAP_ID_MAX, use an alternative struct perm_bits for direct read only access instead of the ecap_perms array. Note that this is safe since the above is the only case where cap_id can exceed PCI_EXT_CAP_ID_MAX (except for the special capabilities, which are already checked before). [1] WARNING: CPU: 118 PID: 5329 at drivers/vfio/pci/vfio_pci_config.c:1900 vfio_pci_config_rw+0x395/0x430 [vfio_pci_core] CPU: 118 UID: 0 PID: 5329 Comm: simx-qemu-syste Not tainted 6.12.0+ #1 (snip) Call Trace: <TASK> ? show_regs+0x69/0x80 ? __warn+0x8d/0x140 ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core] ? report_bug+0x18f/0x1a0 ? handle_bug+0x63/0xa0 ? exc_invalid_op+0x19/0x70 ? asm_exc_invalid_op+0x1b/0x20 ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core] ? vfio_pci_config_rw+0x244/0x430 [vfio_pci_core] vfio_pci_rw+0x101/0x1b0 [vfio_pci_core] vfio_pci_core_read+0x1d/0x30 [vfio_pci_core] vfio_device_fops_read+0x27/0x40 [vfio] vfs_read+0xbd/0x340 ? vfio_device_fops_unl_ioctl+0xbb/0x740 [vfio] ? __rseq_handle_notify_resume+0xa4/0x4b0 __x64_sys_pread64+0x96/0xc0 x64_sys_call+0x1c3d/0x20d0 do_syscall_64+0x4d/0x120 entry_SYSCALL_64_after_hwframe+0x76/0x7e Fixes: 89e1f7d4 ("vfio: Add PCI device driver") Signed-off-by:
Avihai Horon <avihaih@nvidia.com> Reviewed-by:
Yi Liu <yi.l.liu@intel.com> Tested-by:
Alex Williamson <alex.williamson@redhat.com> Signed-off-by:
-
Si-Wei Liu authored
[ Upstream commit 35025963326e44d8bced3eecd42d2f040f4f0024 ] The starting iova address to iterate iotlb map entry within a range was set to an irrelevant value when passing to the itree_next() iterator, although luckily it doesn't affect the outcome of finding out the granule of the smallest iotlb map size. Fix the code to make it consistent with the following for-loop. Fixes: 94abbccd ("vdpa/mlx5: Add shared memory registration code") Signed-off-by:
Si-Wei Liu <si-wei.liu@oracle.com> Signed-off-by:
Dragos Tatulea <dtatulea@nvidia.com> Message-Id: <20241021134040.975221-3-dtatulea@nvidia.com> Signed-off-by:
Michael S. Tsirkin <mst@redhat.com> Acked-by:
Jason Wang <jasowang@redhat.com> Signed-off-by:
-
Chuck Lever authored
[ Upstream commit 62a8642b ] nfsd4_shutdown_copy() is just this: while ((copy = nfsd4_get_copy(clp)) != NULL) nfsd4_stop_copy(copy); nfsd4_get_copy() bumps @copy's reference count, preventing nfsd4_stop_copy() from releasing @copy. A while loop like this usually works by removing the first element of the list, but neither nfsd4_get_copy() nor nfsd4_stop_copy() alters the async_copies list. Best I can tell, then, is that nfsd4_shutdown_copy() continues to loop until other threads manage to remove all the items from this list. The spinning loop blocks shutdown until these items are gone. Possibly the reason we haven't seen this issue in the field is because client_has_state() prevents __destroy_client() from calling nfsd4_shutdown_copy() if there are any items on this list. In a subsequent patch I plan to remove that restriction. Fixes: e0639dc5 ("NFSD introduce async copy feature") Reviewed-by:
Jeff Layton <jlayton@kernel.org> Signed-off-by:
Chuck Lever <chuck.lever@oracle.com> Signed-off-by:
-
Chuck Lever authored
[ Upstream commit f64ea4af ] It's only current caller already length-checks the string, but let's be safe. Fixes: 0964a3d3 ("[PATCH] knfsd: nfsd4 reboot dirname fix") Reviewed-by:
-
Chuck Lever authored
[ Upstream commit 1e02c641 ] @ses is initialized to NULL. If __nfsd4_find_backchannel() finds no available backchannel session, setup_callback_client() will try to dereference @ses and segfault. Fixes: dcbeaa68 ("nfsd4: allow backchannel recovery") Reviewed-by:
-
Sibi Sankar authored
[ Upstream commit 7b22b771 ] Any write access to the IMEM region when the Q6 is setting up XPU protection on it will result in a XPU violation. Fix this by ensuring IMEM writes related to the MBA post-mortem logs happen before the Q6 is brought out of reset. Fixes: 318130cc ("remoteproc: qcom_q6v5_mss: Add MBA log extraction support") Signed-off-by:
Sibi Sankar <quic_sibis@quicinc.com> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Tested-by:
Bjorn Andersson <andersson@kernel.org> Signed-off-by:
-
Jonathan Marek authored
[ Upstream commit 06c59d97 ] The name len field of the CMD_OPEN packet is only 16-bits and the upper 16-bits of "param2" are a different "prio" field, which can be nonzero in certain situations, and CMD_OPEN packets can be unexpectedly dropped because of this. Fix this by masking out the upper 16 bits of param2. Fixes: b4f8e52b ("rpmsg: Introduce Qualcomm RPM glink driver") Signed-off-by:
Jonathan Marek <jonathan@marek.ca> Reviewed-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20241007235935.6216-1-jonathan@marek.ca Signed-off-by:
-
Bjorn Andersson authored
[ Upstream commit 4e816d03 ] The upstream GLINK driver was first introduced to communicate with the RPM on MSM8996, presumably as an artifact from that era the command defines was prefixed RPM_CMD, while they actually are GLINK_CMDs. Let's rename these, to keep things tidy. No functional change. Signed-off-by:
Bjorn Andersson <quic_bjorande@quicinc.com> Reviewed-by:
Chris Lew <quic_clew@quicinc.com> Signed-off-by:
-
Arun Kumar Neelakantam authored
[ Upstream commit b16a37e1 ] The current design sleeps unconditionally in TX FIFO full case and wakeup only after sleep timer expires which adds random delays in clients TX path. Avoid sleep and use READ_NOTIFY command so that writer can be woken up when remote notifies about read completion by sending IRQ. Signed-off-by:
Deepak Kumar Singh <deesin@codeaurora.org> Signed-off-by:
Arun Kumar Neelakantam <aneela@codeaurora.org> Signed-off-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/1596086296-28529-7-git-send-email-deesin@codeaurora.org Stable-dep-of: 06c59d97 ("rpmsg: glink: use only lower 16-bits of param2 for CMD_OPEN name length") Signed-off-by:
-
Arun Kumar Neelakantam authored
[ Upstream commit 8956927f ] With current design the transport can send packets of size upto FIFO_SIZE which is 16k and return failure for all packets above 16k. Add TX_DATA_CONT command to send packets greater than 16k by splitting into 8K chunks. Signed-off-by:
-
Benjamin Peterson authored
[ Upstream commit 1302e352 ] syscall__scnprintf_args may not place anything in the output buffer (e.g., because the arguments are all zero). If that happened in trace__fprintf_sys_enter, its fprintf would receive an unitialized buffer leading to garbage output. Fix the problem by passing the (possibly zero) bounds of the argument buffer to the output fprintf. Fixes: a98392bb ("perf trace: Use beautifiers on syscalls:sys_enter_ handlers") Signed-off-by:
Benjamin Peterson <benjamin@engflow.com> Tested-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Tested-by:
Howard Chu <howardchu95@gmail.com> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Ian Rogers <irogers@google.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Kan Liang <kan.liang@linux.intel.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: https://lore.kernel.org/r/20241107232128.108981-2-benjamin@engflow.com Signed-off-by:
-
Benjamin Peterson authored
[ Upstream commit 3fd7c369 ] If a perf trace event selector specifies a maximum number of events to output (i.e., "/nr=N/" syntax), the event printing handler, trace__event_handler, disables the event selector after the maximum number events are printed. Furthermore, trace__event_handler checked if the event selector was disabled before doing any work. This avoided exceeding the maximum number of events to print if more events were in the buffer before the selector was disabled. However, the event selector can be disabled for reasons other than exceeding the maximum number of events. In particular, when the traced subprocess exits, the main loop disables all event selectors. This meant the last events of a traced subprocess might be lost to the printing handler's short-circuiting logic. This nondeterministic problem could be seen by running the following many times: $ perf trace -e syscalls:sys_enter_exit_group true trace__event_handler should simply check for exceeding the maximum number of events to print rather than the state of the event selector. Fixes: a9c5e6c1 ("perf trace: Introduce per-event maximum number of events property") Signed-off-by:
-
Antonio Quartulli authored
[ Upstream commit 63a24cf8 ] When CONFIG_FEC is set (due to COMPILE_TEST) along with CONFIG_M54xx, coldfire/device.c has compile errors due to missing MCFEC_* and MCF_IRQ_FEC_* symbols. Make the whole FEC blocks dependent on having the HW macros defined, rather than on CONFIG_FEC itself. This fix is very similar to commit e6e1e7b1 ("m68k: coldfire/device.c: only build for MCF_EDMA when h/w macros are defined") Fixes: b7ce7f0d ("m68knommu: merge common ColdFire FEC platform setup code") To: Greg Ungerer <gerg@linux-m68k.org> To: Geert Uytterhoeven <geert@linux-m68k.org> Cc: linux-m68k@lists.linux-m68k.org Cc: linux-kernel@vger.kernel.org Signed-off-by:
Antonio Quartulli <antonio@mandelbit.com> Signed-off-by:
Greg Ungerer <gerg@kernel.org> Signed-off-by:
-
Jean-Michel Hautbois authored
[ Upstream commit f2121409 ] Fix a typo in the CONFIG_M5441x preprocessor condition, where the GPIO register offset was incorrectly set to 8 instead of 0. This prevented proper GPIO configuration for m5441x targets. Fixes: bea8bcb1 ("m68knommu: Add support for the Coldfire m5441x.") Signed-off-by:
Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org> Signed-off-by:
-
Benjamin Peterson authored
[ Upstream commit 5fb8e565 ] trace__fprintf_tp_fields may not print any tracepoint arguments. E.g., if the argument values are all zero. Previously, this would result in a totally uninitialized buffer being passed to fprintf, which could lead to garbage on the console. Fix the problem by passing the number of initialized bytes fprintf. Fixes: f11b2803 ("perf trace: Allow choosing how to augment the tracepoint arguments") Signed-off-by:
Namhyung Kim <namhyung@kernel.org> Signed-off-by:
-
Yongpeng Yang authored
[ Upstream commit 43563069 ] In the __f2fs_init_atgc_curseg->get_atssr_segment calling, curseg->segno is NULL_SEGNO, indicating that there is no summary block that needs to be written. Fixes: 093749e2 ("f2fs: support age threshold based garbage collection") Signed-off-by:
Yongpeng Yang <yangyongpeng1@oppo.com> Reviewed-by:
Chao Yu <chao@kernel.org> Signed-off-by:
Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by:
-
Christoph Hellwig authored
[ Upstream commit 5bcd655f ] Signed-off-by:
Christoph Hellwig <hch@lst.de> Reviewed-by:
-
Christoph Hellwig authored
[ Upstream commit 8442d94b ] allocate_segment_by_default has just two callers, which use very different code pathes inside it based on the force paramter. Just open code the logic in the two callers using a new helper to decided if a new segment should be allocated. Signed-off-by:
-
Christoph Hellwig authored
[ Upstream commit 1c8a8ec0 ] There is only single instance of these ops, so remove the indirection and call allocate_segment_by_default directly. Signed-off-by:
-
Chao Yu authored
[ Upstream commit 509f1010 ] As we did for other cases, in fix_curseg_write_pointer(), let's use wrapped f2fs_allocate_new_section() instead of native allocate_segment_by_default(), by this way, it fixes to cover segment allocation with curseg_lock and sentry_lock. Signed-off-by:
Chao Yu <yuchao0@huawei.com> Signed-off-by:
-
LongPing Wei authored
[ Upstream commit c3af1f13 ] This f2fs_bug_on was introduced by commit 2c190504 ("f2fs: check segment type in __f2fs_replace_block") when there were only 6 curseg types. After commit d0b9e42a ("f2fs: introduce inmem curseg") was introduced, the condition should be changed to checking curseg->seg_type. Fixes: d0b9e42a ("f2fs: introduce inmem curseg") Signed-off-by:
LongPing Wei <weilongping@oppo.com> Reviewed-by:
-
