From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=0.9 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, INVALID_MSGID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 98043C742A2 for ; Thu, 11 Jul 2019 19:14:55 +0000 (UTC) Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 0120721019 for ; Thu, 11 Jul 2019 19:14:53 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=foxmail.com header.i=@foxmail.com header.b="S9Dv4gdU" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0120721019 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=foxmail.com Authentication-Results: mail.kernel.org; spf=fail smtp.mailfrom=kernelnewbies-bounces@kernelnewbies.org Received: from localhost ([::1] helo=shelob.surriel.com) by shelob.surriel.com with esmtp (Exim 4.92) (envelope-from ) id 1hleWO-0002pn-Td; Thu, 11 Jul 2019 15:14:24 -0400 Received: from smtpproxy19.qq.com ([184.105.206.84]) by shelob.surriel.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1hhqPh-0006NC-IF for kernelnewbies@kernelnewbies.org; Mon, 01 Jul 2019 03:07:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=foxmail.com; s=s201512; t=1561964831; bh=uWn4ipWWShg9OjStqOVjCA4DXlOqkUttBrtuaNdPtv0=; h=Message-ID:Subject:From:To:Date:MIME-Version; b=S9Dv4gdU6aUvDuP5uuSjofyNx9Q6IBsINWXoFcgg3c0xMOlcCzG56AxfGV7IOKvRi 37cekIvelgDsAzBakYyQb3CXT1G7FQBJXjxqM6ILjMf5wP85XvxRlqSMoORm+bXaoE 3Ohv2x7YeXMXPD53CtC4UKltJ/SCVlUwbd9BIsoo= X-QQ-mid: esmtp7t1561964830tyr4spc9k Received: from swind (unknown [119.108.214.73]) by esmtp4.qq.com (ESMTP) with SMTP id 0 for ; Mon, 01 Jul 2019 15:07:09 +0800 (CST) X-QQ-SSF: 01000000000000F0F4100F000000003 X-QQ-FEAT: 2qHYTc5/T5OM5YkB8M9x5DtBY0MYyCe33/T4mGRPbtnFzPg4KUXtY05l4BsNY 0hv66Jo/Dw8XUN5BIl3MazmyYgBn7XgW9l9AApuZiMpYItwLWrpyWyAjF7B0ySAAr2GD9TU 3mBs1Gk8wDc1l4yCjznIAqMOh+tE5t9fPCyxBKND2oMGOYnIexgfUhlAbLVCdnLULLOB/QO H3UDOsM8kKvMInOUqrvTLFIXORIehHwNY5/WWKVIZtOUDy5ci09UcUwNdN0CLZlEdKQwOCt vhXPer6fMkv0xH X-QQ-GoodBg: 0 Message-ID: <5ca240404b42f1a298cf6c73126c772ae616f109.camel@foxmail.com>+82343598D6BBE339 Subject: questions about kfifo From: laokz To: kernelnewbies@kernelnewbies.org Date: Mon, 01 Jul 2019 15:07:08 +0800 User-Agent: Evolution 3.30.5-1.1 MIME-Version: 1.0 X-QQ-SENDSIZE: 520 Feedback-ID: esmtp:foxmail.com:bgforeign:bgforeign4 X-QQ-Bgrelay: 1 X-Mailman-Approved-At: Thu, 11 Jul 2019 15:14:23 -0400 X-BeenThere: kernelnewbies@kernelnewbies.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Learn about the Linux kernel List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kernelnewbies-bounces@kernelnewbies.org 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