ggry #115

KonstantinBYvitebsk · 2014-08-21T17:17:09Z

No description provided.

[ Upstream commit 3af57f7 ] The s390 bpf jit compiler emits the signed divide instructions "dr" and "d" for unsigned divisions. This can cause problems: the dividend will be zero extended to a 64 bit value and the divisor is the 32 bit signed value as specified A or X accumulator, even though A and X are supposed to be treated as unsigned values. The divide instrunctions will generate an exception if the result cannot be expressed with a 32 bit signed value. This is the case if e.g. the dividend is 0xffffffff and the divisor either 1 or also 0xffffffff (signed: -1). To avoid all these issues simply use unsigned divide instructions. Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

…is called [ Upstream commit 11c21a3 ] commit a622260("ip_tunnel: fix kernel panic with icmp_dest_unreach") clear IPCB in ip_tunnel_xmit() , or else skb->cb[] may contain garbage from GSO segmentation layer. But commit 0e6fbc5("ip_tunnels: extend iptunnel_xmit()") refactor codes, and it clear IPCB behind the dst_link_failure(). So clear IPCB in ip_tunnel_xmit() just like commti a622260("ip_tunnel: fix kernel panic with icmp_dest_unreach"). Signed-off-by: Duan Jiong <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

[ Upstream commit d0bc655 ] Make sure the practice set by commit 0afb166 "vxlan: Add capability of Rx checksum offload for inner packet" is applied when the skb goes through the portion of the RX code which is shared between vxlan netdevices and ovs vxlan port instances. Cc: Joseph Gasparakis <[email protected]> Cc: Pravin B Shelar <[email protected]> Signed-off-by: Or Gerlitz <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

[ Upstream commit a0065f2 ] The two commits 0115e8e (net: remove delay at device dismantle) and 748e2d9 (net: reinstate rtnl in call_netdevice_notifiers()) silently removed a NULL pointer check for in_dev since Linux 3.7. This patch re-introduces this check as it causes crashing the kernel when setting small mtu values on non-ip capable netdevices. Signed-off-by: Oliver Hartkopp <[email protected]> Acked-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

