1 files changed, 71 insertions, 0 deletions
diff --git a/debian/patches-rt/0086-printk-Adjust-mapping-for-32bit-seq-macros.patch b/debian/patches-rt/0086-printk-Adjust-mapping-for-32bit-seq-macros.patch
new file mode 100644
index 0000000000..d6ff341f46
--- /dev/null
+++ b/debian/patches-rt/0086-printk-Adjust-mapping-for-32bit-seq-macros.patch
@@ -0,0 +1,71 @@
+From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
+Date: Thu, 7 Dec 2023 14:15:15 +0000
+Subject: [PATCH 086/134] printk: Adjust mapping for 32bit seq macros
+Origin: https://www.kernel.org/pub/linux/kernel/projects/rt/6.6/older/patches-6.6.7-rt18.tar.xz
+
+Note: This change only applies to 32bit architectures. On 64bit
+      architectures the macros are NOPs.
+
+__ulseq_to_u64seq() computes the upper 32 bits of the passed
+argument value (@ulseq). The upper bits are derived from a base
+value (@rb_next_seq) in a way that assumes @ulseq represents a
+64bit number that is less than or equal to @rb_next_seq.
+
+Until now this mapping has been correct for all call sites. However,
+in a follow-up commit, values of @ulseq will be passed in that are
+higher than the base value. This requires a change to how the 32bit
+value is mapped to a 64bit sequence number.
+
+Rather than mapping @ulseq such that the base value is the end of a
+32bit block, map @ulseq such that the base value is in the middle of
+a 32bit block. This allows supporting 31 bits before and after the
+base value, which is deemed acceptable for the console sequence
+number during runtime.
+
+Here is an example to illustrate the previous and new mappings.
+
+For a base value (@rb_next_seq) of 2 2000 0000...
+
+Before this change the range of possible return values was:
+
+1 2000 0001 to 2 2000 0000
+
+__ulseq_to_u64seq(1fff ffff) => 2 1fff ffff
+__ulseq_to_u64seq(2000 0000) => 2 2000 0000
+__ulseq_to_u64seq(2000 0001) => 1 2000 0001
+__ulseq_to_u64seq(9fff ffff) => 1 9fff ffff
+__ulseq_to_u64seq(a000 0000) => 1 a000 0000
+__ulseq_to_u64seq(a000 0001) => 1 a000 0001
+
+After this change the range of possible return values are:
+1 a000 0001 to 2 a000 0000
+
+__ulseq_to_u64seq(1fff ffff) => 2 1fff ffff
+__ulseq_to_u64seq(2000 0000) => 2 2000 0000
+__ulseq_to_u64seq(2000 0001) => 2 2000 0001
+__ulseq_to_u64seq(9fff ffff) => 2 9fff ffff
+__ulseq_to_u64seq(a000 0000) => 2 a000 0000
+__ulseq_to_u64seq(a000 0001) => 1 a000 0001
+
+[ john.ogness: Rewrite commit message. ]
+
+Reported-by: Francesco Dolcini <francesco@dolcini.it>
+Reported-by: kernel test robot <oliver.sang@intel.com>
+Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
+Signed-off-by: John Ogness <john.ogness@linutronix.de>
+Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
+---
+ kernel/printk/printk_ringbuffer.h |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/kernel/printk/printk_ringbuffer.h
++++ b/kernel/printk/printk_ringbuffer.h
+@@ -407,7 +407,7 @@ static inline u64 __ulseq_to_u64seq(stru
+ 	 * Also the access to the ring buffer is always safe.
+ 	 */
+ 	rb_next_seq = prb_next_seq(rb);
+-	seq = rb_next_seq - ((u32)rb_next_seq - ulseq);
++	seq = rb_next_seq - (s32)((u32)rb_next_seq - ulseq);
+ 
+ 	return seq;
+ }