On Sun, Sep 30, 2007 at 08:26:01AM +0800, Herbert Xu wrote:
>
> Indeed. The only other case I can think of is defragmentation.
> But even there we should be able to squeeze it into the original
> skb :)
OK it won't be pretty but it's definitely doable. We simply
swap the contents of that skb wit
On Sat, Sep 29, 2007 at 11:18:18AM -0600, Eric W. Biederman wrote:
>
> Regardless of the correctness of where we have ASSERT_RTNL.
> I think not actually taking the mutex on the assertion failure path
> (just so we can release it), is still a good deal regardless.
Provided that you add a might_sle
On Sat, Sep 29, 2007 at 05:13:39PM -0700, David Miller wrote:
>
> The reason is that if we have to COW or resize the SKB it
> could result in a realloc of the sk_buff struct which is
> why we need the **pskb thing.
>
> But strangely I can't find any skbuff.h interfaces that
> require that any lon
On Sat, Sep 29, 2007 at 05:32:41PM +0200, Patrick McHardy wrote:
>
> For unicast addresses its not strictly necessary since they may
> only be changed under the RTNL anyway. The reason why it takes
> the tx_lock is for consistency with multicast address handling,
> which can't rely on the RTNL sinc
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Sat, 29 Sep 2007 17:21:23 +0200
> Unfortunately gcc doesn't perform tail call optimization when the
> address of a parameter or local variable is passed to an extern
> function before the tail call, which NF_HOOK does for the skb.
To which Herbert l
On Sat, Sep 29, 2007 at 05:21:23PM +0200, Patrick McHardy wrote:
>
> Unfortunately gcc doesn't perform tail call optimization when the
> address of a parameter or local variable is passed to an extern
> function before the tail call, which NF_HOOK does for the skb.
You mean the struct sk_buff **ps
Patrick McHardy <[EMAIL PROTECTED]> writes:
> Maybe I can save you some time: we used to do down_trylock()
> for the rtnl mutex, so senders would simply return if someone
> else was already processing the queue *or* the rtnl was locked
> for some other reason. In the first case the process already
On Sat, 29 Sep 2007, Cedric Le Goater wrote:
> Ilpo Järvinen wrote:
> > On Fri, 28 Sep 2007, Ilpo Järvinen wrote:
> >> On Fri, 28 Sep 2007, Cedric Le Goater wrote:
> >>
> >>> I just found that warning in my logs. It seems that it's been
> >>> happening since rc7-mm1 at least.
> >>>
> >>> WARNING
As discussed before, this patch provides userland with a way to access
relevant options in Router Advertisements, after they are processed and
validated by the kernel. Extra options are processed in a generic way;
this patch only exports RDNSS options described in RFC5006, but support
to control wh
Eric W. Biederman wrote:
> Regardless of the correctness of where we have ASSERT_RTNL.
> I think not actually taking the mutex on the assertion failure path
> (just so we can release it), is still a good deal regardless.
Agreed. I actually have an identical patch somewhere that
I wanted to submit
Eric W. Biederman wrote:
> Patrick McHardy <[EMAIL PROTECTED]> writes:
>
>>>Currently I don't fold the namesapce into the hash so multiple
>>>namespaces using the same socket name will be guaranteed a hash
>>>collision.
>>
>>
>>That doesn't sound like a good thing :) Is there a reason for
>>not av
Eric W. Biederman wrote:
> Patrick McHardy <[EMAIL PROTECTED]> writes:
>
>
>>I'm wondering why this receive queue processing on unlock is still
>>necessary today, we don't do trylock in rtnetlink_rcv anymore, so
>>all senders will simply wait until the lock is released and then
>>process the queu
Patrick McHardy wrote:
Corey Hickey wrote:
Patchset try 2 addresses the review by Michael Buesch.
Patchset try 3 addresses the review by Patrick McHardy.
Patchset try 4 has a few cosmetic improvements.
Nobody reviewed my last set of patches, and I wasn't pushy about asking.
Since it's been a wh
Herbert Xu <[EMAIL PROTECTED]> writes:
> Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>>
>> Currently we have the call path:
>> macvlan_open -> dev_unicast_add -> __dev_set_rx_mode ->
>>__dev_set_promiscuity -> ASSERT_RTNL -> mutex_trylock
>>
>> When mutex debugging is on taking a mutex
Patrick McHardy <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>> Because of the global nature of garbage collection, and because of the
>> cost of per namespace hash tables unix_socket_table has been kept
>> global. With a filter added on lookups so we don't see sockets from
>> the wrong
Patrick McHardy <[EMAIL PROTECTED]> writes:
> I'm wondering why this receive queue processing on unlock is still
> necessary today, we don't do trylock in rtnetlink_rcv anymore, so
> all senders will simply wait until the lock is released and then
> process the queue.
Good question, I should prob
Eric W. Biederman wrote:
> Because of the global nature of garbage collection, and because of the
> cost of per namespace hash tables unix_socket_table has been kept
> global. With a filter added on lookups so we don't see sockets from
> the wrong namespace.
>
> Currently I don't fold the namesap
Eric W. Biederman wrote:
> void rtnl_unlock(void)
> {
> - mutex_unlock(&rtnl_mutex);
> - if (rtnl && rtnl->sk_receive_queue.qlen)
> + struct net *net;
> +
> + /*
> + * Loop through all of the rtnl sockets until none of them (in
> + * a live network namespace) have queue
Corey Hickey wrote:
> Patchset try 2 addresses the review by Michael Buesch.
> Patchset try 3 addresses the review by Patrick McHardy.
> Patchset try 4 has a few cosmetic improvements.
>
> Nobody reviewed my last set of patches, and I wasn't pushy about asking.
> Since it's been a while, I ported
Herbert Xu wrote:
> Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>
>>Currently we have the call path:
>>macvlan_open -> dev_unicast_add -> __dev_set_rx_mode ->
>> __dev_set_promiscuity -> ASSERT_RTNL -> mutex_trylock
>>
>>When mutex debugging is on taking a mutex complains if we are not
>>al
Herbert Xu wrote:
> Herbert Xu <[EMAIL PROTECTED]> wrote:
>
>>On Fri, Sep 28, 2007 at 06:55:32PM +0200, Patrick McHardy wrote:
>>
>>>Looking at ip_input.o as example (everything without forced inlining):
>>>
>>> textdata bss dec hex filename
>>> 2076 8 02084
Ilpo Järvinen wrote:
> On Fri, 28 Sep 2007, Ilpo Järvinen wrote:
>> On Fri, 28 Sep 2007, Cedric Le Goater wrote:
>>
>>> I just found that warning in my logs. It seems that it's been
>>> happening since rc7-mm1 at least.
>>>
>>> WARNING: at /home/legoater/linux/2.6.23-rc8-mm2/net/ipv4/tcp_input.c:
On Fri, 28 Sep 2007, Ilpo Järvinen wrote:
> On Fri, 28 Sep 2007, Cedric Le Goater wrote:
>
> > I just found that warning in my logs. It seems that it's been
> > happening since rc7-mm1 at least.
> >
> > WARNING: at /home/legoater/linux/2.6.23-rc8-mm2/net/ipv4/tcp_input.c:2314
> > tcp_fastretran
From: Laurent Riffard <[EMAIL PROTECTED]>
Date: Sat, 29 Sep 2007 11:22:06 +0200
> Could a router problem prevent "ping 127.0.0.1" from working ?
Two things that are new and could cause these problems:
1) We dynamically allocate the loopback device now.
2) We have the network namespace stuff.
A
Le 29.09.2007 10:31, Andrew Morton a écrit :
> On Fri, 28 Sep 2007 21:48:18 +0200 Laurent Riffard <[EMAIL PROTECTED]> wrote:
>
>> Hi,
>>
>> >From time to time, I experience some complete network hangs:
>>
>> Suddenly, all network connections become unresponsive. Even "ping
>> 127.0.0.1" doesn't wo
On Fri, 28 Sep 2007 21:48:18 +0200 Laurent Riffard <[EMAIL PROTECTED]> wrote:
> Hi,
>
> >From time to time, I experience some complete network hangs:
>
> Suddenly, all network connections become unresponsive. Even "ping
> 127.0.0.1" doesn't work. SysRq-w does not show any blocked processus.
>
>
26 matches
Mail list logo
