* Re: TCP: orphans broken by RFC 2525 #2.17
From: David Miller @ 2010-09-26 23:08 UTC (permalink / raw)
To: w; +Cc: netdev
In-Reply-To: <20100926225440.GH12373@1wt.eu>
From: Willy Tarreau <w@1wt.eu>
Date: Mon, 27 Sep 2010 00:54:40 +0200
> On Sun, Sep 26, 2010 at 03:38:32PM -0700, David Miller wrote:
>> From: Willy Tarreau <w@1wt.eu>
>> Date: Mon, 27 Sep 2010 00:34:48 +0200
>>
>> > I don't see what is being violated nor what reliability has been
>> > compromised.
>>
>> The TCP protcol's obligation to reliably deliver data between
>> two applications, that is what has been violated.
>
> Once again, I don't see why, due to the orphans mechanism. Please
> consider for a minute that the application-level close() is distinct
> from the protocol-level close. The application-level close() just
> instructs the lower layer to turn the connection into an orphan.
A close() is equivalent to a shutdown() with both the send and
receive masks set.
You are telling TCP that you expect no more data to be received.
^ permalink raw reply
* Re: TCP: orphans broken by RFC 2525 #2.17
From: Willy Tarreau @ 2010-09-26 23:25 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20100926.160838.246540910.davem@davemloft.net>
On Sun, Sep 26, 2010 at 04:08:38PM -0700, David Miller wrote:
> From: Willy Tarreau <w@1wt.eu>
> Date: Mon, 27 Sep 2010 00:54:40 +0200
>
> > On Sun, Sep 26, 2010 at 03:38:32PM -0700, David Miller wrote:
> >> From: Willy Tarreau <w@1wt.eu>
> >> Date: Mon, 27 Sep 2010 00:34:48 +0200
> >>
> >> > I don't see what is being violated nor what reliability has been
> >> > compromised.
> >>
> >> The TCP protcol's obligation to reliably deliver data between
> >> two applications, that is what has been violated.
> >
> > Once again, I don't see why, due to the orphans mechanism. Please
> > consider for a minute that the application-level close() is distinct
> > from the protocol-level close. The application-level close() just
> > instructs the lower layer to turn the connection into an orphan.
>
> A close() is equivalent to a shutdown() with both the send and
> receive masks set.
>
> You are telling TCP that you expect no more data to be received.
Agreed. But that's not a reason for killing outgoing data that is
being sent when there are some data left in the rcv buffer.
Honnestly David, after some thinking, could you still find a valid use
of the orphans as they are now ? I personally fail to do so. And what
drove me to the kernel on this issue is that I found the behaviour
inconsistent with the principle of the orphan itself.
Willy
^ permalink raw reply
* RE: [RFC PATCH v9 12/16] Add mp(mediate passthru) device.
From: Xin, Xiaohui @ 2010-09-27 0:42 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: netdev@vger.kernel.org, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, mingo@elte.hu, davem@davemloft.net,
herbert@gondor.hengli.com.au, jdike@linux.intel.com
In-Reply-To: <20100926115018.GA19655@redhat.com>
>From: Michael S. Tsirkin [mailto:mst@redhat.com]
>Sent: Sunday, September 26, 2010 7:50 PM
>To: Xin, Xiaohui
>Cc: netdev@vger.kernel.org; kvm@vger.kernel.org; linux-kernel@vger.kernel.org;
>mingo@elte.hu; davem@davemloft.net; herbert@gondor.hengli.com.au;
>jdike@linux.intel.com
>Subject: Re: [RFC PATCH v9 12/16] Add mp(mediate passthru) device.
>
>On Thu, Sep 23, 2010 at 08:56:33PM +0800, Xin, Xiaohui wrote:
>> >-----Original Message-----
>> >From: Michael S. Tsirkin [mailto:mst@redhat.com]
>> >Sent: Wednesday, September 22, 2010 7:55 PM
>> >To: Xin, Xiaohui
>> >Cc: netdev@vger.kernel.org; kvm@vger.kernel.org; linux-kernel@vger.kernel.org;
>> >mingo@elte.hu; davem@davemloft.net; herbert@gondor.hengli.com.au;
>> >jdike@linux.intel.com
>> >Subject: Re: [RFC PATCH v9 12/16] Add mp(mediate passthru) device.
>> >
>> >On Wed, Sep 22, 2010 at 07:41:36PM +0800, Xin, Xiaohui wrote:
>> >> >-----Original Message-----
>> >> >From: Michael S. Tsirkin [mailto:mst@redhat.com]
>> >> >Sent: Tuesday, September 21, 2010 9:14 PM
>> >> >To: Xin, Xiaohui
>> >> >Cc: netdev@vger.kernel.org; kvm@vger.kernel.org; linux-kernel@vger.kernel.org;
>> >> >mingo@elte.hu; davem@davemloft.net; herbert@gondor.hengli.com.au;
>> >> >jdike@linux.intel.com
>> >> >Subject: Re: [RFC PATCH v9 12/16] Add mp(mediate passthru) device.
>> >> >
>> >> >On Tue, Sep 21, 2010 at 09:39:31AM +0800, Xin, Xiaohui wrote:
>> >> >> >From: Michael S. Tsirkin [mailto:mst@redhat.com]
>> >> >> >Sent: Monday, September 20, 2010 7:37 PM
>> >> >> >To: Xin, Xiaohui
>> >> >> >Cc: netdev@vger.kernel.org; kvm@vger.kernel.org; linux-kernel@vger.kernel.org;
>> >> >> >mingo@elte.hu; davem@davemloft.net; herbert@gondor.hengli.com.au;
>> >> >> >jdike@linux.intel.com
>> >> >> >Subject: Re: [RFC PATCH v9 12/16] Add mp(mediate passthru) device.
>> >> >> >
>> >> >> >On Mon, Sep 20, 2010 at 04:08:48PM +0800, xiaohui.xin@intel.com wrote:
>> >> >> >> From: Xin Xiaohui <xiaohui.xin@intel.com>
>> >> >> >>
>> >> >> >> ---
>> >> >> >> Michael,
>> >> >> >> I have move the ioctl to configure the locked memory to vhost
>> >> >> >
>> >> >> >It's ok to move this to vhost but vhost does not
>> >> >> >know how much memory is needed by the backend.
>> >> >>
>> >> >> I think the backend here you mean is mp device.
>> >> >> Actually, the memory needed is related to vq->num to run zero-copy
>> >> >> smoothly.
>> >> >> That means mp device did not know it but vhost did.
>> >> >
>> >> >Well, this might be so if you insist on locking
>> >> >all posted buffers immediately. However, let's assume I have a
>> >> >very large ring and prepost a ton of RX buffers:
>> >> >there's no need to lock all of them directly:
>> >> >
>> >> >if we have buffers A and B, we can lock A, pass it
>> >> >to hardware, and when A is consumed unlock A, lock B
>> >> >and pass it to hardware.
>> >> >
>> >> >
>> >> >It's not really critical. But note we can always have userspace
>> >> >tell MP device all it wants to know, after all.
>> >> >
>> >> Ok. Here are two values we have mentioned, one is how much memory
>> >> user application wants to lock, and one is how much memory locked
>> >> is needed to run smoothly. When net backend is setup, we first need
>> >> an ioctl to get how much memory is needed to lock, and then we call
>> >> another ioctl to set how much it want to lock. Is that what's in your mind?
>> >
>> >That's fine.
>> >
>> >> >> And the rlimt stuff is per process, we use current pointer to set
>> >> >> and check the rlimit, the operations should be in the same process.
>> >> >
>> >> >Well no, the ring is handled from the kernel thread: we switch the mm to
>> >> >point to the owner task so copy from/to user and friends work, but you
>> >> >can't access the rlimit etc.
>> >> >
>> >> Yes, the userspace and vhost kernel is not the same process. But we can
>> >> record the task pointer as mm.
>> >
>> >So you will have to store mm and do device->mm, not current->mm.
>> >Anyway, better not touch mm on data path.
>> >
>> >> >> Now the check operations are in vhost process, as mp_recvmsg() or
>> >> >> mp_sendmsg() are called by vhost.
>> >> >
>> >> >Hmm, what do you mean by the check operations?
>> >> >send/recv are data path operations, they shouldn't
>> >> >do any checks, should they?
>> >> >
>> >> As you mentioned what infiniband driver done:
>> >> down_write(¤t->mm->mmap_sem);
>> >>
>> >> locked = npages + current->mm->locked_vm;
>> >> lock_limit = rlimit(RLIMIT_MEMLOCK) >> PAGE_SHIFT;
>> >>
>> >> if ((locked > lock_limit) && !capable(CAP_IPC_LOCK)) {
>> >> ret = -ENOMEM;
>> >> goto out;
>> >> }
>> >>
>> >> cur_base = addr & PAGE_MASK;
>> >>
>> >> ret = 0;
>> >> while (npages) {
>> >> ret = get_user_pages(current, current->mm, cur_base,
>> >> min_t(unsigned long, npages,
>> >> PAGE_SIZE / sizeof (struct page
>*)),
>> >> 1, !umem->writable, page_list,
>vma_list);
>> >>
>> >> I think it's a data path too.
>> >
>> >in infiniband this is used to 'register memory' which is not data path.
>> >
>> >> We do the check because get_user_pages() really pin and locked
>> >> the memory.
>> >
>> >Don't do this. Performance will be bad.
>> >Do the check once in ioctl and increment locked_vm by max amount you will use.
>> >On data path just make sure you do not exceed what userspace told you
>> >to.
>>
>> What's in my mind is that in the ioctl which to get the memory locked needed to run
>smoothly,
>> it just return a value of how much memory is needed by mp device.
>> And then in the ioctl which to set the memory locked by user space, it check the rlimit and
>> increment locked_vm by user want.
>
>Fine.
>
>> But I'm not sure how to "make sure do not exceed what
>> userspace told to". If we don't check locked_vm, what do we use to check? And Is it
>another kind of check on data path?
>
>An example: on ioctl we have incremented locked_vm by say 128K.
>We will record this number 128K in mp data structure and on data path
>verify that amount of memory we actually lock with get_user_pages_fast
>does not exceed 128K. This is not part of mm and so can use
>any locking scheme, no need to take mm semaphore.
>
>
Thanks, and later, I did do that in v11 patches.
>
>> >
>> >>
>> >> >> So set operations should be in
>> >> >> vhost process too, it's natural.
>> >> >>
>> >> >> >So I think we'll need another ioctl in the backend
>> >> >> >to tell userspace how much memory is needed?
>> >> >> >
>> >> >> Except vhost tells it to mp device, mp did not know
>> >> >> how much memory is needed to run zero-copy smoothly.
>> >> >> Is userspace interested about the memory mp is needed?
>> >> >
>> >> >Couldn't parse this last question.
>> >> >I think userspace generally does want control over
>> >> >how much memory we'll lock. We should not just lock
>> >> >as much as we can.
>> >> >
>> >> >--
>> >> >MST
^ permalink raw reply
* RE: [PATCH v11 00/17] Provide a zero-copy method on KVM virtio-net.
From: Xin, Xiaohui @ 2010-09-27 0:44 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: netdev@vger.kernel.org, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, mingo@elte.hu, davem@davemloft.net,
herbert@gondor.hengli.com.au, jdike@linux.intel.com
In-Reply-To: <20100926170142.GA24196@redhat.com>
>From: Michael S. Tsirkin [mailto:mst@redhat.com]
>Sent: Monday, September 27, 2010 1:02 AM
>To: Xin, Xiaohui
>Cc: netdev@vger.kernel.org; kvm@vger.kernel.org; linux-kernel@vger.kernel.org;
>mingo@elte.hu; davem@davemloft.net; herbert@gondor.hengli.com.au;
>jdike@linux.intel.com
>Subject: Re: [PATCH v11 00/17] Provide a zero-copy method on KVM virtio-net.
>
>On Sat, Sep 25, 2010 at 12:27:18PM +0800, xiaohui.xin@intel.com wrote:
>> We provide an zero-copy method which driver side may get external
>> buffers to DMA. Here external means driver don't use kernel space
>> to allocate skb buffers. Currently the external buffer can be from
>> guest virtio-net driver.
>>
>> The idea is simple, just to pin the guest VM user space and then
>> let host NIC driver has the chance to directly DMA to it.
>> The patches are based on vhost-net backend driver. We add a device
>> which provides proto_ops as sendmsg/recvmsg to vhost-net to
>> send/recv directly to/from the NIC driver. KVM guest who use the
>> vhost-net backend may bind any ethX interface in the host side to
>> get copyless data transfer thru guest virtio-net frontend.
>> patch 01-10: net core and kernel changes.
>> patch 11-13: new device as interface to mantpulate external buffers.
>> patch 14: for vhost-net.
>> patch 15: An example on modifying NIC driver to using napi_gro_frags().
>> patch 16: An example how to get guest buffers based on driver
>> who using napi_gro_frags().
>> patch 17: It's a patch to address comments from Michael S. Thirkin
>> to add 2 new ioctls in mp device.
>> We split it out here to make easier reiewer.
>
>
>
>I commented on how to avoid mm semaphore on data path separately, and
>since you didn't have time to review that yet, I won't repeat that here.
>
I think I did avoid that in data path to use mm semaphore. I stored the value
in mp structures and check with that.
>At this point what are the plans on macvtap integration?
>You indicated this is the interface you intend to use longterm.
I'm now working on that.
Thanks
Xiaohui
^ permalink raw reply
* Re: TCP: orphans broken by RFC 2525 #2.17
From: David Miller @ 2010-09-27 1:12 UTC (permalink / raw)
To: w; +Cc: netdev
In-Reply-To: <20100926232530.GK12373@1wt.eu>
From: Willy Tarreau <w@1wt.eu>
Date: Mon, 27 Sep 2010 01:25:30 +0200
> Agreed. But that's not a reason for killing outgoing data that is
> being sent when there are some data left in the rcv buffer.
What alternative notification to the peer do you suggest other than a
reset, then? TCP gives us no other.
That's the thing, data integrity is full duplex, thus once it has been
compromised in one direction everything currently in flight must be
zapped.
^ permalink raw reply
* Re: [PATCH v3] net: af_packet: don't call tpacket_destruct_skb() until the skb is sent out
From: David Miller @ 2010-09-27 1:22 UTC (permalink / raw)
To: jarkao2; +Cc: xiaosuo, eric.dumazet, socketcan, mst, netdev
In-Reply-To: <20100924063623.GA6359@ff.dom.local>
From: Jarek Poplawski <jarkao2@gmail.com>
Date: Fri, 24 Sep 2010 06:36:23 +0000
> af_packet could check some flag which guarantees the queued dev can do
> skb_orphan after the real xmit and copy buffers otherwise.
Jarek, we pre-orphan SKBs in the core way before device even gets
the packet.
So talking about device-specific situations where this could behave
differently has no sense.
^ permalink raw reply
* Re: [PATCH v3] net: af_packet: don't call tpacket_destruct_skb() until the skb is sent out
From: Changli Gao @ 2010-09-27 1:24 UTC (permalink / raw)
To: Jarek Poplawski, xiaohui.xin
Cc: David S. Miller, Eric Dumazet, Oliver Hartkopp,
Michael S. Tsirkin, netdev
In-Reply-To: <20100924063623.GA6359@ff.dom.local>
On Fri, Sep 24, 2010 at 2:36 PM, Jarek Poplawski <jarkao2@gmail.com> wrote:
> On 2010-09-23 12:15, Changli Gao wrote:
>> Since skb->destructor() is used to account socket memory, and maybe called
>> before the skb is sent out, a corrupt skb maybe sent out finally.
>>
>> A new destructor is added into structure skb_shared_info(), and it won't
>> be called until the last reference to the data of an skb is put. af_packet
>> uses this destructor instead.
>
> IMHO, we shouldn't allow for fixing the bad design of one protocol at
> the expense of others by adding more and more conditionals. The proper
> way of handling paged skbs (splice compatible) exists. And the current
> patch doesn't even fix the problem completely against things like
> pskb_expand_head or pskb_copy.
pskb_expand_head is handled in my patch, but not pskb_copy().
indeed, there are many issues to fix, and xiaohui's patch may have the
same issues. The proper way may put the destruct handler in pages
instead.
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: [PATCH v3] net: af_packet: don't call tpacket_destruct_skb() until the skb is sent out
From: David Miller @ 2010-09-27 1:25 UTC (permalink / raw)
To: eric.dumazet; +Cc: jarkao2, xiaosuo, socketcan, mst, netdev
In-Reply-To: <1285311660.2380.62.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 24 Sep 2010 09:01:00 +0200
> af_packet (tx with mmap) is broken. I wonder who really uses it ?
I suspect now that af_packet supports VNET headers on transmit,
there are some things using this tx+mmap thing for sure.
> To properly cope with paged skbs, it should not try to fit several
> packets per page.
>
> The mmap api should change so that one mmaped page belongs to at most
> one skb, or else we need invasive changes in net/core
>
> This probably makes this stuff less interesting, unless the need is to
> send big packets. In this case, why splice was not used instead of
> custom mmap ?
I don't really see what the big issue is.
When the data destructor runs it means that packet's part of the pages
are available for reuse for the tx mmap client. And if I read it
correctly, that's exactly what tpacket_destruct_skb() is in fact doing.
There seems to be no conflict with that rule and reusing a page for
multiple packets.
^ permalink raw reply
* Re: [PATCH net-next-2.6] net: propagate NETIF_F_HIGHDMA to vlans
From: David Miller @ 2010-09-27 1:27 UTC (permalink / raw)
To: eric.dumazet; +Cc: jeffrey.t.kirsher, netdev, gospo, bphilips, yi.zou
In-Reply-To: <1285238771.2864.38.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 23 Sep 2010 12:46:11 +0200
> Automatically allows vlans to get NETIF_F_HIGHDMA if underlying device
> supports it.
>
> On 32bit arches (and more precisely if CONFIG_HIGHMEM is enabled), it
> can help to reduce cost of illegal_highdma() and __skb_linearize()
> calls.
>
> Tested on tg3 , bnx2, bonding, this worked very well.
>
> This is a generalization of a patch provided by Yi Zou & Jeff Kirsher.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH] br2684: fix scheduling while atomic
From: David Miller @ 2010-09-27 1:29 UTC (permalink / raw)
To: mmvinni; +Cc: karl, netdev, chas
In-Reply-To: <538742.564.qm@web58407.mail.re3.yahoo.com>
From: Mikko Vinni <mmvinni@yahoo.com>
Date: Thu, 23 Sep 2010 09:51:24 -0700 (PDT)
> From: Karl Hiramoto <karl@hiramoto.org>
>> Subject: [PATCH] br2684: fix scheduling while atomic
>>
>> You can't call atomic_notifier_chain_unregister() while in atomic context.
>>
>> Fix, call un/register_atmdevice_notifier in module __init and __exit.
>>
>> Bug report:
>> http://comments.gmane.org/gmane.linux.network/172603
>>
>> Signed-off-by: Karl Hiramoto <karl@hiramoto.org>
>
> Feel free to add
>
> Reported-and-tested-by: Mikko Vinni <mmvinni@yahoo.com>
Applied, thanks guys.
^ permalink raw reply
* Re: ESP trailer_len calculation
From: David Miller @ 2010-09-27 1:46 UTC (permalink / raw)
To: herbert; +Cc: kaber, eric.dumazet, netdev
In-Reply-To: <20100925062317.GA15565@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Sat, 25 Sep 2010 14:23:17 +0800
> The number 17 does look very strange, however, after going through
> the logic it does seem correct.
>
> To calculate the minimum safe trailer length we need to consider
> the worst-case scenario, and that is a packet where the payload
> just happens to be one byte less than the cipher block size.
>
> ESP always adds two bytes, then pads to at least the cipher
> block size, follwed by the authentication value. So in the
> worst case we need to add
>
> 2 + (blocksize - 1) + authlen =
> blocksize + 1 + authlen
>
> which is exactly what Patrick's patch does.
Thanks for explaining this Herbert, but I have to admit it's a bit
disappointing :-)
So what we have is that headerlen is actually a function f() which
depends upon the payload length and the size of any IP options, rather
than a fixed value that can be computed based upon the cipher
blocksize, encap mode, and device MTU.
I guess if we really cared about this we could make headerlen a method
rather than a value, but I doubt it's that much of an issue.
^ permalink raw reply
* Re: [PATCH] net: reset skb queue mapping when rx'ing over tunnel
From: David Miller @ 2010-09-27 1:48 UTC (permalink / raw)
To: eric.dumazet; +Cc: therbert, netdev, chavey
In-Reply-To: <1285397350.2478.102.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 25 Sep 2010 08:49:10 +0200
> Le vendredi 24 septembre 2010 à 09:18 -0700, Tom Herbert a écrit :
>> > Hmm...
>> >
>> > This would need to be reverted later when tunnels are updated to be
>> > multiqueue aware ? I made an attempt with GRE some days ago.
>> >
>> > I dont understand why this patch is needed, since get_rps_cpu() has a
>> > check anyway
>> >
>> I think the skb queue_mapping should correspond to a queue in the
>> skb's device as an invariant. In the case that an skb's device is
>> change from a multiqueue device to single queue device (like GRE), the
>> inconsistency in the queue_mapping is fairly innocuous, we get one
>> warning but will pretty much take the unlikely branch for GRE packets
>> then on. But imagine a case where skb's device was change from one
>> multiqueue device to another, but the queue mapping was not also
>> updated. This would cause poor weighting in get_rps_cpus. For
>> example, if the new device had fewer queues than the old one,
>> get_rps_cpu will bias toward using queue 0's rps mask.
>
> I believe your patch is fine. Thanks
>
> Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH] smsc911x: Add MODULE_ALIAS()
From: David Miller @ 2010-09-27 1:50 UTC (permalink / raw)
To: vincent.stehle; +Cc: netdev
In-Reply-To: <4C9BCFC5.9090808@bergerie>
From: Vincent <vincent.stehle@laposte.net>
Date: Fri, 24 Sep 2010 00:08:05 +0200
> The smsc911x ethernet driver is lacking a module alias. This does
> prevent auto-loading of the driver.
>
> The attached patch fixes this. Please apply.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next-2.6] net: update SOCK_MIN_RCVBUF
From: David Miller @ 2010-09-27 1:53 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1285345177.2503.346.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 24 Sep 2010 18:19:37 +0200
> SOCK_MIN_RCVBUF current value is 256 bytes
>
> It doesnt permit to receive the smallest possible frame, considering
> socket sk_rmem_alloc/sk_rcvbuf account skb truesizes. On 64bit arches,
> sizeof(struct sk_buff) is 240 bytes. Add the typical 64 bytes of
> headroom, and we go over the limit.
>
> With old kernels and 32bit arches, we were under the limit, if netdriver
> was doing copybreak.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Fair enough, applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH 1/9] ibm_newemac: use free_netdev(netdev) instead of kfree()
From: David Miller @ 2010-09-27 1:54 UTC (permalink / raw)
To: segooon-Re5JQEeQqe8AvxtiuMwx3w
Cc: jpirko-H+wXaHxf7aLQT0dZR+AlfA, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
kernel-janitors-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1285495080-21857-1-git-send-email-segooon-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Vasiliy Kulikov <segooon-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Sun, 26 Sep 2010 13:58:00 +0400
> Freeing netdev without free_netdev() leads to net, tx leaks.
> I might lead to dereferencing freed pointer.
>
> The semantic match that finds this problem is as follows:
> (http://coccinelle.lip6.fr/)
>
> @@
> struct net_device* dev;
> @@
>
> -kfree(dev)
> +free_netdev(dev)
Applied.
^ permalink raw reply
* Re: [PATCH 2/9] rionet: use free_netdev(netdev) instead of kfree()
From: David Miller @ 2010-09-27 1:55 UTC (permalink / raw)
To: segooon; +Cc: kernel-janitors, tj, netdev, linux-kernel
In-Reply-To: <1285495083-21899-1-git-send-email-segooon@gmail.com>
From: Vasiliy Kulikov <segooon@gmail.com>
Date: Sun, 26 Sep 2010 13:58:03 +0400
> Freeing netdev without free_netdev() leads to net, tx leaks.
> I might lead to dereferencing freed pointer.
>
> The semantic match that finds this problem is as follows:
> (http://coccinelle.lip6.fr/)
>
> @@
> struct net_device* dev;
> @@
>
> -kfree(dev)
> +free_netdev(dev)
Applied.
^ permalink raw reply
* Re: [PATCH 3/9] sgiseeq: use free_netdev(netdev) instead of kfree()
From: David Miller @ 2010-09-27 1:55 UTC (permalink / raw)
To: segooon
Cc: kernel-janitors, eric.dumazet, u.kleine-koenig, julia, tj, netdev,
linux-kernel
In-Reply-To: <1285495086-21956-1-git-send-email-segooon@gmail.com>
From: Vasiliy Kulikov <segooon@gmail.com>
Date: Sun, 26 Sep 2010 13:58:06 +0400
> Freeing netdev without free_netdev() leads to net, tx leaks.
> I might lead to dereferencing freed pointer.
>
> The semantic match that finds this problem is as follows:
> (http://coccinelle.lip6.fr/)
>
> @@
> struct net_device* dev;
> @@
>
> -kfree(dev)
> +free_netdev(dev)
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6] rps: allocate rx queues in register_netdevice only
From: David Miller @ 2010-09-27 2:05 UTC (permalink / raw)
To: eric.dumazet; +Cc: bhutchings, netdev, linux-net-drivers, therbert
In-Reply-To: <1285298795.2380.54.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 24 Sep 2010 05:26:35 +0200
> [PATCH net-next-2.6] rps: allocate rx queues in register_netdevice()
>
> Instead of having two places were we allocate dev->_rx, introduce
> netif_alloc_rx_queues() helper and call it only from
> register_netdevice(), not from alloc_netdev_mq()
>
> Goal is to let drivers change dev->num_rx_queues after allocating netdev
> and before registering it.
>
> This also removes a lot of ifdefs in net/core/dev.c
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks Eric.
Please cook up a patch that adds a check to make sure that
alloc_netdev_mq() is never called with number of queues < 1
Thanks again!
^ permalink raw reply
* Re: [PATCH net-next-2.6] net: fix rcu use in ip_route_output_slow
From: David Miller @ 2010-09-27 2:05 UTC (permalink / raw)
To: eric.dumazet; +Cc: paulmck, akpm, netdev
In-Reply-To: <1285314363.2503.12.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 24 Sep 2010 09:46:03 +0200
> [PATCH net-next-2.6] net: fix rcu use in ip_route_output_slow
>
> __in_dev_get_rtnl(dev_out) is called while RTNL is not held, thus
> triggers a lockdep fault.
>
> At this point, we only perform a raw test of dev_out->ip_ptr being NULL,
> we dont need to make sure ip_ptr cant changed right after.
>
> We can use rcu_dereference_raw() for this.
>
> Reported-by: Andrew Morton <akpm@linux-foundation.org>
> Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks everyone!
^ permalink raw reply
* Re: [PATCH net-next-2.6] net: loopback driver cleanup
From: David Miller @ 2010-09-27 2:05 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1285321911.2503.48.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 24 Sep 2010 11:51:51 +0200
> loopback driver uses dev->ml_priv to store its percpu stats pointer.
> It uses ugly casts "(void __percpu __force *)" to shut up sparse
> complains.
>
> Define an union to better document we use ml_priv in loopback driver and
> define a lstats field with appropriate types.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH] ipv6: add a missing unregister_pernet_subsys call
From: David Miller @ 2010-09-27 2:10 UTC (permalink / raw)
To: nhorman; +Cc: netdev, kuznet, pekkas, jmorris, yoshfuji, kaber
In-Reply-To: <20100924195552.GA8477@hmsreliant.think-freely.org>
From: Neil Horman <nhorman@tuxdriver.com>
Date: Fri, 24 Sep 2010 15:55:52 -0400
> Clean up a missing exit path in the ipv6 module init routines. In
> addrconf_init we call ipv6_addr_label_init which calls register_pernet_subsys
> for the ipv6_addr_label_ops structure. But if module loading fails, or if the
> ipv6 module is removed, there is no corresponding unregister_pernet_subsys call,
> which leaves a now-bogus address on the pernet_list, leading to oopses in
> subsequent registrations. This patch cleans up both the failed load path and
> the unload path. Tested by myself with good results.
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Applied.
Thanks a lot Neil.
^ permalink raw reply
* Re: [PATCH] mm: do not print backtraces on GFP_ATOMIC failures
From: KOSAKI Motohiro @ 2010-09-27 2:17 UTC (permalink / raw)
To: Eric Dumazet
Cc: kosaki.motohiro, Andrew Morton, Rik van Riel, linux-mm,
linux-kernel, netdev
In-Reply-To: <1285088427.2617.723.camel@edumazet-laptop>
> > > @@ -72,7 +72,7 @@ struct vm_area_struct;
> > > /* This equals 0, but use constants in case they ever change */
> > > #define GFP_NOWAIT (GFP_ATOMIC & ~__GFP_HIGH)
> > > /* GFP_ATOMIC means both !wait (__GFP_WAIT not set) and use emergency pool */
> > > -#define GFP_ATOMIC (__GFP_HIGH)
> > > +#define GFP_ATOMIC (__GFP_HIGH | __GFP_NOWARN)
> > > #define GFP_NOIO (__GFP_WAIT)
> > > #define GFP_NOFS (__GFP_WAIT | __GFP_IO)
> > > #define GFP_KERNEL (__GFP_WAIT | __GFP_IO | __GFP_FS)
> >
> > A much finer-tuned implementation would be to add __GFP_NOWARN just to
> > the networking call sites. I asked about this in June and it got
> > nixed:
> >
> > http://www.spinics.net/lists/netdev/msg131965.html
> > --
>
> Yes, I remember this particular report was useful to find and correct a
> bug.
>
> I dont know what to say.
>
> Being silent or verbose, it really depends on the context ?
At least, MM developers don't want to track network allocation failure
issue. We don't have enough knowledge in this area. To be honest, We
are unhappy current bad S/N bug report rate ;)
Traditionally, We hoped this warnings help to debug VM issue. but
It haven't happen. We haven't detect VM issue from this allocation
failure report. Instead, We've received a lot of network allocation
failure report.
Recently, The S/N ratio became more bad. If the network device enable
jumbo frame feature, order-2 GFP_ATOMIC allocation is called frequently.
Anybody don't have to assume order-2 allocation can success anytime.
I'm not against accurate warning at all. but I cant tolerate this
semi-random warning steal our time. If anyone will not make accurate
warning, I hope to remove this one completely instead.
^ permalink raw reply
* [PATCH 4/4] net: r6040: store BIOS default MAC in perm_add
From: Otavio Salvador @ 2010-09-27 2:49 UTC (permalink / raw)
To: netdev; +Cc: Otavio Salvador
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---
drivers/net/r6040.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/net/r6040.c b/drivers/net/r6040.c
index 142c381..5780d08 100644
--- a/drivers/net/r6040.c
+++ b/drivers/net/r6040.c
@@ -740,6 +740,9 @@ static void r6040_mac_address(struct net_device *dev)
iowrite16(adrp[0], ioaddr + MID_0L);
iowrite16(adrp[1], ioaddr + MID_0M);
iowrite16(adrp[2], ioaddr + MID_0H);
+
+ /* Store MAC Address in perm_addr */
+ memcpy(dev->perm_addr, dev->dev_addr, ETH_ALEN);
}
static int r6040_open(struct net_device *dev)
--
1.7.2.3.313.gcd15
^ permalink raw reply related
* Re: [PATCH 4/4] net: r6040: store BIOS default MAC in perm_add
From: David Miller @ 2010-09-27 2:58 UTC (permalink / raw)
To: otavio; +Cc: netdev
In-Reply-To: <1285555779-5885-1-git-send-email-otavio@ossystems.com.br>
From: Otavio Salvador <otavio@ossystems.com.br>
Date: Sun, 26 Sep 2010 23:49:39 -0300
> Cc: David S. Miller <davem@davemloft.net>
> Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Applied.
^ permalink raw reply
* linux-next: manual merge of the net tree with the omap tree
From: Stephen Rothwell @ 2010-09-27 4:29 UTC (permalink / raw)
To: David Miller, netdev
Cc: linux-next, linux-kernel, Sukumar Ghorai, Tony Lindgren,
linux-omap, Ohad Ben-Cohen, John W. Linville
Hi all,
Today's linux-next merge of the net tree got a conflict in
arch/arm/mach-omap2/board-zoom-peripherals.c between commit
6db649c505ddc6665176807c16745b9e01cf5031 ("omap: mmc: extended to pass
host capabilities from board file") from the omap tree and commits
b642fde7f137566c993991fd2e7bf6b8274bf625 ("omap: zoom: add fixed
regulator device for wlan") and 80b517f362605f2b6a6cfe086604534290aab2de
("omap: zoom: add mmc3/wl1271 device support") from the net tree.
Just overlapping additions. I fixed it up (see below) and can carry the
fix as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc arch/arm/mach-omap2/board-zoom-peripherals.c
index e5eac46,6aa0728..0000000
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@@ -16,7 -16,8 +16,9 @@@
#include <linux/gpio.h>
#include <linux/i2c/twl.h>
#include <linux/regulator/machine.h>
+#include <linux/mmc/host.h>
+ #include <linux/regulator/fixed.h>
+ #include <linux/wl12xx.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox