questions about kfifo

laokz laokz at
Mon Jul 1 03:07:08 EDT 2019

Hello, all

I have a few questions about kfifo, wishing your opinions.

1. Why __kfifo_init() roundup_pow_of_two(size) nor down?

__kfifo_init() is called by kfifo_init() to initialize a fifo using a
preallocated buffer. If the buffer size is not pow_of_two, it will be
rounded up to the next power of two. But __kfifo_init() only adjusts the
fifo's internal argument 'mask' to reflect the new size, DOES NOT adjust the
preallocated buffer! If so, there would be a potential 'memory collapse'.

Fortunately, I haven't caught any complaint about this. Maybe as
kfifo_init() is the only caller and no much driver use it.

, I know, before 3.9 its algorithm was round down. After a big
discussion, __kfifo_alloc and __kfifo_init all adopted 'to alloc at least
the requested number of elements'. For __kfifo_alloc there is no problem,
but for __kfifo_init it is wrong I think, because __kfifo_alloc's buffer is
managed by kernel itself, __kfifo_init's buffer by user.

My question is, though few application scenarios and 'pow_of_two' rule
should be obey, is it more robust back to round down? Then, 'if a user do
the wrong thing, then the user will get also a wrong result', but NOT a
wrong system.

2. Is it better to optimize __kfifo_in_r()?

__kfifo_in_r() is an enqueue function, first it calls __kfifo_poke_n() to
write the number of elements, then kfifo_copy_in() for actual elements.

In kfifo_copy_in(), it adjusts 'buffer offset' by multiply 'element size' if
esize != 1 before writing, but __kfifo_poke_n() doesn't -- that is, in
special situation __kfifo_in_r() may use inconsistent offset unit to write
this 2 kinds of data. Dequeue function __kfifo_out_r() also has the issue.

I learn that the FIFO model with 'sizeof(datatype)>1 && recsize>0' is
actually not supported by kernel. But to make a more 'generic kernel FIFO
implementation', is it better to do a little fix of 2 helpers __KFIFO_PEEK


More information about the Kernelnewbies mailing list