Kernel Newbies archive on lore.kernel.org
 help / color / Atom feed
* questions about kfifo
@ 2019-07-01  7:07 laokz
  0 siblings, 0 replies; only message in thread
From: laokz @ 2019-07-01  7:07 UTC (permalink / raw)
  To: kernelnewbies

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.

From 
http://linux-kernel.2935.n7.nabble.com/template/NamlServlet.jtp?macro=search_page&node=578203&query=author%3A%22Stefani+Seibold%22&days=0
, 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
and __KFIFO_POKE?

Thanks,
laokz






_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, back to index

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-07-01  7:07 questions about kfifo laokz

Kernel Newbies archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/kernelnewbies/0 kernelnewbies/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 kernelnewbies kernelnewbies/ https://lore.kernel.org/kernelnewbies \
		kernelnewbies@kernelnewbies.org kernelnewbies@archiver.kernel.org
	public-inbox-index kernelnewbies


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernelnewbies.kernelnewbies


AGPL code for this site: git clone https://public-inbox.org/ public-inbox