- Oct 19, 2023
-
-
Dave Stevenson authored
Fixes: 61b138ad ("dt: Add overrides for drm framebuffer allocations on Pi5") Signed-off-by:
Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Dave Stevenson authored
Fixes: 1216ea56 ("drm/fb-helper: Look up preferred fbdev node number from DT") Signed-off-by:
Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Dave Stevenson authored
Fixes: 7ec42740 ("dt: Add DSI1 and DSI2 aliases to 2712") Signed-off-by:
Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Dave Stevenson authored
Apparently aliases are only allowed lower case and hyphens, so swap the use of underscore to hyphen. Fixes: 3aa1f247 ("drm: Look for an alias for the displays to use as the DRM device name") Signed-off-by:
Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Phil Elwell authored
Most bus masters on Pi 5 have access to at least the lower 4GB, but the old DWC OTG controller is still restricted to the first 1GB. Create a Pi 5-specific version of the overlay including a fragment that ensures the swiotlb bounce buffers are allocated in that area. Signed-off-by:
Phil Elwell <phil@raspberrypi.com>
-
Dave Stevenson authored
Adds dtparam overrides to the base Pi5 DT such that vc4, DSI0, DSI1, or DPI can be requested to be /dev/fb[012]. No override is specified by default, so the order will be based on probe order (aka semi-random). Any device that doesn't have an override specified will be placed above all specified overrides. Having an fb1 or fb2 override but no fb0 one will result in no console via fbcon. Signed-off-by:
Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Dave Stevenson authored
For situations where there are multiple DRM cards in a system, add a query of DT for "drm_fb" designations for cards to set their preferred /dev/fbN designation. Signed-off-by:
Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Dave Stevenson authored
Add a flag custom_fb_num to denote that the client has requested a specific fbdev node number via node. Signed-off-by:
Dave Stevenson <dave.stevenson@raspberrypi.com>
-
- Oct 18, 2023
-
-
Phil Elwell authored
"Model B" is no more - "Raspberry Pi 5" is the official name. Signed-off-by:
Phil Elwell <phil@raspberrypi.com>
-
- Oct 17, 2023
-
-
Naushir Patuck authored
Now that we have removed unique PISP media bus codes, the cfe format table has multiple entries with the same media bus code for 16-bit formats. The test in cfe_video_link_validate() did not account for this. Fix it by testing the media bus code and the V4L2 pixelformat 4cc together. As a drive-by, ensure we have a valid CSI2 datatype id when programming the hardware block. Signed-off-by:
Naushir Patuck <naush@raspberrypi.com>
-
Dom Cobley authored
-
Dave Stevenson authored
11cf37e7 switched to using drm_fb_dma_get_gem_addr instead of drm_fb_dma_get_gem_obj and adding fb->offset[]. However the tiled formats need to compute the offset in a more involved manner than drm_fb_dma_get_gem_addr applies, and we were ending up with the offset for src_[xy] being applied twice. Switch back to using drm_fb_dma_get_gem_obj and fully computing the offsets ourselves. Fixes: 11cf37e7 ("drm/vc4: Move the buffer offset out of the vc4_plane_state") Signed-off-by:
Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Phil Elwell authored
bcm2708_fb is disabled by the vc4-kms-v3d overlay, which means that the DMA memcpy support it provides is not available to allow vclog to read the VC logs from the top 16MB on Pi 2 and Pi 3. Add the code to the vc_mem driver, which will still be enabled. It ought to be possible to do a proper DMA_MEM_TO_MEM copy via the generic DMA customer API, but that can be a later step. Signed-off-by:
Phil Elwell <phil@raspberrypi.com>
-
- Oct 16, 2023
-
-
Phil Elwell authored
The RP1 I2C interfaces were being left with their default clock rates, apparently 400kHz. Signed-off-by:
Phil Elwell <phil@raspberrypi.com>
-
Janis Streib authored
Analogous to i2c-rtc-overlay.dts See: https://github.com/raspberrypi/linux/pull/5650
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20231012180030.112560642@linuxfoundation.org Tested-by:
Florian Fainelli <florian.fainelli@broadcom.com> Tested-by:
Pavel Machek (CIP) <pavel@denx.de> Tested-by:
Guenter Roeck <linux@roeck-us.net> Tested-by:
Bagas Sanjaya <bagasdotme@gmail.com> Tested-by:
Takeshi Ogasawara <takeshi.ogasawara@futuring-girl.com> Tested-by:
Ron Economos <re@w6rz.net> Tested-by:
Ricardo B. Marliere <ricardo@marliere.net> Tested-by:
Linux Kernel Functional Testing <lkft@linaro.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Greg Kroah-Hartman authored
commit efb78fa8 ("lib/test_meminit: allocate pages up to order MAX_ORDER") works great in kernels 6.4 and newer thanks to commit 23baf831 ("mm, treewide: redefine MAX_ORDER sanely"), but for older kernels, the loop is off by one, which causes crashes when the test runs. Fix this up by changing "<= MAX_ORDER" "< MAX_ORDER" to allow the test to work properly for older kernel branches. Fixes: 421855d0 ("lib/test_meminit: allocate pages up to order MAX_ORDER") Cc: Andrew Donnellan <ajd@linux.ibm.com> Cc: Alexander Potapenko <glider@google.com> Cc: Xiaoke Wang <xkernel.wang@foxmail.com> Cc: <stable@vger.kernel.org> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Greg Kroah-Hartman authored
This reverts commit f16fd0b1 which is commit 954998b6 upstream. There are reported NFS problems in the 6.1.56 release, so revert a set of NFS patches to hopefully resolve the issue. Reported-by:
poester <poester@internetbrands.com> Link: https://lore.kernel.org/r/20231012165439.137237-2-kernel@linuxace.com Reported-by:
Daniel Díaz <daniel.diaz@linaro.org> Link: https://lore.kernel.org/r/2023100755-livestock-barcode-fe41@gregkh Cc: Trond Myklebust <trond.myklebust@hammerspace.com> Cc: Anna Schumaker <Anna.Schumaker@Netapp.com> Cc: Sasha Levin <sashal@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Greg Kroah-Hartman authored
This reverts commit 4d98038e which is commit 7c633932 upstream. There are reported NFS problems in the 6.1.56 release, so revert a set of NFS patches to hopefully resolve the issue. Reported-by:
poester <poester@internetbrands.com> Link: https://lore.kernel.org/r/20231012165439.137237-2-kernel@linuxace.com Reported-by:
Daniel Díaz <daniel.diaz@linaro.org> Link: https://lore.kernel.org/r/2023100755-livestock-barcode-fe41@gregkh Cc: Trond Myklebust <trond.myklebust@hammerspace.com> Cc: Anna Schumaker <Anna.Schumaker@Netapp.com> Cc: Sasha Levin <sashal@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Greg Kroah-Hartman authored
This reverts commit 1f49386d which is commit 8982f7af upstream. There are reported NFS problems in the 6.1.56 release, so revert a set of NFS patches to hopefully resolve the issue. Reported-by:
poester <poester@internetbrands.com> Link: https://lore.kernel.org/r/20231012165439.137237-2-kernel@linuxace.com Reported-by:
Daniel Díaz <daniel.diaz@linaro.org> Link: https://lore.kernel.org/r/2023100755-livestock-barcode-fe41@gregkh Cc: Trond Myklebust <trond.myklebust@hammerspace.com> Cc: Anna Schumaker <Anna.Schumaker@Netapp.com> Cc: Sasha Levin <sashal@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Greg Kroah-Hartman authored
This reverts commit d4729af1 which is commit b193a78d upstream. There are reported NFS problems in the 6.1.56 release, so revert a set of NFS patches to hopefully resolve the issue. Reported-by:
poester <poester@internetbrands.com> Link: https://lore.kernel.org/r/20231012165439.137237-2-kernel@linuxace.com Reported-by:
Daniel Díaz <daniel.diaz@linaro.org> Link: https://lore.kernel.org/r/2023100755-livestock-barcode-fe41@gregkh Cc: Trond Myklebust <trond.myklebust@hammerspace.com> Cc: Anna Schumaker <Anna.Schumaker@Netapp.com> Cc: Sasha Levin <sashal@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Greg Kroah-Hartman authored
This reverts commit edd1f061 which is commit b11243f7 upstream. There are reported NFS problems in the 6.1.56 release, so revert a set of NFS patches to hopefully resolve the issue. Reported-by:
poester <poester@internetbrands.com> Link: https://lore.kernel.org/r/20231012165439.137237-2-kernel@linuxace.com Reported-by:
Daniel Díaz <daniel.diaz@linaro.org> Link: https://lore.kernel.org/r/2023100755-livestock-barcode-fe41@gregkh Cc: Trond Myklebust <trond.myklebust@hammerspace.com> Cc: Anna Schumaker <Anna.Schumaker@Netapp.com> Cc: Sasha Levin <sashal@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- Oct 13, 2023
-
-
Dom Cobley authored
This reverts commit d60956f3.
-
Dom Cobley authored
This reverts commit 7b11991e.
-
Phil Elwell authored
Signed-off-by:
Phil Elwell <phil@raspberrypi.com>
-
Nick Hollinghurst authored
When polled without the use of IRQ, FT5x06 registers may return undefined initial data, causing unwanted touches or event spamming. A simple way to filter this out is to suppress touches until the TD_STATUS register changes for the first time. Increase the delay before first polling to 300ms, to avoid transient I2C read flakiness that seems to occur after reset. Signed-off-by:
Nick Hollinghurst <nick.hollinghurst@raspberrypi.com>
-
- Oct 12, 2023
-
-
Phil Elwell authored
See: https://github.com/raspberrypi/linux/issues/4179 Signed-off-by:
Phil Elwell <phil@raspberrypi.com>
-
Phil Elwell authored
The RSVP protocol support has been retired from the kernel, so remove the settings from our defconfigs. Signed-off-by:
Phil Elwell <phil@raspberrypi.com>
-
Dave Stevenson authored
The firmware wants the YUYV format stride alignment to be to a multiple of 32pixels / 64 bytes. The kernel driver was configuring it to a multiple of 16 pixels / 32 bytes, which then failed when it tried starting to stream. Correct the alignment requirements. Signed-off-by:
Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Dom Cobley authored
-
- Oct 11, 2023
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20231009130122.946357448@linuxfoundation.org Tested-by:
SeongJae Park <sj@kernel.org> Tested-by:
Shuah Khan <skhan@linuxfoundation.org> Tested-by:
Florian Fainelli <florian.fainelli@broadcom.com> Tested-by:
Bagas Sanjaya <bagasdotme@gmail.com> Tested-by:
Jon Hunter <jonathanh@nvidia.com> Tested-by:
Takeshi Ogasawara <takeshi.ogasawara@futuring-girl.com> Tested-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Juergen Gross authored
commit 87797fad upstream. In unprivileged Xen guests event handling can cause a deadlock with Xen console handling. The evtchn_rwlock and the hvc_lock are taken in opposite sequence in __hvc_poll() and in Xen console IRQ handling. Normally this is no problem, as the evtchn_rwlock is taken as a reader in both paths, but as soon as an event channel is being closed, the lock will be taken as a writer, which will cause read_lock() to block: CPU0 CPU1 CPU2 (IRQ handling) (__hvc_poll()) (closing event channel) read_lock(evtchn_rwlock) spin_lock(hvc_lock) write_lock(evtchn_rwlock) [blocks] spin_lock(hvc_lock) [blocks] read_lock(evtchn_rwlock) [blocks due to writer waiting, and not in_interrupt()] This issue can be avoided by replacing evtchn_rwlock with RCU in xen_free_irq(). Note that RCU is used only to delay freeing of the irq_info memory. There is no RCU based dereferencing or replacement of pointers involved. In order to avoid potential races between removing the irq_info reference and handling of interrupts, set the irq_info pointer to NULL only when freeing its memory. The IRQ itself must be freed at that time, too, as otherwise the same IRQ number could be allocated again before handling of the old instance would have been finished. This is XSA-441 / CVE-2023-34324. Fixes: 54c9de89 ("xen/events: add a new "late EOI" evtchn framework") Reported-by:
Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> Signed-off-by:
Juergen Gross <jgross@suse.com> Reviewed-by:
Julien Grall <jgrall@amazon.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Eric Dumazet authored
commit c486640a upstream. rt6_check_neigh() uses read_lock() to protect n->nud_state reading. This seems overkill and causes false sharing. Signed-off-by:
Eric Dumazet <edumazet@google.com> Reviewed-by:
David Ahern <dsahern@kernel.org> Reviewed-by:
Martin KaFai Lau <martin.lau@kernel.org> Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Bernd Schubert authored
commit 9af86694 upstream. This was noticed by Miklos that file_remove_privs might call into notify_change(), which requires to hold an exclusive lock. The problem exists in FUSE and btrfs. We can fix it without any additional helpers from VFS, in case the privileges would need to be dropped, change the lock type to be exclusive and redo the loop. Fixes: e9adabb9 ("btrfs: use shared lock for direct writes within EOF") CC: Miklos Szeredi <miklos@szeredi.hu> CC: stable@vger.kernel.org # 5.15+ Reviewed-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Bernd Schubert <bschubert@ddn.com> Reviewed-by:
David Sterba <dsterba@suse.com> Signed-off-by:
David Sterba <dsterba@suse.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jakub Kicinski authored
commit c73a72f4 upstream. I've added a flex array to struct nlmsghdr in commit 738136a0 ("netlink: split up copies in the ack construction") to allow accessing the data easily. It leads to warnings with clang, if user space wraps this structure into another struct and the flex array is not at the end of the container. Reviewed-by:
Kees Cook <keescook@chromium.org> Reviewed-by:
David Ahern <dsahern@kernel.org> Link: https://lore.kernel.org/all/20221114023927.GA685@u2004-local/ Link: https://lore.kernel.org/r/20221118033903.1651026-1-kuba@kernel.org Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Filipe Manana authored
commit fee4c199 upstream. When logging a new name, we don't expect to fail joining a log transaction since we know at least one of the inodes was logged before in the current transaction. However if we fail for some unexpected reason, we end up not freeing the fscrypt name we previously allocated. So fix that by freeing the name in case we failed to join a log transaction. Fixes: ab3c5c18 ("btrfs: setup qstr from dentrys using fscrypt helper") Reviewed-by:
Sweet Tea Dorminy <sweettea-kernel@dorminy.me> Signed-off-by:
Filipe Manana <fdmanana@suse.com> Reviewed-by:
David Sterba <dsterba@suse.com> Signed-off-by:
David Sterba <dsterba@suse.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Christophe JAILLET authored
commit abe3bf74 upstream. If new_whiteout_inode() fails, some resources need to be freed. Add the missing goto to the error handling path. Fixes: ab3c5c18 ("btrfs: setup qstr from dentrys using fscrypt helper") Reviewed-by:
Sweet Tea Dorminy <sweettea-kernel@dorminy.me> Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by:
David Sterba <dsterba@suse.com> Signed-off-by:
David Sterba <dsterba@suse.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Ido Schimmel authored
commit 2033ab90 upstream. Cited commit converted the neighbour code to use the standard RCU variant instead of the RCU-bh variant, but the VRF code still uses rcu_read_lock_bh() / rcu_read_unlock_bh() around the neighbour lookup code in its IPv4 and IPv6 output paths, resulting in lockdep splats [1][2]. Can be reproduced using [3]. Fix by switching to rcu_read_lock() / rcu_read_unlock(). [1] ============================= WARNING: suspicious RCU usage 6.5.0-rc1-custom-g9c099e6dbf98 #403 Not tainted ----------------------------- include/net/neighbour.h:302 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 2 locks held by ping/183: #0: ffff888105ea1d80 (sk_lock-AF_INET){+.+.}-{0:0}, at: raw_sendmsg+0xc6c/0x33c0 #1: ffffffff85b46820 (rcu_read_lock_bh){....}-{1:2}, at: vrf_output+0x2e3/0x2030 stack backtrace: CPU: 0 PID: 183 Comm: ping Not tainted 6.5.0-rc1-custom-g9c099e6dbf98 #403 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-1.fc37 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0xc1/0xf0 lockdep_rcu_suspicious+0x211/0x3b0 vrf_output+0x1380/0x2030 ip_push_pending_frames+0x125/0x2a0 raw_sendmsg+0x200d/0x33c0 inet_sendmsg+0xa2/0xe0 __sys_sendto+0x2aa/0x420 __x64_sys_sendto+0xe5/0x1c0 do_syscall_64+0x38/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd [2] ============================= WARNING: suspicious RCU usage 6.5.0-rc1-custom-g9c099e6dbf98 #403 Not tainted ----------------------------- include/net/neighbour.h:302 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 2 locks held by ping6/182: #0: ffff888114b63000 (sk_lock-AF_INET6){+.+.}-{0:0}, at: rawv6_sendmsg+0x1602/0x3e50 #1: ffffffff85b46820 (rcu_read_lock_bh){....}-{1:2}, at: vrf_output6+0xe9/0x1310 stack backtrace: CPU: 0 PID: 182 Comm: ping6 Not tainted 6.5.0-rc1-custom-g9c099e6dbf98 #403 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-1.fc37 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0xc1/0xf0 lockdep_rcu_suspicious+0x211/0x3b0 vrf_output6+0xd32/0x1310 ip6_local_out+0xb4/0x1a0 ip6_send_skb+0xbc/0x340 ip6_push_pending_frames+0xe5/0x110 rawv6_sendmsg+0x2e6e/0x3e50 inet_sendmsg+0xa2/0xe0 __sys_sendto+0x2aa/0x420 __x64_sys_sendto+0xe5/0x1c0 do_syscall_64+0x38/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd [3] #!/bin/bash ip link add name vrf-red up numtxqueues 2 type vrf table 10 ip link add name swp1 up master vrf-red type dummy ip address add 192.0.2.1/24 dev swp1 ip address add 2001:db8:1::1/64 dev swp1 ip neigh add 192.0.2.2 lladdr 00:11:22:33:44:55 nud perm dev swp1 ip neigh add 2001:db8:1::2 lladdr 00:11:22:33:44:55 nud perm dev swp1 ip vrf exec vrf-red ping 192.0.2.2 -c 1 &> /dev/null ip vrf exec vrf-red ping6 2001:db8:1::2 -c 1 &> /dev/null Fixes: 09eed119 ("neighbour: switch to standard rcu, instead of rcu_bh") Reported-by:
Naresh Kamboju <naresh.kamboju@linaro.org> Link: https://lore.kernel.org/netdev/CA+G9fYtEr-=GbcXNDYo3XOkwR+uYgehVoDjsP0pFLUpZ_AZcyg@mail.gmail.com/ Signed-off-by:
Ido Schimmel <idosch@nvidia.com> Reviewed-by:
David Ahern <dsahern@kernel.org> Reviewed-by:
Eric Dumazet <edumazet@google.com> Link: https://lore.kernel.org/r/20230715153605.4068066-1-idosch@nvidia.com Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Eric Dumazet authored
commit ef1148d4 upstream. After blamed commit, nexthop_fib6_nh_bh() and nexthop_fib6_nh() are the same. Delete nexthop_fib6_nh_bh(), and convert /proc/net/ipv6_route to standard rcu to avoid this splat: [ 5723.180080] WARNING: suspicious RCU usage [ 5723.180083] ----------------------------- [ 5723.180084] include/net/nexthop.h:516 suspicious rcu_dereference_check() usage! [ 5723.180086] other info that might help us debug this: [ 5723.180087] rcu_scheduler_active = 2, debug_locks = 1 [ 5723.180089] 2 locks held by cat/55856: [ 5723.180091] #0: ffff9440a582afa8 (&p->lock){+.+.}-{3:3}, at: seq_read_iter (fs/seq_file.c:188) [ 5723.180100] #1: ffffffffaac07040 (rcu_read_lock_bh){....}-{1:2}, at: rcu_lock_acquire (include/linux/rcupdate.h:326) [ 5723.180109] stack backtrace: [ 5723.180111] CPU: 14 PID: 55856 Comm: cat Tainted: G S I 6.3.0-dbx-DEV #528 [ 5723.180115] Call Trace: [ 5723.180117] <TASK> [ 5723.180119] dump_stack_lvl (lib/dump_stack.c:107) [ 5723.180124] dump_stack (lib/dump_stack.c:114) [ 5723.180126] lockdep_rcu_suspicious (include/linux/context_tracking.h:122) [ 5723.180132] ipv6_route_seq_show (include/net/nexthop.h:?) [ 5723.180135] ? ipv6_route_seq_next (net/ipv6/ip6_fib.c:2605) [ 5723.180140] seq_read_iter (fs/seq_file.c:272) [ 5723.180145] seq_read (fs/seq_file.c:163) [ 5723.180151] proc_reg_read (fs/proc/inode.c:316 fs/proc/inode.c:328) [ 5723.180155] vfs_read (fs/read_write.c:468) [ 5723.180160] ? up_read (kernel/locking/rwsem.c:1617) [ 5723.180164] ksys_read (fs/read_write.c:613) [ 5723.180168] __x64_sys_read (fs/read_write.c:621) [ 5723.180170] do_syscall_64 (arch/x86/entry/common.c:?) [ 5723.180174] entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120) [ 5723.180177] RIP: 0033:0x7fa455677d2a Fixes: 09eed119 ("neighbour: switch to standard rcu, instead of rcu_bh") Reported-by:
syzbot <syzkaller@googlegroups.com> Signed-off-by:
Eric Dumazet <edumazet@google.com> Reviewed-by:
David Ahern <dsahern@kernel.org> Link: https://lore.kernel.org/r/20230510154646.370659-1-edumazet@google.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
John David Anglin authored
commit 914988e0 upstream. Back in 2005, Kyle McMartin removed the 16-byte alignment for ldcw semaphores on PA 2.0 machines (CONFIG_PA20). This broke spinlocks on pre PA8800 processors. The main symptom was random faults in mmap'd memory (e.g., gcc compilations, etc). Unfortunately, the errata for this ldcw change is lost. The issue is the 16-byte alignment required for ldcw semaphore instructions can only be reduced to natural alignment when the ldcw operation can be handled coherently in cache. Only PA8800 and PA8900 processors actually support doing the operation in cache. Aligning the spinlock dynamically adds two integer instructions to each spinlock. Tested on rp3440, c8000 and a500. Signed-off-by:
John David Anglin <dave.anglin@bell.net> Link: https://lore.kernel.org/linux-parisc/6b332788-2227-127f-ba6d-55e99ecf4ed8@bell.net/T/#t Link: https://lore.kernel.org/linux-parisc/20050609050702.GB4641@roadwarrior.mcmartin.ca/ Cc: stable@vger.kernel.org Signed-off-by:
Helge Deller <deller@gmx.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-