6.1.157-rc1 review
Subsystems (4)
Greg Kroah-Hartman
maintainerPATCH 157/168 asm-generic/io: Add _RET_IP_ to MMIO trace for more accurate debug info
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sai Prakash Ranjan <[email protected]>
[ Upstream commit 5e5ff73c2e5863f93fc5fd78d178cd8f2af12464 ]
Due to compiler optimizations like inlining, there are cases where MMIO traces using _THIS_IP_ for caller information might not be sufficient to provide accurate debug traces.
1) With optimizations (Seen with GCC):
In this case, _THIS_IP_ works fine and prints the caller information since it will be inlined into the caller and we get the debug traces on who made the MMIO access, for ex:
rwmmio_read: qcom_smmu_tlb_sync+0xe0/0x1b0 width=32 addr=0xffff8000087447f4rwmmio_post_read: qcom_smmu_tlb_sync+0xe0/0x1b0 width=32 val=0x0 addr=0xffff8000087447f4
2) Without optimizations (Seen with Clang):
_THIS_IP_ will not be sufficient in this case as it will print only the MMIO accessors itself which is of not much use since it is not inlined as below for example:
rwmmio_read: readl+0x4/0x80 width=32 addr=0xffff8000087447f4rwmmio_post_read: readl+0x48/0x80 width=32 val=0x4 addr=0xffff8000087447f4
So in order to handle this second case as well irrespective of the compiler optimizations, add _RET_IP_ to MMIO trace to make it provide more accurate debug information in all these scenarios.
Before:
rwmmio_read: readl+0x4/0x80 width=32 addr=0xffff8000087447f4rwmmio_post_read: readl+0x48/0x80 width=32 val=0x4 addr=0xffff8000087447f4
After:
rwmmio_read: qcom_smmu_tlb_sync+0xe0/0x1b0 -> readl+0x4/0x80 width=32 addr=0xffff8000087447f4rwmmio_post_read: qcom_smmu_tlb_sync+0xe0/0x1b0 -> readl+0x4/0x80 width=32 val=0x0 addr=0xffff8000087447f4
Stable-dep-of: 8327bd4fcb6c ("asm-generic/io.h: Skip trace helpers if rwmmio events are disabled")
--- include/asm-generic/io.h | 80 +++++++++++++++++++++--------------------- include/trace/events/rwmmio.h | 43 ++++++++++++++-------- lib/trace_readwrite.c | 16 ++++---- 3 files changed, 75 insertions(+), 64 deletions(-)
include/asm-generic/io.h +40 -40
@@ -80,24 +80,24 @@ DECLARE_TRACEPOINT(rwmmio_read);DECLARE_TRACEPOINT (rwmmio_post_read);void log_write_mmio (u64 val,u8 width,volatile void __iomem *addr, -unsigned long caller_addr); +unsigned long caller_addr,unsigned long caller_addr0);void log_post_write_mmio (u64 val,u8 width,volatile void __iomem *addr, -unsigned long caller_addr); +unsigned long caller_addr,unsigned long caller_addr0);void log_read_mmio (u8 width,const volatile void __iomem *addr, -unsigned long caller_addr); +unsigned long caller_addr,unsigned long caller_addr0);void log_post_read_mmio (u64 val,u8 width,const volatile void __iomem *addr, -unsigned long caller_addr); +unsigned long caller_addr,unsigned long caller_addr0);#else static inline void log_write_mmio (u64 val,u8 width,volatile void __iomem *addr, -unsigned long caller_addr) {} +unsigned long caller_addr,unsigned long caller_addr0) {}static inline void log_post_write_mmio (u64 val,u8 width,volatile void __iomem *addr, -unsigned long caller_addr) {} +unsigned long caller_addr,unsigned long caller_addr0) {}static inline void log_read_mmio (u8 width,const volatile void __iomem *addr, -unsigned long caller_addr) {} +unsigned long caller_addr,unsigned long caller_addr0) {}static inline void log_post_read_mmio (u64 val,u8 width,const volatile void __iomem *addr, -unsigned long caller_addr) {} +unsigned long caller_addr,unsigned long caller_addr0) {}#endif /* CONFIG_TRACE_MMIO_ACCESS */
@@ -188,11 +188,11 @@ static inline u8 readb(const volatile vo {u8 val; -log_read_mmio (8 , addr, _THIS_IP_); +log_read_mmio (8 , addr, _THIS_IP_, _RET_IP_);__io_br (); val =__raw_readb (addr);__io_ar (val); -log_post_read_mmio (val,8 , addr, _THIS_IP_); +log_post_read_mmio (val,8 , addr, _THIS_IP_, _RET_IP_);return val; }#endif
@@ -203,11 +203,11 @@ static inline u16 readw(const volatile v {u16 val; -log_read_mmio (16 , addr, _THIS_IP_); +log_read_mmio (16 , addr, _THIS_IP_, _RET_IP_);__io_br (); val =__le16_to_cpu ((__le16 __force )__raw_readw (addr));__io_ar (val); -log_post_read_mmio (val,16 , addr, _THIS_IP_); +log_post_read_mmio (val,16 , addr, _THIS_IP_, _RET_IP_);return val; }#endif
@@ -218,11 +218,11 @@ static inline u32 readl(const volatile v {u32 val; -log_read_mmio (32 , addr, _THIS_IP_); +log_read_mmio (32 , addr, _THIS_IP_, _RET_IP_);__io_br (); val =__le32_to_cpu ((__le32 __force )__raw_readl (addr));__io_ar (val); -log_post_read_mmio (val,32 , addr, _THIS_IP_); +log_post_read_mmio (val,32 , addr, _THIS_IP_, _RET_IP_);return val; }#endif
@@ -234,11 +234,11 @@ static inline u64 readq(const volatile v {u64 val; -log_read_mmio (64 , addr, _THIS_IP_); +log_read_mmio (64 , addr, _THIS_IP_, _RET_IP_);__io_br (); val =__le64_to_cpu ((__le64 __force )__raw_readq (addr));__io_ar (val); -log_post_read_mmio (val,64 , addr, _THIS_IP_); +log_post_read_mmio (val,64 , addr, _THIS_IP_, _RET_IP_);return val; }#endif
@@ -248,11 +248,11 @@ static inline u64 readq(const volatile v#define writeb writebstatic inline void writeb (u8 value,volatile void __iomem *addr) { -log_write_mmio (value,8 , addr, _THIS_IP_); +log_write_mmio (value,8 , addr, _THIS_IP_, _RET_IP_);__io_bw ();__raw_writeb (value, addr);__io_aw (); -log_post_write_mmio (value,8 , addr, _THIS_IP_); +log_post_write_mmio (value,8 , addr, _THIS_IP_, _RET_IP_); }#endif
@@ -260,11 +260,11 @@ static inline void writeb(u8 value, vola#define writew writewstatic inline void writew (u16 value,volatile void __iomem *addr) { -log_write_mmio (value,16 , addr, _THIS_IP_); +log_write_mmio (value,16 , addr, _THIS_IP_, _RET_IP_);__io_bw ();__raw_writew ((u16 __force )cpu_to_le16 (value), addr);__io_aw (); -log_post_write_mmio (value,16 , addr, _THIS_IP_); +log_post_write_mmio (value,16 , addr, _THIS_IP_, _RET_IP_); }#endif
@@ -272,11 +272,11 @@ static inline void writew(u16 value, vol#define writel writelstatic inline void writel (u32 value,volatile void __iomem *addr) { -log_write_mmio (value,32 , addr, _THIS_IP_); +log_write_mmio (value,32 , addr, _THIS_IP_, _RET_IP_);__io_bw ();__raw_writel ((u32 __force )__cpu_to_le32 (value), addr);__io_aw (); -log_post_write_mmio (value,32 , addr, _THIS_IP_); +log_post_write_mmio (value,32 , addr, _THIS_IP_, _RET_IP_); }#endif
@@ -285,11 +285,11 @@ static inline void writel(u32 value, vol#define writeq writeqstatic inline void writeq (u64 value,volatile void __iomem *addr) { -log_write_mmio (value,64 , addr, _THIS_IP_); +log_write_mmio (value,64 , addr, _THIS_IP_, _RET_IP_);__io_bw ();__raw_writeq ((u64 __force )__cpu_to_le64 (value), addr);__io_aw (); -log_post_write_mmio (value,64 , addr, _THIS_IP_); +log_post_write_mmio (value,64 , addr, _THIS_IP_, _RET_IP_); }#endif #endif /* CONFIG_64BIT */
@@ -305,9 +305,9 @@ static inline u8 readb_relaxed(const vol {u8 val; -log_read_mmio (8 , addr, _THIS_IP_); +log_read_mmio (8 , addr, _THIS_IP_, _RET_IP_); val =__raw_readb (addr); -log_post_read_mmio (val,8 , addr, _THIS_IP_); +log_post_read_mmio (val,8 , addr, _THIS_IP_, _RET_IP_);return val; }#endif
@@ -318,9 +318,9 @@ static inline u16 readw_relaxed(const vo {u16 val; -log_read_mmio (16 , addr, _THIS_IP_); +log_read_mmio (16 , addr, _THIS_IP_, _RET_IP_); val =__le16_to_cpu (__raw_readw (addr)); -log_post_read_mmio (val,16 , addr, _THIS_IP_); +log_post_read_mmio (val,16 , addr, _THIS_IP_, _RET_IP_);return val; }#endif
@@ -331,9 +331,9 @@ static inline u32 readl_relaxed(const vo {u32 val; -log_read_mmio (32 , addr, _THIS_IP_); +log_read_mmio (32 , addr, _THIS_IP_, _RET_IP_); val =__le32_to_cpu (__raw_readl (addr)); -log_post_read_mmio (val,32 , addr, _THIS_IP_); +log_post_read_mmio (val,32 , addr, _THIS_IP_, _RET_IP_);return val; }#endif
@@ -344,9 +344,9 @@ static inline u64 readq_relaxed(const vo {u64 val; -log_read_mmio (64 , addr, _THIS_IP_); +log_read_mmio (64 , addr, _THIS_IP_, _RET_IP_); val =__le64_to_cpu (__raw_readq (addr)); -log_post_read_mmio (val,64 , addr, _THIS_IP_); +log_post_read_mmio (val,64 , addr, _THIS_IP_, _RET_IP_);return val; }#endif
@@ -355,9 +355,9 @@ static inline u64 readq_relaxed(const vo#define writeb_relaxed writeb_relaxedstatic inline void writeb_relaxed (u8 value,volatile void __iomem *addr) { -log_write_mmio (value,8 , addr, _THIS_IP_); +log_write_mmio (value,8 , addr, _THIS_IP_, _RET_IP_);__raw_writeb (value, addr); -log_post_write_mmio (value,8 , addr, _THIS_IP_); +log_post_write_mmio (value,8 , addr, _THIS_IP_, _RET_IP_); }#endif
@@ -365,9 +365,9 @@ static inline void writeb_relaxed(u8 val#define writew_relaxed writew_relaxedstatic inline void writew_relaxed (u16 value,volatile void __iomem *addr) { -log_write_mmio (value,16 , addr, _THIS_IP_); +log_write_mmio (value,16 , addr, _THIS_IP_, _RET_IP_);__raw_writew (cpu_to_le16 (value), addr); -log_post_write_mmio (value,16 , addr, _THIS_IP_); +log_post_write_mmio (value,16 , addr, _THIS_IP_, _RET_IP_); }#endif
@@ -375,9 +375,9 @@ static inline void writew_relaxed(u16 va#define writel_relaxed writel_relaxedstatic inline void writel_relaxed (u32 value,volatile void __iomem *addr) { -log_write_mmio (value,32 , addr, _THIS_IP_); +log_write_mmio (value,32 , addr, _THIS_IP_, _RET_IP_);__raw_writel (__cpu_to_le32 (value), addr); -log_post_write_mmio (value,32 , addr, _THIS_IP_); +log_post_write_mmio (value,32 , addr, _THIS_IP_, _RET_IP_); }#endif
@@ -385,9 +385,9 @@ static inline void writel_relaxed(u32 va#define writeq_relaxed writeq_relaxedstatic inline void writeq_relaxed (u64 value,volatile void __iomem *addr) { -log_write_mmio (value,64 , addr, _THIS_IP_); +log_write_mmio (value,64 , addr, _THIS_IP_, _RET_IP_);__raw_writeq (__cpu_to_le64 (value), addr); -log_post_write_mmio (value,64 , addr, _THIS_IP_); +log_post_write_mmio (value,64 , addr, _THIS_IP_, _RET_IP_); }#endif
include/trace/events/rwmmio.h +27 -16
108 lines not on this page · raw message
lib/trace_readwrite.c +8 -8
@@ -14,33 +14,33 @@#ifdef CONFIG_TRACE_MMIO_ACCESS void log_write_mmio (u64 val,u8 width,volatile void __iomem *addr, -unsigned long caller_addr) +unsigned long caller_addr,unsigned long caller_addr0) { -trace_rwmmio_write (caller_addr, val, width, addr); +trace_rwmmio_write (caller_addr, caller_addr0, val, width, addr); }EXPORT_SYMBOL_GPL (log_write_mmio);EXPORT_TRACEPOINT_SYMBOL_GPL (rwmmio_write);void log_post_write_mmio (u64 val,u8 width,volatile void __iomem *addr, -unsigned long caller_addr) +unsigned long caller_addr,unsigned long caller_addr0) { -trace_rwmmio_post_write (caller_addr, val, width, addr); +trace_rwmmio_post_write (caller_addr, caller_addr0, val, width, addr); }EXPORT_SYMBOL_GPL (log_post_write_mmio);EXPORT_TRACEPOINT_SYMBOL_GPL (rwmmio_post_write);void log_read_mmio (u8 width,const volatile void __iomem *addr, -unsigned long caller_addr) +unsigned long caller_addr,unsigned long caller_addr0) { -trace_rwmmio_read (caller_addr, width, addr); +trace_rwmmio_read (caller_addr, caller_addr0, width, addr); }EXPORT_SYMBOL_GPL (log_read_mmio);EXPORT_TRACEPOINT_SYMBOL_GPL (rwmmio_read);void log_post_read_mmio (u64 val,u8 width,const volatile void __iomem *addr, -unsigned long caller_addr) +unsigned long caller_addr,unsigned long caller_addr0) { -trace_rwmmio_post_read (caller_addr, val, width, addr); +trace_rwmmio_post_read (caller_addr, caller_addr0, val, width, addr); }EXPORT_SYMBOL_GPL (log_post_read_mmio);EXPORT_TRACEPOINT_SYMBOL_GPL (rwmmio_post_read);
Greg Kroah-Hartman
maintainerPATCH 158/168 asm-generic/io.h: suppress endianness warnings for relaxed accessors
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vladimir Oltean <[email protected]>
[ Upstream commit 05d3855b4d21ef3c2df26be1cbba9d2c68915fcb ]
Copy the forced type casts from the normal MMIO accessors to suppress the sparse warnings that point out __raw_readl() returns a native endian word (just like readl()).
Stable-dep-of: 8327bd4fcb6c ("asm-generic/io.h: Skip trace helpers if rwmmio events are disabled")
--- include/asm-generic/io.h | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)
include/asm-generic/io.h +6 -6
@@ -319,7 +319,7 @@ static inline u16 readw_relaxed(const vou16 val;log_read_mmio (16 , addr, _THIS_IP_, _RET_IP_); - val =__le16_to_cpu (__raw_readw (addr)); + val =__le16_to_cpu ((__le16 __force )__raw_readw (addr));log_post_read_mmio (val,16 , addr, _THIS_IP_, _RET_IP_);return val; }
@@ -332,7 +332,7 @@ static inline u32 readl_relaxed(const vou32 val;log_read_mmio (32 , addr, _THIS_IP_, _RET_IP_); - val =__le32_to_cpu (__raw_readl (addr)); + val =__le32_to_cpu ((__le32 __force )__raw_readl (addr));log_post_read_mmio (val,32 , addr, _THIS_IP_, _RET_IP_);return val; }
@@ -345,7 +345,7 @@ static inline u64 readq_relaxed(const vou64 val;log_read_mmio (64 , addr, _THIS_IP_, _RET_IP_); - val =__le64_to_cpu (__raw_readq (addr)); + val =__le64_to_cpu ((__le64 __force )__raw_readq (addr));log_post_read_mmio (val,64 , addr, _THIS_IP_, _RET_IP_);return val; }
@@ -366,7 +366,7 @@ static inline void writeb_relaxed(u8 valstatic inline void writew_relaxed (u16 value,volatile void __iomem *addr) {log_write_mmio (value,16 , addr, _THIS_IP_, _RET_IP_); -__raw_writew (cpu_to_le16 (value), addr); +__raw_writew ((u16 __force )cpu_to_le16 (value), addr);log_post_write_mmio (value,16 , addr, _THIS_IP_, _RET_IP_); }#endif
@@ -376,7 +376,7 @@ static inline void writew_relaxed(u16 vastatic inline void writel_relaxed (u32 value,volatile void __iomem *addr) {log_write_mmio (value,32 , addr, _THIS_IP_, _RET_IP_); -__raw_writel (__cpu_to_le32 (value), addr); +__raw_writel ((u32 __force )__cpu_to_le32 (value), addr);log_post_write_mmio (value,32 , addr, _THIS_IP_, _RET_IP_); }#endif
@@ -386,7 +386,7 @@ static inline void writel_relaxed(u32 vastatic inline void writeq_relaxed (u64 value,volatile void __iomem *addr) {log_write_mmio (value,64 , addr, _THIS_IP_, _RET_IP_); -__raw_writeq (__cpu_to_le64 (value), addr); +__raw_writeq ((u64 __force )__cpu_to_le64 (value), addr);log_post_write_mmio (value,64 , addr, _THIS_IP_, _RET_IP_); }#endif
Greg Kroah-Hartman
maintainerPATCH 159/168 asm-generic/io.h: Skip trace helpers if rwmmio events are disabled
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Varad Gautam <[email protected]>
[ Upstream commit 8327bd4fcb6c1dab01ce5c6ff00b42496836dcd2 ]
With CONFIG_TRACE_MMIO_ACCESS=y, the {read,write}{b,w,l,q}{_relaxed}() mmio accessors unconditionally call log_{post_}{read,write}_mmio() helpers, which in turn call the ftrace ops for rwmmio trace events
This adds a performance penalty per mmio accessor call, even when rwmmio events are disabled at runtime (~80% overhead on local measurement).
Guard these with tracepoint_enabled().
--- include/asm-generic/io.h | 98 +++++++++++++++++++++++++++++++---------------- 1 file changed, 66 insertions(+), 32 deletions(-)
include/asm-generic/io.h +66 -32
@@ -74,6 +74,7 @@#if IS_ENABLED (CONFIG_TRACE_MMIO_ACCESS ) && !(defined(__DISABLE_TRACE_MMIO__))#include <linux/tracepoint-defs.h> +#define rwmmio_tracepoint_enabled (tracepoint) tracepoint_enabled(tracepoint)DECLARE_TRACEPOINT (rwmmio_write);DECLARE_TRACEPOINT (rwmmio_post_write);DECLARE_TRACEPOINT (rwmmio_read);
@@ -90,6 +91,7 @@ void log_post_read_mmio(u64 val, u8 widt#else +#define rwmmio_tracepoint_enabled (tracepoint) falsestatic inline void log_write_mmio (u64 val,u8 width,volatile void __iomem *addr,unsigned long caller_addr,unsigned long caller_addr0) {} static inline void log_post_write_mmio(u64 val, u8 width, volatile void __iomem *addr,
@@ -188,11 +190,13 @@ static inline u8 readb(const volatile vo {u8 val; -log_read_mmio (8 , addr, _THIS_IP_, _RET_IP_); +if (rwmmio_tracepoint_enabled (rwmmio_read)) +log_read_mmio (8 , addr, _THIS_IP_, _RET_IP_);__io_br (); val =__raw_readb (addr);__io_ar (val); -log_post_read_mmio (val,8 , addr, _THIS_IP_, _RET_IP_); +if (rwmmio_tracepoint_enabled (rwmmio_post_read)) +log_post_read_mmio (val,8 , addr, _THIS_IP_, _RET_IP_);return val; }#endif
@@ -203,11 +207,13 @@ static inline u16 readw(const volatile v {u16 val; -log_read_mmio (16 , addr, _THIS_IP_, _RET_IP_); +if (rwmmio_tracepoint_enabled (rwmmio_read)) +log_read_mmio (16 , addr, _THIS_IP_, _RET_IP_);__io_br (); val =__le16_to_cpu ((__le16 __force )__raw_readw (addr));__io_ar (val); -log_post_read_mmio (val,16 , addr, _THIS_IP_, _RET_IP_); +if (rwmmio_tracepoint_enabled (rwmmio_post_read)) +log_post_read_mmio (val,16 , addr, _THIS_IP_, _RET_IP_);return val; }#endif
@@ -218,11 +224,13 @@ static inline u32 readl(const volatile v {u32 val; -log_read_mmio (32 , addr, _THIS_IP_, _RET_IP_); +if (rwmmio_tracepoint_enabled (rwmmio_read)) +log_read_mmio (32 , addr, _THIS_IP_, _RET_IP_);__io_br (); val =__le32_to_cpu ((__le32 __force )__raw_readl (addr));__io_ar (val); -log_post_read_mmio (val,32 , addr, _THIS_IP_, _RET_IP_); +if (rwmmio_tracepoint_enabled (rwmmio_post_read)) +log_post_read_mmio (val,32 , addr, _THIS_IP_, _RET_IP_);return val; }#endif
@@ -234,11 +242,13 @@ static inline u64 readq(const volatile v {u64 val; -log_read_mmio (64 , addr, _THIS_IP_, _RET_IP_); +if (rwmmio_tracepoint_enabled (rwmmio_read)) +log_read_mmio (64 , addr, _THIS_IP_, _RET_IP_);__io_br (); val =__le64_to_cpu ((__le64 __force )__raw_readq (addr));__io_ar (val); -log_post_read_mmio (val,64 , addr, _THIS_IP_, _RET_IP_); +if (rwmmio_tracepoint_enabled (rwmmio_post_read)) +log_post_read_mmio (val,64 , addr, _THIS_IP_, _RET_IP_);return val; }#endif
@@ -248,11 +258,13 @@ static inline u64 readq(const volatile v#define writeb writebstatic inline void writeb (u8 value,volatile void __iomem *addr) { -log_write_mmio (value,8 , addr, _THIS_IP_, _RET_IP_); +if (rwmmio_tracepoint_enabled (rwmmio_write)) +log_write_mmio (value,8 , addr, _THIS_IP_, _RET_IP_);__io_bw ();__raw_writeb (value, addr);__io_aw (); -log_post_write_mmio (value,8 , addr, _THIS_IP_, _RET_IP_); +if (rwmmio_tracepoint_enabled (rwmmio_post_write)) +log_post_write_mmio (value,8 , addr, _THIS_IP_, _RET_IP_); }#endif
@@ -260,11 +272,13 @@ static inline void writeb(u8 value, vola#define writew writewstatic inline void writew (u16 value,volatile void __iomem *addr) { -log_write_mmio (value,16 , addr, _THIS_IP_, _RET_IP_); +if (rwmmio_tracepoint_enabled (rwmmio_write)) +log_write_mmio (value,16 , addr, _THIS_IP_, _RET_IP_);__io_bw ();__raw_writew ((u16 __force )cpu_to_le16 (value), addr);__io_aw (); -log_post_write_mmio (value,16 , addr, _THIS_IP_, _RET_IP_); +if (rwmmio_tracepoint_enabled (rwmmio_post_write)) +log_post_write_mmio (value,16 , addr, _THIS_IP_, _RET_IP_); }#endif
@@ -272,11 +286,13 @@ static inline void writew(u16 value, vol#define writel writelstatic inline void writel (u32 value,volatile void __iomem *addr) { -log_write_mmio (value,32 , addr, _THIS_IP_, _RET_IP_); +if (rwmmio_tracepoint_enabled (rwmmio_write)) +log_write_mmio (value,32 , addr, _THIS_IP_, _RET_IP_);__io_bw ();__raw_writel ((u32 __force )__cpu_to_le32 (value), addr);__io_aw (); -log_post_write_mmio (value,32 , addr, _THIS_IP_, _RET_IP_); +if (rwmmio_tracepoint_enabled (rwmmio_post_write)) +log_post_write_mmio (value,32 , addr, _THIS_IP_, _RET_IP_); }#endif
@@ -285,11 +301,13 @@ static inline void writel(u32 value, vol#define writeq writeqstatic inline void writeq (u64 value,volatile void __iomem *addr) { -log_write_mmio (value,64 , addr, _THIS_IP_, _RET_IP_); +if (rwmmio_tracepoint_enabled (rwmmio_write)) +log_write_mmio (value,64 , addr, _THIS_IP_, _RET_IP_);__io_bw ();__raw_writeq ((u64 __force )__cpu_to_le64 (value), addr);__io_aw (); -log_post_write_mmio (value,64 , addr, _THIS_IP_, _RET_IP_); +if (rwmmio_tracepoint_enabled (rwmmio_post_write)) +log_post_write_mmio (value,64 , addr, _THIS_IP_, _RET_IP_); }#endif #endif /* CONFIG_64BIT */
@@ -305,9 +323,11 @@ static inline u8 readb_relaxed(const vol {u8 val; -log_read_mmio (8 , addr, _THIS_IP_, _RET_IP_); +if (rwmmio_tracepoint_enabled (rwmmio_read)) +log_read_mmio (8 , addr, _THIS_IP_, _RET_IP_); val =__raw_readb (addr); -log_post_read_mmio (val,8 , addr, _THIS_IP_, _RET_IP_); +if (rwmmio_tracepoint_enabled (rwmmio_post_read)) +log_post_read_mmio (val,8 , addr, _THIS_IP_, _RET_IP_);return val; }#endif
@@ -318,9 +338,11 @@ static inline u16 readw_relaxed(const vo {u16 val; -log_read_mmio (16 , addr, _THIS_IP_, _RET_IP_); +if (rwmmio_tracepoint_enabled (rwmmio_read)) +log_read_mmio (16 , addr, _THIS_IP_, _RET_IP_); val =__le16_to_cpu ((__le16 __force )__raw_readw (addr)); -log_post_read_mmio (val,16 , addr, _THIS_IP_, _RET_IP_); +if (rwmmio_tracepoint_enabled (rwmmio_post_read)) +log_post_read_mmio (val,16 , addr, _THIS_IP_, _RET_IP_);return val; }#endif
@@ -331,9 +353,11 @@ static inline u32 readl_relaxed(const vo {u32 val; -log_read_mmio (32 , addr, _THIS_IP_, _RET_IP_); +if (rwmmio_tracepoint_enabled (rwmmio_read)) +log_read_mmio (32 , addr, _THIS_IP_, _RET_IP_); val =__le32_to_cpu ((__le32 __force )__raw_readl (addr)); -log_post_read_mmio (val,32 , addr, _THIS_IP_, _RET_IP_); +if (rwmmio_tracepoint_enabled (rwmmio_post_read)) +log_post_read_mmio (val,32 , addr, _THIS_IP_, _RET_IP_);return val; }#endif
@@ -344,9 +368,11 @@ static inline u64 readq_relaxed(const vo {u64 val; -log_read_mmio (64 , addr, _THIS_IP_, _RET_IP_); +if (rwmmio_tracepoint_enabled (rwmmio_read)) +log_read_mmio (64 , addr, _THIS_IP_, _RET_IP_); val =__le64_to_cpu ((__le64 __force )__raw_readq (addr)); -log_post_read_mmio (val,64 , addr, _THIS_IP_, _RET_IP_); +if (rwmmio_tracepoint_enabled (rwmmio_post_read)) +log_post_read_mmio (val,64 , addr, _THIS_IP_, _RET_IP_);return val; }#endif
@@ -355,9 +381,11 @@ static inline u64 readq_relaxed(const vo#define writeb_relaxed writeb_relaxedstatic inline void writeb_relaxed (u8 value,volatile void __iomem *addr) { -log_write_mmio (value,8 , addr, _THIS_IP_, _RET_IP_); +if (rwmmio_tracepoint_enabled (rwmmio_write)) +log_write_mmio (value,8 , addr, _THIS_IP_, _RET_IP_);__raw_writeb (value, addr); -log_post_write_mmio (value,8 , addr, _THIS_IP_, _RET_IP_); +if (rwmmio_tracepoint_enabled (rwmmio_post_write)) +log_post_write_mmio (value,8 , addr, _THIS_IP_, _RET_IP_); }#endif
@@ -365,9 +393,11 @@ static inline void writeb_relaxed(u8 val#define writew_relaxed writew_relaxedstatic inline void writew_relaxed (u16 value,volatile void __iomem *addr) { -log_write_mmio (value,16 , addr, _THIS_IP_, _RET_IP_); +if (rwmmio_tracepoint_enabled (rwmmio_write)) +log_write_mmio (value,16 , addr, _THIS_IP_, _RET_IP_);__raw_writew ((u16 __force )cpu_to_le16 (value), addr); -log_post_write_mmio (value,16 , addr, _THIS_IP_, _RET_IP_); +if (rwmmio_tracepoint_enabled (rwmmio_post_write)) +log_post_write_mmio (value,16 , addr, _THIS_IP_, _RET_IP_); }#endif
@@ -375,9 +405,11 @@ static inline void writew_relaxed(u16 va#define writel_relaxed writel_relaxedstatic inline void writel_relaxed (u32 value,volatile void __iomem *addr) { -log_write_mmio (value,32 , addr, _THIS_IP_, _RET_IP_); +if (rwmmio_tracepoint_enabled (rwmmio_write)) +log_write_mmio (value,32 , addr, _THIS_IP_, _RET_IP_);__raw_writel ((u32 __force )__cpu_to_le32 (value), addr); -log_post_write_mmio (value,32 , addr, _THIS_IP_, _RET_IP_); +if (rwmmio_tracepoint_enabled (rwmmio_post_write)) +log_post_write_mmio (value,32 , addr, _THIS_IP_, _RET_IP_); }#endif
@@ -385,9 +417,11 @@ static inline void writel_relaxed(u32 va#define writeq_relaxed writeq_relaxedstatic inline void writeq_relaxed (u64 value,volatile void __iomem *addr) { -log_write_mmio (value,64 , addr, _THIS_IP_, _RET_IP_); +if (rwmmio_tracepoint_enabled (rwmmio_write)) +log_write_mmio (value,64 , addr, _THIS_IP_, _RET_IP_);__raw_writeq ((u64 __force )__cpu_to_le64 (value), addr); -log_post_write_mmio (value,64 , addr, _THIS_IP_, _RET_IP_); +if (rwmmio_tracepoint_enabled (rwmmio_post_write)) +log_post_write_mmio (value,64 , addr, _THIS_IP_, _RET_IP_); }#endif
Greg Kroah-Hartman
maintainerPATCH 160/168 mptcp: pm: in-kernel: usable client side with C-flag
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matthieu Baerts (NGI0) <[email protected]>
commit 4b1ff850e0c1aacc23e923ed22989b827b9808f9 upstream.
When servers set the C-flag in their MP_CAPABLE to tell clients not to create subflows to the initial address and port, clients will likely not use their other endpoints. That's because the in-kernel path-manager uses the 'subflow' endpoints to create subflows only to the initial address and port.
If the limits have not been modified to accept ADD_ADDR, the client doesn't try to establish new subflows. If the limits accept ADD_ADDR, the routing routes will be used to select the source IP.
The C-flag is typically set when the server is operating behind a legacy Layer 4 load balancer, or using anycast IP address. Clients having their different 'subflow' endpoints setup, don't end up creating multiple subflows as expected, and causing some deployment issues.
A special case is then added here: when servers set the C-flag in the MPC and directly sends an ADD_ADDR, this single ADD_ADDR is accepted. The 'subflows' endpoints will then be used with this new remote IP and port. This exception is only allowed when the ADD_ADDR is sent immediately after the 3WHS, and makes the client switching to the 'fully established' mode. After that, 'select_local_address()' will not be able to find any subflows, because 'id_avail_bitmap' will be filled in mptcp_pm_create_subflow_or_signal_addr(), when switching to 'fully established' mode.
[ Conflict in pm.c, because commit 498d7d8b75f1 ("mptcp: pm: remove
'_nl' from mptcp_pm_nl_is_init_remote_addr") renamed an helper in the context, and it is not in this version. The same new code can be applied at the same place.
Conflict in pm_kernel.c, because the modified code has been moved from pm_netlink.c to pm_kernel.c in commit 8617e85e04bd ("mptcp: pm: split in-kernel PM specific code"), which is not in this version. The resolution is easy: simply by applying the patch where 'pm_kernel.c' has been replaced 'pm_netlink.c'.
Conflict in pm_netlink.c, because commit b83fbca1b4c9 ("mptcp: pm:
reduce entries iterations on connect") is not in this version. Instead of using the 'locals' variable (struct mptcp_pm_local *) from the new version and embedding a "struct mptcp_addr_info", we can simply continue to use the 'addrs' variable (struct mptcp_addr_info *). Because commit b9d69db87fb7 ("mptcp: let the in-kernel PM use mixed IPv4 and IPv6 addresses") is not in this version, it is also required to pass an extra parameter to fill_local_addresses_vec(): struct mptcp_addr_info *remote, which is available from the caller side. Conflict in protocol.h, because commit af3dc0ad3167 ("mptcp: Remove unused declaration mptcp_sockopt_sync()") is not in this version and it removed one line in the context. The resolution is easy because the new function can still be added at the same place. ]
--- net/mptcp/pm.c | 7 ++++-- net/mptcp/pm_netlink.c | 55 +++++++++++++++++++++++++++++++++++++++++++++++-- net/mptcp/protocol.h | 8 +++++++ 3 files changed, 66 insertions(+), 4 deletions(-)
net/mptcp/pm.c +5 -2
@@ -225,9 +225,12 @@ void mptcp_pm_add_addr_received(const st }else {__MPTCP_INC_STATS (sock_net ((struct sock *)msk),MPTCP_MIB_ADDADDRDROP ); } -/* id0 should not have a different address */ +/* - id0 should not have a different address +* - special case for C-flag: linked to fill_local_addresses_vec() +*/ }else if ((addr->id ==0 && !mptcp_pm_nl_is_init_remote_addr (msk, addr)) || - (addr->id >0 && !READ_ONCE (pm->accept_addr))) { + (addr->id >0 && !READ_ONCE (pm->accept_addr) && + !mptcp_pm_add_addr_c_flag_case (msk))) {mptcp_pm_announce_addr (msk, addr, true);mptcp_pm_add_addr_send_ack (msk); }else if (mptcp_pm_schedule_work (msk,MPTCP_PM_ADD_ADDR_RECEIVED )) {
net/mptcp/pm_netlink.c +53 -2
93 lines not on this page · raw message
net/mptcp/protocol.h +8 -0
@@ -958,6 +958,14 @@ static inline void mptcp_pm_close_subflospin_unlock_bh (&msk->pm.lock); } +static inline bool mptcp_pm_add_addr_c_flag_case (struct mptcp_sock *msk) +{ +return READ_ONCE (msk->pm.remote_deny_join_id0) && + msk->pm.local_addr_used ==0 && +mptcp_pm_get_add_addr_accept_max (msk) ==0 && + msk->pm.subflows <mptcp_pm_get_subflows_max (msk); +} +void mptcp_sockopt_sync (struct mptcp_sock *msk,struct sock *ssk);void mptcp_sockopt_sync_locked (struct mptcp_sock *msk,struct sock *ssk);
Greg Kroah-Hartman
maintainerPATCH 161/168 minixfs: Verify inode mode when loading from disk
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tetsuo Handa <[email protected]>
[ Upstream commit 73861970938ad1323eb02bbbc87f6fbd1e5bacca ]
The inode mode loaded from corrupted disk can be invalid. Do like what commit 0a9e74051313 ("isofs: Verify inode mode when loading from disk") does.
--- fs/minix/inode.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
fs/minix/inode.c +7 -1
@@ -470,8 +470,14 @@ void minix_set_inode(struct inode *inode, dev_t rdev) inode->i_op = &minix_symlink_inode_operations;inode_nohighmem (inode); inode->i_mapping->a_ops = &minix_aops; - }else + }else if (S_ISCHR (inode->i_mode) ||S_ISBLK (inode->i_mode) || +S_ISFIFO (inode->i_mode) ||S_ISSOCK (inode->i_mode)) {init_special_inode (inode, inode->i_mode, rdev); + }else { +printk (KERN_DEBUG "MINIX-fs: Invalid file type 0%04o for inode %lu.\n" , + inode->i_mode, inode->i_ino); +make_bad_inode (inode); + } }/*
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 162/168 pid: Add a judgment for ns null in pid_nr_ns
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: gaoxiang17 <[email protected]>
[ Upstream commit 006568ab4c5ca2309ceb36fa553e390b4aa9c0c7 ]
__task_pid_nr_ns
ns = task_active_pid_ns(current);
pid_nr_ns(rcu_dereference(*task_pid_ptr(task, type)), ns);
if (pid && ns->level <= pid->level) {Sometimes null is returned for task_active_pid_ns. Then it will trigger kernel panic in pid_nr_ns.
For example:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058 Mem abort info: ESR = 0x0000000096000007 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x07: level 3 translation fault Data abort info: ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 39-bit VAs, pgdp=00000002175aa000 [0000000000000058] pgd=08000002175ab003, p4d=08000002175ab003, pud=08000002175ab003, pmd=08000002175be003, pte=0000000000000000 pstate: 834000c5 (Nzcv daIF +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : __task_pid_nr_ns+0x74/0xd0 lr : __task_pid_nr_ns+0x24/0xd0 sp : ffffffc08001bd10 x29: ffffffc08001bd10 x28: ffffffd4422b2000 x27: 0000000000000001 x26: ffffffd442821168 x25: ffffffd442821000 x24: 00000f89492eab31 x23: 00000000000000c0 x22: ffffff806f5693c0 x21: ffffff806f5693c0 x20: 0000000000000001 x19: 0000000000000000 x18: 0000000000000000 x17: 00000000529c6ef0 x16: 00000000529c6ef0 x15: 00000000023a1adc x14: 0000000000000003 x13: 00000000007ef6d8 x12: 001167c391c78800 x11: 00ffffffffffffff x10: 0000000000000000 x9 : 0000000000000001 x8 : ffffff80816fa3c0 x7 : 0000000000000000 x6 : 49534d702d535449 x5 : ffffffc080c4c2c0 x4 : ffffffd43ee128c8 x3 : ffffffd43ee124dc x2 : 0000000000000000 x1 : 0000000000000001 x0 : ffffff806f5693c0 Call trace: __task_pid_nr_ns+0x74/0xd0 ... __handle_irq_event_percpu+0xd4/0x284 handle_irq_event+0x48/0xb0 handle_fasteoi_irq+0x160/0x2d8 generic_handle_domain_irq+0x44/0x60 gic_handle_irq+0x4c/0x114 call_on_irq_stack+0x3c/0x74 do_interrupt_handler+0x4c/0x84 el1_interrupt+0x34/0x58 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x68/0x6c account_kernel_stack+0x60/0x144 exit_task_stack_account+0x1c/0x80 do_exit+0x7e4/0xaf8 ... get_signal+0x7bc/0x8d8 do_notify_resume+0x128/0x828 el0_svc+0x6c/0x70 el0t_64_sync_handler+0x68/0xbc el0t_64_sync+0x1a8/0x1ac Code: 35fffe54 911a02a8 f9400108 b4000128 (b9405a69) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Oops: Fatal exception in interrupt
--- kernel/pid.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
kernel/pid.c +1 -1
@@ -474,7 +474,7 @@ pid_t pid_nr_ns(struct pid *pid, struct pid_namespace *ns)struct upid *upid;pid_t nr =0 ; -if (pid && ns->level <= pid->level) { +if (pid && ns && ns->level <= pid->level) { upid = &pid->numbers[ns->level];if (upid->ns == ns) nr = upid->nr;
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 163/168 pid: make __task_pid_nr_ns(ns => NULL) safe for zombie callers
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Oleg Nesterov <[email protected]>
[ Upstream commit abdfd4948e45c51b19162cf8b3f5003f8f53c9b9 ]
task_pid_vnr(another_task) will crash if the caller was already reaped. The pid_alive(current) check can't really help, the parent/debugger can call release_task() right after this check.
This also means that even task_ppid_nr_ns(current, NULL) is not safe, pid_alive() only ensures that it is safe to dereference ->real_parent.
Change __task_pid_nr_ns() to ensure ns != NULL.
--- kernel/pid.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
kernel/pid.c +2 -1
@@ -497,7 +497,8 @@ pid_t __task_pid_nr_ns(struct task_struct *task, enum pid_type type,rcu_read_lock ();if (!ns) ns =task_active_pid_ns (current); - nr =pid_nr_ns (rcu_dereference (*task_pid_ptr (task, type)), ns); +if (ns) + nr =pid_nr_ns (rcu_dereference (*task_pid_ptr (task, type)), ns);rcu_read_unlock ();return nr;
Signature · 1 line
2.51.0
Re: [PATCH 6.1 163/168] pid: make __task_pid_nr_ns(ns => NULL) safe for zombie callers
Quoted 2 lines · Greg Kroah-Hartman
6.1-stable review patch. If anyone has any objections, please let me know.
Well, I don't think this is a -stable material...
This patch tried to make the usage of __task_pid_nr_ns() more simple/safe, but I don't think we have the problematic users right now.
And please see
[PATCH 1/2] Revert "pid: make __task_pid_nr_ns(ns => NULL) safe for zombie callers" https://lore.kernel.org/all/[email protected]/
because we have another commit 006568ab4c5c ("pid: Add a judgment for ns null in pid_nr_ns"). Which too (imo) is not for -stable. The panic fixed by this patch was caused by the out-of-tree and buggy code.
Oleg.
Quoted 44 lines
------------------
From: Oleg Nesterov <[email protected]>
[ Upstream commit
abdfd4948e45c51b19162cf8b3f5003f8f53c9b9]
task_pid_vnr(another_task)will crash if the caller was already reaped. Thepid_alive(current)check can't really help, the parent/debugger can callrelease_task()right after this check.This also means that even
task_ppid_nr_ns(current, NULL)is not safe,pid_alive()only ensures that it is safe to dereference ->real_parent.Change
__task_pid_nr_ns()to ensure ns != NULL.Originally-by 高翔 <[email protected]>Signed-off-by Oleg Nesterov <[email protected]>Signed-off-by Christian Brauner <[email protected]>Signed-off-by Sasha Levin <[email protected]>--- kernel/pid.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)kernel/pid.c +2
-1@@ -497,7 +497,8 @@ pid_t __task_pid_nr_ns(struct task_struct *task, enum pid_type type,rcu_read_lock ();if (!ns) ns =task_active_pid_ns (current); - nr =pid_nr_ns (rcu_dereference (*task_pid_ptr (task, type)), ns); +if (ns) + nr =pid_nr_ns (rcu_dereference (*task_pid_ptr (task, type)), ns);rcu_read_unlock ();return nr;Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerRe: [PATCH 6.1 163/168] pid: make __task_pid_nr_ns(ns => NULL) safe for zombie callers
Quoted 9 lines · Oleg Nesterov
Quoted 2 lines · Greg Kroah-Hartman
6.1-stable review patch. If anyone has any objections, please let me know.
Well, I don't think this is a -stable material...
This patch tried to make the usage of
__task_pid_nr_ns()more simple/safe, but I don't think we have the problematic users right now.
Quoted 8 lines
And please see
[PATCH 1/2] Revert "pid: make __task_pid_nr_ns(ns => NULL) safe for zombie callers" https://lore.kernel.org/all/[email protected]/because we have another commit
006568ab4c5c("pid: Add a judgment for ns null inpid_nr_ns"). Which too (imo) is not for -stable. The panic fixed by this patch was caused by the out-of-tree and buggy code.
Thanks for letting me know, I'll go drop this patch from all stable queues now.
greg k-h
Greg Kroah-Hartman
maintainerPATCH 164/168 fs: Add initramfs_options to set initramfs mount options
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lichen Liu <[email protected]>
[ Upstream commit 278033a225e13ec21900f0a92b8351658f5377f2 ]
When CONFIG_TMPFS is enabled, the initial root filesystem is a tmpfs. By default, a tmpfs mount is limited to using 50% of the available RAM for its content. This can be problematic in memory-constrained environments, particularly during a kdump capture.
In a kdump scenario, the capture kernel boots with a limited amount of memory specified by the 'crashkernel' parameter. If the initramfs is large, it may fail to unpack into the tmpfs rootfs due to insufficient space. This is because to get X MB of usable space in tmpfs, 2*X MB of memory must be available for the mount. This leads to an OOM failure during the early boot process, preventing a successful crash dump.
This patch introduces a new kernel command-line parameter, initramfs_options, which allows passing specific mount options directly to the rootfs when it is first mounted. This gives users control over the rootfs behavior.
For example, a user can now specify initramfs_options=size=75% to allow the tmpfs to use up to 75% of the available memory. This can significantly reduce the memory pressure for kdump.
Consider a practical example:
To unpack a 48MB initramfs, the tmpfs needs 48MB of usable space. With the default 50% limit, this requires a memory pool of 96MB to be available for the tmpfs mount. The total memory requirement is therefore
approximately: 16MB (vmlinuz) + 48MB (loaded initramfs) + 48MB (unpacked kernel) + 96MB (for tmpfs) + 12MB (runtime overhead) ≈ 220MB.
By using initramfs_options=size=75%, the memory pool required for the 48MB tmpfs is reduced to 48MB / 0.75 = 64MB. This reduces the total memory requirement by 32MB (96MB - 64MB), allowing the kdump to succeed with a smaller crashkernel size, such as 192MB.
An alternative approach of reusing the existing rootflags parameter was considered. However, a new, dedicated initramfs_options parameter was chosen to avoid altering the current behavior of rootflags (which applies to the final root filesystem) and to prevent any potential regressions.
Also add documentation for the new kernel parameter "initramfs_options"
This approach is inspired by prior discussions and patches on the topic.
Ref: https://www.lightofdawn.org/blog/?viewDetailed=00128
Ref: https://landley.net/notes-2015.html#01-01-2015
Ref: https://lkml.org/lkml/2021/6/29/783
Ref: https://www.kernel.org/doc/html/latest/filesystems/ramfs-rootfs-initramfs.html#what-is-rootfs
--- Documentation/admin-guide/kernel-parameters.txt | 3 +++ fs/namespace.c | 11 ++++++++++- 2 files changed, 13 insertions(+), 1 deletion(-)
Documentation/admin-guide/kernel-parameters.txt +3 -0
@@ -5446,6 +5446,9 @@ rootflags= [KNL] Set root filesystem mount option string + initramfs_options= [KNL] + Specify mount options for for the initramfs mount. + rootfstype= [KNL] Set root filesystem type rootwait [KNL] Wait (indefinitely) for root device to show up.
fs/namespace.c +10 -1
@@ -64,6 +64,15 @@ static int __init set_mphash_entries(char *str) }__setup ("mphash_entries=" , set_mphash_entries); +static char *__initdata initramfs_options; +static int __init initramfs_options_setup (char *str) +{ + initramfs_options = str; +return 1 ; +} + +__setup ("initramfs_options=" , initramfs_options_setup); +static u64 event;static DEFINE_IDA (mnt_id_ida);static DEFINE_IDA (mnt_group_ida);
@@ -4414,7 +4423,7 @@ static void __init init_mount_tree(void)struct mnt_namespace *ns;struct path root; - mnt =vfs_kern_mount (&rootfs_fs_type,0 ,"rootfs" ,NULL ); + mnt =vfs_kern_mount (&rootfs_fs_type,0 ,"rootfs" , initramfs_options);if (IS_ERR (mnt))panic ("Can't create rootfs" );
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 165/168 cramfs: Verify inode mode when loading from disk
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tetsuo Handa <[email protected]>
[ Upstream commit 7f9d34b0a7cb93d678ee7207f0634dbf79e47fe5 ]
The inode mode loaded from corrupted disk can be invalid. Do like what commit 0a9e74051313 ("isofs: Verify inode mode when loading from disk") does.
--- fs/cramfs/inode.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-)
fs/cramfs/inode.c +10 -1
@@ -117,9 +117,18 @@ static struct inode *get_cramfs_inode(struct super_block *sb,inode_nohighmem (inode); inode->i_data.a_ops = &cramfs_aops;break ; -default : +case S_IFCHR : +case S_IFBLK : +case S_IFIFO : +case S_IFSOCK :init_special_inode (inode, cramfs_inode->mode,old_decode_dev (cramfs_inode->size)); +break ; +default : +printk (KERN_DEBUG "CRAMFS: Invalid file type 0%04o for inode %lu.\n" , + inode->i_mode, inode->i_ino); +iget_failed (inode); +return ERR_PTR (-EIO ); } inode->i_mode = cramfs_inode->mode;
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 166/168 writeback: Avoid softlockup when switching many inodes
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jan Kara <[email protected]>
[ Upstream commit 66c14dccd810d42ec5c73bb8a9177489dfd62278 ]
process_inode_switch_wbs_work() can be switching over 100 inodes to a different cgroup. Since switching an inode requires counting all dirty & under-writeback pages in the address space of each inode, this can take a significant amount of time. Add a possibility to reschedule after processing each inode to avoid softlockups.
--- fs/fs-writeback.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-)
fs/fs-writeback.c +10 -1
@@ -477,6 +477,7 @@ static void inode_switch_wbs_work_fn(struct work_struct *work)*/ down_read (&bdi->wb_switch_rwsem); + inodep = isw->inodes;/* * By the time control reaches here, RCU grace period has passed * since I_WB_SWITCH assertion and all wb stat update transactions
@@ -487,6 +488,7 @@ static void inode_switch_wbs_work_fn(struct work_struct *work)* gives us exclusion against all wb related operations on @inode * including IO list manipulations and stat updates. */ +relock:if (old_wb < new_wb) {spin_lock (&old_wb->list_lock);spin_lock_nested (&new_wb->list_lock,SINGLE_DEPTH_NESTING );
@@ -495,10 +497,17 @@ static void inode_switch_wbs_work_fn(struct work_struct *work)spin_lock_nested (&old_wb->list_lock,SINGLE_DEPTH_NESTING ); } -for (inodep = isw->inodes; *inodep; inodep++) { +while (*inodep) {WARN_ON_ONCE ((*inodep)->i_wb != old_wb);if (inode_do_switch_wbs (*inodep, old_wb, new_wb)) nr_switched++; + inodep++; +if (*inodep &&need_resched ()) { +spin_unlock (&new_wb->list_lock); +spin_unlock (&old_wb->list_lock); +cond_resched (); + goto relock; + } }spin_unlock (&new_wb->list_lock);
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 167/168 writeback: Avoid excessively long inode switching times
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jan Kara <[email protected]>
[ Upstream commit 9a6ebbdbd41235ea3bc0c4f39e2076599b8113cc ]
With lazytime mount option enabled we can be switching many dirty inodes on cgroup exit to the parent cgroup. The numbers observed in practice when systemd slice of a large cron job exits can easily reach hundreds of thousands or millions. The logic in inode_do_switch_wbs() which sorts the inode into appropriate place in b_dirty list of the target wb however has linear complexity in the number of dirty inodes thus overall time complexity of switching all the inodes is quadratic leading to workers being pegged for hours consuming 100% of the CPU and switching inodes to the parent wb.
Simple reproducer of the issue:
FILES=10000
# Filesystem mounted with lazytime mount option
MNT=/mnt/
echo "Creating files and switching timestamps"
for (( j = 0; j < 50; j ++ )); do
mkdir $MNT/dir$j
for (( i = 0; i < $FILES; i++ )); do
echo "foo" >$MNT/dir$j/file$i
done
touch -a -t 202501010000 $MNT/dir$j/file* done
wait
echo "Syncing and flushing"
sync
echo 3 >/proc/sys/vm/drop_caches
echo "Reading all files from a cgroup"
mkdir /sys/fs/cgroup/unified/mycg1 || exit
echo $$ >/sys/fs/cgroup/unified/mycg1/cgroup.procs || exit
for (( j = 0; j < 50; j ++ )); do
cat /mnt/dir$j/file* >/dev/null &
done
wait
echo "Switching wbs"
# Now rmdir the cgroup after the script exitsWe need to maintain b_dirty list ordering to keep writeback happy so instead of sorting inode into appropriate place just append it at the end of the list and clobber dirtied_time_when. This may result in inode writeback starting later after cgroup switch however cgroup switches are rare so it shouldn't matter much. Since the cgroup had write access to the inode, there are no practical concerns of the possible DoS issues.
--- fs/fs-writeback.c | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-)
fs/fs-writeback.c +11 -10
@@ -420,22 +420,23 @@ static bool inode_do_switch_wbs(struct inode *inode,* Transfer to @new_wb's IO list if necessary. If the @inode is dirty, * the specific list @inode was on is ignored and the @inode is put on * ->b_dirty which is always correct including from ->b_dirty_time. -* The transfer preserves @inode->dirtied_when ordering. If the @inode -* was clean, it means it was on the b_attached list, so move it onto -* the b_attached list of @new_wb. +* If the @inode was clean, it means it was on the b_attached list, so +* move it onto the b_attached list of @new_wb. */ if (!list_empty (&inode->i_io_list)) { inode->i_wb = new_wb;if (inode->i_state &I_DIRTY_ALL ) { -struct inode *pos; - -list_for_each_entry (pos, &new_wb->b_dirty, i_io_list) -if (time_after_eq (inode->dirtied_when, - pos->dirtied_when)) -break ; +/* +* We need to keep b_dirty list sorted by +* dirtied_time_when. However properly sorting the +* inode in the list gets too expensive when switching +* many inodes. So just attach inode at the end of the +* dirty list and clobber the dirtied_time_when. +*/ + inode->dirtied_time_when = jiffies;inode_io_list_move_locked (inode, new_wb, - pos->i_io_list.prev); + &new_wb->b_dirty); }else {inode_cgwb_move_to_attached (inode, new_wb); }
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 168/168 xen/events: Update virq_to_irq on migration
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jason Andryuk <[email protected]>
[ Upstream commit 3fcc8e146935415d69ffabb5df40ecf50e106131 ]
VIRQs come in 3 flavors, per-VPU, per-domain, and global, and the VIRQs are tracked in per-cpu virq_to_irq arrays.
Per-domain and global VIRQs must be bound on CPU 0, and bind_virq_to_irq() sets the per_cpu virq_to_irq at registration time Later, the interrupt can migrate, and info->cpu is updated. When calling __unbind_from_irq(), the per-cpu virq_to_irq is cleared for a different cpu. If bind_virq_to_irq() is called again with CPU 0, the stale irq is returned. There won't be any irq_info for the irq, so things break.
Make xen_rebind_evtchn_to_cpu() update the per_cpu virq_to_irq mappings to keep them update to date with the current cpu. This ensures the correct virq_to_irq is cleared in __unbind_from_irq().
Message-ID: <[email protected]>
--- drivers/xen/events/events_base.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-)
drivers/xen/events/events_base.c +12 -1
@@ -1807,9 +1807,20 @@ static int xen_rebind_evtchn_to_cpu(stru* virq or IPI channel, which don't actually need to be rebound. Ignore * it, but don't do the xenlinux-level rebind in that case. */ -if (HYPERVISOR_event_channel_op (EVTCHNOP_bind_vcpu, &bind_vcpu) >=0 ) +if (HYPERVISOR_event_channel_op (EVTCHNOP_bind_vcpu, &bind_vcpu) >=0 ) { +int old_cpu = info->cpu; +bind_evtchn_to_cpu (evtchn, tcpu, false); +if (info->type ==IRQT_VIRQ ) { +int virq = info->u.virq; +int irq =per_cpu (virq_to_irq, old_cpu)[virq]; + +per_cpu (virq_to_irq, old_cpu)[virq] =-1 ; +per_cpu (virq_to_irq, tcpu)[virq] = irq; + } + } +do_unmask (info,EVT_MASK_REASON_TEMPORARY );return 0 ;
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.1.157 release. There are 168 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sun, 19 Oct 2025 14:50:59 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.1.157-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.1.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v6.1:
10 builds: 10 pass, 0 fail
28 boots: 28 pass, 0 fail
119 tests: 119 pass, 0 failLinux version: 6.1.157-rc1-gec44a71e7948
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra186-p3509-0000+p3636-0001, tegra194-p2972-0000,
tegra194-p3509-0000+p3668-0000, tegra20-ventana,
tegra210-p2371-2180, tegra210-p3450-0000,
tegra30-cardhu-a04Jon
Hi!
Quoted 4 lines
This is the start of the stable review cycle for the 6.1.157 release. There are 168 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
CIP testing did not find any problems here:
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-6.1.y
Best regards,
Pavel
Signature · 2 lines
In cooperation with DENX Software Engineering GmbH, HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
The kernel, bpf tool, perf tool, and kselftest builds fine for v6.1.157-rc1 on x86 and arm64 Azure VM.
Thanks,
Hardik
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.1.157 release. There are 168 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sun, 19 Oct 2025 14:50:59 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.1.157-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.1.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Am 17.10.2025 um 16:51 schrieb Greg Kroah-Hartman:
Quoted 4 lines
This is the start of the stable review cycle for the 6.1.157 release. There are 168 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Builds, boots and works on my 2-socket Ivy Bridge Xeon E5-2697 v2 server. No dmesg oddities or regressions found.
Beste Grüße,
Peter Schneider
Signature · 8 lines
Climb the mountain not to plant your flag, but to embrace the challenge, enjoy the air and behold the view. Climb it so you can see the world, not so the world can see you. -- David McCullough Jr. OpenPGP: 0xA3828BD796CCE11A8CADE8866E3A92C92C3FF244 Download: https://www.peters-netzplatz.de/download/pschneider1968_pub.asc https://keys.mailvelope.com/pks/lookup?op=get&[email protected] https://keys.mailvelope.com/pks/lookup?op=get&[email protected]
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.1.157 release. There are 168 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sun, 19 Oct 2025 14:50:59 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.1.157-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.1.y
and the diffstat can be found below.thanks,
greg k-h
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels, build tested on BMIPS_GENERIC:
Signature · 1 line
Florian
# Librecast Test Results
020/020 [ OK ] liblcrq
010/010 [ OK ] libmld
120/120 [ OK ] liblibrecast
CPU/kernel: Linux auntie 6.1.157-rc1-00169-gec44a71e7948 #113 SMP PREEMPT_DYNAMIC Sat Oct 18 08:16:18 -00 2025 x86_64 AMD Ryzen 9 9950X 16-Core Processor AuthenticAMD GNU/Linux
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.1.157 release. There are 168 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sun, 19 Oct 2025 14:50:59 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.1.157-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.1.y
and the diffstat can be found below.thanks,
greg k-h
The S390 builds failed on stable-rc 6.1.157-rc1 with gcc-14, gcc-8 and clang-21 due to following build warnings / errors.
This reported regressions also found on
- 5.15.195-rc1
- 6.6.113-rc1
### Build error:drivers/s390/cio/device.c: In function 'purge_fn':drivers/s390/cio/device.c:1316:23: error: passing argument 1 of 'spin_lock_irq' from incompatible pointer type [-Wincompatible-pointer-types]
1316 | spin_lock_irq(&sch->lock);
| ^~~~~~~~~~
| |
| spinlock_t ** {aka struct spinlock **}In file included from drivers/s390/cio/device.c:16:include/linux/spinlock.h:374:55: note: expected 'spinlock_t *' {aka 'struct spinlock *'} but argument is of type 'spinlock_t **' {aka 'struct spinlock **'}
374 | static __always_inline void spin_lock_irq(spinlock_t *lock)
| ~~~~~~~~~~~~^~~~
drivers/s390/cio/device.c:1339:25: error: passing argument 1 of
'spin_unlock_irq' from incompatible pointer type
[-Wincompatible-pointer-types]
1339 | spin_unlock_irq(&sch->lock);
| ^~~~~~~~~~
| |
| spinlock_t ** {aka struct spinlock **}include/linux/spinlock.h:399:57: note: expected 'spinlock_t *' {aka 'struct spinlock *'} but argument is of type 'spinlock_t **' {aka 'struct spinlock **'}
399 | static __always_inline void spin_unlock_irq(spinlock_t *lock)
| ~~~~~~~~~~~~^~~~
make[4]: *** [scripts/Makefile.build:250: drivers/s390/cio/device.o] Error 1
### Suspecting patches
Suspecting commit,
s390/cio: Update purge function to unregister the unused subchannels [ Upstream commit 9daa5a8795865f9a3c93d8d1066785b07ded6073 ]
Build regressions: 6.1.157-rc1: s390/cio/device.c:1316:23: error:
passing argument 1 of 'spin_lock_irq' from incompatible pointer type
## Build
* Build log: https://storage.tuxsuite.com/public/linaro/lkft/builds/34COEro5epq7T4CfI69lXe4c1ZJ/build.log
* Build details:
https://regressions.linaro.org/lkft/linux-stable-rc-linux-6.1.y/v6.1.156-169-gec44a71e7948/log-parser-build-kernel/gcc-compiler-_drivers_s_cio_device_c_error_passing_argument_of_spin_lock_irq_from_incompatible_pointer_type/
* Build plan: https://tuxapi.tuxsuite.com/v1/groups/linaro/projects/lkft/builds/34COEro5epq7T4CfI69lXe4c1ZJ
* Build link: https://storage.tuxsuite.com/public/linaro/lkft/builds/34COEro5epq7T4CfI69lXe4c1ZJ/
* Kernel config:
https://storage.tuxsuite.com/public/linaro/lkft/builds/34COEro5epq7T4CfI69lXe4c1ZJ/config
### Steps to reproduce
- tuxmake --runtime podman --target-arch s390 --toolchain gcc-12
--kconfig defconfig
## Build
* kernel: 6.1.157-rc1
* git: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
* git commit: ec44a71e7948d92858fec8b3fbefb7638144f586
* git describe: v6.1.156-169-gec44a71e7948
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.1.y/build/v6.1.156-169-gec44a71e7948
## Test Regressions (compared to v6.1.155-197-gb9f52894e35f)
* s390, build
- clang-21-allnoconfig
- clang-21-defconfig
- clang-21-tinyconfig
- clang-nightly-allnoconfig
- clang-nightly-defconfig
- clang-nightly-tinyconfig
- gcc-14-allmodconfig
- gcc-14-allnoconfig
- gcc-14-defconfig
- gcc-14-tinyconfig
- gcc-8-allnoconfig
- gcc-8-defconfig-fe40093d
- gcc-8-tinyconfig
## Metric Regressions (compared to v6.1.155-197-gb9f52894e35f)
## Test Fixes (compared to v6.1.155-197-gb9f52894e35f)
## Metric Fixes (compared to v6.1.155-197-gb9f52894e35f)
## Test result summary
total: 87986, pass: 72984, fail: 2700, skip: 12061, xfail: 241
## Build Summary
* arc: 5 total, 5 passed, 0 failed
* arm: 133 total, 132 passed, 1 failed
* arm64: 41 total, 38 passed, 3 failed
* i386: 21 total, 21 passed, 0 failed
* mips: 26 total, 25 passed, 1 failed
* parisc: 4 total, 4 passed, 0 failed
* powerpc: 32 total, 31 passed, 1 failed
* riscv: 11 total, 10 passed, 1 failed
* s390: 14 total, 0 passed, 14 failed
* sh: 10 total, 10 passed, 0 failed
* sparc: 7 total, 7 passed, 0 failed
* x86_64: 33 total, 32 passed, 1 failed
## Test suites summary
* boot
* commands
* kselftest-arm64
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-exec
* kselftest-fpu
* kselftest-futex
* kselftest-intel_pstate
* kselftest-kcmp
* kselftest-kvm
* kselftest-livepatch
* kselftest-membarrier
* kselftest-mincore
* kselftest-mqueue
* kselftest-openat2
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-sigaltstack
* kselftest-size
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user_events
* kselftest-vDSO
* kselftest-x86
* kunit
* kvm-unit-tests
* lava
* libgpiod
* libhugetlbfs
* log-parser-boot
* log-parser-build-clang
* log-parser-build-gcc
* log-parser-test
* ltp-capability
* ltp-commands
* ltp-containers
* ltp-controllers
* ltp-cpuhotplug
* ltp-crypto
* ltp-cve
* ltp-dio
* ltp-fcntl-locktests
* ltp-fs
* ltp-fs_bind
* ltp-fs_perms_simple
* ltp-hugetlb
* ltp-math
* ltp-mm
* ltp-nptl
* ltp-pty
* ltp-sched
* ltp-smoke
* ltp-syscalls
* ltp-tracing
* perf
* rcutorture
--
Linaro LKFT
https://lkft.linaro.org
Quoted 8 lines · On Fri, 17 Oct 2025 16:51:19 +0200 Greg Kroah-Hartman…
This is the start of the stable review cycle for the 6.1.157 release. There are 168 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sun, 19 Oct 2025 14:50:59 +0000. Anything received after that time might be too late.
Boot-tested under QEMU for Rust x86_64:
Thanks!
Cheers,
Miguel