On Tue, Mar 19, 2024 at 10:47:42AM +0000, Sakari Ailus wrote: > Hi Greg, > > On Tue, Mar 19, 2024 at 08:51:43AM +0100, Greg Kroah-Hartman wrote: > > On Mon, Mar 18, 2024 at 10:01:26AM +0200, Sakari Ailus wrote: > > > Unregister the MEI VSC interrupt handler before system suspend and > > > re-register it at system resume time. This mirrors implementation of other > > > MEI devices. > > > > > > This patch fixes the bug that causes continuous stream of MEI VSC errors > > > after system resume. > > > > > > Fixes: 386a766c4169 ("mei: Add MEI hardware support for IVSC device") > > > Cc: stable@vger.kernel.org # for 6.8 > > > Reported-by: Dominik Brodowski <linux@dominikbrodowski.net> > > > Signed-off-by: Wentong Wu <wentong.wu@intel.com> > > > Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> > > > --- > > > drivers/misc/mei/platform-vsc.c | 17 ++++++- > > > drivers/misc/mei/vsc-tp.c | 84 +++++++++++++++++++++++---------- > > > drivers/misc/mei/vsc-tp.h | 3 ++ > > > 3 files changed, 78 insertions(+), 26 deletions(-) > > > > What is the git commit id of this in Linus's tree? > > This one isn't in Linus's (or any other maintainer) tree yet. Then why was it sent only for 6.8? Please read: https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html for how to do this properly. thanks, greg k-h
On Wed, Mar 13, 2024 at 10:46:50PM +0100, Conrad Kostecki wrote: > Previously, patches have been added to limit the reported count of SATA > ports for asm1064 and asm1166 SATA controllers, as those controllers do > report more ports than physical having. > > Unfortunately, this causes trouble for users, which are using SATA > controllers, which provide more ports through SATA PMP > (Port-MultiPlier) and are now not any more recognized. > > This happens, as asm1064 and 1166 are handling SATA PMP transparently, > so all non-physical ports needs to be enabled to use that feature. > > This patch reverts both patches for asm1064 and asm1166, so old > behavior is restored and SATA PMP will work again, so all physical and > non-physical ports will work again. > > Fixes: 0077a504e1a4 ("ahci: asm1166: correct count of reported ports") > Fixes: 9815e3961754 ("ahci: asm1064: correct count of reported ports") > Cc: stable@vger.kernel.org > Reported-by: Matt <cryptearth@googlemail.com> > Signed-off-by: Conrad Kostecki <conikost@gentoo.org> > --- > drivers/ata/ahci.c | 13 ------------- > 1 file changed, 13 deletions(-) > > diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c > index 78570684ff68..562302e2e57c 100644 > --- a/drivers/ata/ahci.c > +++ b/drivers/ata/ahci.c > @@ -669,19 +669,6 @@ MODULE_PARM_DESC(mobile_lpm_policy, "Default LPM policy for mobile chipsets"); > static void ahci_pci_save_initial_config(struct pci_dev *pdev, > struct ahci_host_priv *hpriv) > { > - if (pdev->vendor == PCI_VENDOR_ID_ASMEDIA) { > - switch (pdev->device) { > - case 0x1166: > - dev_info(&pdev->dev, "ASM1166 has only six ports\n"); > - hpriv->saved_port_map = 0x3f; > - break; > - case 0x1064: > - dev_info(&pdev->dev, "ASM1064 has only four ports\n"); > - hpriv->saved_port_map = 0xf; > - break; > - } > - } > - > if (pdev->vendor == PCI_VENDOR_ID_JMICRON && pdev->device == 0x2361) { > dev_info(&pdev->dev, "JMB361 has only one port\n"); > hpriv->saved_port_map = 1; > -- > 2.44.0 > I took the liberty to add additional information in the commit message. Applied: https://git.kernel.org/pub/scm/linux/kernel/git/libata/linux.git/commit/?id=6cd8adc3e18960f6e59d797285ed34ef473cc896 ...and already sent to Linus: https://lore.kernel.org/linux-ide/20240319113758.197709-1-cassel@kernel.org/T/#u Kind regards, Niklas
We can trigger a slab-out-of-bounds with the following commands: mkfs.ext4 -F /dev/$disk 10G mount /dev/$disk /tmp/test echo 2147483647 > /sys/fs/ext4/$disk/mb_group_prealloc echo test > /tmp/test/file && sync ================================================================== BUG: KASAN: slab-out-of-bounds in ext4_mb_find_good_group_avg_frag_lists+0x8a/0x200 [ext4] Read of size 8 at addr ffff888121b9d0f0 by task kworker/u2:0/11 CPU: 0 PID: 11 Comm: kworker/u2:0 Tainted: GL 6.7.0-next-20240118 #521 Call Trace: dump_stack_lvl+0x2c/0x50 kasan_report+0xb6/0xf0 ext4_mb_find_good_group_avg_frag_lists+0x8a/0x200 [ext4] ext4_mb_regular_allocator+0x19e9/0x2370 [ext4] ext4_mb_new_blocks+0x88a/0x1370 [ext4] ext4_ext_map_blocks+0x14f7/0x2390 [ext4] ext4_map_blocks+0x569/0xea0 [ext4] ext4_do_writepages+0x10f6/0x1bc0 [ext4] [...] ================================================================== The flow of issue triggering is as follows: // Set s_mb_group_prealloc to 2147483647 via sysfs ext4_mb_new_blocks ext4_mb_normalize_request ext4_mb_normalize_group_request ac->ac_g_ex.fe_len = EXT4_SB(sb)->s_mb_group_prealloc ext4_mb_regular_allocator ext4_mb_choose_next_group ext4_mb_choose_next_group_best_avail mb_avg_fragment_size_order order = fls(len) - 2 = 29 ext4_mb_find_good_group_avg_frag_lists frag_list = &sbi->s_mb_avg_fragment_size[order] if (list_empty(frag_list)) // Trigger SOOB! At 4k block size, the length of the s_mb_avg_fragment_size list is 14, but an oversized s_mb_group_prealloc is set, causing slab-out-of-bounds to be triggered by an attempt to access an element at index 29. Add a new attr_id attr_clusters_in_group with values in the range [0, sbi->s_clusters_per_group] and declare mb_group_prealloc as that type to fix the issue. In addition avoid returning an order from mb_avg_fragment_size_order() greater than MB_NUM_ORDERS(sb) and reduce some useless loops. Fixes: 7e170922f06b ("ext4: Add allocation criteria 1.5 (CR1_5)") CC: stable@vger.kernel.org Signed-off-by: Baokun Li <libaokun1@huawei.com> Reviewed-by: Jan Kara <jack@suse.cz> Reviewed-by: Ojaswin Mujoo <ojaswin@linux.ibm.com> --- fs/ext4/mballoc.c | 4 ++++ fs/ext4/sysfs.c | 13 ++++++++++++- 2 files changed, 16 insertions(+), 1 deletion(-) diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c index 12b3f196010b..dbf04f91516c 100644 --- a/fs/ext4/mballoc.c +++ b/fs/ext4/mballoc.c @@ -831,6 +831,8 @@ static int mb_avg_fragment_size_order(struct super_block *sb, ext4_grpblk_t len) return 0; if (order == MB_NUM_ORDERS(sb)) order--; + if (WARN_ON_ONCE(order > MB_NUM_ORDERS(sb))) + order = MB_NUM_ORDERS(sb) - 1; return order; } @@ -1008,6 +1010,8 @@ static void ext4_mb_choose_next_group_best_avail(struct ext4_allocation_context * goal length. */ order = fls(ac->ac_g_ex.fe_len) - 1; + if (WARN_ON_ONCE(order - 1 > MB_NUM_ORDERS(ac->ac_sb))) + order = MB_NUM_ORDERS(ac->ac_sb); min_order = order - sbi->s_mb_best_avail_max_trim_order; if (min_order < 0) min_order = 0; diff --git a/fs/ext4/sysfs.c b/fs/ext4/sysfs.c index 7f455b5f22c0..ddd71673176c 100644 --- a/fs/ext4/sysfs.c +++ b/fs/ext4/sysfs.c @@ -29,6 +29,7 @@ typedef enum { attr_trigger_test_error, attr_first_error_time, attr_last_error_time, + attr_clusters_in_group, attr_feature, attr_pointer_ui, attr_pointer_ul, @@ -207,13 +208,14 @@ EXT4_ATTR_FUNC(sra_exceeded_retry_limit, 0444); EXT4_ATTR_OFFSET(inode_readahead_blks, 0644, inode_readahead, ext4_sb_info, s_inode_readahead_blks); +EXT4_ATTR_OFFSET(mb_group_prealloc, 0644, clusters_in_group, + ext4_sb_info, s_mb_group_prealloc); EXT4_RW_ATTR_SBI_UI(inode_goal, s_inode_goal); EXT4_RW_ATTR_SBI_UI(mb_stats, s_mb_stats); EXT4_RW_ATTR_SBI_UI(mb_max_to_scan, s_mb_max_to_scan); EXT4_RW_ATTR_SBI_UI(mb_min_to_scan, s_mb_min_to_scan); EXT4_RW_ATTR_SBI_UI(mb_order2_req, s_mb_order2_reqs); EXT4_RW_ATTR_SBI_UI(mb_stream_req, s_mb_stream_request); -EXT4_RW_ATTR_SBI_UI(mb_group_prealloc, s_mb_group_prealloc); EXT4_RW_ATTR_SBI_UI(mb_max_linear_groups, s_mb_max_linear_groups); EXT4_RW_ATTR_SBI_UI(extent_max_zeroout_kb, s_extent_max_zeroout_kb); EXT4_ATTR(trigger_fs_error, 0200, trigger_test_error); @@ -376,6 +378,7 @@ static ssize_t ext4_generic_attr_show(struct ext4_attr *a, switch (a->attr_id) { case attr_inode_readahead: + case attr_clusters_in_group: case attr_pointer_ui: if (a->attr_ptr == ptr_ext4_super_block_offset) return sysfs_emit(buf, "%u\n", le32_to_cpup(ptr)); @@ -455,6 +458,14 @@ static ssize_t ext4_generic_attr_store(struct ext4_attr *a, else *((unsigned int *) ptr) = t; return len; + case attr_clusters_in_group: + ret = kstrtouint(skip_spaces(buf), 0, &t); + if (ret) + return ret; + if (t > sbi->s_clusters_per_group) + return -EINVAL; + *((unsigned int *) ptr) = t; + return len; case attr_pointer_ul: ret = kstrtoul(skip_spaces(buf), 0, <); if (ret) -- 2.31.1
On Tue, 19 Mar 2024 at 00:10, Adam Dunlap <acdunlap@google.com> wrote: > > When done from a virtual machine, instructions that touch APIC memory > must be emulated. By convention, MMIO access are typically performed via > io.h helpers such as 'readl()' or 'writeq()' to simplify instruction > emulation/decoding (ex: in KVM hosts and SEV guests) [0]. > > Currently, native_apic_mem_read() does not follow this convention, > allowing the compiler to emit instructions other than the MOV > instruction generated by readl(). In particular, when compiled with > clang and run as a SEV-ES or SEV-SNP guest, the compiler would emit a > TESTL instruction which is not supported by the SEV-ES emulator, causing > a boot failure in that environment. It is likely the same problem would > happen in a TDX guest as that uses the same instruction emulator as > SEV-ES. > > To make sure all emulators can emulate APIC memory reads via MOV, use > the readl() function in native_apic_mem_read(). It is expected that any > emulator would support MOV in any addressing mode it is the most generic > and is what is ususally emitted currently. > > The TESTL instruction is emitted when native_apic_mem_read() is inlined > into apic_mem_wait_icr_idle(). The emulator comes from insn_decode_mmio > in arch/x86/lib/insn-eval.c. It's not worth it to extend > insn_decode_mmio to support more instructions since, in theory, the > compiler could choose to output nearly any instruction for such reads > which would bloat the emulator beyond reason. > > [0] https://lore.kernel.org/all/20220405232939.73860-12-kirill.shutemov@linux.intel.com/ > > Signed-off-by: Adam Dunlap <acdunlap@google.com> > Tested-by: Kevin Loughlin <kevinloughlin@google.com> > Reviewed-by: Thomas Gleixner <tglx@linutronix.de> > Cc: stable@vger.kernel.org > Reviewed-by: Ard Biesheuvel <ardb@kernel.org> > --- > > An alterative to this approach would be to use inline assembly instead > of the readl() helper, as that is what native_apic_mem_write() does. I > consider using readl() to be cleaner since it is documented to be a simple > wrapper and inline assembly is less readable. native_apic_mem_write() > cannot be trivially updated to use writel since it appears to use custom > asm to workaround for a processor-specific bug. > > Patch changelog: > V1 -> V2: Replaced asm with readl function which does the same thing > V2 -> V3: Updated commit message to show more motivation and > justification > V3 -> V4: Fixed nits in commit message > > Link to v2 discussion: https://lore.kernel.org/all/20220908170456.3177635-1-acdunlap@google.com/ > > arch/x86/include/asm/apic.h | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/arch/x86/include/asm/apic.h b/arch/x86/include/asm/apic.h > index 9d159b771dc8..dddd3fc195ef 100644 > --- a/arch/x86/include/asm/apic.h > +++ b/arch/x86/include/asm/apic.h > @@ -13,6 +13,7 @@ > #include <asm/mpspec.h> > #include <asm/msr.h> > #include <asm/hardirq.h> > +#include <asm/io.h> > > #define ARCH_APICTIMER_STOPS_ON_C3 1 > > @@ -96,7 +97,7 @@ static inline void native_apic_mem_write(u32 reg, u32 v) > > static inline u32 native_apic_mem_read(u32 reg) > { > - return *((volatile u32 *)(APIC_BASE + reg)); > + return readl((void __iomem *)(APIC_BASE + reg)); > } > > static inline void native_apic_mem_eoi(void) > -- > 2.43.0.594.gd9cf4e227d-goog >
On Tue, Mar 19, 2024 at 11:34 AM Benno Lossin <benno.lossin@proton.me> wrote: > > I can re-send it for you again, or do you want to send it yourself? > I think it is also a good idea to add a link to [1] in the code, since > the above explanation is rather long and fits better in the commit > message. Agreed, if you want to have a note in the code itself (to avoid mistakes re-adding them, I imagine), then I would say a short sentence + link is best. Your link is a good one for an explanation, since it mentions explicitly the UB. The reference's list [1] would be a good fit for non-explanation purposes -- it mentions explicitly `!` (and `Infallible` is supposed to eventually be an alias as far as I know). In addition, while it is not important in this case (i.e. most likely nobody is affected), it doesn't hurt to include an example that shows the issue in general for this sort of patches, i.e. what kind of code will be prevented from compiling, e.g. pr_info!("{}", Box::<core::convert::Infallible>::init(kernel::init::zeroed())?); In any case, even v1 looks good to me -- thanks! [1] https://doc.rust-lang.org/reference/behavior-considered-undefined.html Cheers, Miguel
Hi Greg,
On Tue, Mar 19, 2024 at 08:51:43AM +0100, Greg Kroah-Hartman wrote:
> On Mon, Mar 18, 2024 at 10:01:26AM +0200, Sakari Ailus wrote:
> > Unregister the MEI VSC interrupt handler before system suspend and
> > re-register it at system resume time. This mirrors implementation of other
> > MEI devices.
> >
> > This patch fixes the bug that causes continuous stream of MEI VSC errors
> > after system resume.
> >
> > Fixes: 386a766c4169 ("mei: Add MEI hardware support for IVSC device")
> > Cc: stable@vger.kernel.org # for 6.8
> > Reported-by: Dominik Brodowski <linux@dominikbrodowski.net>
> > Signed-off-by: Wentong Wu <wentong.wu@intel.com>
> > Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
> > ---
> > drivers/misc/mei/platform-vsc.c | 17 ++++++-
> > drivers/misc/mei/vsc-tp.c | 84 +++++++++++++++++++++++----------
> > drivers/misc/mei/vsc-tp.h | 3 ++
> > 3 files changed, 78 insertions(+), 26 deletions(-)
>
> What is the git commit id of this in Linus's tree?
This one isn't in Linus's (or any other maintainer) tree yet.
--
Regards,
Sakari Ailus
On Mon, Mar 18, 2024 at 04:25:09PM +0100, Jan Kara wrote: > On Mon 18-03-24 18:09:18, Ojaswin Mujoo wrote: > > On Thu, Mar 14, 2024 at 10:09:01PM +0800, Baokun Li wrote: > > > We can trigger a slab-out-of-bounds with the following commands: > > > > > > mkfs.ext4 -F /dev/$disk 10G > > > mount /dev/$disk /tmp/test > > > echo 2147483647 > /sys/fs/ext4/$disk/mb_group_prealloc > > > echo test > /tmp/test/file && sync > > > > > > ================================================================== > > > BUG: KASAN: slab-out-of-bounds in ext4_mb_find_good_group_avg_frag_lists+0x8a/0x200 [ext4] > > > Read of size 8 at addr ffff888121b9d0f0 by task kworker/u2:0/11 > > > CPU: 0 PID: 11 Comm: kworker/u2:0 Tainted: GL 6.7.0-next-20240118 #521 > > > Call Trace: > > > dump_stack_lvl+0x2c/0x50 > > > kasan_report+0xb6/0xf0 > > > ext4_mb_find_good_group_avg_frag_lists+0x8a/0x200 [ext4] > > > ext4_mb_regular_allocator+0x19e9/0x2370 [ext4] > > > ext4_mb_new_blocks+0x88a/0x1370 [ext4] > > > ext4_ext_map_blocks+0x14f7/0x2390 [ext4] > > > ext4_map_blocks+0x569/0xea0 [ext4] > > > ext4_do_writepages+0x10f6/0x1bc0 [ext4] > > > [...] > > > ================================================================== > > > > > > The flow of issue triggering is as follows: > > > > > > // Set s_mb_group_prealloc to 2147483647 via sysfs > > > ext4_mb_new_blocks > > > ext4_mb_normalize_request > > > ext4_mb_normalize_group_request > > > ac->ac_g_ex.fe_len = EXT4_SB(sb)->s_mb_group_prealloc > > > ext4_mb_regular_allocator > > > ext4_mb_choose_next_group > > > ext4_mb_choose_next_group_best_avail > > > mb_avg_fragment_size_order > > > order = fls(len) - 2 = 29 > > > ext4_mb_find_good_group_avg_frag_lists > > > frag_list = &sbi->s_mb_avg_fragment_size[order] > > > if (list_empty(frag_list)) // Trigger SOOB! > > > > > > At 4k block size, the length of the s_mb_avg_fragment_size list is 14, > > > but an oversized s_mb_group_prealloc is set, causing slab-out-of-bounds > > > to be triggered by an attempt to access an element at index 29. > > > > > > Add a new attr_id attr_clusters_in_group with values in the range > > > [0, sbi->s_clusters_per_group] and declare mb_group_prealloc as > > > that type to fix the issue. In addition avoid returning an order > > > from mb_avg_fragment_size_order() greater than MB_NUM_ORDERS(sb) > > > and reduce some useless loops. > > > > > > Fixes: 7e170922f06b ("ext4: Add allocation criteria 1.5 (CR1_5)") > > > CC: stable@vger.kernel.org > > > Signed-off-by: Baokun Li <libaokun1@huawei.com> > > > Reviewed-by: Jan Kara <jack@suse.cz> > > > --- > > > fs/ext4/mballoc.c | 4 ++++ > > > fs/ext4/sysfs.c | 13 ++++++++++++- > > > 2 files changed, 16 insertions(+), 1 deletion(-) > > > > > > diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c > > > index 12b3f196010b..48afe5aa228c 100644 > > > --- a/fs/ext4/mballoc.c > > > +++ b/fs/ext4/mballoc.c > > > @@ -831,6 +831,8 @@ static int mb_avg_fragment_size_order(struct super_block *sb, ext4_grpblk_t len) > > > return 0; > > > if (order == MB_NUM_ORDERS(sb)) > > > order--; > > > + if (WARN_ON_ONCE(order > MB_NUM_ORDERS(sb))) > > > + order = MB_NUM_ORDERS(sb) - 1; > > > > Hey Baokun, > > > > Thanks for fixing this. This patch looks good to me, feel free to add: > > > > Reviewed-by: Ojaswin Mujoo <ojaswin@linux.ibm.com> > > > > my comments after this are less about the patch and more about some > > thoughts on the working of average fragment lists. > > > > So going through the v2 and this patch got me thinking about what really > > is going to happen when a user tries to allocate 32768 blocks which is also > > the maximum value we could have in say ac->ac_g_ex.fe_len. > > > > When this happens, ext4_mb_regular_allocator() will directly set the > > criteria as CR_GOAL_LEN_FAST. Now, we'll follow: > > > > ext4_mb_choose_next_group_goal_fast() > > for (i=mb_avg_fragment_size_order(); i < MB_NUM_ORDERS; i++) { .. } > > > > Here, mb_avg_fragment_siz_order() will do something like: > > > > order = fls(32768) - 2 = 14 > > ... > > if (order == MB_NUM_ORDERS(sb)) > > order--; > > > > return order; > > > > And we'll look in the fragment list[13] and since none of the groups > > there would have 32768 blocks free (since we dont track it here) we'll > > unnecessarily traverse the full list before falling to CR_BEST_AVAIL_LEN > > (this will become a noop due to the way order and min_order > > are calculated) and eventually to CR_GOAL_LEN_SLOW where we might get > > something or end up splitting. > > Yeah, agreed this looks a bit suboptimal. I'm just not 100% sure whether > we'll ever generate a request to allocate 32768 blocks - that would need > verification with tracing - because I have some vague recollection I once > arrived at conclusion this is not possible. Ahh, right! I see the following line in mpage_add_bh_to_extent(): /* Don't go larger than mballoc is willing to allocate */ if (map->m_len >= MAX_WRITEPAGES_EXTENT_LEN) return false; Where MAX_WRITEPAGES_EXTENT_LEN is 2048 ie 8MB on 4k filesystem. As pointed out by your comment there, it seems to come from the fact that we have some restrictions in ext4_mb_normalize_range() which don't allow us to go beyond 8MB length. I think I was also looking at that code sometime back and it really needs some rework, I'll try to test a few things out. So yep, in the usual paths we shouldn't be sending a request as big as 32768 blocks but it's still possible with group prealloc with s_mb_group_prealloc set to 32768. Anyways, thanks for pointing this out, I'll try to look into the code path more to see how we can optimize it better and maybe if we can lift the 2048 block restriction. Regards, ojaswin > > > I think something more optimal would be to: > > > > 1. Add another entry to average fragment lists for completely empty > > groups. (As a sidenote i think we should use something like MB_NUM_FRAG_ORDER > > instead of MB_NUM_ORDERS in calculating limits related to average > > fragment lists since the NUM_ORDERS seems to be the buddy max order ie > > 8192 blocks only valid for CR_POWER2 and shouldn't really limit the > > fragment size lists) > > I guess the thinking was that you can never get larger than > 1<<(MB_NUM_ORDERS-1) chunk from mballoc so there's no point to keep > fragment lists of such chunks? > > Honza > -- > Jan Kara <jack@suse.com> > SUSE Labs, CR
On 3/19/24 06:28, Laine Taffin Altman wrote: > On Mar 18, 2024, at 9:39 PM, Boqun Feng <boqun.feng@gmail.com> wrote: >> On Mon, Mar 18, 2024 at 08:17:07PM -0700, Laine Taffin Altman wrote: >>> On Mar 18, 2024, at 10:25 AM, Boqun Feng <boqun.feng@gmail.com> wrote: >>>> On Wed, Mar 13, 2024 at 11:09:37PM +0000, Benno Lossin wrote: >>>>> From: Laine Taffin Altman <alexanderaltman@me.com> >>>>> >>>>> It is not enough for a type to be a ZST to guarantee that zeroed memory >>>>> is a valid value for it; it must also be inhabited. Creating a value of >>>>> an uninhabited type, ZST or no, is immediate UB. >>>>> Thus remove the implementation of `Zeroable` for `Infallible`, since >>>>> that type is not inhabited. >>>>> >>>>> Cc: stable@vger.kernel.org >>>>> Fixes: 38cde0bd7b67 ("rust: init: add `Zeroable` trait and `init::zeroed` function") >>>>> Closes: https://github.com/Rust-for-Linux/pinned-init/pull/13 >>>>> Signed-off-by: Laine Taffin Altman <alexanderaltman@me.com> >>>>> Signed-off-by: Benno Lossin <benno.lossin@proton.me> >>>> >>>> I think either in the commit log or in the code comment, there better be >>>> a link or explanation on "(un)inhabited type". The rest looks good to >>>> me. >>> >>> Would the following be okay for that purpose? >>> >>> A type is inhabited if at least one valid value of that type exists; a >>> type is uninhabited if no valid values of that type exist. The terms >>> "inhabited" and "uninhabited" in this sense originate in type theory, >>> a branch of mathematics. >>> >>> In Rust, producing an invalid value of any type is immediate undefined >>> behavior (UB); this includes via zeroing memory. Therefore, since an >>> uninhabited type has no valid values, producing any values at all for >>> it is UB. >>> >>> The Rust standard library type `core::convert::Infallible` is >>> uninhabited, by virtue of having been declared as an enum with no >>> cases, which always produces uninhabited types in Rust. Thus, remove >>> the implementation of `Zeroable` for `Infallible`, thereby avoiding >>> the UB. >>> >> >> Yeah, this works for me. Thanks! > > Great! Should it be re-sent or can the new wording be incorporated upon merge? I can re-send it for you again, or do you want to send it yourself? I think it is also a good idea to add a link to [1] in the code, since the above explanation is rather long and fits better in the commit message. -- Cheers, Benno [1]: https://doc.rust-lang.org/nomicon/exotic-sizes.html#empty-types
On 2024/3/18 20:39, Ojaswin Mujoo wrote: > On Thu, Mar 14, 2024 at 10:09:01PM +0800, Baokun Li wrote: >> --- a/fs/ext4/mballoc.c >> +++ b/fs/ext4/mballoc.c >> @@ -831,6 +831,8 @@ static int mb_avg_fragment_size_order(struct super_block *sb, ext4_grpblk_t len) >> return 0; >> if (order == MB_NUM_ORDERS(sb)) >> order--; >> + if (WARN_ON_ONCE(order > MB_NUM_ORDERS(sb))) >> + order = MB_NUM_ORDERS(sb) - 1; > Hey Baokun, Hi Ojaswin, > > Thanks for fixing this. This patch looks good to me, feel free to add: > > Reviewed-by: Ojaswin Mujoo <ojaswin@linux.ibm.com> Thanks for the review! > my comments after this are less about the patch and more about some > thoughts on the working of average fragment lists. > > So going through the v2 and this patch got me thinking about what really > is going to happen when a user tries to allocate 32768 blocks which is also > the maximum value we could have in say ac->ac_g_ex.fe_len. > > When this happens, ext4_mb_regular_allocator() will directly set the > criteria as CR_GOAL_LEN_FAST. Now, we'll follow: > > ext4_mb_choose_next_group_goal_fast() > for (i=mb_avg_fragment_size_order(); i < MB_NUM_ORDERS; i++) { .. } > > Here, mb_avg_fragment_siz_order() will do something like: > > order = fls(32768) - 2 = 14 > ... > if (order == MB_NUM_ORDERS(sb)) > order--; > > return order; > > And we'll look in the fragment list[13] and since none of the groups > there would have 32768 blocks free (since we dont track it here) we'll > unnecessarily traverse the full list before falling to CR_BEST_AVAIL_LEN > (this will become a noop due to the way order and min_order > are calculated) and eventually to CR_GOAL_LEN_SLOW where we might get > something or end up splitting. That's not quite right, in ext4_mb_choose_next_group_goal_fast() even though we're looking for the group with order 13, the group with 32768 free blocks is also in there. So after passing ext4_mb_good_group() in ext4_mb_find_good_group_avg_frag_lists(), we get a group with 32768 free blocks. And in ext4_mb_choose_next_group_best_avail() we were supposed to allocate blocks quickly by trim order, so it's necessary here too. So there are no unnecessary loops here. But this will trigger the freshly added WARN_ON_ONCE, so in the new iteration I need to change it to: if (WARN_ON_ONCE(order > MB_NUM_ORDERS(ac->ac_sb) + 1)) order = MB_NUM_ORDERS(ac->ac_sb) - 1; In addition, when the block size is 4k, there are these limitations: 1) Limit the maximum size of the data allocation estimate to 8M in ext4_mb_normalize_request(). 2) #define MAX_WRITEPAGES_EXTENT_LEN 2048 3) #define DIO_MAX_BLOCKS 4096 4) Metadata is generally not allocated in many blocks at a time So it seems that only group_prealloc will allocate more than 2048 blocks at a time. And I've tried removing those 8M/2048/4096 limits before, but the performance of DIO write barely changed, and it doesn't look like the performance bottleneck is here in the number of blocks allocated at a time at the moment. Thanks, Baokun > I think something more optimal would be to: > > 1. Add another entry to average fragment lists for completely empty > groups. (As a sidenote i think we should use something like MB_NUM_FRAG_ORDER > instead of MB_NUM_ORDERS in calculating limits related to average > fragment lists since the NUM_ORDERS seems to be the buddy max order ie > 8192 blocks only valid for CR_POWER2 and shouldn't really limit the > fragment size lists) > > 2. If we don't want to go with 1 (maybe there's some history for that), > then probably should exit early from CR_GOAL_LEN_FAST so that we don't > iterate there. > > Would like to hear your thoughts on it Baokun, Jan. > > Regards, > ojaswin >
On Tue, 19 Mar 2024, Ville Syrjala <ville.syrjala@linux.intel.com> wrote: > From: Ville Syrjälä <ville.syrjala@linux.intel.com> > > If we have no VBT, or the VBT didn't declare the encoder > in question, we won't have the 'devdata' for the encoder. > Instead of oopsing just bail early. > > We won't be able to tell whether the port is DP++ or not, > but so be it. > > Cc: stable@vger.kernel.org > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10464 > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> > --- > drivers/gpu/drm/i915/display/intel_bios.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/i915/display/intel_bios.c b/drivers/gpu/drm/i915/display/intel_bios.c > index c7841b3eede8..c13a98431a7b 100644 > --- a/drivers/gpu/drm/i915/display/intel_bios.c > +++ b/drivers/gpu/drm/i915/display/intel_bios.c > @@ -3458,6 +3458,9 @@ bool intel_bios_encoder_supports_dp_dual_mode(const struct intel_bios_encoder_da > { > const struct child_device_config *child = &devdata->child; The above oopses already. BR, Jani. > > + if (!devdata) > + return false; > + > if (!intel_bios_encoder_supports_dp(devdata) || > !intel_bios_encoder_supports_hdmi(devdata)) > return false; -- Jani Nikula, Intel
From: Ville Syrjälä <ville.syrjala@linux.intel.com> If we have no VBT, or the VBT didn't declare the encoder in question, we won't have the 'devdata' for the encoder. Instead of oopsing just bail early. We won't be able to tell whether the port is DP++ or not, but so be it. Cc: stable@vger.kernel.org Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10464 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> --- drivers/gpu/drm/i915/display/intel_bios.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_bios.c b/drivers/gpu/drm/i915/display/intel_bios.c index c7841b3eede8..c13a98431a7b 100644 --- a/drivers/gpu/drm/i915/display/intel_bios.c +++ b/drivers/gpu/drm/i915/display/intel_bios.c @@ -3458,6 +3458,9 @@ bool intel_bios_encoder_supports_dp_dual_mode(const struct intel_bios_encoder_da { const struct child_device_config *child = &devdata->child; + if (!devdata) + return false; + if (!intel_bios_encoder_supports_dp(devdata) || !intel_bios_encoder_supports_hdmi(devdata)) return false; -- 2.43.2
Gentle ping. ________________________________________ From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Sent: 08 March 2024 15:07 To: Ingo Molnar; Peter Zijlstra Cc: linux-kernel@vger.kernel.org; Mathieu Desnoyers; Yeo Reum Yun; stable@vger.kernel.org; Steven Rostedt; Vincent Guittot; Juri Lelli; Dietmar Eggemann; Ben Segall; Mel Gorman; Daniel Bristot de Oliveira; Valentin Schneider; Catalin Marinas; Mark Rutland; Will Deacon; Aaron Lu Subject: [PATCH] sched: Add missing memory barrier in switch_mm_cid Many architectures' switch_mm() (e.g. arm64) do not have an smp_mb() which the core scheduler code has depended upon since commit: commit 223baf9d17f25 ("sched: Fix performance regression introduced by mm_cid") If switch_mm() doesn't call smp_mb(), sched_mm_cid_remote_clear() can unset the actively used cid when it fails to observe active task after it sets lazy_put. There *is* a memory barrier between storing to rq->curr and _return to userspace_ (as required by membarrier), but the rseq mm_cid has stricter requirements: the barrier needs to be issued between store to rq->curr and switch_mm_cid(), which happens earlier than: - spin_unlock(), - switch_to(). So it's fine when the architecture switch_mm happens to have that barrier already, but less so when the architecture only provides the full barrier in switch_to() or spin_unlock(). It is a bug in the rseq switch_mm_cid() implementation. All architectures that don't have memory barriers in switch_mm(), but rather have the full barrier either in finish_lock_switch() or switch_to() have them too late for the needs of switch_mm_cid(). Introduce a new smp_mb__after_switch_mm(), defined as smp_mb() in the generic barrier.h header, and use it in switch_mm_cid() for scheduler transitions where switch_mm() is expected to provide a memory barrier. Architectures can override smp_mb__after_switch_mm() if their switch_mm() implementation provides an implicit memory barrier. Override it with a no-op on x86 which implicitly provide this memory barrier by writing to CR3. Link: https://lore.kernel.org/lkml/20240305145335.2696125-1-yeoreum.yun@arm.com/ Reported-by: levi.yun <yeoreum.yun@arm.com> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Fixes: 223baf9d17f2 ("sched: Fix performance regression introduced by mm_cid") Cc: <stable@vger.kernel.org> # 6.4.x Cc: Ingo Molnar <mingo@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Vincent Guittot <vincent.guittot@linaro.org> Cc: Juri Lelli <juri.lelli@redhat.com> Cc: Dietmar Eggemann <dietmar.eggemann@arm.com> Cc: Ben Segall <bsegall@google.com> Cc: Mel Gorman <mgorman@suse.de> Cc: Daniel Bristot de Oliveira <bristot@redhat.com> Cc: Valentin Schneider <vschneid@redhat.com> Cc: levi.yun <yeoreum.yun@arm.com> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Will Deacon <will@kernel.org> Cc: Aaron Lu <aaron.lu@intel.com> --- arch/x86/include/asm/barrier.h | 3 +++ include/asm-generic/barrier.h | 8 ++++++++ kernel/sched/sched.h | 20 ++++++++++++++------ 3 files changed, 25 insertions(+), 6 deletions(-) diff --git a/arch/x86/include/asm/barrier.h b/arch/x86/include/asm/barrier.h index 35389b2af88e..0d5e54201eb2 100644 --- a/arch/x86/include/asm/barrier.h +++ b/arch/x86/include/asm/barrier.h @@ -79,6 +79,9 @@ do { \ #define __smp_mb__before_atomic() do { } while (0) #define __smp_mb__after_atomic() do { } while (0) +/* Writing to CR3 provides a full memory barrier in switch_mm(). */ +#define smp_mb__after_switch_mm() do { } while (0) + #include <asm-generic/barrier.h> /* diff --git a/include/asm-generic/barrier.h b/include/asm-generic/barrier.h index 961f4d88f9ef..5a6c94d7a598 100644 --- a/include/asm-generic/barrier.h +++ b/include/asm-generic/barrier.h @@ -296,5 +296,13 @@ do { \ #define io_stop_wc() do { } while (0) #endif +/* + * Architectures that guarantee an implicit smp_mb() in switch_mm() + * can override smp_mb__after_switch_mm. + */ +#ifndef smp_mb__after_switch_mm +#define smp_mb__after_switch_mm() smp_mb() +#endif + #endif /* !__ASSEMBLY__ */ #endif /* __ASM_GENERIC_BARRIER_H */ diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h index 2e5a95486a42..044d842c696c 100644 --- a/kernel/sched/sched.h +++ b/kernel/sched/sched.h @@ -79,6 +79,8 @@ # include <asm/paravirt_api_clock.h> #endif +#include <asm/barrier.h> + #include "cpupri.h" #include "cpudeadline.h" @@ -3481,13 +3483,19 @@ static inline void switch_mm_cid(struct rq *rq, * between rq->curr store and load of {prev,next}->mm->pcpu_cid[cpu]. * Provide it here. */ - if (!prev->mm) // from kernel + if (!prev->mm) { // from kernel smp_mb(); - /* - * user -> user transition guarantees a memory barrier through - * switch_mm() when current->mm changes. If current->mm is - * unchanged, no barrier is needed. - */ + } else { // from user + /* + * user -> user transition relies on an implicit + * memory barrier in switch_mm() when + * current->mm changes. If the architecture + * switch_mm() does not have an implicit memory + * barrier, it is emitted here. If current->mm + * is unchanged, no barrier is needed. + */ + smp_mb__after_switch_mm(); + } } if (prev->mm_cid_active) { mm_cid_snapshot_time(rq, prev->mm); -- 2.39.2 IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
On Mon, Mar 18, 2024 at 10:01:26AM +0200, Sakari Ailus wrote:
> Unregister the MEI VSC interrupt handler before system suspend and
> re-register it at system resume time. This mirrors implementation of other
> MEI devices.
>
> This patch fixes the bug that causes continuous stream of MEI VSC errors
> after system resume.
>
> Fixes: 386a766c4169 ("mei: Add MEI hardware support for IVSC device")
> Cc: stable@vger.kernel.org # for 6.8
> Reported-by: Dominik Brodowski <linux@dominikbrodowski.net>
> Signed-off-by: Wentong Wu <wentong.wu@intel.com>
> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
> ---
> drivers/misc/mei/platform-vsc.c | 17 ++++++-
> drivers/misc/mei/vsc-tp.c | 84 +++++++++++++++++++++++----------
> drivers/misc/mei/vsc-tp.h | 3 ++
> 3 files changed, 78 insertions(+), 26 deletions(-)
What is the git commit id of this in Linus's tree?
thanks,
greg k-h
The index in the loop has already been added one and is equal to the number of PDOs to be updated when leaving the loop. Fixes: cd099cde4ed2 ("usb: typec: tcpm: Support multiple capabilities") Cc: stable@vger.kernel.org Signed-off-by: Kyle Tso <kyletso@google.com> --- drivers/usb/typec/tcpm/tcpm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c index 3d505614bff1..566dad0cb9d3 100644 --- a/drivers/usb/typec/tcpm/tcpm.c +++ b/drivers/usb/typec/tcpm/tcpm.c @@ -6852,14 +6852,14 @@ static int tcpm_pd_set(struct typec_port *p, struct usb_power_delivery *pd) if (data->sink_desc.pdo[0]) { for (i = 0; i < PDO_MAX_OBJECTS && data->sink_desc.pdo[i]; i++) port->snk_pdo[i] = data->sink_desc.pdo[i]; - port->nr_snk_pdo = i + 1; + port->nr_snk_pdo = i; port->operating_snk_mw = data->operating_snk_mw; } if (data->source_desc.pdo[0]) { for (i = 0; i < PDO_MAX_OBJECTS && data->source_desc.pdo[i]; i++) port->snk_pdo[i] = data->source_desc.pdo[i]; - port->nr_src_pdo = i + 1; + port->nr_src_pdo = i; } switch (port->state) { -- 2.44.0.291.gc1ea87d7ee-goog
The attribute writing should return the number of bytes used from the buffer on success. Fixes: a7cff92f0635 ("usb: typec: USB Power Delivery helpers for ports and partners") Cc: stable@vger.kernel.org Signed-off-by: Kyle Tso <kyletso@google.com> --- drivers/usb/typec/class.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/usb/typec/class.c b/drivers/usb/typec/class.c index 389c7f0b8d93..9610e647a8d4 100644 --- a/drivers/usb/typec/class.c +++ b/drivers/usb/typec/class.c @@ -1310,6 +1310,7 @@ static ssize_t select_usb_power_delivery_store(struct device *dev, { struct typec_port *port = to_typec_port(dev); struct usb_power_delivery *pd; + int ret; if (!port->ops || !port->ops->pd_set) return -EOPNOTSUPP; @@ -1318,7 +1319,11 @@ static ssize_t select_usb_power_delivery_store(struct device *dev, if (!pd) return -EINVAL; - return port->ops->pd_set(port, pd); + ret = port->ops->pd_set(port, pd); + if (ret) + return ret; + + return size; } static ssize_t select_usb_power_delivery_show(struct device *dev, -- 2.44.0.291.gc1ea87d7ee-goog
Please backport b3810c5a2cc4a6665f7a65bed5393c75ce3f3aa2 x86/efistub: Clear decompressor BSS in native EFI entrypoint to stable kernels v6.1 and newer. Thanks, Ard.
On Fri, Mar 08, 2024 at 05:26:00PM +0200, Dragos Tatulea wrote: > When the skb is reorganized during esp_output (!esp->inline), the pages > coming from the original skb fragments are supposed to be released back > to the system through put_page. But if the skb fragment pages are > originating from a page_pool, calling put_page on them will trigger a > page_pool leak which will eventually result in a crash. > > This leak can be easily observed when using CONFIG_DEBUG_VM and doing > ipsec + gre (non offloaded) forwarding: ... > The suggested fix is to introduce a new wrapper (skb_page_unref) that > covers page refcounting for page_pool pages as well. > > Cc: stable@vger.kernel.org > Fixes: 6a5bcd84e886 ("page_pool: Allow drivers to hint on SKB recycling") > Reported-and-tested-by: Anatoli N.Chechelnickiy <Anatoli.Chechelnickiy@m.interpipe.biz> > Reported-by: Ian Kumlien <ian.kumlien@gmail.com> > Link: https://lore.kernel.org/netdev/CAA85sZvvHtrpTQRqdaOx6gd55zPAVsqMYk_Lwh4Md5knTq7AyA@mail.gmail.com > Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com> > Reviewed-by: Mina Almasry <almasrymina@google.com> > Reviewed-by: Jakub Kicinski <kuba@kernel.org> Applied to the ipsec tree, thanks a lot!
On 12/03/2024 0:30, Michael Liang wrote: > The mlx5 comp irq name scheme is changed a little bit between > commit 3663ad34bc70 ("net/mlx5: Shift control IRQ to the last index") > and commit 3354822cde5a ("net/mlx5: Use dynamic msix vectors allocation"). > The index in the comp irq name used to start from 0 but now it starts > from 1. There is nothing critical here, but it's harmless to change > back to the old behavior, a.k.a starting from 0. > > Fixes: 3354822cde5a ("net/mlx5: Use dynamic msix vectors allocation") > Reviewed-by: Mohamed Khalfella <mkhalfella@purestorage.com> > Reviewed-by: Yuanyuan Zhong <yzhong@purestorage.com> > Signed-off-by: Michael Liang <mliang@purestorage.com> Reviewed-by: Shay Drory <shayd@nvidia.com> > --- > drivers/net/ethernet/mellanox/mlx5/core/pci_irq.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/net/ethernet/mellanox/mlx5/core/pci_irq.c b/drivers/net/ethernet/mellanox/mlx5/core/pci_irq.c > index 4dcf995cb1a2..6bac8ad70ba6 100644 > --- a/drivers/net/ethernet/mellanox/mlx5/core/pci_irq.c > +++ b/drivers/net/ethernet/mellanox/mlx5/core/pci_irq.c > @@ -19,6 +19,7 @@ > #define MLX5_IRQ_CTRL_SF_MAX 8 > /* min num of vectors for SFs to be enabled */ > #define MLX5_IRQ_VEC_COMP_BASE_SF 2 > +#define MLX5_IRQ_VEC_COMP_BASE 1 > > #define MLX5_EQ_SHARE_IRQ_MAX_COMP (8) > #define MLX5_EQ_SHARE_IRQ_MAX_CTRL (UINT_MAX) > @@ -246,6 +247,7 @@ static void irq_set_name(struct mlx5_irq_pool *pool, char *name, int vecidx) > return; > } > > + vecidx -= MLX5_IRQ_VEC_COMP_BASE; > snprintf(name, MLX5_MAX_IRQ_NAME, "mlx5_comp%d", vecidx); > } > > @@ -585,7 +587,7 @@ struct mlx5_irq *mlx5_irq_request_vector(struct mlx5_core_dev *dev, u16 cpu, > struct mlx5_irq_table *table = mlx5_irq_table_get(dev); > struct mlx5_irq_pool *pool = table->pcif_pool; > struct irq_affinity_desc af_desc; > - int offset = 1; > + int offset = MLX5_IRQ_VEC_COMP_BASE; > > if (!pool->xa_num_irqs.max) > offset = 0;
On Mar 18, 2024, at 9:39 PM, Boqun Feng <boqun.feng@gmail.com> wrote: > On Mon, Mar 18, 2024 at 08:17:07PM -0700, Laine Taffin Altman wrote: >> On Mar 18, 2024, at 10:25 AM, Boqun Feng <boqun.feng@gmail.com> wrote: >>> On Wed, Mar 13, 2024 at 11:09:37PM +0000, Benno Lossin wrote: >>>> From: Laine Taffin Altman <alexanderaltman@me.com> >>>> >>>> It is not enough for a type to be a ZST to guarantee that zeroed memory >>>> is a valid value for it; it must also be inhabited. Creating a value of >>>> an uninhabited type, ZST or no, is immediate UB. >>>> Thus remove the implementation of `Zeroable` for `Infallible`, since >>>> that type is not inhabited. >>>> >>>> Cc: stable@vger.kernel.org >>>> Fixes: 38cde0bd7b67 ("rust: init: add `Zeroable` trait and `init::zeroed` function") >>>> Closes: https://github.com/Rust-for-Linux/pinned-init/pull/13 >>>> Signed-off-by: Laine Taffin Altman <alexanderaltman@me.com> >>>> Signed-off-by: Benno Lossin <benno.lossin@proton.me> >>> >>> I think either in the commit log or in the code comment, there better be >>> a link or explanation on "(un)inhabited type". The rest looks good to >>> me. >> >> Would the following be okay for that purpose? >> >> A type is inhabited if at least one valid value of that type exists; a >> type is uninhabited if no valid values of that type exist. The terms >> "inhabited" and "uninhabited" in this sense originate in type theory, >> a branch of mathematics. >> >> In Rust, producing an invalid value of any type is immediate undefined >> behavior (UB); this includes via zeroing memory. Therefore, since an >> uninhabited type has no valid values, producing any values at all for >> it is UB. >> >> The Rust standard library type `core::convert::Infallible` is >> uninhabited, by virtue of having been declared as an enum with no >> cases, which always produces uninhabited types in Rust. Thus, remove >> the implementation of `Zeroable` for `Infallible`, thereby avoiding >> the UB. >> > > Yeah, this works for me. Thanks! Great! Should it be re-sent or can the new wording be incorporated upon merge? Thank, Laine > > Regards, > Boqun > >> Thanks, >> Laine >> >>> >>> Reviewed-by: Boqun Feng <boqun.feng@gmail.com> >>> >>> Regards, >>> Boqun >>> >>>> --- >>>> rust/kernel/init.rs | 4 ++-- >>>> 1 file changed, 2 insertions(+), 2 deletions(-) >>>> >>>> diff --git a/rust/kernel/init.rs b/rust/kernel/init.rs >>>> index 424257284d16..538e03cfc84a 100644 >>>> --- a/rust/kernel/init.rs >>>> +++ b/rust/kernel/init.rs >>>> @@ -1292,8 +1292,8 @@ macro_rules! impl_zeroable { >>>> i8, i16, i32, i64, i128, isize, >>>> f32, f64, >>>> >>>> - // SAFETY: These are ZSTs, there is nothing to zero. >>>> - {<T: ?Sized>} PhantomData<T>, core::marker::PhantomPinned, Infallible, (), >>>> + // SAFETY: These are inhabited ZSTs, there is nothing to zero and a valid value exists. >>>> + {<T: ?Sized>} PhantomData<T>, core::marker::PhantomPinned, (), >>>> >>>> // SAFETY: Type is allowed to take any value, including all zeros. >>>> {<T>} MaybeUninit<T>, >>>> >>>> base-commit: 768409cff6cc89fe1194da880537a09857b6e4db >>>> -- >>>> 2.42.0 >>>> >>>> >>>> >>
[-- Attachment #1: Type: text/plain, Size: 1009 bytes --] On 18/03/2024 17:58, Philip Müller wrote: > I'm currently developing on the OrangePi Neo-01, which ships with two > similar touchpads using the Synaptics driver. On 6.7.10 those two > devices get detected normally. On 6.8.1 it seems to error out. > > I either get none, or at best only one of those two devices. > > i2c_hid_acpi: probe of i2c-XXX0001:00 failed with error -110 > i2c_hid_acpi: probe of i2c-XXX0002:00 failed with error -110 > > what would be the best way to debug this? > I found the regression in commit aa69d6974185e9f7a552ba982540a38e34f69690 HID: i2c-hid: Switch i2c_hid_parse() to goto style error handling When I use the commit before I can rmmod and modprobe in a batch script using a loop without erroring out to -110. Attached the testing script and dmesg log snippets #!/bin/bash for ((n=0;n<5;n++)) do sudo rmmod i2c_hid_acpi sleep 1 sudo modprobe i2c_hid_acpi --force-vermagic sleep 2 done I will try to use the code of 6.8.1 and revert that commit. -- Best, Philip [-- Attachment #2: regression-i2c.txt --] [-- Type: text/plain, Size: 20924 bytes --] Errors with https://github.com/torvalds/linux/commit/af93a167eda90192563bce64c4bb989836afac1f [ 3008.790912] input: OPI0001:00 0911:5288 Mouse as /devices/platform/AMDI0010:00/i2c-0/i2c-OPI0001:00/0018:0911:5288.008F/input/input353 [ 3008.791171] input: OPI0001:00 0911:5288 Touchpad as /devices/platform/AMDI0010:00/i2c-0/i2c-OPI0001:00/0018:0911:5288.008F/input/input354 [ 3008.791419] hid-multitouch 0018:0911:5288.008F: input,hidraw4: I2C HID v1.00 Mouse [OPI0001:00 0911:5288] on i2c-OPI0001:00 [ 3008.797498] input: OPI0002:00 0911:5288 Mouse as /devices/platform/AMDI0010:02/i2c-2/i2c-OPI0002:00/0018:0911:5288.0090/input/input355 [ 3008.797669] input: OPI0002:00 0911:5288 Touchpad as /devices/platform/AMDI0010:02/i2c-2/i2c-OPI0002:00/0018:0911:5288.0090/input/input356 [ 3008.797864] hid-multitouch 0018:0911:5288.0090: input,hidraw5: I2C HID v1.00 Mouse [OPI0002:00 0911:5288] on i2c-OPI0002:00 [ 3012.606771] input: OPI0002:00 0911:5288 Mouse as /devices/platform/AMDI0010:02/i2c-2/i2c-OPI0002:00/0018:0911:5288.0092/input/input360 [ 3012.606908] input: OPI0002:00 0911:5288 Touchpad as /devices/platform/AMDI0010:02/i2c-2/i2c-OPI0002:00/0018:0911:5288.0092/input/input361 [ 3012.607057] hid-multitouch 0018:0911:5288.0092: input,hidraw4: I2C HID v1.00 Mouse [OPI0002:00 0911:5288] on i2c-OPI0002:00 [ 3013.470476] i2c_hid_acpi i2c-OPI0001:00: can't add hid device: -110 [ 3013.524540] i2c_hid_acpi: probe of i2c-OPI0001:00 failed with error -110 [ 3017.196513] input: OPI0001:00 0911:5288 Mouse as /devices/platform/AMDI0010:00/i2c-0/i2c-OPI0001:00/0018:0911:5288.0094/input/input365 [ 3017.196824] input: OPI0001:00 0911:5288 Touchpad as /devices/platform/AMDI0010:00/i2c-0/i2c-OPI0001:00/0018:0911:5288.0094/input/input366 [ 3017.197175] hid-multitouch 0018:0911:5288.0094: input,hidraw4: I2C HID v1.00 Mouse [OPI0001:00 0911:5288] on i2c-OPI0001:00 [ 3017.199658] input: OPI0002:00 0911:5288 Mouse as /devices/platform/AMDI0010:02/i2c-2/i2c-OPI0002:00/0018:0911:5288.0095/input/input367 [ 3017.199760] input: OPI0002:00 0911:5288 Touchpad as /devices/platform/AMDI0010:02/i2c-2/i2c-OPI0002:00/0018:0911:5288.0095/input/input368 [ 3017.199826] hid-multitouch 0018:0911:5288.0095: input,hidraw5: I2C HID v1.00 Mouse [OPI0002:00 0911:5288] on i2c-OPI0002:00 [ 3020.999460] input: OPI0001:00 0911:5288 Mouse as /devices/platform/AMDI0010:00/i2c-0/i2c-OPI0001:00/0018:0911:5288.0097/input/input372 [ 3020.999552] input: OPI0002:00 0911:5288 Mouse as /devices/platform/AMDI0010:02/i2c-2/i2c-OPI0002:00/0018:0911:5288.0098/input/input374 [ 3020.999673] input: OPI0001:00 0911:5288 Touchpad as /devices/platform/AMDI0010:00/i2c-0/i2c-OPI0001:00/0018:0911:5288.0097/input/input373 [ 3020.999823] input: OPI0002:00 0911:5288 Touchpad as /devices/platform/AMDI0010:02/i2c-2/i2c-OPI0002:00/0018:0911:5288.0098/input/input375 [ 3020.999944] hid-multitouch 0018:0911:5288.0097: input,hidraw4: I2C HID v1.00 Mouse [OPI0001:00 0911:5288] on i2c-OPI0001:00 [ 3021.000048] hid-multitouch 0018:0911:5288.0098: input,hidraw5: I2C HID v1.00 Mouse [OPI0002:00 0911:5288] on i2c-OPI0002:00 [ 3025.789683] i2c_hid_acpi i2c-OPI0002:00: can't add hid device: -110 [ 3025.792247] i2c_hid_acpi i2c-OPI0001:00: can't add hid device: -110 [ 3025.856860] i2c_hid_acpi: probe of i2c-OPI0001:00 failed with error -110 [ 3025.893633] i2c_hid_acpi: probe of i2c-OPI0002:00 failed with error -110 [ 3038.880093] i2c_hid_acpi i2c-OPI0002:00: can't add hid device: -110 [ 3038.884960] i2c_hid_acpi i2c-OPI0001:00: can't add hid device: -110 [ 3038.938955] i2c_hid_acpi: probe of i2c-OPI0002:00 failed with error -110 [ 3038.945724] i2c_hid_acpi: probe of i2c-OPI0001:00 failed with error -110 [ 3042.494261] input: OPI0002:00 0911:5288 Mouse as /devices/platform/AMDI0010:02/i2c-2/i2c-OPI0002:00/0018:0911:5288.009D/input/input385 [ 3042.494436] input: OPI0001:00 0911:5288 Mouse as /devices/platform/AMDI0010:00/i2c-0/i2c-OPI0001:00/0018:0911:5288.009C/input/input387 [ 3042.494526] input: OPI0002:00 0911:5288 Touchpad as /devices/platform/AMDI0010:02/i2c-2/i2c-OPI0002:00/0018:0911:5288.009D/input/input386 [ 3042.494807] input: OPI0001:00 0911:5288 Touchpad as /devices/platform/AMDI0010:00/i2c-0/i2c-OPI0001:00/0018:0911:5288.009C/input/input388 [ 3042.494975] hid-multitouch 0018:0911:5288.009D: input,hidraw4: I2C HID v1.00 Mouse [OPI0002:00 0911:5288] on i2c-OPI0002:00 [ 3042.495104] hid-multitouch 0018:0911:5288.009C: input,hidraw5: I2C HID v1.00 Mouse [OPI0001:00 0911:5288] on i2c-OPI0001:00 [ 3046.400593] input: OPI0002:00 0911:5288 Mouse as /devices/platform/AMDI0010:02/i2c-2/i2c-OPI0002:00/0018:0911:5288.009E/input/input389 [ 3046.400797] input: OPI0002:00 0911:5288 Touchpad as /devices/platform/AMDI0010:02/i2c-2/i2c-OPI0002:00/0018:0911:5288.009E/input/input390 [ 3046.401017] hid-multitouch 0018:0911:5288.009E: input,hidraw0: I2C HID v1.00 Mouse [OPI0002:00 0911:5288] on i2c-OPI0002:00 [ 3047.254001] i2c_hid_acpi i2c-OPI0001:00: can't add hid device: -110 [ 3047.338357] i2c_hid_acpi: probe of i2c-OPI0001:00 failed with error -110 [ 3054.806603] input: OPI0001:00 0911:5288 Mouse as /devices/platform/AMDI0010:00/i2c-0/i2c-OPI0001:00/0018:0911:5288.009F/input/input391 [ 3054.806881] input: OPI0002:00 0911:5288 Mouse as /devices/platform/AMDI0010:02/i2c-2/i2c-OPI0002:00/0018:0911:5288.00A0/input/input393 [ 3054.806976] input: OPI0001:00 0911:5288 Touchpad as /devices/platform/AMDI0010:00/i2c-0/i2c-OPI0001:00/0018:0911:5288.009F/input/input392 [ 3054.807170] input: OPI0002:00 0911:5288 Touchpad as /devices/platform/AMDI0010:02/i2c-2/i2c-OPI0002:00/0018:0911:5288.00A0/input/input394 [ 3054.807341] hid-multitouch 0018:0911:5288.009F: input,hidraw0: I2C HID v1.00 Mouse [OPI0001:00 0911:5288] on i2c-OPI0001:00 [ 3054.807520] hid-multitouch 0018:0911:5288.00A0: input,hidraw4: I2C HID v1.00 Mouse [OPI0002:00 0911:5288] on i2c-OPI0002:00 [ 3064.452881] i2c_hid_acpi i2c-OPI0002:00: can't add hid device: -110 [ 3064.456850] i2c_hid_acpi i2c-OPI0001:00: can't add hid device: -110 [ 3064.517131] i2c_hid_acpi: probe of i2c-OPI0002:00 failed with error -110 [ 3064.533487] i2c_hid_acpi: probe of i2c-OPI0001:00 failed with error -110 [ 3082.597720] input: OPI0001:00 0911:5288 Mouse as /devices/platform/AMDI0010:00/i2c-0/i2c-OPI0001:00/0018:0911:5288.00A2/input/input398 [ 3082.597901] input: OPI0001:00 0911:5288 Touchpad as /devices/platform/AMDI0010:00/i2c-0/i2c-OPI0001:00/0018:0911:5288.00A2/input/input399 [ 3082.597951] input: OPI0002:00 0911:5288 Mouse as /devices/platform/AMDI0010:02/i2c-2/i2c-OPI0002:00/0018:0911:5288.00A3/input/input400 [ 3082.598069] hid-multitouch 0018:0911:5288.00A2: input,hidraw0: I2C HID v1.00 Mouse [OPI0001:00 0911:5288] on i2c-OPI0001:00 [ 3082.598485] input: OPI0002:00 0911:5288 Touchpad as /devices/platform/AMDI0010:02/i2c-2/i2c-OPI0002:00/0018:0911:5288.00A3/input/input401 [ 3082.598950] hid-multitouch 0018:0911:5288.00A3: input,hidraw4: I2C HID v1.00 Mouse [OPI0002:00 0911:5288] on i2c-OPI0002:00 [ 3092.182446] i2c_hid_acpi i2c-OPI0001:00: can't add hid device: -110 [ 3092.183473] i2c_hid_acpi i2c-OPI0002:00: can't add hid device: -110 [ 3092.227784] i2c_hid_acpi: probe of i2c-OPI0002:00 failed with error -110 [ 3092.241669] i2c_hid_acpi: probe of i2c-OPI0001:00 failed with error -110 [ 3095.759747] input: OPI0001:00 0911:5288 Mouse as /devices/platform/AMDI0010:00/i2c-0/i2c-OPI0001:00/0018:0911:5288.00A6/input/input408 [ 3095.759919] input: OPI0001:00 0911:5288 Touchpad as /devices/platform/AMDI0010:00/i2c-0/i2c-OPI0001:00/0018:0911:5288.00A6/input/input409 [ 3095.760098] hid-multitouch 0018:0911:5288.00A6: input,hidraw4: I2C HID v1.00 Mouse [OPI0001:00 0911:5288] on i2c-OPI0001:00 [ 3096.610008] i2c_hid_acpi i2c-OPI0002:00: can't add hid device: -110 [ 3096.710767] i2c_hid_acpi: probe of i2c-OPI0002:00 failed with error -110 [ 3101.302732] i2c_hid_acpi i2c-OPI0002:00: can't add hid device: -110 [ 3101.302945] i2c_hid_acpi i2c-OPI0001:00: can't add hid device: -110 [ 3101.390289] i2c_hid_acpi: probe of i2c-OPI0002:00 failed with error -110 [ 3101.416972] i2c_hid_acpi: probe of i2c-OPI0001:00 failed with error -110 [ 3104.932305] input: OPI0001:00 0911:5288 Mouse as /devices/platform/AMDI0010:00/i2c-0/i2c-OPI0001:00/0018:0911:5288.00A8/input/input413 [ 3104.932507] input: OPI0001:00 0911:5288 Touchpad as /devices/platform/AMDI0010:00/i2c-0/i2c-OPI0001:00/0018:0911:5288.00A8/input/input414 [ 3104.932660] hid-multitouch 0018:0911:5288.00A8: input,hidraw0: I2C HID v1.00 Mouse [OPI0001:00 0911:5288] on i2c-OPI0001:00 [ 3105.785640] i2c_hid_acpi i2c-OPI0002:00: can't add hid device: -110 [ 3105.873322] i2c_hid_acpi: probe of i2c-OPI0002:00 failed with error -110 Fine with https://github.com/torvalds/linux/commit/aa69d6974185e9f7a552ba982540a38e34f69690 [ 3155.416063] input: OPI0001:00 0911:5288 Mouse as /devices/platform/AMDI0010:00/i2c-0/i2c-OPI0001:00/0018:0911:5288.00AA/input/input418 [ 3155.416167] input: OPI0001:00 0911:5288 Touchpad as /devices/platform/AMDI0010:00/i2c-0/i2c-OPI0001:00/0018:0911:5288.00AA/input/input419 [ 3155.416178] input: OPI0002:00 0911:5288 Mouse as /devices/platform/AMDI0010:02/i2c-2/i2c-OPI0002:00/0018:0911:5288.00AB/input/input420 [ 3155.416249] hid-multitouch 0018:0911:5288.00AA: input,hidraw4: I2C HID v1.00 Mouse [OPI0001:00 0911:5288] on i2c-OPI0001:00 [ 3155.416341] input: OPI0002:00 0911:5288 Touchpad as /devices/platform/AMDI0010:02/i2c-2/i2c-OPI0002:00/0018:0911:5288.00AB/input/input421 [ 3155.416459] hid-multitouch 0018:0911:5288.00AB: input,hidraw5: I2C HID v1.00 Mouse [OPI0002:00 0911:5288] on i2c-OPI0002:00 [ 3159.412480] input: OPI0001:00 0911:5288 Mouse as /devices/platform/AMDI0010:00/i2c-0/i2c-OPI0001:00/0018:0911:5288.00AD/input/input425 [ 3159.412620] input: OPI0001:00 0911:5288 Touchpad as /devices/platform/AMDI0010:00/i2c-0/i2c-OPI0001:00/0018:0911:5288.00AD/input/input426 [ 3159.412793] hid-multitouch 0018:0911:5288.00AD: input,hidraw4: I2C HID v1.00 Mouse [OPI0001:00 0911:5288] on i2c-OPI0001:00 [ 3159.412936] input: OPI0002:00 0911:5288 Mouse as /devices/platform/AMDI0010:02/i2c-2/i2c-OPI0002:00/0018:0911:5288.00AE/input/input427 [ 3159.413153] input: OPI0002:00 0911:5288 Touchpad as /devices/platform/AMDI0010:02/i2c-2/i2c-OPI0002:00/0018:0911:5288.00AE/input/input428 [ 3159.413342] hid-multitouch 0018:0911:5288.00AE: input,hidraw5: I2C HID v1.00 Mouse [OPI0002:00 0911:5288] on i2c-OPI0002:00 [ 3163.232539] input: OPI0001:00 0911:5288 Mouse as /devices/platform/AMDI0010:00/i2c-0/i2c-OPI0001:00/0018:0911:5288.00B0/input/input432 [ 3163.232855] input: OPI0001:00 0911:5288 Touchpad as /devices/platform/AMDI0010:00/i2c-0/i2c-OPI0001:00/0018:0911:5288.00B0/input/input433 [ 3163.233222] hid-multitouch 0018:0911:5288.00B0: input,hidraw4: I2C HID v1.00 Mouse [OPI0001:00 0911:5288] on i2c-OPI0001:00 [ 3163.235194] input: OPI0002:00 0911:5288 Mouse as /devices/platform/AMDI0010:02/i2c-2/i2c-OPI0002:00/0018:0911:5288.00B1/input/input434 [ 3163.235299] input: OPI0002:00 0911:5288 Touchpad as /devices/platform/AMDI0010:02/i2c-2/i2c-OPI0002:00/0018:0911:5288.00B1/input/input435 [ 3163.235385] hid-multitouch 0018:0911:5288.00B1: input,hidraw5: I2C HID v1.00 Mouse [OPI0002:00 0911:5288] on i2c-OPI0002:00 [ 3167.138382] input: OPI0002:00 0911:5288 Mouse as /devices/platform/AMDI0010:02/i2c-2/i2c-OPI0002:00/0018:0911:5288.00B3/input/input439 [ 3167.138470] input: OPI0001:00 0911:5288 Mouse as /devices/platform/AMDI0010:00/i2c-0/i2c-OPI0001:00/0018:0911:5288.00B4/input/input441 [ 3167.138541] input: OPI0002:00 0911:5288 Touchpad as /devices/platform/AMDI0010:02/i2c-2/i2c-OPI0002:00/0018:0911:5288.00B3/input/input440 [ 3167.138636] input: OPI0001:00 0911:5288 Touchpad as /devices/platform/AMDI0010:00/i2c-0/i2c-OPI0001:00/0018:0911:5288.00B4/input/input442 [ 3167.138826] hid-multitouch 0018:0911:5288.00B3: input,hidraw4: I2C HID v1.00 Mouse [OPI0002:00 0911:5288] on i2c-OPI0002:00 [ 3167.138902] hid-multitouch 0018:0911:5288.00B4: input,hidraw5: I2C HID v1.00 Mouse [OPI0001:00 0911:5288] on i2c-OPI0001:00 [ 3171.038312] input: OPI0002:00 0911:5288 Mouse as /devices/platform/AMDI0010:02/i2c-2/i2c-OPI0002:00/0018:0911:5288.00B6/input/input446 [ 3171.038416] input: OPI0002:00 0911:5288 Touchpad as /devices/platform/AMDI0010:02/i2c-2/i2c-OPI0002:00/0018:0911:5288.00B6/input/input447 [ 3171.038509] hid-multitouch 0018:0911:5288.00B6: input,hidraw4: I2C HID v1.00 Mouse [OPI0002:00 0911:5288] on i2c-OPI0002:00 [ 3171.038764] input: OPI0001:00 0911:5288 Mouse as /devices/platform/AMDI0010:00/i2c-0/i2c-OPI0001:00/0018:0911:5288.00B7/input/input448 [ 3171.039029] input: OPI0001:00 0911:5288 Touchpad as /devices/platform/AMDI0010:00/i2c-0/i2c-OPI0001:00/0018:0911:5288.00B7/input/input449 [ 3171.039303] hid-multitouch 0018:0911:5288.00B7: input,hidraw5: I2C HID v1.00 Mouse [OPI0001:00 0911:5288] on i2c-OPI0001:00 [ 3176.144371] input: OPI0001:00 0911:5288 Mouse as /devices/platform/AMDI0010:00/i2c-0/i2c-OPI0001:00/0018:0911:5288.00B9/input/input453 [ 3176.144490] input: OPI0001:00 0911:5288 Touchpad as /devices/platform/AMDI0010:00/i2c-0/i2c-OPI0001:00/0018:0911:5288.00B9/input/input454 [ 3176.144581] hid-multitouch 0018:0911:5288.00B9: input,hidraw4: I2C HID v1.00 Mouse [OPI0001:00 0911:5288] on i2c-OPI0001:00 [ 3176.144619] input: OPI0002:00 0911:5288 Mouse as /devices/platform/AMDI0010:02/i2c-2/i2c-OPI0002:00/0018:0911:5288.00BA/input/input455 [ 3176.144782] input: OPI0002:00 0911:5288 Touchpad as /devices/platform/AMDI0010:02/i2c-2/i2c-OPI0002:00/0018:0911:5288.00BA/input/input456 [ 3176.144967] hid-multitouch 0018:0911:5288.00BA: input,hidraw5: I2C HID v1.00 Mouse [OPI0002:00 0911:5288] on i2c-OPI0002:00 [ 3179.994328] input: OPI0002:00 0911:5288 Mouse as /devices/platform/AMDI0010:02/i2c-2/i2c-OPI0002:00/0018:0911:5288.00BC/input/input460 [ 3179.994386] input: OPI0001:00 0911:5288 Mouse as /devices/platform/AMDI0010:00/i2c-0/i2c-OPI0001:00/0018:0911:5288.00BD/input/input462 [ 3179.994524] input: OPI0002:00 0911:5288 Touchpad as /devices/platform/AMDI0010:02/i2c-2/i2c-OPI0002:00/0018:0911:5288.00BC/input/input461 [ 3179.994653] input: OPI0001:00 0911:5288 Touchpad as /devices/platform/AMDI0010:00/i2c-0/i2c-OPI0001:00/0018:0911:5288.00BD/input/input463 [ 3179.994976] hid-multitouch 0018:0911:5288.00BC: input,hidraw4: I2C HID v1.00 Mouse [OPI0002:00 0911:5288] on i2c-OPI0002:00 [ 3179.995119] hid-multitouch 0018:0911:5288.00BD: input,hidraw5: I2C HID v1.00 Mouse [OPI0001:00 0911:5288] on i2c-OPI0001:00 [ 3183.940584] input: OPI0002:00 0911:5288 Mouse as /devices/platform/AMDI0010:02/i2c-2/i2c-OPI0002:00/0018:0911:5288.00BF/input/input467 [ 3183.940818] input: OPI0002:00 0911:5288 Touchpad as /devices/platform/AMDI0010:02/i2c-2/i2c-OPI0002:00/0018:0911:5288.00BF/input/input468 [ 3183.940955] hid-multitouch 0018:0911:5288.00BF: input,hidraw4: I2C HID v1.00 Mouse [OPI0002:00 0911:5288] on i2c-OPI0002:00 [ 3183.943668] input: OPI0001:00 0911:5288 Mouse as /devices/platform/AMDI0010:00/i2c-0/i2c-OPI0001:00/0018:0911:5288.00C0/input/input469 [ 3183.943743] input: OPI0001:00 0911:5288 Touchpad as /devices/platform/AMDI0010:00/i2c-0/i2c-OPI0001:00/0018:0911:5288.00C0/input/input470 [ 3183.943811] hid-multitouch 0018:0911:5288.00C0: input,hidraw5: I2C HID v1.00 Mouse [OPI0001:00 0911:5288] on i2c-OPI0001:00 [ 3187.886502] input: OPI0002:00 0911:5288 Mouse as /devices/platform/AMDI0010:02/i2c-2/i2c-OPI0002:00/0018:0911:5288.00C2/input/input474 [ 3187.886587] input: OPI0002:00 0911:5288 Touchpad as /devices/platform/AMDI0010:02/i2c-2/i2c-OPI0002:00/0018:0911:5288.00C2/input/input475 [ 3187.886658] hid-multitouch 0018:0911:5288.00C2: input,hidraw4: I2C HID v1.00 Mouse [OPI0002:00 0911:5288] on i2c-OPI0002:00 [ 3187.886999] input: OPI0001:00 0911:5288 Mouse as /devices/platform/AMDI0010:00/i2c-0/i2c-OPI0001:00/0018:0911:5288.00C3/input/input476 [ 3187.887179] input: OPI0001:00 0911:5288 Touchpad as /devices/platform/AMDI0010:00/i2c-0/i2c-OPI0001:00/0018:0911:5288.00C3/input/input477 [ 3187.887359] hid-multitouch 0018:0911:5288.00C3: input,hidraw5: I2C HID v1.00 Mouse [OPI0001:00 0911:5288] on i2c-OPI0001:00 [ 3191.689758] input: OPI0001:00 0911:5288 Mouse as /devices/platform/AMDI0010:00/i2c-0/i2c-OPI0001:00/0018:0911:5288.00C5/input/input481 [ 3191.690052] input: OPI0001:00 0911:5288 Touchpad as /devices/platform/AMDI0010:00/i2c-0/i2c-OPI0001:00/0018:0911:5288.00C5/input/input482 [ 3191.690413] hid-multitouch 0018:0911:5288.00C5: input,hidraw4: I2C HID v1.00 Mouse [OPI0001:00 0911:5288] on i2c-OPI0001:00 [ 3191.693215] input: OPI0002:00 0911:5288 Mouse as /devices/platform/AMDI0010:02/i2c-2/i2c-OPI0002:00/0018:0911:5288.00C6/input/input483 [ 3191.693353] input: OPI0002:00 0911:5288 Touchpad as /devices/platform/AMDI0010:02/i2c-2/i2c-OPI0002:00/0018:0911:5288.00C6/input/input484 [ 3191.693513] hid-multitouch 0018:0911:5288.00C6: input,hidraw5: I2C HID v1.00 Mouse [OPI0002:00 0911:5288] on i2c-OPI0002:00 [ 3197.842522] input: OPI0002:00 0911:5288 Mouse as /devices/platform/AMDI0010:02/i2c-2/i2c-OPI0002:00/0018:0911:5288.00C8/input/input488 [ 3197.842605] input: OPI0001:00 0911:5288 Mouse as /devices/platform/AMDI0010:00/i2c-0/i2c-OPI0001:00/0018:0911:5288.00C9/input/input490 [ 3197.842821] input: OPI0002:00 0911:5288 Touchpad as /devices/platform/AMDI0010:02/i2c-2/i2c-OPI0002:00/0018:0911:5288.00C8/input/input489 [ 3197.842940] input: OPI0001:00 0911:5288 Touchpad as /devices/platform/AMDI0010:00/i2c-0/i2c-OPI0001:00/0018:0911:5288.00C9/input/input491 [ 3197.843137] hid-multitouch 0018:0911:5288.00C8: input,hidraw4: I2C HID v1.00 Mouse [OPI0002:00 0911:5288] on i2c-OPI0002:00 [ 3197.843202] hid-multitouch 0018:0911:5288.00C9: input,hidraw5: I2C HID v1.00 Mouse [OPI0001:00 0911:5288] on i2c-OPI0001:00 [ 3201.712374] input: OPI0002:00 0911:5288 Mouse as /devices/platform/AMDI0010:02/i2c-2/i2c-OPI0002:00/0018:0911:5288.00CB/input/input495 [ 3201.712472] input: OPI0001:00 0911:5288 Mouse as /devices/platform/AMDI0010:00/i2c-0/i2c-OPI0001:00/0018:0911:5288.00CC/input/input497 [ 3201.712569] input: OPI0002:00 0911:5288 Touchpad as /devices/platform/AMDI0010:02/i2c-2/i2c-OPI0002:00/0018:0911:5288.00CB/input/input496 [ 3201.712713] input: OPI0001:00 0911:5288 Touchpad as /devices/platform/AMDI0010:00/i2c-0/i2c-OPI0001:00/0018:0911:5288.00CC/input/input498 [ 3201.712847] hid-multitouch 0018:0911:5288.00CB: input,hidraw4: I2C HID v1.00 Mouse [OPI0002:00 0911:5288] on i2c-OPI0002:00 [ 3201.712898] hid-multitouch 0018:0911:5288.00CC: input,hidraw5: I2C HID v1.00 Mouse [OPI0001:00 0911:5288] on i2c-OPI0001:00 [ 3205.632267] input: OPI0001:00 0911:5288 Mouse as /devices/platform/AMDI0010:00/i2c-0/i2c-OPI0001:00/0018:0911:5288.00CE/input/input502 [ 3205.632522] input: OPI0001:00 0911:5288 Touchpad as /devices/platform/AMDI0010:00/i2c-0/i2c-OPI0001:00/0018:0911:5288.00CE/input/input503 [ 3205.632926] hid-multitouch 0018:0911:5288.00CE: input,hidraw4: I2C HID v1.00 Mouse [OPI0001:00 0911:5288] on i2c-OPI0001:00 [ 3205.635642] input: OPI0002:00 0911:5288 Mouse as /devices/platform/AMDI0010:02/i2c-2/i2c-OPI0002:00/0018:0911:5288.00CF/input/input504 [ 3205.635729] input: OPI0002:00 0911:5288 Touchpad as /devices/platform/AMDI0010:02/i2c-2/i2c-OPI0002:00/0018:0911:5288.00CF/input/input505 [ 3205.635832] hid-multitouch 0018:0911:5288.00CF: input,hidraw5: I2C HID v1.00 Mouse [OPI0002:00 0911:5288] on i2c-OPI0002:00 [ 3209.604485] input: OPI0002:00 0911:5288 Mouse as /devices/platform/AMDI0010:02/i2c-2/i2c-OPI0002:00/0018:0911:5288.00D1/input/input509 [ 3209.604647] input: OPI0002:00 0911:5288 Touchpad as /devices/platform/AMDI0010:02/i2c-2/i2c-OPI0002:00/0018:0911:5288.00D1/input/input510 [ 3209.604917] hid-multitouch 0018:0911:5288.00D1: input,hidraw4: I2C HID v1.00 Mouse [OPI0002:00 0911:5288] on i2c-OPI0002:00 [ 3209.605419] input: OPI0001:00 0911:5288 Mouse as /devices/platform/AMDI0010:00/i2c-0/i2c-OPI0001:00/0018:0911:5288.00D2/input/input511 [ 3209.605672] input: OPI0001:00 0911:5288 Touchpad as /devices/platform/AMDI0010:00/i2c-0/i2c-OPI0001:00/0018:0911:5288.00D2/input/input512 [ 3209.605913] hid-multitouch 0018:0911:5288.00D2: input,hidraw5: I2C HID v1.00 Mouse [OPI0001:00 0911:5288] on i2c-OPI0001:00 [ 3213.534413] input: OPI0001:00 0911:5288 Mouse as /devices/platform/AMDI0010:00/i2c-0/i2c-OPI0001:00/0018:0911:5288.00D4/input/input516 [ 3213.534580] input: OPI0002:00 0911:5288 Mouse as /devices/platform/AMDI0010:02/i2c-2/i2c-OPI0002:00/0018:0911:5288.00D5/input/input518 [ 3213.534596] input: OPI0001:00 0911:5288 Touchpad as /devices/platform/AMDI0010:00/i2c-0/i2c-OPI0001:00/0018:0911:5288.00D4/input/input517 [ 3213.534887] input: OPI0002:00 0911:5288 Touchpad as /devices/platform/AMDI0010:02/i2c-2/i2c-OPI0002:00/0018:0911:5288.00D5/input/input519 [ 3213.534957] hid-multitouch 0018:0911:5288.00D4: input,hidraw4: I2C HID v1.00 Mouse [OPI0001:00 0911:5288] on i2c-OPI0001:00 [ 3213.535078] hid-multitouch 0018:0911:5288.00D5: input,hidraw5: I2C HID v1.00 Mouse [OPI0002:00 0911:5288] on i2c-OPI0002:00
On Mon, Mar 18, 2024 at 08:17:07PM -0700, Laine Taffin Altman wrote: > On Mar 18, 2024, at 10:25 AM, Boqun Feng <boqun.feng@gmail.com> wrote: > > On Wed, Mar 13, 2024 at 11:09:37PM +0000, Benno Lossin wrote: > >> From: Laine Taffin Altman <alexanderaltman@me.com> > >> > >> It is not enough for a type to be a ZST to guarantee that zeroed memory > >> is a valid value for it; it must also be inhabited. Creating a value of > >> an uninhabited type, ZST or no, is immediate UB. > >> Thus remove the implementation of `Zeroable` for `Infallible`, since > >> that type is not inhabited. > >> > >> Cc: stable@vger.kernel.org > >> Fixes: 38cde0bd7b67 ("rust: init: add `Zeroable` trait and `init::zeroed` function") > >> Closes: https://github.com/Rust-for-Linux/pinned-init/pull/13 > >> Signed-off-by: Laine Taffin Altman <alexanderaltman@me.com> > >> Signed-off-by: Benno Lossin <benno.lossin@proton.me> > > > > I think either in the commit log or in the code comment, there better be > > a link or explanation on "(un)inhabited type". The rest looks good to > > me. > > Would the following be okay for that purpose? > > A type is inhabited if at least one valid value of that type exists; a > type is uninhabited if no valid values of that type exist. The terms > "inhabited" and "uninhabited" in this sense originate in type theory, > a branch of mathematics. > > In Rust, producing an invalid value of any type is immediate undefined > behavior (UB); this includes via zeroing memory. Therefore, since an > uninhabited type has no valid values, producing any values at all for > it is UB. > > The Rust standard library type `core::convert::Infallible` is > uninhabited, by virtue of having been declared as an enum with no > cases, which always produces uninhabited types in Rust. Thus, remove > the implementation of `Zeroable` for `Infallible`, thereby avoiding > the UB. > Yeah, this works for me. Thanks! Regards, Boqun > Thanks, > Laine > > > > > Reviewed-by: Boqun Feng <boqun.feng@gmail.com> > > > > Regards, > > Boqun > > > >> --- > >> rust/kernel/init.rs | 4 ++-- > >> 1 file changed, 2 insertions(+), 2 deletions(-) > >> > >> diff --git a/rust/kernel/init.rs b/rust/kernel/init.rs > >> index 424257284d16..538e03cfc84a 100644 > >> --- a/rust/kernel/init.rs > >> +++ b/rust/kernel/init.rs > >> @@ -1292,8 +1292,8 @@ macro_rules! impl_zeroable { > >> i8, i16, i32, i64, i128, isize, > >> f32, f64, > >> > >> - // SAFETY: These are ZSTs, there is nothing to zero. > >> - {<T: ?Sized>} PhantomData<T>, core::marker::PhantomPinned, Infallible, (), > >> + // SAFETY: These are inhabited ZSTs, there is nothing to zero and a valid value exists. > >> + {<T: ?Sized>} PhantomData<T>, core::marker::PhantomPinned, (), > >> > >> // SAFETY: Type is allowed to take any value, including all zeros. > >> {<T>} MaybeUninit<T>, > >> > >> base-commit: 768409cff6cc89fe1194da880537a09857b6e4db > >> -- > >> 2.42.0 > >> > >> > >> >
On Mar 18, 2024, at 10:25 AM, Boqun Feng <boqun.feng@gmail.com> wrote: > On Wed, Mar 13, 2024 at 11:09:37PM +0000, Benno Lossin wrote: >> From: Laine Taffin Altman <alexanderaltman@me.com> >> >> It is not enough for a type to be a ZST to guarantee that zeroed memory >> is a valid value for it; it must also be inhabited. Creating a value of >> an uninhabited type, ZST or no, is immediate UB. >> Thus remove the implementation of `Zeroable` for `Infallible`, since >> that type is not inhabited. >> >> Cc: stable@vger.kernel.org >> Fixes: 38cde0bd7b67 ("rust: init: add `Zeroable` trait and `init::zeroed` function") >> Closes: https://github.com/Rust-for-Linux/pinned-init/pull/13 >> Signed-off-by: Laine Taffin Altman <alexanderaltman@me.com> >> Signed-off-by: Benno Lossin <benno.lossin@proton.me> > > I think either in the commit log or in the code comment, there better be > a link or explanation on "(un)inhabited type". The rest looks good to > me. Would the following be okay for that purpose? A type is inhabited if at least one valid value of that type exists; a type is uninhabited if no valid values of that type exist. The terms "inhabited" and "uninhabited" in this sense originate in type theory, a branch of mathematics. In Rust, producing an invalid value of any type is immediate undefined behavior (UB); this includes via zeroing memory. Therefore, since an uninhabited type has no valid values, producing any values at all for it is UB. The Rust standard library type `core::convert::Infallible` is uninhabited, by virtue of having been declared as an enum with no cases, which always produces uninhabited types in Rust. Thus, remove the implementation of `Zeroable` for `Infallible`, thereby avoiding the UB. Thanks, Laine > > Reviewed-by: Boqun Feng <boqun.feng@gmail.com> > > Regards, > Boqun > >> --- >> rust/kernel/init.rs | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/rust/kernel/init.rs b/rust/kernel/init.rs >> index 424257284d16..538e03cfc84a 100644 >> --- a/rust/kernel/init.rs >> +++ b/rust/kernel/init.rs >> @@ -1292,8 +1292,8 @@ macro_rules! impl_zeroable { >> i8, i16, i32, i64, i128, isize, >> f32, f64, >> >> - // SAFETY: These are ZSTs, there is nothing to zero. >> - {<T: ?Sized>} PhantomData<T>, core::marker::PhantomPinned, Infallible, (), >> + // SAFETY: These are inhabited ZSTs, there is nothing to zero and a valid value exists. >> + {<T: ?Sized>} PhantomData<T>, core::marker::PhantomPinned, (), >> >> // SAFETY: Type is allowed to take any value, including all zeros. >> {<T>} MaybeUninit<T>, >> >> base-commit: 768409cff6cc89fe1194da880537a09857b6e4db >> -- >> 2.42.0 >> >> >>
On Sat, 09 Mar 2024 14:15:01 +0100, Konrad Dybcio wrote:
> Wire up LMH on QCM2290 and fix a bad bug while at it.
>
> P1-2 for thermal, P3 for qcom
>
>
Applied, thanks!
[3/3] arm64: dts: qcom: qcm2290: Add LMH node
commit: 7d6d561fa934594faf359f6fffee0e2dd59f8110
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
On Fri Mar 15, 2024 at 9:05 PM EET, Silvio Gissi wrote: > The expiry time of a key is unconditionally overwritten during > instantiation, defaulting to turn it permanent. This causes a problem > for DNS resolution as the expiration set by user-space is overwritten to > TIME64_MAX, disabling further DNS updates. Fix this by restoring the > condition that key_set_expiry is only called when the pre-parser sets a > specific expiry. > > Fixes: 39299bdd2546 ("keys, dns: Allow key types (eg. DNS) to be reclaimed immediately on expiry") > Signed-off-by: Silvio Gissi <sifonsec@amazon.com> > cc: David Howells <dhowells@redhat.com> > cc: Hazem Mohamed Abuelfotoh <abuehaze@amazon.com> > cc: linux-afs@lists.infradead.org > cc: linux-cifs@vger.kernel.org > cc: keyrings@vger.kernel.org > cc: netdev@vger.kernel.org > cc: stable@vger.kernel.org > --- > security/keys/key.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/security/keys/key.c b/security/keys/key.c > index 560790038329..0aa5f01d16ff 100644 > --- a/security/keys/key.c > +++ b/security/keys/key.c > @@ -463,7 +463,8 @@ static int __key_instantiate_and_link(struct key *key, > if (authkey) > key_invalidate(authkey); > > - key_set_expiry(key, prep->expiry); > + if (prep->expiry != TIME64_MAX) > + key_set_expiry(key, prep->expiry); > } > } > I checked the original commit and reflected to the fix: Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> David, I can pick this one too as I'm anyway sending PR for rc2? [1] https://lore.kernel.org/keyrings/CZX77XLG67HZ.UAU4NUQO27JP@kernel.org/ BR, Jarkko
When done from a virtual machine, instructions that touch APIC memory must be emulated. By convention, MMIO access are typically performed via io.h helpers such as 'readl()' or 'writeq()' to simplify instruction emulation/decoding (ex: in KVM hosts and SEV guests) [0]. Currently, native_apic_mem_read() does not follow this convention, allowing the compiler to emit instructions other than the MOV instruction generated by readl(). In particular, when compiled with clang and run as a SEV-ES or SEV-SNP guest, the compiler would emit a TESTL instruction which is not supported by the SEV-ES emulator, causing a boot failure in that environment. It is likely the same problem would happen in a TDX guest as that uses the same instruction emulator as SEV-ES. To make sure all emulators can emulate APIC memory reads via MOV, use the readl() function in native_apic_mem_read(). It is expected that any emulator would support MOV in any addressing mode it is the most generic and is what is ususally emitted currently. The TESTL instruction is emitted when native_apic_mem_read() is inlined into apic_mem_wait_icr_idle(). The emulator comes from insn_decode_mmio in arch/x86/lib/insn-eval.c. It's not worth it to extend insn_decode_mmio to support more instructions since, in theory, the compiler could choose to output nearly any instruction for such reads which would bloat the emulator beyond reason. [0] https://lore.kernel.org/all/20220405232939.73860-12-kirill.shutemov@linux.intel.com/ Signed-off-by: Adam Dunlap <acdunlap@google.com> Tested-by: Kevin Loughlin <kevinloughlin@google.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Cc: stable@vger.kernel.org --- An alterative to this approach would be to use inline assembly instead of the readl() helper, as that is what native_apic_mem_write() does. I consider using readl() to be cleaner since it is documented to be a simple wrapper and inline assembly is less readable. native_apic_mem_write() cannot be trivially updated to use writel since it appears to use custom asm to workaround for a processor-specific bug. Patch changelog: V1 -> V2: Replaced asm with readl function which does the same thing V2 -> V3: Updated commit message to show more motivation and justification V3 -> V4: Fixed nits in commit message Link to v2 discussion: https://lore.kernel.org/all/20220908170456.3177635-1-acdunlap@google.com/ arch/x86/include/asm/apic.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/x86/include/asm/apic.h b/arch/x86/include/asm/apic.h index 9d159b771dc8..dddd3fc195ef 100644 --- a/arch/x86/include/asm/apic.h +++ b/arch/x86/include/asm/apic.h @@ -13,6 +13,7 @@ #include <asm/mpspec.h> #include <asm/msr.h> #include <asm/hardirq.h> +#include <asm/io.h> #define ARCH_APICTIMER_STOPS_ON_C3 1 @@ -96,7 +97,7 @@ static inline void native_apic_mem_write(u32 reg, u32 v) static inline u32 native_apic_mem_read(u32 reg) { - return *((volatile u32 *)(APIC_BASE + reg)); + return readl((void __iomem *)(APIC_BASE + reg)); } static inline void native_apic_mem_eoi(void) -- 2.43.0.594.gd9cf4e227d-goog