All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick McHardy <kaber@trash.net>
To: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Subject: Re: [RFC PATCH 7/9] ipv4: ipmr: convert struct mfc_cache to struct list_head
Date: Tue, 13 Apr 2010 13:18:26 +0200	[thread overview]
Message-ID: <4BC45302.7080004@trash.net> (raw)
In-Reply-To: <20100413.041506.177518126.davem@davemloft.net>

David Miller wrote:
> From: kaber@trash.net
> Date: Sun, 11 Apr 2010 19:37:13 +0200
> 
>> From: Patrick McHardy <kaber@trash.net>
>>
>> Signed-off-by: Patrick McHardy <kaber@trash.net>
> 
> Great, it looks like you didn't fall into most of the
> traps that usually occur during a list_head conversion :-)
> 
> But:
> 
>> -		c->next = net->ipv4.mfc_unres_queue;
>> -		net->ipv4.mfc_unres_queue = c;
>> +		list_add_tail(&c->list, &net->ipv4.mfc_unres_queue);
>  ...
>>  	write_lock_bh(&mrt_lock);
>> -	c->next = net->ipv4.mfc_cache_array[line];
>> -	net->ipv4.mfc_cache_array[line] = c;
>> +	list_add_tail(&c->list, &net->ipv4.mfc_cache_array[line]);
>>  	write_unlock_bh(&mrt_lock);
> 
> Are you sure we mean to insert to the tail here?  It looks like a head
> insertion to me beforehand, and the fact that the previous list
> iterators start at the list head pointer seem to confirm this.

I don't think it matters since each entry only exists once and
there are no ordering requirements, but I'll change it just to
make sure.

Thanks for your review so far :)

  reply	other threads:[~2010-04-13 11:18 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-11 17:37 [RFC PATCH 0/9] net: support multiple independant multicast routing instances kaber
2010-04-11 17:37 ` [RFC PATCH 1/9] net: fib_rules: consolidate IPv4 and DECnet ->default_pref() functions kaber
2010-04-13 11:06   ` David Miller
2010-04-11 17:37 ` [RFC PATCH 2/9] net: fib_rules: set family in fib_rule_hdr centrally kaber
2010-04-13 11:06   ` David Miller
2010-04-11 17:37 ` [RFC PATCH 3/9] net: fib_rules: decouple address families from real address families kaber
2010-04-13 11:08   ` David Miller
2010-04-11 17:37 ` [RFC PATCH 4/9] ipv4: raw: move struct raw_sock and raw_sk() to include/net/raw.h kaber
2010-04-13 11:09   ` David Miller
2010-04-11 17:37 ` [RFC PATCH 5/9] ipv4: ipmr: move unres_queue and timer to per-namespace data kaber
2010-04-13 11:10   ` David Miller
2010-04-11 17:37 ` [RFC PATCH 6/9] ipv4: ipmr: remove net pointer from struct mfc_cache kaber
2010-04-13 11:10   ` David Miller
2010-04-11 17:37 ` [RFC PATCH 7/9] ipv4: ipmr: convert struct mfc_cache to struct list_head kaber
2010-04-13 11:15   ` David Miller
2010-04-13 11:18     ` Patrick McHardy [this message]
2010-04-11 17:37 ` [RFC PATCH 8/9] net: ipmr: move mroute data into seperate structure kaber
2010-04-13 11:15   ` David Miller
2010-04-11 17:37 ` [RFC PATCH 9/9] net: ipmr: support multiple tables kaber
2010-04-13 11:17   ` David Miller
2010-04-13 11:18     ` Patrick McHardy

Reply instructions:

You may reply publicly 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=4BC45302.7080004@trash.net \
    --to=kaber@trash.net \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.