Kernel Newbies archive on lore.kernel.org
 help / color / Atom feed
From: laokz <laokz@foxmail.com>
To: kernelnewbies@kernelnewbies.org
Subject: questions about kfifo
Date: Mon, 01 Jul 2019 15:07:08 +0800
Message-ID: <5ca240404b42f1a298cf6c73126c772ae616f109.camel@foxmail.com> (raw)

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

                 reply index

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5ca240404b42f1a298cf6c73126c772ae616f109.camel@foxmail.com \
    --to=laokz@foxmail.com \
    --cc=kernelnewbies@kernelnewbies.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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