Messages in this thread | | | Date | Fri, 12 Jan 2024 17:19:29 +0100 | From | Petr Mladek <> | Subject | Re: [PATCH printk v3 03/14] printk: Use prb_first_seq() as base for 32bit seq macros |
| |
On Thu 2023-12-14 22:47:50, John Ogness wrote: > Note: This change only applies to 32bit architectures. On 64bit > architectures the macros are NOPs. > > Currently prb_next_seq() is used as the base for the 32bit seq > macros __u64seq_to_ulseq() and __ulseq_to_u64seq(). However, in > a follow-up commit, prb_next_seq() will need to make use of the > 32bit seq macros. > > Use prb_first_seq() as the base for the 32bit seq macros instead > because it is guaranteed to return 64bit sequence numbers without > relying on any 32bit seq macros. > > Signed-off-by: John Ogness <john.ogness@linutronix.de>
This increases the risk of an overflow which would result into wrong u64 sequence number. I was curious what numbers we are talking about.
Here is my thinking:
The difference between prb_next_seq() and prb_first_seq() is limited by the amount of messages stored in the buffer.
Every stored message must have meta data stored in desc_ring. The current code expects average length of the message to be 32.
Now, __ulseq_to_u64seq() would give wrong result when (s32)((u32)rb_first_seq - ulseq) overflows. It is 2^31 sequence numbers.
If we create desc buffer for these messages then the data buffer would be 32x bigger, so:
2^31 * 32 = 68,719,476,736 => 68GB
=> we seem to be on the safe side with a good reserve.
Reviewed-by: Petr Mladek <pmladek@suse.com>
Best Regards, Petr
| |