From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752024AbdBNG7l (ORCPT ); Tue, 14 Feb 2017 01:59:41 -0500 Received: from mga05.intel.com ([192.55.52.43]:45456 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750716AbdBNG7k (ORCPT ); Tue, 14 Feb 2017 01:59:40 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.35,160,1484035200"; d="scan'208";a="820644410" From: "Huang\, Ying" To: Byungchul Park Cc: "Huang\, Ying" , , , , , , , , Subject: Re: [PATCH v2 1/9] llist: Provide a safe version for llist_for_each References: <1486970469-30917-1-git-send-email-byungchul.park@lge.com> <1486970469-30917-2-git-send-email-byungchul.park@lge.com> <87efz2pmny.fsf@yhuang-dev.intel.com> <20170213074403.GK16086@X58A-UD3R> <87y3xao7cj.fsf@yhuang-dev.intel.com> <20170213075805.GL16086@X58A-UD3R> <20170214064452.GQ16086@X58A-UD3R> Date: Tue, 14 Feb 2017 14:59:36 +0800 In-Reply-To: <20170214064452.GQ16086@X58A-UD3R> (Byungchul Park's message of "Tue, 14 Feb 2017 15:44:52 +0900") Message-ID: <8760kdgsvb.fsf@yhuang-dev.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Byungchul Park writes: > On Mon, Feb 13, 2017 at 04:58:05PM +0900, Byungchul Park wrote: >> On Mon, Feb 13, 2017 at 03:52:44PM +0800, Huang, Ying wrote: >> > Byungchul Park writes: >> > >> > > On Mon, Feb 13, 2017 at 03:36:33PM +0800, Huang, Ying wrote: >> > >> Byungchul Park writes: >> > >> >> > >> > Sometimes we have to dereference next field of llist node before entering >> > >> > loop becasue the node might be deleted or the next field might be >> > >> > modified within the loop. So this adds the safe version of llist_for_each, >> > >> > that is, llist_for_each_safe. >> > >> > >> > >> > Signed-off-by: Byungchul Park >> > >> > --- >> > >> > include/linux/llist.h | 19 +++++++++++++++++++ >> > >> > 1 file changed, 19 insertions(+) >> > >> > >> > >> > diff --git a/include/linux/llist.h b/include/linux/llist.h >> > >> > index fd4ca0b..4c508a5 100644 >> > >> > --- a/include/linux/llist.h >> > >> > +++ b/include/linux/llist.h >> > >> > @@ -105,6 +105,25 @@ static inline void init_llist_head(struct llist_head *list) >> > >> > for ((pos) = (node); pos; (pos) = (pos)->next) >> > >> > >> > >> > /** >> > >> > + * llist_for_each_safe - iterate over some deleted entries of a lock-less list >> > >> > + * safe against removal of list entry >> > >> > + * @pos: the &struct llist_node to use as a loop cursor >> > >> > + * @n: another type * to use as temporary storage >> > >> >> > >> s/type */&struct llist_node/ >> > > >> > > Yes. >> > > >> > >> >> > >> > + * @node: the first entry of deleted list entries >> > >> > + * >> > >> > + * In general, some entries of the lock-less list can be traversed >> > >> > + * safely only after being deleted from list, so start with an entry >> > >> > + * instead of list head. >> > >> > + * >> > >> > + * If being used on entries deleted from lock-less list directly, the >> > >> > + * traverse order is from the newest to the oldest added entry. If >> > >> > + * you want to traverse from the oldest to the newest, you must >> > >> > + * reverse the order by yourself before traversing. >> > >> > + */ >> > >> > +#define llist_for_each_safe(pos, n, node) \ >> > >> > + for ((pos) = (node); (pos) && ((n) = (pos)->next, true); (pos) = (n)) >> > >> > + >> > >> >> > >> Following the style of other xxx_for_each_safe, >> > >> >> > >> #define llist_for_each_safe(pos, n, node) \ >> > >> for (pos = (node), (pos && (n = pos->next)); pos; pos = n, n = pos->next) >> > > >> > > Do you think it should be modified? I think mine is simpler. No? >> > >> > Personally I prefer the style of other xxx_for_each_safe(). >> >> Yes, I will modify it as you recommand. >> >> Thank you very much. > > I wanted to modify it as you recommanded but it has a bug. It should be > (to fix the bug): > > for (pos = (node), (pos && (n = pos->next)); pos; pos = n, (pos && \ > (n = pos->next))) > > Don't you think this is too messy? Or do I miss something? I still think > the following is neater and simpler. > > for (pos = node; pos && (n = pos->next, true); pos = n) OK. This looks better. Best Regards, Huang, Ying > Or could you recommand another preference?