[ Upstream commit a452ce3 ] I see a memory leak when using a transparent HTTP proxy using TPROXY together with TCP early demux and Kernel v3.8.13.15 (Ubuntu stable): unreferenced object 0xffff88008cba4a40 (size 1696): comm "softirq", pid 0, jiffies 4294944115 (age 8907.520s) hex dump (first 32 bytes): 0a e0 20 6a 40 04 1b 37 92 be 32 e2 e8 b4 00 00 .. [email protected]..... 02 00 07 01 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff810b710a>] kmem_cache_alloc+0xad/0xb9 [<ffffffff81270185>] sk_prot_alloc+0x29/0xc5 [<ffffffff812702cf>] sk_clone_lock+0x14/0x283 [<ffffffff812aaf3a>] inet_csk_clone_lock+0xf/0x7b [<ffffffff8129a893>] netlink_broadcast+0x14/0x16 [<ffffffff812c1573>] tcp_create_openreq_child+0x1b/0x4c3 [<ffffffff812c033e>] tcp_v4_syn_recv_sock+0x38/0x25d [<ffffffff812c13e4>] tcp_check_req+0x25c/0x3d0 [<ffffffff812bf87a>] tcp_v4_do_rcv+0x287/0x40e [<ffffffff812a08a7>] ip_route_input_noref+0x843/0xa55 [<ffffffff812bfeca>] tcp_v4_rcv+0x4c9/0x725 [<ffffffff812a26f4>] ip_local_deliver_finish+0xe9/0x154 [<ffffffff8127a927>] __netif_receive_skb+0x4b2/0x514 [<ffffffff8127aa77>] process_backlog+0xee/0x1c5 [<ffffffff8127c949>] net_rx_action+0xa7/0x200 [<ffffffff81209d86>] add_interrupt_randomness+0x39/0x157 But there are many more, resulting in the machine going OOM after some days. From looking at the TPROXY code, and with help from Florian, I see that the memory leak is introduced in tcp_v4_early_demux(): void tcp_v4_early_demux(struct sk_buff *skb) { /* ... */ iph = ip_hdr(skb); th = tcp_hdr(skb); if (th->doff < sizeof(struct tcphdr) / 4) return; sk = __inet_lookup_established(dev_net(skb->dev), &tcp_hashinfo, iph->saddr, th->source, iph->daddr, ntohs(th->dest), skb->skb_iif); if (sk) { skb->sk = sk; where the socket is assigned unconditionally to skb->sk, also bumping the refcnt on it. This is problematic, because in our case the skb has already a socket assigned in the TPROXY target. This then results in the leak I see. The very same issue seems to be with IPv6, but haven't tested. Reviewed-by: Florian Westphal <[email protected]> Signed-off-by: Holger Eitzenberger <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

[ Upstream commit cefe007 ] This patch removes grant transfer releasing code from netfront, and uses gnttab_end_foreign_access to end grant access since gnttab_end_foreign_access_ref may fail when the grant entry is currently used for reading or writing. * clean up grant transfer code kept from old netfront(2.6.18) which grants pages for access/map and transfer. But grant transfer is deprecated in current netfront, so remove corresponding release code for transfer. * fix resource leak, release grant access (through gnttab_end_foreign_access) and skb for tx/rx path, use get_page to ensure page is released when grant access is completed successfully. Xen-blkfront/xen-tpmfront/xen-pcifront also have similar issue, but patches for them will be created separately. V6: Correct subject line and commit message. V5: Remove unecessary change in xennet_end_access. V4: Revert put_page in gnttab_end_foreign_access, and keep netfront change in single patch. V3: Changes as suggestion from David Vrabel, ensure pages are not freed untill grant acess is ended. V2: Improve patch comments. Signed-off-by: Annie Li <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

[ Upstream commit c0c0c50 ] When dealing with icmp messages, the skb->data points the ip header that triggered the sending of the icmp message. In gre_cisco_err(), the parse_gre_header() is called, and the iptunnel_pull_header() is called to pull the skb at the end of the parse_gre_header(), so the skb->data doesn't point the inner ip header. Unfortunately, the ipgre_err still needs those ip addresses in inner ip header to look up tunnel by ip_tunnel_lookup(). So just use icmp_hdr() to get inner ip header instead of skb->data. Signed-off-by: Duan Jiong <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

[ Based upon upstream commit 70315d2 ] Fix inet_diag_dump_icsk() to reflect the fact that both TIME_WAIT and FIN_WAIT2 connections are represented by inet_timewait_sock (not just TIME_WAIT). Thus: (a) We need to iterate through the time_wait buckets if the user wants either TIME_WAIT or FIN_WAIT2. (Before fixing this, "ss -nemoi state fin-wait-2" would not return any sockets, even if there were some in FIN_WAIT2.) (b) We need to check tw_substate to see if the user wants to dump sockets in the particular substate (TIME_WAIT or FIN_WAIT2) that a given connection is in. (Before fixing this, "ss -nemoi state time-wait" would actually return sockets in state FIN_WAIT2.) An analogous fix is in v3.13: 70315d2 ("inet_diag: fix inet_diag_dump_icsk() to use correct state for timewait sockets") but that patch is quite different because 3.13 code is very different in this area due to the unification of TCP hash tables in 05dbc7b ("tcp/dccp: remove twchain") in v3.13-rc1. I tested that this applies cleanly between v3.3 and v3.12, and tested that it works in both 3.3 and 3.12. It does not apply cleanly to 3.2 and earlier (though it makes semantic sense), and semantically is not the right fix for 3.13 and beyond (as mentioned above). Signed-off-by: Neal Cardwell <[email protected]> Cc: Eric Dumazet <[email protected]> Acked-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 0ef38d7 upstream. The patch 3ddc5b4 breaks networking on alpha (there is a follow-up fix 5cfe8f1, but networking is still broken even with the second patch). The patch 3ddc5b4 makes csum_partial_copy_from_user check the pointer with access_ok. However, csum_partial_copy_from_user is called also from csum_partial_copy_nocheck and csum_partial_copy_nocheck is called on kernel pointers and it is supposed not to check pointer validity. This bug results in ssh session hangs if the system is loaded and bulk data are printed to ssh terminal. This patch fixes csum_partial_copy_nocheck to call set_fs(KERNEL_DS), so that access_ok in csum_partial_copy_from_user accepts kernel-space addresses. Signed-off-by: Mikulas Patocka <[email protected]> Signed-off-by: Matt Turner <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 57737c4 upstream. This commit: f8dae00: parisc: Ensure full cache coherency for kmap/kunmap caused negative caching side-effects, e.g. hanging processes with expect and too many inequivalent alias messages from flush_dcache_page() on Debian 5 systems. This patch now partly reverts it and has been in production use on our debian buildd makeservers since a week without any major problems. Signed-off-by: Helge Deller <[email protected]> Signed-off-by: John David Anglin <[email protected]> Signed-off-by: Helge Deller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 48eaef0 upstream. Signed-off-by: Andreas Schwab <[email protected]> Signed-off-by: Alexander Graf <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 70713fe upstream. Use gva_t instead of unsigned int for eaddr in deliver_tlb_miss(). Signed-off-by: Mihai Caraman <[email protected]> Signed-off-by: Alexander Graf <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit cbd209f upstream. Some old AD codecs don't like the independent HP handling, either it contains a single DAC (AD1981) or it mandates the mixer routing (AD1986A). This patch removes the indep_hp flag for such codecs. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=68081 Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

(This is a backport of *part* of upstream 611885b "ALSA: hda - hdmi: Disallow unsupported 2ch remapping on NVIDIA codecs" to stable 3.10 through 3.12. Later stable already contain all of the original patch.) Mainline commit 611885b "ALSA: hda - hdmi: Disallow unsupported 2ch remapping on NVIDIA codecs" introduces function patch_nvhdmi(). That function is edited by 75fae11 "ALSA: hda/hdmi - allow PIN_OUT to be dynamically enabled". In order to backport the PIN_OUT patch, I am first back-porting just the addition of function patch_nvhdmi(), so that the conflicts applying the PIN_OUT patch are simplified. Ideally, one might backport all of 611885b. However, that commit doesn't apply to stable kernels, since it relies on a chain of other patches which implement new features. Signed-off-by: Anssi Hannula <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> [swarren, extracted just a small part of the original patch] Signed-off-by: Stephen Warren <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

(This is upstream 75fae11 "ALSA: hda/hdmi - allow PIN_OUT to be dynamically enabled", backported to stable 3.10 through 3.12. 3.13 and later can take the original patch.) Commit 384a48d "ALSA: hda: HDMI: Support codecs with fewer cvts than pins" dynamically enabled each pin widget's PIN_OUT only when the pin was actively in use. This was required on certain NVIDIA CODECs for correct operation. Specifically, if multiple pin widgets each had their mux input select the same audio converter widget and each pin widget had PIN_OUT enabled, then only one of the pin widgets would actually receive the audio, and often not the one the user wanted! However, this apparently broke some Intel systems, and commit 6169b67 "ALSA: hda - Always turn on pins for HDMI/DP" reverted the dynamic setting of PIN_OUT. This in turn broke the afore-mentioned NVIDIA CODECs. This change supports either dynamic or static handling of PIN_OUT, selected by a flag set up during CODEC initialization. This flag is enabled for all recent NVIDIA GPUs. Reported-by: Uosis <[email protected]> Signed-off-by: Stephen Warren <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 2cbe5c7 upstream. Previously, hpfs scanned all bitmaps each time the user asked for free space using statfs. This patch changes it so that hpfs scans the bitmaps only once, remembes the free space and on next invocation of statfs it returns the value instantly. New versions of wine are hammering on the statfs syscall very heavily, making some games unplayable when they're stored on hpfs, with load times in minutes. This should be backported to the stable kernels because it fixes user-visible problem (excessive level load times in wine). Signed-off-by: Mikulas Patocka <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 83e83ec upstream. There is no need to skip querying the config and string descriptors for unauthorized WUSB devices when usb_new_device is called. It is allowed by WUSB spec. The only action that needs to be delayed until authorization time is the set config. This change allows user mode tools to see the config and string descriptors earlier in enumeration which is needed for some WUSB devices to function properly on Android systems. It also reduces the amount of divergent code paths needed for WUSB devices. Signed-off-by: Thomas Pugliese <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit dcaf9ae upstream. Bfa driver crash is observed while pushing the firmware on to chinook quad port card due to uninitialized bfi_image_ct2 access which gets initialized only for CT2 ASIC based cards after request_firmware(). For quard port chinook (CT2 ASIC based), bfi_image_ct2 is not getting initialized as there is no check for chinook PCI device ID before request_firmware and instead bfi_image_cb is initialized as it is the default case for card type check. This patch includes changes to read the right firmware for quad port chinook. Signed-off-by: Vijaya Mohan Guvva <[email protected]> Signed-off-by: James Bottomley <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit f466f75 upstream. vqs are freed in virtscsi_freeze but the hotcpu_notifier is not unregistered. We will have a use-after-free usage when the notifier callback is called after virtscsi_freeze. Fixes: 285e71e ("virtio-scsi: reset virtqueue affinity when doing cpu hotplug") Signed-off-by: Asias He <[email protected]> Reviewed-by: Paolo Bonzini <[email protected]> Signed-off-by: Jason Wang <[email protected]> Signed-off-by: Rusty Russell <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 4a4caa2 upstream. This patch addresses an traditional iscsi-target fabric ack starvation issue where iscsit_allocate_cmd() -> percpu_ida_alloc_state() ends up hitting slow path percpu-ida code, because iscsit_ack_from_expstatsn() is expected to free ack'ed tags after tag allocation. This is done to take into account the tags waiting to be acknowledged and released in iscsit_ack_from_expstatsn(), but who's number are not directly limited by the CmdSN Window queue_depth being enforced by the target. So that said, this patch bumps up the pre-allocated number of per session tags to: (max(queue_depth, ISCSIT_MIN_TAGS) * 2) + ISCSIT_EXTRA_TAGS for good measure to avoid the percpu_ida_alloc_state() slow path. Signed-off-by: Nicholas Bellinger <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit ee291e6 upstream. When creating network portals rapidly, such as when restoring a configuration, LIO's code to reuse existing portals can return a false negative if the thread hasn't run yet and set np_thread_state to ISCSI_NP_THREAD_ACTIVE. This causes an error in the network stack when attempting to bind to the same address/port. This patch sets NP_THREAD_ACTIVE before the np is placed on g_np_list, so even if the thread hasn't run yet, iscsit_get_np will return the existing np. Also, convert np_lock -> np_mutex + hold across adding new net portal to g_np_list to prevent a race where two threads may attempt to create the same network portal, resulting in one of them failing. (nab: Add missing mutex_unlocks in iscsit_add_np failure paths) (DanC: Fix incorrect spin_unlock -> spin_unlock_bh) Signed-off-by: Andy Grover <[email protected]> Signed-off-by: Nicholas Bellinger <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 90515e7 upstream. We may return early in btrfs_drop_snapshot(), we shouldn't call btrfs_std_err() for this case, fix it. Signed-off-by: Wang Shilong <[email protected]> Signed-off-by: Josef Bacik <[email protected]> Signed-off-by: Chris Mason <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit d024206 upstream. Currently, any user can snapshot any subvolume if the path is accessible and thus indirectly create and keep files he does not own under his direcotries. This is not possible with traditional directories. In security context, a user can snapshot root filesystem and pin any potentially buggy binaries, even if the updates are applied. All the snapshots are visible to the administrator, so it's possible to verify if there are suspicious snapshots. Another more practical problem is that any user can pin the space used by eg. root and cause ENOSPC. Original report: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/484786 Signed-off-by: David Sterba <[email protected]> Signed-off-by: Josef Bacik <[email protected]> Signed-off-by: Chris Mason <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit d4edc5b upstream. On POWER platforms, the hypervisor can notify the guest kernel about dynamic changes in the cpu-numa associativity (VPHN topology update). Hence the cpu-to-node mappings that we got from the firmware during boot, may no longer be valid after such updates. This is handled using the arch_update_cpu_topology() hook in the scheduler, and the sched-domains are rebuilt according to the new mappings. But unfortunately, at the moment, CPU hotplug ignores these updated mappings and instead queries the firmware for the cpu-to-numa relationships and uses them during CPU online. So the kernel can end up assigning wrong NUMA nodes to CPUs during subsequent CPU hotplug online operations (after booting). Further, a particularly problematic scenario can result from this bug: On POWER platforms, the SMT mode can be switched between 1, 2, 4 (and even 8) threads per core. The switch to Single-Threaded (ST) mode is performed by offlining all except the first CPU thread in each core. Switching back to SMT mode involves onlining those other threads back, in each core. Now consider this scenario: 1. During boot, the kernel gets the cpu-to-node mappings from the firmware and assigns the CPUs to NUMA nodes appropriately, during CPU online. 2. Later on, the hypervisor updates the cpu-to-node mappings dynamically and communicates this update to the kernel. The kernel in turn updates its cpu-to-node associations and rebuilds its sched domains. Everything is fine so far. 3. Now, the user switches the machine from SMT to ST mode (say, by running ppc64_cpu --smt=1). This involves offlining all except 1 thread in each core. 4. The user then tries to switch back from ST to SMT mode (say, by running ppc64_cpu --smt=4), and this involves onlining those threads back. Since CPU hotplug ignores the new mappings, it queries the firmware and tries to associate the newly onlined sibling threads to the old NUMA nodes. This results in sibling threads within the same core getting associated with different NUMA nodes, which is incorrect. The scheduler's build-sched-domains code gets thoroughly confused with this and enters an infinite loop and causes soft-lockups, as explained in detail in commit 3be7db6 (powerpc: VPHN topology change updates all siblings). So to fix this, use the numa_cpu_lookup_table to remember the updated cpu-to-node mappings, and use them during CPU hotplug online operations. Further, we also need to ensure that all threads in a core are assigned to a common NUMA node, irrespective of whether all those threads were online during the topology update. To achieve this, we take care not to use cpu_sibling_mask() since it is not hotplug invariant. Instead, we use cpu_first_sibling_thread() and set up the mappings manually using the 'threads_per_core' value for that particular platform. This helps us ensure that we don't hit this bug with any combination of CPU hotplug and SMT mode switching. Signed-off-by: Srivatsa S. Bhat <[email protected]> Signed-off-by: Benjamin Herrenschmidt <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 91b973f upstream. The code in remove_cache_dir() is supposed to remove the "cache" subdirectory from the sysfs directory for a CPU when that CPU is being offlined. It tries to do this by calling kobject_put() on the kobject for the subdirectory. However, the subdirectory only gets removed once the last reference goes away, and the reference being put here may well not be the last reference. That means that the "cache" subdirectory may still exist when the offlining operation has finished. If the same CPU subsequently gets onlined, the code tries to add a new "cache" subdirectory. If the old subdirectory has not yet been removed, we get a WARN_ON in the sysfs code, with stack trace, and an error message printed on the console. Further, we ultimately end up with an online cpu with no "cache" subdirectory. This fixes it by doing an explicit kobject_del() at the point where we want the subdirectory to go away. kobject_del() removes the sysfs directory even though the object still exists in memory. The object will get freed at some point in the future. A subsequent onlining operation can create a new sysfs directory, even if the old object still exists in memory, without causing any problems. Signed-off-by: Paul Mackerras <[email protected]> Signed-off-by: Benjamin Herrenschmidt <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 3b56496 upstream. This adds the workaround for erratum 793 as a precaution in case not every BIOS implements it. This addresses CVE-2013-6885. Erratum text: [Revision Guide for AMD Family 16h Models 00h-0Fh Processors, document 51810 Rev. 3.04 November 2013] 793 Specific Combination of Writes to Write Combined Memory Types and Locked Instructions May Cause Core Hang Description Under a highly specific and detailed set of internal timing conditions, a locked instruction may trigger a timing sequence whereby the write to a write combined memory type is not flushed, causing the locked instruction to stall indefinitely. Potential Effect on System Processor core hang. Suggested Workaround BIOS should set MSR C001_1020[15] = 1b. Fix Planned No fix planned [ hpa: updated description, fixed typo in MSR name ] Signed-off-by: Borislav Petkov <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Tested-by: Aravind Gopalakrishnan <[email protected]> Signed-off-by: H. Peter Anvin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 8ed8146 upstream. Hello. I got below leak with linux-3.10.0-54.0.1.el7.x86_64 . [ 681.903890] kmemleak: 5538 new suspected memory leaks (see /sys/kernel/debug/kmemleak) Below is a patch, but I don't know whether we need special handing for undoing ebitmap_set_bit() call. ---------- >>From fe97527a90fe95e2239dfbaa7558f0ed559c0992 Mon Sep 17 00:00:00 2001 From: Tetsuo Handa <[email protected]> Date: Mon, 6 Jan 2014 16:30:21 +0900 Subject: SELinux: Fix memory leak upon loading policy Commit 2463c26 "SELinux: put name based create rules in a hashtable" did not check return value from hashtab_insert() in filename_trans_read(). It leaks memory if hashtab_insert() returns error. unreferenced object 0xffff88005c9160d0 (size 8): comm "systemd", pid 1, jiffies 4294688674 (age 235.265s) hex dump (first 8 bytes): 57 0b 00 00 6b 6b 6b a5 W...kkk. backtrace: [<ffffffff816604ae>] kmemleak_alloc+0x4e/0xb0 [<ffffffff811cba5e>] kmem_cache_alloc_trace+0x12e/0x360 [<ffffffff812aec5d>] policydb_read+0xd1d/0xf70 [<ffffffff812b345c>] security_load_policy+0x6c/0x500 [<ffffffff812a623c>] sel_write_load+0xac/0x750 [<ffffffff811eb680>] vfs_write+0xc0/0x1f0 [<ffffffff811ec08c>] SyS_write+0x4c/0xa0 [<ffffffff81690419>] system_call_fastpath+0x16/0x1b [<ffffffffffffffff>] 0xffffffffffffffff However, we should not return EEXIST error to the caller, or the systemd will show below message and the boot sequence freezes. systemd[1]: Failed to load SELinux policy. Freezing. Signed-off-by: Tetsuo Handa <[email protected]> Acked-by: Eric Paris <[email protected]> Signed-off-by: Paul Moore <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit dced341 upstream. The trace buffer has a descriptor pointer that goes back to the trace array. But it was never assigned. Luckily, nothing uses it (yet), but it will in the future. Although nothing currently uses this, if any of the new features get backported to older kernels, and because this is such a simple change, I'm marking it for stable too. Fixes: 12883ef "tracing: Consolidate max_tr into main trace_array structure" Signed-off-by: Steven Rostedt <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 3132e10 upstream. If trace_puts() is used very early in boot up, it can crash the machine if it is called before the ring buffer is allocated. If a trace_printk() is used with no arguments, then it will be converted into a trace_puts() and suffer the same fate. Fixes: 09ae723 "tracing: Add trace_puts() for even faster trace_printk() tracing" Signed-off-by: Steven Rostedt <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

Commit c14f7cc ("PCI: Assign PCI domain IDs by ida_alloc()") introduced a use-after-free bug in the bus removal cleanup. The issue was found with kfence: [ 19.285870] ================================================================== [ 19.293351] BUG: KFENCE: use-after-free read in pci_bus_release_domain_nr+0x10/0x70 [ 19.302817] Use-after-free read at 0x000000007f3b80eb (in kfence-torvalds#115): [ 19.309677] pci_bus_release_domain_nr+0x10/0x70 [ 19.309691] dw_pcie_host_deinit+0x28/0x78 [ 19.309702] tegra_pcie_deinit_controller+0x1c/0x38 [pcie_tegra194] [ 19.309734] tegra_pcie_dw_probe+0x648/0xb28 [pcie_tegra194] [ 19.309752] platform_probe+0x90/0xd8 [ 19.309764] really_probe+0xb8/0x298 [ 19.309777] __driver_probe_device+0x78/0xd8 [ 19.309788] driver_probe_device+0x38/0x120 [ 19.309799] __device_attach_driver+0x94/0xe0 [ 19.309812] bus_for_each_drv+0x70/0xc8 [ 19.309822] __device_attach+0xfc/0x188 [ 19.309833] device_initial_probe+0x10/0x18 [ 19.309844] bus_probe_device+0x94/0xa0 [ 19.309854] deferred_probe_work_func+0x80/0xb8 [ 19.309864] process_one_work+0x1e0/0x348 [ 19.309882] worker_thread+0x48/0x410 [ 19.309891] kthread+0xf4/0x110 [ 19.309904] ret_from_fork+0x10/0x20 [ 19.311457] kfence-torvalds#115: 0x00000000063a155a-0x00000000ba698da8, size=1072, cache=kmalloc-2k [ 19.311469] allocated by task 96 on cpu 10 at 19.279323s: [ 19.311562] __kmem_cache_alloc_node+0x260/0x278 [ 19.311571] kmalloc_trace+0x24/0x30 [ 19.311580] pci_alloc_bus+0x24/0xa0 [ 19.311590] pci_register_host_bridge+0x48/0x4b8 [ 19.311601] pci_scan_root_bus_bridge+0xc0/0xe8 [ 19.311613] pci_host_probe+0x18/0xc0 [ 19.311623] dw_pcie_host_init+0x2c0/0x568 [ 19.311630] tegra_pcie_dw_probe+0x610/0xb28 [pcie_tegra194] [ 19.311647] platform_probe+0x90/0xd8 [ 19.311653] really_probe+0xb8/0x298 [ 19.311663] __driver_probe_device+0x78/0xd8 [ 19.311672] driver_probe_device+0x38/0x120 [ 19.311682] __device_attach_driver+0x94/0xe0 [ 19.311694] bus_for_each_drv+0x70/0xc8 [ 19.311702] __device_attach+0xfc/0x188 [ 19.311713] device_initial_probe+0x10/0x18 [ 19.311724] bus_probe_device+0x94/0xa0 [ 19.311733] deferred_probe_work_func+0x80/0xb8 [ 19.311743] process_one_work+0x1e0/0x348 [ 19.311753] worker_thread+0x48/0x410 [ 19.311763] kthread+0xf4/0x110 [ 19.311771] ret_from_fork+0x10/0x20 [ 19.311782] freed by task 96 on cpu 10 at 19.285833s: [ 19.311799] release_pcibus_dev+0x30/0x40 [ 19.311808] device_release+0x30/0x90 [ 19.311814] kobject_put+0xa8/0x120 [ 19.311832] device_unregister+0x20/0x30 [ 19.311839] pci_remove_bus+0x78/0x88 [ 19.311850] pci_remove_root_bus+0x5c/0x98 [ 19.311860] dw_pcie_host_deinit+0x28/0x78 [ 19.311866] tegra_pcie_deinit_controller+0x1c/0x38 [pcie_tegra194] [ 19.311883] tegra_pcie_dw_probe+0x648/0xb28 [pcie_tegra194] [ 19.311900] platform_probe+0x90/0xd8 [ 19.311906] really_probe+0xb8/0x298 [ 19.311916] __driver_probe_device+0x78/0xd8 [ 19.311926] driver_probe_device+0x38/0x120 [ 19.311936] __device_attach_driver+0x94/0xe0 [ 19.311947] bus_for_each_drv+0x70/0xc8 [ 19.311956] __device_attach+0xfc/0x188 [ 19.311966] device_initial_probe+0x10/0x18 [ 19.311976] bus_probe_device+0x94/0xa0 [ 19.311985] deferred_probe_work_func+0x80/0xb8 [ 19.311995] process_one_work+0x1e0/0x348 [ 19.312005] worker_thread+0x48/0x410 [ 19.312014] kthread+0xf4/0x110 [ 19.312022] ret_from_fork+0x10/0x20 [ 19.313579] CPU: 10 PID: 96 Comm: kworker/u24:2 Not tainted 6.2.0 #4 [ 19.320171] Hardware name: /, BIOS 1.0-d7fb19b 08/10/2022 [ 19.325852] Workqueue: events_unbound deferred_probe_work_func [ 19.331919] ================================================================== The stack trace is a bit misleading as dw_pcie_host_deinit() doesn't directly call pci_bus_release_domain_nr(). The issue turns out to be in pci_remove_root_bus() which first calls pci_remove_bus() which frees the struct pci_bus when its struct device is released. Then pci_bus_release_domain_nr() is called and accesses the freed struct pci_bus. Reordering these fixes the issue. Fixes: c14f7cc ("PCI: Assign PCI domain IDs by ida_alloc()") Reported-by: Jon Hunter <[email protected]> Tested-by: Jon Hunter <[email protected]> Cc: Pali Rohár <[email protected]> Signed-off-by: Rob Herring <[email protected]>

Commit c14f7cc ("PCI: Assign PCI domain IDs by ida_alloc()") introduced a use-after-free bug in the bus removal cleanup. The issue was found with kfence: [ 19.293351] BUG: KFENCE: use-after-free read in pci_bus_release_domain_nr+0x10/0x70 [ 19.302817] Use-after-free read at 0x000000007f3b80eb (in kfence-torvalds#115): [ 19.309677] pci_bus_release_domain_nr+0x10/0x70 [ 19.309691] dw_pcie_host_deinit+0x28/0x78 [ 19.309702] tegra_pcie_deinit_controller+0x1c/0x38 [pcie_tegra194] [ 19.309734] tegra_pcie_dw_probe+0x648/0xb28 [pcie_tegra194] [ 19.309752] platform_probe+0x90/0xd8 ... [ 19.311457] kfence-torvalds#115: 0x00000000063a155a-0x00000000ba698da8, size=1072, cache=kmalloc-2k [ 19.311469] allocated by task 96 on cpu 10 at 19.279323s: [ 19.311562] __kmem_cache_alloc_node+0x260/0x278 [ 19.311571] kmalloc_trace+0x24/0x30 [ 19.311580] pci_alloc_bus+0x24/0xa0 [ 19.311590] pci_register_host_bridge+0x48/0x4b8 [ 19.311601] pci_scan_root_bus_bridge+0xc0/0xe8 [ 19.311613] pci_host_probe+0x18/0xc0 [ 19.311623] dw_pcie_host_init+0x2c0/0x568 [ 19.311630] tegra_pcie_dw_probe+0x610/0xb28 [pcie_tegra194] [ 19.311647] platform_probe+0x90/0xd8 ... [ 19.311782] freed by task 96 on cpu 10 at 19.285833s: [ 19.311799] release_pcibus_dev+0x30/0x40 [ 19.311808] device_release+0x30/0x90 [ 19.311814] kobject_put+0xa8/0x120 [ 19.311832] device_unregister+0x20/0x30 [ 19.311839] pci_remove_bus+0x78/0x88 [ 19.311850] pci_remove_root_bus+0x5c/0x98 [ 19.311860] dw_pcie_host_deinit+0x28/0x78 [ 19.311866] tegra_pcie_deinit_controller+0x1c/0x38 [pcie_tegra194] [ 19.311883] tegra_pcie_dw_probe+0x648/0xb28 [pcie_tegra194] [ 19.311900] platform_probe+0x90/0xd8 ... [ 19.313579] CPU: 10 PID: 96 Comm: kworker/u24:2 Not tainted 6.2.0 #4 [ 19.320171] Hardware name: /, BIOS 1.0-d7fb19b 08/10/2022 [ 19.325852] Workqueue: events_unbound deferred_probe_work_func The stack trace is a bit misleading as dw_pcie_host_deinit() doesn't directly call pci_bus_release_domain_nr(). The issue turns out to be in pci_remove_root_bus() which first calls pci_remove_bus() which frees the struct pci_bus when its struct device is released. Then pci_bus_release_domain_nr() is called and accesses the freed struct pci_bus. Reordering these fixes the issue. Fixes: c14f7cc ("PCI: Assign PCI domain IDs by ida_alloc()") Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected] Reported-by: Jon Hunter <[email protected]> Tested-by: Jon Hunter <[email protected]> Signed-off-by: Rob Herring <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Kuppuswamy Sathyanarayanan <[email protected]> Cc: [email protected] # v6.2+ Cc: Pali Rohár <[email protected]>

commit 30ba2d0 upstream. Commit c14f7cc ("PCI: Assign PCI domain IDs by ida_alloc()") introduced a use-after-free bug in the bus removal cleanup. The issue was found with kfence: [ 19.293351] BUG: KFENCE: use-after-free read in pci_bus_release_domain_nr+0x10/0x70 [ 19.302817] Use-after-free read at 0x000000007f3b80eb (in kfence-torvalds#115): [ 19.309677] pci_bus_release_domain_nr+0x10/0x70 [ 19.309691] dw_pcie_host_deinit+0x28/0x78 [ 19.309702] tegra_pcie_deinit_controller+0x1c/0x38 [pcie_tegra194] [ 19.309734] tegra_pcie_dw_probe+0x648/0xb28 [pcie_tegra194] [ 19.309752] platform_probe+0x90/0xd8 ... [ 19.311457] kfence-torvalds#115: 0x00000000063a155a-0x00000000ba698da8, size=1072, cache=kmalloc-2k [ 19.311469] allocated by task 96 on cpu 10 at 19.279323s: [ 19.311562] __kmem_cache_alloc_node+0x260/0x278 [ 19.311571] kmalloc_trace+0x24/0x30 [ 19.311580] pci_alloc_bus+0x24/0xa0 [ 19.311590] pci_register_host_bridge+0x48/0x4b8 [ 19.311601] pci_scan_root_bus_bridge+0xc0/0xe8 [ 19.311613] pci_host_probe+0x18/0xc0 [ 19.311623] dw_pcie_host_init+0x2c0/0x568 [ 19.311630] tegra_pcie_dw_probe+0x610/0xb28 [pcie_tegra194] [ 19.311647] platform_probe+0x90/0xd8 ... [ 19.311782] freed by task 96 on cpu 10 at 19.285833s: [ 19.311799] release_pcibus_dev+0x30/0x40 [ 19.311808] device_release+0x30/0x90 [ 19.311814] kobject_put+0xa8/0x120 [ 19.311832] device_unregister+0x20/0x30 [ 19.311839] pci_remove_bus+0x78/0x88 [ 19.311850] pci_remove_root_bus+0x5c/0x98 [ 19.311860] dw_pcie_host_deinit+0x28/0x78 [ 19.311866] tegra_pcie_deinit_controller+0x1c/0x38 [pcie_tegra194] [ 19.311883] tegra_pcie_dw_probe+0x648/0xb28 [pcie_tegra194] [ 19.311900] platform_probe+0x90/0xd8 ... [ 19.313579] CPU: 10 PID: 96 Comm: kworker/u24:2 Not tainted 6.2.0 #4 [ 19.320171] Hardware name: /, BIOS 1.0-d7fb19b 08/10/2022 [ 19.325852] Workqueue: events_unbound deferred_probe_work_func The stack trace is a bit misleading as dw_pcie_host_deinit() doesn't directly call pci_bus_release_domain_nr(). The issue turns out to be in pci_remove_root_bus() which first calls pci_remove_bus() which frees the struct pci_bus when its struct device is released. Then pci_bus_release_domain_nr() is called and accesses the freed struct pci_bus. Reordering these fixes the issue. Fixes: c14f7cc ("PCI: Assign PCI domain IDs by ida_alloc()") Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected] Reported-by: Jon Hunter <[email protected]> Tested-by: Jon Hunter <[email protected]> Signed-off-by: Rob Herring <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Kuppuswamy Sathyanarayanan <[email protected]> Cc: [email protected] # v6.2+ Cc: Pali Rohár <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

Commit c14f7cc ("PCI: Assign PCI domain IDs by ida_alloc()") introduced a use-after-free bug in the bus removal cleanup. The issue was found with kfence: [ 19.293351] BUG: KFENCE: use-after-free read in pci_bus_release_domain_nr+0x10/0x70 [ 19.302817] Use-after-free read at 0x000000007f3b80eb (in kfence-torvalds#115): [ 19.309677] pci_bus_release_domain_nr+0x10/0x70 [ 19.309691] dw_pcie_host_deinit+0x28/0x78 [ 19.309702] tegra_pcie_deinit_controller+0x1c/0x38 [pcie_tegra194] [ 19.309734] tegra_pcie_dw_probe+0x648/0xb28 [pcie_tegra194] [ 19.309752] platform_probe+0x90/0xd8 ... [ 19.311457] kfence-torvalds#115: 0x00000000063a155a-0x00000000ba698da8, size=1072, cache=kmalloc-2k [ 19.311469] allocated by task 96 on cpu 10 at 19.279323s: [ 19.311562] __kmem_cache_alloc_node+0x260/0x278 [ 19.311571] kmalloc_trace+0x24/0x30 [ 19.311580] pci_alloc_bus+0x24/0xa0 [ 19.311590] pci_register_host_bridge+0x48/0x4b8 [ 19.311601] pci_scan_root_bus_bridge+0xc0/0xe8 [ 19.311613] pci_host_probe+0x18/0xc0 [ 19.311623] dw_pcie_host_init+0x2c0/0x568 [ 19.311630] tegra_pcie_dw_probe+0x610/0xb28 [pcie_tegra194] [ 19.311647] platform_probe+0x90/0xd8 ... [ 19.311782] freed by task 96 on cpu 10 at 19.285833s: [ 19.311799] release_pcibus_dev+0x30/0x40 [ 19.311808] device_release+0x30/0x90 [ 19.311814] kobject_put+0xa8/0x120 [ 19.311832] device_unregister+0x20/0x30 [ 19.311839] pci_remove_bus+0x78/0x88 [ 19.311850] pci_remove_root_bus+0x5c/0x98 [ 19.311860] dw_pcie_host_deinit+0x28/0x78 [ 19.311866] tegra_pcie_deinit_controller+0x1c/0x38 [pcie_tegra194] [ 19.311883] tegra_pcie_dw_probe+0x648/0xb28 [pcie_tegra194] [ 19.311900] platform_probe+0x90/0xd8 ... [ 19.313579] CPU: 10 PID: 96 Comm: kworker/u24:2 Not tainted 6.2.0 #4 [ 19.320171] Hardware name: /, BIOS 1.0-d7fb19b 08/10/2022 [ 19.325852] Workqueue: events_unbound deferred_probe_work_func The stack trace is a bit misleading as dw_pcie_host_deinit() doesn't directly call pci_bus_release_domain_nr(). The issue turns out to be in pci_remove_root_bus() which first calls pci_remove_bus() which frees the struct pci_bus when its struct device is released. Then pci_bus_release_domain_nr() is called and accesses the freed struct pci_bus. Reordering these fixes the issue. Fixes: c14f7cc ("PCI: Assign PCI domain IDs by ida_alloc()") Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected] Reported-by: Jon Hunter <[email protected]> Tested-by: Jon Hunter <[email protected]> Signed-off-by: Rob Herring <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Kuppuswamy Sathyanarayanan <[email protected]> Cc: [email protected] # v6.2+ Cc: Pali Rohár <[email protected]>

commit 30ba2d0 upstream. Commit c14f7cc ("PCI: Assign PCI domain IDs by ida_alloc()") introduced a use-after-free bug in the bus removal cleanup. The issue was found with kfence: [ 19.293351] BUG: KFENCE: use-after-free read in pci_bus_release_domain_nr+0x10/0x70 [ 19.302817] Use-after-free read at 0x000000007f3b80eb (in kfence-torvalds#115): [ 19.309677] pci_bus_release_domain_nr+0x10/0x70 [ 19.309691] dw_pcie_host_deinit+0x28/0x78 [ 19.309702] tegra_pcie_deinit_controller+0x1c/0x38 [pcie_tegra194] [ 19.309734] tegra_pcie_dw_probe+0x648/0xb28 [pcie_tegra194] [ 19.309752] platform_probe+0x90/0xd8 ... [ 19.311457] kfence-torvalds#115: 0x00000000063a155a-0x00000000ba698da8, size=1072, cache=kmalloc-2k [ 19.311469] allocated by task 96 on cpu 10 at 19.279323s: [ 19.311562] __kmem_cache_alloc_node+0x260/0x278 [ 19.311571] kmalloc_trace+0x24/0x30 [ 19.311580] pci_alloc_bus+0x24/0xa0 [ 19.311590] pci_register_host_bridge+0x48/0x4b8 [ 19.311601] pci_scan_root_bus_bridge+0xc0/0xe8 [ 19.311613] pci_host_probe+0x18/0xc0 [ 19.311623] dw_pcie_host_init+0x2c0/0x568 [ 19.311630] tegra_pcie_dw_probe+0x610/0xb28 [pcie_tegra194] [ 19.311647] platform_probe+0x90/0xd8 ... [ 19.311782] freed by task 96 on cpu 10 at 19.285833s: [ 19.311799] release_pcibus_dev+0x30/0x40 [ 19.311808] device_release+0x30/0x90 [ 19.311814] kobject_put+0xa8/0x120 [ 19.311832] device_unregister+0x20/0x30 [ 19.311839] pci_remove_bus+0x78/0x88 [ 19.311850] pci_remove_root_bus+0x5c/0x98 [ 19.311860] dw_pcie_host_deinit+0x28/0x78 [ 19.311866] tegra_pcie_deinit_controller+0x1c/0x38 [pcie_tegra194] [ 19.311883] tegra_pcie_dw_probe+0x648/0xb28 [pcie_tegra194] [ 19.311900] platform_probe+0x90/0xd8 ... [ 19.313579] CPU: 10 PID: 96 Comm: kworker/u24:2 Not tainted 6.2.0 #4 [ 19.320171] Hardware name: /, BIOS 1.0-d7fb19b 08/10/2022 [ 19.325852] Workqueue: events_unbound deferred_probe_work_func The stack trace is a bit misleading as dw_pcie_host_deinit() doesn't directly call pci_bus_release_domain_nr(). The issue turns out to be in pci_remove_root_bus() which first calls pci_remove_bus() which frees the struct pci_bus when its struct device is released. Then pci_bus_release_domain_nr() is called and accesses the freed struct pci_bus. Reordering these fixes the issue. Fixes: c14f7cc ("PCI: Assign PCI domain IDs by ida_alloc()") Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected] Reported-by: Jon Hunter <[email protected]> Tested-by: Jon Hunter <[email protected]> Signed-off-by: Rob Herring <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Kuppuswamy Sathyanarayanan <[email protected]> Cc: [email protected] # v6.2+ Cc: Pali Rohár <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

Commit c14f7cc ("PCI: Assign PCI domain IDs by ida_alloc()") introduced a use-after-free bug in the bus removal cleanup. The issue was found with kfence: [ 19.293351] BUG: KFENCE: use-after-free read in pci_bus_release_domain_nr+0x10/0x70 [ 19.302817] Use-after-free read at 0x000000007f3b80eb (in kfence-torvalds#115): [ 19.309677] pci_bus_release_domain_nr+0x10/0x70 [ 19.309691] dw_pcie_host_deinit+0x28/0x78 [ 19.309702] tegra_pcie_deinit_controller+0x1c/0x38 [pcie_tegra194] [ 19.309734] tegra_pcie_dw_probe+0x648/0xb28 [pcie_tegra194] [ 19.309752] platform_probe+0x90/0xd8 ... [ 19.311457] kfence-torvalds#115: 0x00000000063a155a-0x00000000ba698da8, size=1072, cache=kmalloc-2k [ 19.311469] allocated by task 96 on cpu 10 at 19.279323s: [ 19.311562] __kmem_cache_alloc_node+0x260/0x278 [ 19.311571] kmalloc_trace+0x24/0x30 [ 19.311580] pci_alloc_bus+0x24/0xa0 [ 19.311590] pci_register_host_bridge+0x48/0x4b8 [ 19.311601] pci_scan_root_bus_bridge+0xc0/0xe8 [ 19.311613] pci_host_probe+0x18/0xc0 [ 19.311623] dw_pcie_host_init+0x2c0/0x568 [ 19.311630] tegra_pcie_dw_probe+0x610/0xb28 [pcie_tegra194] [ 19.311647] platform_probe+0x90/0xd8 ... [ 19.311782] freed by task 96 on cpu 10 at 19.285833s: [ 19.311799] release_pcibus_dev+0x30/0x40 [ 19.311808] device_release+0x30/0x90 [ 19.311814] kobject_put+0xa8/0x120 [ 19.311832] device_unregister+0x20/0x30 [ 19.311839] pci_remove_bus+0x78/0x88 [ 19.311850] pci_remove_root_bus+0x5c/0x98 [ 19.311860] dw_pcie_host_deinit+0x28/0x78 [ 19.311866] tegra_pcie_deinit_controller+0x1c/0x38 [pcie_tegra194] [ 19.311883] tegra_pcie_dw_probe+0x648/0xb28 [pcie_tegra194] [ 19.311900] platform_probe+0x90/0xd8 ... [ 19.313579] CPU: 10 PID: 96 Comm: kworker/u24:2 Not tainted 6.2.0 #4 [ 19.320171] Hardware name: /, BIOS 1.0-d7fb19b 08/10/2022 [ 19.325852] Workqueue: events_unbound deferred_probe_work_func The stack trace is a bit misleading as dw_pcie_host_deinit() doesn't directly call pci_bus_release_domain_nr(). The issue turns out to be in pci_remove_root_bus() which first calls pci_remove_bus() which frees the struct pci_bus when its struct device is released. Then pci_bus_release_domain_nr() is called and accesses the freed struct pci_bus. Reordering these fixes the issue. Fixes: c14f7cc ("PCI: Assign PCI domain IDs by ida_alloc()") Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected] Reported-by: Jon Hunter <[email protected]> Tested-by: Jon Hunter <[email protected]> Signed-off-by: Rob Herring <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Kuppuswamy Sathyanarayanan <[email protected]> Cc: [email protected] # v6.2+ Cc: Pali Rohár <[email protected]>

This test add and remove a underlying disk to raid concurretly, verify that the following problem is fixed: run mdadm test 23rdev-lifetime at Fri Apr 28 03:25:30 UTC 2023 md: could not open device unknown-block(1,0). sysfs: cannot create duplicate filename '/devices/virtual/block/md0/md/dev-ram0' CPU: 26 PID: 10521 Comm: test Not tainted 6.3.0-rc2-00134-g7b3a8828043c torvalds#115 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/014 Call Trace: <TASK> dump_stack_lvl+0xe7/0x180 dump_stack+0x18/0x30 sysfs_warn_dup+0xa2/0xd0 sysfs_create_dir_ns+0x119/0x140 kobject_add_internal+0x143/0x4d0 kobject_add_varg+0x35/0x70 kobject_add+0x64/0xd0 bind_rdev_to_array+0x254/0x840 [md_mod] new_dev_store+0x14d/0x350 [md_mod] md_attr_store+0xc1/0x1a0 [md_mod] sysfs_kf_write+0x51/0x70 kernfs_fop_write_iter+0x188/0x270 vfs_write+0x27e/0x460 ksys_write+0x85/0x180 __x64_sys_write+0x21/0x30 do_syscall_64+0x6c/0xe0 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f26bacf5387 Code: 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 84 RSP: 002b:00007ffe98d79e68 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007f26bacf5387 RDX: 0000000000000004 RSI: 000055bd10282bf0 RDI: 0000000000000001 RBP: 000055bd10282bf0 R08: 000000000000000a R09: 00007f26bad8b4e0 R10: 00007f26bad8b3e0 R11: 0000000000000246 R12: 0000000000000004 R13: 00007f26badc8520 R14: 0000000000000004 R15: 00007f26badc8700 </TASK> Signed-off-by: Yu Kuai <[email protected]>

Enable CPU v4 instruction tests for arm64. Below are the test results from BPF test_progs selftests: # ./test_progs -t ldsx_insn,verifier_sdiv,verifier_movsx,verifier_ldsx,verifier_gotol,verifier_bswap torvalds#115/1 ldsx_insn/map_val and probed_memory:OK torvalds#115/2 ldsx_insn/ctx_member_sign_ext:OK torvalds#115/3 ldsx_insn/ctx_member_narrow_sign_ext:OK torvalds#115 ldsx_insn:OK torvalds#302/1 verifier_bswap/BSWAP, 16:OK torvalds#302/2 verifier_bswap/BSWAP, 16 @unpriv:OK torvalds#302/3 verifier_bswap/BSWAP, 32:OK torvalds#302/4 verifier_bswap/BSWAP, 32 @unpriv:OK torvalds#302/5 verifier_bswap/BSWAP, 64:OK torvalds#302/6 verifier_bswap/BSWAP, 64 @unpriv:OK torvalds#302 verifier_bswap:OK torvalds#316/1 verifier_gotol/gotol, small_imm:OK torvalds#316/2 verifier_gotol/gotol, small_imm @unpriv:OK torvalds#316 verifier_gotol:OK torvalds#324/1 verifier_ldsx/LDSX, S8:OK torvalds#324/2 verifier_ldsx/LDSX, S8 @unpriv:OK torvalds#324/3 verifier_ldsx/LDSX, S16:OK torvalds#324/4 verifier_ldsx/LDSX, S16 @unpriv:OK torvalds#324/5 verifier_ldsx/LDSX, S32:OK torvalds#324/6 verifier_ldsx/LDSX, S32 @unpriv:OK torvalds#324/7 verifier_ldsx/LDSX, S8 range checking, privileged:OK torvalds#324/8 verifier_ldsx/LDSX, S16 range checking:OK torvalds#324/9 verifier_ldsx/LDSX, S16 range checking @unpriv:OK torvalds#324/10 verifier_ldsx/LDSX, S32 range checking:OK torvalds#324/11 verifier_ldsx/LDSX, S32 range checking @unpriv:OK torvalds#324 verifier_ldsx:OK torvalds#335/1 verifier_movsx/MOV32SX, S8:OK torvalds#335/2 verifier_movsx/MOV32SX, S8 @unpriv:OK torvalds#335/3 verifier_movsx/MOV32SX, S16:OK torvalds#335/4 verifier_movsx/MOV32SX, S16 @unpriv:OK torvalds#335/5 verifier_movsx/MOV64SX, S8:OK torvalds#335/6 verifier_movsx/MOV64SX, S8 @unpriv:OK torvalds#335/7 verifier_movsx/MOV64SX, S16:OK torvalds#335/8 verifier_movsx/MOV64SX, S16 @unpriv:OK torvalds#335/9 verifier_movsx/MOV64SX, S32:OK torvalds#335/10 verifier_movsx/MOV64SX, S32 @unpriv:OK torvalds#335/11 verifier_movsx/MOV32SX, S8, range_check:OK torvalds#335/12 verifier_movsx/MOV32SX, S8, range_check @unpriv:OK torvalds#335/13 verifier_movsx/MOV32SX, S16, range_check:OK torvalds#335/14 verifier_movsx/MOV32SX, S16, range_check @unpriv:OK torvalds#335/15 verifier_movsx/MOV32SX, S16, range_check 2:OK torvalds#335/16 verifier_movsx/MOV32SX, S16, range_check 2 @unpriv:OK torvalds#335/17 verifier_movsx/MOV64SX, S8, range_check:OK torvalds#335/18 verifier_movsx/MOV64SX, S8, range_check @unpriv:OK torvalds#335/19 verifier_movsx/MOV64SX, S16, range_check:OK torvalds#335/20 verifier_movsx/MOV64SX, S16, range_check @unpriv:OK torvalds#335/21 verifier_movsx/MOV64SX, S32, range_check:OK torvalds#335/22 verifier_movsx/MOV64SX, S32, range_check @unpriv:OK torvalds#335/23 verifier_movsx/MOV64SX, S16, R10 Sign Extension:OK torvalds#335/24 verifier_movsx/MOV64SX, S16, R10 Sign Extension @unpriv:OK torvalds#335 verifier_movsx:OK torvalds#347/1 verifier_sdiv/SDIV32, non-zero imm divisor, check 1:OK torvalds#347/2 verifier_sdiv/SDIV32, non-zero imm divisor, check 1 @unpriv:OK torvalds#347/3 verifier_sdiv/SDIV32, non-zero imm divisor, check 2:OK torvalds#347/4 verifier_sdiv/SDIV32, non-zero imm divisor, check 2 @unpriv:OK torvalds#347/5 verifier_sdiv/SDIV32, non-zero imm divisor, check 3:OK torvalds#347/6 verifier_sdiv/SDIV32, non-zero imm divisor, check 3 @unpriv:OK torvalds#347/7 verifier_sdiv/SDIV32, non-zero imm divisor, check 4:OK torvalds#347/8 verifier_sdiv/SDIV32, non-zero imm divisor, check 4 @unpriv:OK torvalds#347/9 verifier_sdiv/SDIV32, non-zero imm divisor, check 5:OK torvalds#347/10 verifier_sdiv/SDIV32, non-zero imm divisor, check 5 @unpriv:OK torvalds#347/11 verifier_sdiv/SDIV32, non-zero imm divisor, check 6:OK torvalds#347/12 verifier_sdiv/SDIV32, non-zero imm divisor, check 6 @unpriv:OK torvalds#347/13 verifier_sdiv/SDIV32, non-zero imm divisor, check 7:OK torvalds#347/14 verifier_sdiv/SDIV32, non-zero imm divisor, check 7 @unpriv:OK torvalds#347/15 verifier_sdiv/SDIV32, non-zero imm divisor, check 8:OK torvalds#347/16 verifier_sdiv/SDIV32, non-zero imm divisor, check 8 @unpriv:OK torvalds#347/17 verifier_sdiv/SDIV32, non-zero reg divisor, check 1:OK torvalds#347/18 verifier_sdiv/SDIV32, non-zero reg divisor, check 1 @unpriv:OK torvalds#347/19 verifier_sdiv/SDIV32, non-zero reg divisor, check 2:OK torvalds#347/20 verifier_sdiv/SDIV32, non-zero reg divisor, check 2 @unpriv:OK torvalds#347/21 verifier_sdiv/SDIV32, non-zero reg divisor, check 3:OK torvalds#347/22 verifier_sdiv/SDIV32, non-zero reg divisor, check 3 @unpriv:OK torvalds#347/23 verifier_sdiv/SDIV32, non-zero reg divisor, check 4:OK torvalds#347/24 verifier_sdiv/SDIV32, non-zero reg divisor, check 4 @unpriv:OK torvalds#347/25 verifier_sdiv/SDIV32, non-zero reg divisor, check 5:OK torvalds#347/26 verifier_sdiv/SDIV32, non-zero reg divisor, check 5 @unpriv:OK torvalds#347/27 verifier_sdiv/SDIV32, non-zero reg divisor, check 6:OK torvalds#347/28 verifier_sdiv/SDIV32, non-zero reg divisor, check 6 @unpriv:OK torvalds#347/29 verifier_sdiv/SDIV32, non-zero reg divisor, check 7:OK torvalds#347/30 verifier_sdiv/SDIV32, non-zero reg divisor, check 7 @unpriv:OK torvalds#347/31 verifier_sdiv/SDIV32, non-zero reg divisor, check 8:OK torvalds#347/32 verifier_sdiv/SDIV32, non-zero reg divisor, check 8 @unpriv:OK torvalds#347/33 verifier_sdiv/SDIV64, non-zero imm divisor, check 1:OK torvalds#347/34 verifier_sdiv/SDIV64, non-zero imm divisor, check 1 @unpriv:OK torvalds#347/35 verifier_sdiv/SDIV64, non-zero imm divisor, check 2:OK torvalds#347/36 verifier_sdiv/SDIV64, non-zero imm divisor, check 2 @unpriv:OK torvalds#347/37 verifier_sdiv/SDIV64, non-zero imm divisor, check 3:OK torvalds#347/38 verifier_sdiv/SDIV64, non-zero imm divisor, check 3 @unpriv:OK torvalds#347/39 verifier_sdiv/SDIV64, non-zero imm divisor, check 4:OK torvalds#347/40 verifier_sdiv/SDIV64, non-zero imm divisor, check 4 @unpriv:OK torvalds#347/41 verifier_sdiv/SDIV64, non-zero imm divisor, check 5:OK torvalds#347/42 verifier_sdiv/SDIV64, non-zero imm divisor, check 5 @unpriv:OK torvalds#347/43 verifier_sdiv/SDIV64, non-zero imm divisor, check 6:OK torvalds#347/44 verifier_sdiv/SDIV64, non-zero imm divisor, check 6 @unpriv:OK torvalds#347/45 verifier_sdiv/SDIV64, non-zero reg divisor, check 1:OK torvalds#347/46 verifier_sdiv/SDIV64, non-zero reg divisor, check 1 @unpriv:OK torvalds#347/47 verifier_sdiv/SDIV64, non-zero reg divisor, check 2:OK torvalds#347/48 verifier_sdiv/SDIV64, non-zero reg divisor, check 2 @unpriv:OK torvalds#347/49 verifier_sdiv/SDIV64, non-zero reg divisor, check 3:OK torvalds#347/50 verifier_sdiv/SDIV64, non-zero reg divisor, check 3 @unpriv:OK torvalds#347/51 verifier_sdiv/SDIV64, non-zero reg divisor, check 4:OK torvalds#347/52 verifier_sdiv/SDIV64, non-zero reg divisor, check 4 @unpriv:OK torvalds#347/53 verifier_sdiv/SDIV64, non-zero reg divisor, check 5:OK torvalds#347/54 verifier_sdiv/SDIV64, non-zero reg divisor, check 5 @unpriv:OK torvalds#347/55 verifier_sdiv/SDIV64, non-zero reg divisor, check 6:OK torvalds#347/56 verifier_sdiv/SDIV64, non-zero reg divisor, check 6 @unpriv:OK torvalds#347/57 verifier_sdiv/SMOD32, non-zero imm divisor, check 1:OK torvalds#347/58 verifier_sdiv/SMOD32, non-zero imm divisor, check 1 @unpriv:OK torvalds#347/59 verifier_sdiv/SMOD32, non-zero imm divisor, check 2:OK torvalds#347/60 verifier_sdiv/SMOD32, non-zero imm divisor, check 2 @unpriv:OK torvalds#347/61 verifier_sdiv/SMOD32, non-zero imm divisor, check 3:OK torvalds#347/62 verifier_sdiv/SMOD32, non-zero imm divisor, check 3 @unpriv:OK torvalds#347/63 verifier_sdiv/SMOD32, non-zero imm divisor, check 4:OK torvalds#347/64 verifier_sdiv/SMOD32, non-zero imm divisor, check 4 @unpriv:OK torvalds#347/65 verifier_sdiv/SMOD32, non-zero imm divisor, check 5:OK torvalds#347/66 verifier_sdiv/SMOD32, non-zero imm divisor, check 5 @unpriv:OK torvalds#347/67 verifier_sdiv/SMOD32, non-zero imm divisor, check 6:OK torvalds#347/68 verifier_sdiv/SMOD32, non-zero imm divisor, check 6 @unpriv:OK torvalds#347/69 verifier_sdiv/SMOD32, non-zero reg divisor, check 1:OK torvalds#347/70 verifier_sdiv/SMOD32, non-zero reg divisor, check 1 @unpriv:OK torvalds#347/71 verifier_sdiv/SMOD32, non-zero reg divisor, check 2:OK torvalds#347/72 verifier_sdiv/SMOD32, non-zero reg divisor, check 2 @unpriv:OK torvalds#347/73 verifier_sdiv/SMOD32, non-zero reg divisor, check 3:OK torvalds#347/74 verifier_sdiv/SMOD32, non-zero reg divisor, check 3 @unpriv:OK torvalds#347/75 verifier_sdiv/SMOD32, non-zero reg divisor, check 4:OK torvalds#347/76 verifier_sdiv/SMOD32, non-zero reg divisor, check 4 @unpriv:OK torvalds#347/77 verifier_sdiv/SMOD32, non-zero reg divisor, check 5:OK torvalds#347/78 verifier_sdiv/SMOD32, non-zero reg divisor, check 5 @unpriv:OK torvalds#347/79 verifier_sdiv/SMOD32, non-zero reg divisor, check 6:OK torvalds#347/80 verifier_sdiv/SMOD32, non-zero reg divisor, check 6 @unpriv:OK torvalds#347/81 verifier_sdiv/SMOD64, non-zero imm divisor, check 1:OK torvalds#347/82 verifier_sdiv/SMOD64, non-zero imm divisor, check 1 @unpriv:OK torvalds#347/83 verifier_sdiv/SMOD64, non-zero imm divisor, check 2:OK torvalds#347/84 verifier_sdiv/SMOD64, non-zero imm divisor, check 2 @unpriv:OK torvalds#347/85 verifier_sdiv/SMOD64, non-zero imm divisor, check 3:OK torvalds#347/86 verifier_sdiv/SMOD64, non-zero imm divisor, check 3 @unpriv:OK torvalds#347/87 verifier_sdiv/SMOD64, non-zero imm divisor, check 4:OK torvalds#347/88 verifier_sdiv/SMOD64, non-zero imm divisor, check 4 @unpriv:OK torvalds#347/89 verifier_sdiv/SMOD64, non-zero imm divisor, check 5:OK torvalds#347/90 verifier_sdiv/SMOD64, non-zero imm divisor, check 5 @unpriv:OK torvalds#347/91 verifier_sdiv/SMOD64, non-zero imm divisor, check 6:OK torvalds#347/92 verifier_sdiv/SMOD64, non-zero imm divisor, check 6 @unpriv:OK torvalds#347/93 verifier_sdiv/SMOD64, non-zero imm divisor, check 7:OK torvalds#347/94 verifier_sdiv/SMOD64, non-zero imm divisor, check 7 @unpriv:OK torvalds#347/95 verifier_sdiv/SMOD64, non-zero imm divisor, check 8:OK torvalds#347/96 verifier_sdiv/SMOD64, non-zero imm divisor, check 8 @unpriv:OK torvalds#347/97 verifier_sdiv/SMOD64, non-zero reg divisor, check 1:OK torvalds#347/98 verifier_sdiv/SMOD64, non-zero reg divisor, check 1 @unpriv:OK torvalds#347/99 verifier_sdiv/SMOD64, non-zero reg divisor, check 2:OK torvalds#347/100 verifier_sdiv/SMOD64, non-zero reg divisor, check 2 @unpriv:OK torvalds#347/101 verifier_sdiv/SMOD64, non-zero reg divisor, check 3:OK torvalds#347/102 verifier_sdiv/SMOD64, non-zero reg divisor, check 3 @unpriv:OK torvalds#347/103 verifier_sdiv/SMOD64, non-zero reg divisor, check 4:OK torvalds#347/104 verifier_sdiv/SMOD64, non-zero reg divisor, check 4 @unpriv:OK torvalds#347/105 verifier_sdiv/SMOD64, non-zero reg divisor, check 5:OK torvalds#347/106 verifier_sdiv/SMOD64, non-zero reg divisor, check 5 @unpriv:OK torvalds#347/107 verifier_sdiv/SMOD64, non-zero reg divisor, check 6:OK torvalds#347/108 verifier_sdiv/SMOD64, non-zero reg divisor, check 6 @unpriv:OK torvalds#347/109 verifier_sdiv/SMOD64, non-zero reg divisor, check 7:OK torvalds#347/110 verifier_sdiv/SMOD64, non-zero reg divisor, check 7 @unpriv:OK torvalds#347/111 verifier_sdiv/SMOD64, non-zero reg divisor, check 8:OK torvalds#347/112 verifier_sdiv/SMOD64, non-zero reg divisor, check 8 @unpriv:OK torvalds#347/113 verifier_sdiv/SDIV32, zero divisor:OK torvalds#347/114 verifier_sdiv/SDIV32, zero divisor @unpriv:OK torvalds#347/115 verifier_sdiv/SDIV64, zero divisor:OK torvalds#347/116 verifier_sdiv/SDIV64, zero divisor @unpriv:OK torvalds#347/117 verifier_sdiv/SMOD32, zero divisor:OK torvalds#347/118 verifier_sdiv/SMOD32, zero divisor @unpriv:OK torvalds#347/119 verifier_sdiv/SMOD64, zero divisor:OK torvalds#347/120 verifier_sdiv/SMOD64, zero divisor @unpriv:OK torvalds#347 verifier_sdiv:OK Summary: 6/166 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Xu Kuohai <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Tested-by: Florent Revest <[email protected]> Acked-by: Yonghong Song <[email protected]> Acked-by: Florent Revest <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]

Stash enq_flags when marking for direct dispatch

heicarst and others added 30 commits February 6, 2014 11:22

KVM: PPC: Book3S HV: use xics_wake_cpu only when defined

de0bb60

commit 48eaef0 upstream. Signed-off-by: Andreas Schwab <[email protected]> Signed-off-by: Alexander Graf <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

Linux 3.12.10

39386d7

logic10492 pushed a commit to logic10492/linux-amd-zen2 that referenced this pull request Jan 18, 2024

Merge pull request torvalds#115 from sched-ext/enq_flags

7909b33

Stash enq_flags when marking for direct dispatch

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

ggry #115

ggry #115

KonstantinBYvitebsk commented Aug 21, 2014

ggry #115

Are you sure you want to change the base?

ggry #115

Conversation

KonstantinBYvitebsk commented Aug 21, 2014