Messages in this thread | | | Date | Fri, 12 Jan 2024 11:28:33 +0100 | From | Petr Mladek <> | Subject | Re: [PATCH printk v3 02/14] printk: Adjust mapping for 32bit seq macros |
| |
On Thu 2023-12-14 22:47:49, John Ogness wrote: > 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> > Closes: https://lore.kernel.org/oe-lkp/202311171611.78d41dbe-oliver.sang@intel.com > Reported-by: kernel test robot <oliver.sang@intel.com> > Closes: https://lore.kernel.org/oe-lkp/202311161555.3ee16fc9-oliver.sang@intel.com > Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> > Signed-off-by: John Ogness <john.ogness@linutronix.de>
Great catch! It must have been complicated to debug this.
Reviewed-by: Petr Mladek <pmladek@suse.com>
Best Regards, Petr
| |