From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752468AbdBNGpR (ORCPT ); Tue, 14 Feb 2017 01:45:17 -0500 Received: from LGEAMRELO11.lge.com ([156.147.23.51]:37535 "EHLO lgeamrelo11.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752187AbdBNGpQ (ORCPT ); Tue, 14 Feb 2017 01:45:16 -0500 X-Original-SENDERIP: 156.147.1.127 X-Original-MAILFROM: byungchul.park@lge.com X-Original-SENDERIP: 10.177.222.33 X-Original-MAILFROM: byungchul.park@lge.com Date: Tue, 14 Feb 2017 15:44:52 +0900 From: Byungchul Park To: "Huang, Ying" Cc: peterz@infradead.org, mingo@kernel.org, neilb@suse.de, nab@linux-iscsi.org, viro@zeniv.linux.org.uk, oleg@redhat.com, shli@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 1/9] llist: Provide a safe version for llist_for_each Message-ID: <20170214064452.GQ16086@X58A-UD3R> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170213075805.GL16086@X58A-UD3R> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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) Or could you recommand another preference?