Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp3772692ybl; Tue, 20 Aug 2019 01:57:24 -0700 (PDT) X-Google-Smtp-Source: APXvYqxJIthYs1ytBRvjJIjejgxe80t9ktpDnFdYTuba1InkF5HETSrf4/liw6eVMwP29+/+u78l X-Received: by 2002:a63:394:: with SMTP id 142mr23778805pgd.43.1566291444183; Tue, 20 Aug 2019 01:57:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1566291444; cv=none; d=google.com; s=arc-20160816; b=WFpVHbm3sdsRgwpOsQK0H72/mQziCfXBJ4xs4Th+j2D0acYHrRFX8zlh4lAewciD3I Bcq2v8ca/IH6tk10nmXqOlWXMVmsuPZpj1rqyf9f6Od8LAe+97WJXvrbWpSh6IefHaIP iZXDDxj+F5p9pEuMsU6Kd1CpjAIAL/C4zu/8nTpSZkHYEwnZLXvSyltAkwUntXibLKyn gISmtwEZks5/WXMFitaSbd4tev9t6VFO+QPP3z2ln8aUerhl6GKps63UR+rQDiwJEyAX h4royHaWEwi9IjTzkTKapvxfZzFQ+JxHWm4/hNjcjKSGX0nkmFQ5gaG1sRoERdKGBjll 3OPA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=CYYz6T73/PZIwSc5YBFuCqu3hyyN5tI2lm3pnBENB+0=; b=Mz8/07R6qKDy+Y460D1rMrjxCwtviS7+3VWF85w9gmagGKqa9PQ/SU06dvvR5N6UMP /yUGTT4xNWscEFitE6IgEn1yj26OOJrtSfK0zghKFEfM973SK2T8GquXiG9ONKyzUpJp lhHbNtxVb16y7dqrmQttnyAiV072h2fn686amhxtEsYQ6JbB1IxTzFGR3g4WnClv4Cyr b9tSNkLSpFawTWyThFFKLkQc9CvSxqESZDiAAjGdWNv/cuOnZISMfsaprvy1ciaXF9Cq jMBDEYuCCRaT7AK+P4vziJC6Els4SGy8mbvxfWa62x8oJi/PQmZwCDidFlkALmYScVRq sVrg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p22si11823790pli.255.2019.08.20.01.57.09; Tue, 20 Aug 2019 01:57:24 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729400AbfHTIz5 (ORCPT + 99 others); Tue, 20 Aug 2019 04:55:57 -0400 Received: from mx2.suse.de ([195.135.220.15]:60992 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728545AbfHTIz4 (ORCPT ); Tue, 20 Aug 2019 04:55:56 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id DAEA6ABC4; Tue, 20 Aug 2019 08:55:54 +0000 (UTC) Date: Tue, 20 Aug 2019 10:55:54 +0200 From: Petr Mladek To: John Ogness Cc: linux-kernel@vger.kernel.org, Andrea Parri , Sergey Senozhatsky , Sergey Senozhatsky , Steven Rostedt , Brendan Higgins , Peter Zijlstra , Thomas Gleixner , Linus Torvalds , Greg Kroah-Hartman Subject: comments style: Re: [RFC PATCH v4 1/9] printk-rb: add a new printk ringbuffer implementation Message-ID: <20190820085554.deuejmxn4kbqnq7n@pathway.suse.cz> References: <20190807222634.1723-1-john.ogness@linutronix.de> <20190807222634.1723-2-john.ogness@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190807222634.1723-2-john.ogness@linutronix.de> User-Agent: NeoMutt/20170912 (1.9.0) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu 2019-08-08 00:32:26, John Ogness wrote: > --- /dev/null > +++ b/kernel/printk/dataring.c > +/** > + * _datablock_valid() - Check if given positions yield a valid data block. > + * > + * @dr: The associated data ringbuffer. > + * > + * @head_lpos: The newest data logical position. > + * > + * @tail_lpos: The oldest data logical position. > + * > + * @begin_lpos: The beginning logical position of the data block to check. > + * > + * @next_lpos: The logical position of the next adjacent data block. > + * This value is used to identify the end of the data block. > + * Please remove the empty lines between arguments description. They make the comments too scattered. > + * A data block is considered valid if it satisfies the two conditions: > + * > + * * tail_lpos <= begin_lpos < next_lpos <= head_lpos > + * * tail_lpos is at most exactly 1 wrap behind head_lpos > + * > + * Return: true if the specified data block is valid. > + */ To be sure, the empty lines between paragraphs are useful. The following is still well readable: /** * _datablock_valid() - Check if given positions yield a valid data block. * @dr: The associated data ringbuffer. * @head_lpos: The newest data logical position. * @tail_lpos: The oldest data logical position. * @begin_lpos: The beginning logical position of the data block to check. * @next_lpos: The logical position of the next adjacent data block. * This value is used to identify the end of the data block. * A data block is considered valid if it satisfies the two conditions: * * * tail_lpos <= begin_lpos < next_lpos <= head_lpos * * tail_lpos is at most exactly 1 wrap behind head_lpos * * Return: true if the specified data block is valid. */ > +static unsigned long _dataring_pop(struct dataring *dr, > + unsigned long tail_lpos) > +{ > + unsigned long new_tail_lpos; > + unsigned long begin_lpos; > + unsigned long next_lpos; > + struct dr_datablock *db; > + struct dr_desc *desc; > + > + /* > + * dA: > + * > + * @db has an address dependency on @tail_pos. Therefore @tail_lpos > + * must be loaded before dB, which accesses @db. > + */ > + db = to_datablock(dr, tail_lpos); > + > + /* > + * dB: > + * > + * When a writer has completed accessing its data block, it sets the > + * @id thus making the data block available for invalidation. This > + * _acquire() ensures that this task sees all data ringbuffer and > + * descriptor values seen by the writer as @id was set. This is > + * necessary to ensure that the data block can be correctly identified > + * as valid (i.e. @begin_lpos, @next_lpos, @head_lpos are at least the > + * values seen by that writer, which yielded a valid data block at > + * that time). It is not enough to rely on the address dependency of > + * @desc to @id because @head_lpos is not depedent on @id. This pairs > + * with the _release() in dataring_datablock_setid(). This human readable description is really useful. > + * > + * Memory barrier involvement: > + * > + * If dB reads from gA, then dC reads from fG. > + * If dB reads from gA, then dD reads from fH. > + * If dB reads from gA, then dE reads from fE. > + * > + * Note that if dB reads from gA, then dC cannot read from fC. > + * Note that if dB reads from gA, then dD cannot read from fD. > + * > + * Relies on: > + * > + * RELEASE from fG to gA > + * matching > + * ADDRESS DEP. from dB to dC > + * > + * RELEASE from fH to gA > + * matching > + * ADDRESS DEP. from dB to dD > + * > + * RELEASE from fE to gA > + * matching > + * ACQUIRE from dB to dE > + */ But I am not sure how much this is useful. It would take ages to decrypt all these shortcuts (signs) and translate them into something human readable. Also it might get outdated easily. That said, I haven't found yet if there was a system in all the shortcuts. I mean if they can be descrypted easily out of head. Also I am not familiar with the notation of the dependencies. If this is really needed then I am really scared of some barriers that guard too many things. This one is a good example. > + desc = dr->getdesc(smp_load_acquire(&db->id), dr->getdesc_arg); > + > + /* dD: */ It would be great if all these shortcuts (signs) are followed with something human readable. Few words might be enough. > + next_lpos = READ_ONCE(desc->next_lpos); > + > + if (!_datablock_valid(dr, > + /* dE: */ > + atomic_long_read(&dr->head_lpos), > + tail_lpos, begin_lpos, next_lpos)) { > + /* Another task has already invalidated the data block. */ > + goto out; > + } > + > + > +++ b/kernel/printk/numlist.c > +bool numlist_read(struct numlist *nl, unsigned long id, unsigned long *seq, > + unsigned long *next_id) > +{ > + struct nl_node *n; > + > + n = nl->node(id, nl->node_arg); > + if (!n) > + return false; > + > + if (seq) { > + /* > + * aA: > + * > + * Adresss dependency on @id. > + */ This is too scattered. If we really need so many shortcuts (signs) then we should find a better style. The following looks perfectly fine to me: /* aA: Adresss dependency on @id. */ > + *seq = READ_ONCE(n->seq); > + } > + > + if (next_id) { > + /* > + * aB: > + * > + * Adresss dependency on @id. > + */ > + *next_id = READ_ONCE(n->next_id); > + } > + Best Regards, Petr