* Re: [PATCH] sfc: Fix efx_rx_buf_offset() for recycled pages
From: Luis Henriques @ 2013-09-30 16:48 UTC (permalink / raw)
To: Ben Hutchings; +Cc: David Miller, stable, netdev
In-Reply-To: <1379607231.1514.13.camel@bwh-desktop.uk.level5networks.com>
Ben Hutchings <bhutchings@solarflare.com> writes:
> [Re-sending with cc to the current stable address. I still had the old
> address in contacts, though I've definitely sent to the current address
> previously...]
>
> This bug fix is only for stable branches older than 3.10. The bug was
> fixed upstream by commit 2768935a4660 ('sfc: reuse pages to avoid DMA
> mapping/unmapping costs'), but that change is totally unsuitable for
> stable.
>
> Commit b590ace09d51 ('sfc: Fix efx_rx_buf_offset() in the presence of
> swiotlb') added an explicit page_offset member to struct
> efx_rx_buffer, which must be set consistently with the u.page and
> dma_addr fields. However, it failed to add the necessary assignment
> in efx_resurrect_rx_buffer(). It also did not correct the calculation
> of efx_rx_buffer::dma_addr in efx_resurrect_rx_buffer(), which assumes
> that DMA-mapping a page will result in a page-aligned DMA address
> (exactly what swiotlb violates).
>
> Add the assignment of efx_rx_buffer::page_offset and change the
> calculation of dma_addr to make use of it.
>
> I'm attaching the patches for 3.0.y, 3.2.y and 3.4.y (the last of which
> should also be applicable to the later unofficial stable branches).
>
> Ben.
Thanks Ben. I'm queuing it for the 3.5 kernel.
Cheers,
--
Luis
^ permalink raw reply
* Re: [PATCH] ipv6: udp packets following an UFO enqueued packet need also be handled by UFO
From: Hannes Frederic Sowa @ 2013-09-30 17:23 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, yoshfuji, davem
In-Reply-To: <20130930114343.GA6356@minipsycho.brq.redhat.com>
On Mon, Sep 30, 2013 at 01:43:43PM +0200, Jiri Pirko wrote:
> Sat, Sep 21, 2013 at 06:27:00AM CEST, hannes@stressinduktion.org wrote:
> >In the following scenario the socket is corked:
> >If the first UDP packet is larger then the mtu we try to append it to the
> >write queue via ip6_ufo_append_data. A following packet, which is smaller
> >than the mtu would be appended to the already queued up gso-skb via
> >plain ip6_append_data. This causes random memory corruptions.
> >
> >In ip6_ufo_append_data we also have to be careful to not queue up the
> >same skb multiple times. So setup the gso frame only when no first skb
> >is available.
> >
> >This also fixes a shortcoming where we add the current packet's length to
> >cork->length but return early because of a packet > mtu with dontfrag set
> >(instead of sutracting it again).
> >
> >Found with trinity.
> >
> >Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
> >Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
> >---
> >
> >I could only test this with virtualized UFO enabled network cards. Could
> >someone test this on real hardware?
> >
> > net/ipv6/ip6_output.c | 53 +++++++++++++++++++++------------------------------
> > 1 file changed, 22 insertions(+), 31 deletions(-)
> >
> >diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
> >index 3a692d5..a54c45c 100644
> >--- a/net/ipv6/ip6_output.c
> >+++ b/net/ipv6/ip6_output.c
> >@@ -1015,6 +1015,8 @@ static inline int ip6_ufo_append_data(struct sock *sk,
> > * udp datagram
> > */
> > if ((skb = skb_peek_tail(&sk->sk_write_queue)) == NULL) {
> >+ struct frag_hdr fhdr;
> >+
> > skb = sock_alloc_send_skb(sk,
> > hh_len + fragheaderlen + transhdrlen + 20,
> > (flags & MSG_DONTWAIT), &err);
> >@@ -1036,12 +1038,6 @@ static inline int ip6_ufo_append_data(struct sock *sk,
> > skb->protocol = htons(ETH_P_IPV6);
> > skb->ip_summed = CHECKSUM_PARTIAL;
> > skb->csum = 0;
> >- }
> >-
> >- err = skb_append_datato_frags(sk,skb, getfrag, from,
> >- (length - transhdrlen));
> >- if (!err) {
> >- struct frag_hdr fhdr;
> >
> > /* Specify the length of each IPv6 datagram fragment.
> > * It has to be a multiple of 8.
> >@@ -1052,15 +1048,10 @@ static inline int ip6_ufo_append_data(struct sock *sk,
> > ipv6_select_ident(&fhdr, rt);
> > skb_shinfo(skb)->ip6_frag_id = fhdr.identification;
> > __skb_queue_tail(&sk->sk_write_queue, skb);
> >-
> >- return 0;
> > }
> >- /* There is not enough support do UPD LSO,
> >- * so follow normal path
> >- */
> >- kfree_skb(skb);
> >
> >- return err;
> >+ return skb_append_datato_frags(sk, skb, getfrag, from,
> >+ (length - transhdrlen));
> > }
> >
>
> What if non-ufo-path-created skb is peeked?
You mean like:
first append a frame < mtu
second frame > mtu so it gets handles by ip6_ufo_append?
Currently I don't see a problem with it but I may be wrong. What is
your suspicion?
Greetings,
Hannes
^ permalink raw reply
* Re: [patch net] udp6: respect IPV6_DONTFRAG sockopt in case there are pending frames
From: Hannes Frederic Sowa @ 2013-09-30 17:56 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, davem, kuznet, jmorris, kaber, yoshfuji
In-Reply-To: <1380549038-6291-1-git-send-email-jiri@resnulli.us>
On Mon, Sep 30, 2013 at 03:50:38PM +0200, Jiri Pirko wrote:
> if up->pending != 0 dontfrag is left with default value -1. That
> causes that application that do:
> sendto len>mtu flag MSG_MORE
> sendto len>mtu flag 0
> will receive EMSGSIZE errno as the result of the second sendto.
>
> This patch fixes it by respecting IPV6_DONTFRAG socket option.
>
> introduced by:
> commit 4b340ae20d0e2366792abe70f46629e576adaf5e "IPv6: Complete IPV6_DONTFRAG support"
>
> Please push to stable as well.
>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
> ---
> net/ipv6/udp.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
> index 72b7eaa..1878609 100644
> --- a/net/ipv6/udp.c
> +++ b/net/ipv6/udp.c
> @@ -1225,9 +1225,6 @@ do_udp_sendmsg:
> if (tclass < 0)
> tclass = np->tclass;
>
> - if (dontfrag < 0)
> - dontfrag = np->dontfrag;
> -
> if (msg->msg_flags&MSG_CONFIRM)
> goto do_confirm;
> back_from_confirm:
> @@ -1246,6 +1243,8 @@ back_from_confirm:
> up->pending = AF_INET6;
>
> do_append_data:
> + if (dontfrag < 0)
> + dontfrag = np->dontfrag;
> up->len += ulen;
> getfrag = is_udplite ? udplite_getfrag : ip_generic_getfrag;
> err = ip6_append_data(sk, getfrag, msg->msg_iov, ulen,
Hmm, I wonder if we need the same change in ipv6/raw.c.
Looks good at first sight, but I need to do some more tests.
^ permalink raw reply
* Re: [ipv4:PATCH] Allow userspace to specify primary or secondary ip on interface
From: Vincent Li @ 2013-09-30 18:04 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org, linux-kernel
In-Reply-To: <20130929.175936.607666065014569193.davem@davemloft.net>
Yes, I found I can use 'ip route replace' command to change the 'src'
address as workaround. Julian also responded in another thread that He
could come up with a patch to sort ip with scope, primary, secondary
preferences.
https://lkml.org/lkml/2013/9/27/482
Vincent
On Sun, Sep 29, 2013 at 2:59 PM, David Miller <davem@davemloft.net> wrote:
> From: Vincent Li <vincent.mc.li@gmail.com>
> Date: Tue, 24 Sep 2013 14:09:48 -0700
>
>> the reason for this patch is that we have a multi blade cluster platform
>> sharing 'floating management ip' and also that each blade has its own
>> management ip on the management interface, so whichever blade in the
>> cluster becomes primary blade, the 'floating mangaement ip' follows it,
>> and we want any of our traffic originated from the primary blade source from
>> the 'floating management ip' for consistency. but in this case, since the local
>> blade management ip is always the primary ip on the mangaement interface and
>> 'floating management ip' is always secondary, kernel always choose the primary
>> ip as source ip address. thus we would like to add the flexibility in kernel to
>> allow us to specify which ip to be primary or secondary.
>
> You have the flexibility already.
>
> You can specify a specific source address ot use in routes.
^ permalink raw reply
* RE: [PATCH 1/1] linux-firmware: Add Brocade FC/FCOE Adapter firmware files
From: Rasesh Mody @ 2013-09-30 18:07 UTC (permalink / raw)
To: Ben Hutchings; +Cc: dwmw2@infradead.org, netdev, linux-scsi
In-Reply-To: <1380513458.1441.20.camel@deadeye.wl.decadent.org.uk>
>From: Ben Hutchings [mailto:ben@decadent.org.uk]
>Sent: Sunday, September 29, 2013 8:58 PM
>
>On Tue, 2013-09-10 at 16:10 -0700, Rasesh Mody wrote:
>> This patch adds firmware files for Brocade HBA and CNA drivers(BFA and
>BNA).
>>
>> Signed-off-by: Rasesh Mody <rmody@brocade.com>
>> ---
>> WHENCE | 27 +++++++++++++++++++++++++++
>> cbfw-3.2.1.1.bin | Bin 0 -> 412528 bytes ct2fw-3.2.1.1.bin | Bin 0
>> -> 582440 bytes ctfw-3.2.1.1.bin | Bin 0 -> 537160 bytes
>> 4 files changed, 27 insertions(+)
>> create mode 100644 cbfw-3.2.1.1.bin
>> create mode 100644 ct2fw-3.2.1.1.bin
>> create mode 100644 ctfw-3.2.1.1.bin
>[...]
>
>Applied, thanks. Sorry for the delay.
Thank you.
--Rasesh
^ permalink raw reply
* Re: [PATCH net v3] vxlan: Use RCU apis to access sk_user_data.
From: David Miller @ 2013-09-30 18:23 UTC (permalink / raw)
To: pshelar; +Cc: netdev, eric.dumazet, stephen, jesse
In-Reply-To: <1380043540-10417-1-git-send-email-pshelar@nicira.com>
From: Pravin B Shelar <pshelar@nicira.com>
Date: Tue, 24 Sep 2013 10:25:40 -0700
> Use of RCU api makes vxlan code easier to understand. It also
> fixes bug due to missing ACCESS_ONCE() on sk_user_data dereference.
> In rare case without ACCESS_ONCE() compiler might omit vs on
> sk_user_data dereference.
> Compiler can use vs as alias for sk->sk_user_data, resulting in
> multiple sk_user_data dereference in rcu read context which
> could change.
>
> CC: Jesse Gross <jesse@nicira.com>
> Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
Applied, thanks Pravin.
^ permalink raw reply
* Re: [PATCH net 1/2] ip_tunnel: Fix a memory corruption in ip_tunnel_xmit
From: David Miller @ 2013-09-30 18:40 UTC (permalink / raw)
To: pshelar; +Cc: steffen.klassert, netdev
In-Reply-To: <CALnjE+pkaAwiSp_S=TE70L+QvyZr1TzEC48Dnz9+8Hy3fbnOyQ@mail.gmail.com>
From: Pravin Shelar <pshelar@nicira.com>
Date: Fri, 27 Sep 2013 19:34:59 -0700
> All callers of iptunnel_xmit() are required to setup sufficient
> headroom. So skb_push check are not necessary.
This bug shows that such a check is needed, and would have saved
people like Steffen lots of time tracking down the problem.
I think we should re-instate the check.
I also think that __skb_push() is quite dangerous, in general. And if
it is to be used at all, it should only be used in circumstances where
all of the context necessary to assert that it cannot underflow the
buffer are right there in the same function.
In fact, the whole damn reason for the assertions in skb_push() is the
catch cases where preconditions are not met across functional
boundaries. Exactly like the case here.
So again, __skb_push() should be changed back to skb_push() here.
Steffen can you respin these patches and make sure to:
1) Add reference to SHA1_ID and commit header line of commit
introducing this bug, as Eric requested, in this format:
$SHA1_ID ("Commit header line text.")
2) __skb_push() --> skb_push()
Thank you.
^ permalink raw reply
* Re: [PATCH v2] powerpc/83xx: gianfar_ptp: select 1588 clock source through dts file
From: David Miller @ 2013-09-30 18:50 UTC (permalink / raw)
To: aida.mynzhasova-Fmhy8gsqeTEvJsYlp49lxw
Cc: linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
devicetree-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
richardcochran-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <1380093863-5388-1-git-send-email-aida.mynzhasova-Fmhy8gsqeTEvJsYlp49lxw@public.gmane.org>
From: Aida Mynzhasova <aida.mynzhasova-Fmhy8gsqeTEvJsYlp49lxw@public.gmane.org>
Date: Wed, 25 Sep 2013 11:24:23 +0400
> Currently IEEE 1588 timer reference clock source is determined through
> hard-coded value in gianfar_ptp driver. This patch allows to select ptp
> clock source by means of device tree file node.
>
> For instance:
>
> fsl,cksel = <0>;
>
> for using external (TSEC_TMR_CLK input) high precision timer
> reference clock.
>
> Other acceptable values:
>
> <1> : eTSEC system clock
> <2> : eTSEC1 transmit clock
> <3> : RTC clock input
>
> When this attribute isn't used, eTSEC system clock will serve as
> IEEE 1588 timer reference clock.
>
> Signed-off-by: Aida Mynzhasova <aida.mynzhasova-Fmhy8gsqeTEvJsYlp49lxw@public.gmane.org>
Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] moxa: drop free_irq of devm_request_irq allocated irq
From: David Miller @ 2013-09-30 18:55 UTC (permalink / raw)
To: weiyj.lk
Cc: grant.likely, rob.herring, jg1.han, jonas.jensen, yongjun_wei,
netdev
In-Reply-To: <CAPgLHd8YRP7kL_jNHi3J9jFn86f=Fv-AWWUY_aRGZQOgVTNPgg@mail.gmail.com>
From: Wei Yongjun <weiyj.lk@gmail.com>
Date: Wed, 25 Sep 2013 15:33:29 +0800
> From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
>
> irq allocated with devm_request_irq should not be freed using
> free_irq, because doing so causes a dangling pointer, and a
> subsequent double free.
>
> Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
I think this is a dangerous change, if the IRQ fires after the point
of the existing free_irq() call it will try to dereference the net
device struct which will be free by the time the devm release code
runes.
I'm not applying this patch, sorry.
^ permalink raw reply
* Re: [PATCH 2/2] net: qmi_wwan: fix checkpatch warnings
From: David Miller @ 2013-09-30 19:00 UTC (permalink / raw)
To: bjorn; +Cc: fabio.porcedda, netdev, linux-usb, dcbw
In-Reply-To: <877ge5own8.fsf@nemi.mork.no>
From: Bjørn Mork <bjorn@mork.no>
Date: Wed, 25 Sep 2013 15:31:39 +0200
> Sorry, I really don't see the point of this. Yes, the lines are longer
> than 80 columns, but breaking them don't improve the readability at
> all. On the contrary, IMHO.
>
> So NAK from me for this part.
Sorry, breaking things up like this is what we do everywhere.
It's not strictly 80 columns but "about 80 columns".
And the only place we don't break things up is for messages that end
up in the kernel log. Those strings can take the line as long as is
reasonably necessary.
But at argument delimiters and operators for long complex expressions,
we break it up so that the lines do not significantly exceed 80
columns.
Anything else is your opinion, and not what we've been trying to do
consistently across the kernel and in particular in the networking.
Therefore this patch is perfectly fine and I intent to apply it.
^ permalink raw reply
* Re: [PATCH 1/2] net: qmi_wwan: add Telit LE920 newer firmware support
From: David Miller @ 2013-09-30 19:02 UTC (permalink / raw)
To: fabio.porcedda-Re5JQEeQqe8AvxtiuMwx3w
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
bjorn-yOkvZcmFvRU, dcbw-H+wXaHxf7aLQT0dZR+AlfA
In-Reply-To: <1380100886-16531-1-git-send-email-fabio.porcedda-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Fabio Porcedda <fabio.porcedda-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Wed, 25 Sep 2013 11:21:25 +0200
> Newer firmware use a new pid and a different interface.
>
> Signed-off-by: Fabio Porcedda <fabio.porcedda-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Applied to net-next
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/2] net: qmi_wwan: fix checkpatch warnings
From: David Miller @ 2013-09-30 19:02 UTC (permalink / raw)
To: fabio.porcedda; +Cc: netdev, linux-usb, bjorn, dcbw
In-Reply-To: <1380100886-16531-2-git-send-email-fabio.porcedda@gmail.com>
From: Fabio Porcedda <fabio.porcedda@gmail.com>
Date: Wed, 25 Sep 2013 11:21:26 +0200
> Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH] net: qmi_wwan: fix Cinterion PLXX product ID
From: David Miller @ 2013-09-30 19:04 UTC (permalink / raw)
To: Christian.Schmiedl-av01+Y74gORBDgjK7y7TUQ
Cc: aleksander-bhGbAngMcJvQT0dZR+AlfA, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, bjorn-yOkvZcmFvRU,
dcbw-H+wXaHxf7aLQT0dZR+AlfA,
Hans-Christoph.Schemmel-av01+Y74gORBDgjK7y7TUQ,
Nicolaus.Colberg-av01+Y74gORBDgjK7y7TUQ
In-Reply-To: <376FB829F3ECB542B825EAF4D8CA8A9701F9D6114530-6vtk6ynWDJf9L9UzlSODQOG7l92LEt8e@public.gmane.org>
From: Schmiedl Christian <Christian.Schmiedl-av01+Y74gORBDgjK7y7TUQ@public.gmane.org>
Date: Thu, 26 Sep 2013 16:02:13 +0200
> Aleksander Morgado <aleksander-bhGbAngMcJvQT0dZR+AlfA@public.gmane.org> writes:
>
>> Cinterion PLXX LTE devices have a 0x0060 product ID, not 0x12d1.
>>
>> The blacklisting in the serial/option driver does actually use the
>> correct PID, as per commit 8ff10bdb14a52e3f25d4ce09e0582a8684c1a6db
>> ('USB: Blacklisted Cinterion's PLxx WWAN Interface').
>
> Thanks for patching
>
> Acked-by: Christian Schmiedl <christian.schmiedl-av01+Y74gORBDgjK7y7TUQ@public.gmane.org>
Applied, thanks everyone.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] ipv6: Fix preferred_lft not updating in some cases
From: David Miller @ 2013-09-30 19:06 UTC (permalink / raw)
To: hannes; +Cc: pmarks, netdev, yoshfuji, lorenzo
In-Reply-To: <20130928202828.GB23654@order.stressinduktion.org>
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Sat, 28 Sep 2013 22:28:28 +0200
> Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH net-next v3 1/2] dev: update __dev_notify_flags() to send rtnl msg
From: David Miller @ 2013-09-30 19:08 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: stephen, netdev
In-Reply-To: <1380103365-5185-1-git-send-email-nicolas.dichtel@6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Wed, 25 Sep 2013 12:02:44 +0200
> This patch only prepares the next one, there is no functional change.
> Now, __dev_notify_flags() can also be used to notify flags changes via
> rtnetlink.
>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next v3 2/2] dev: always advertise rx_flags changes via netlink
From: David Miller @ 2013-09-30 19:08 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: stephen, netdev
In-Reply-To: <1380103365-5185-2-git-send-email-nicolas.dichtel@6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Wed, 25 Sep 2013 12:02:45 +0200
> When flags IFF_PROMISC and IFF_ALLMULTI are changed, netlink messages are not
> consistent. For example, if a multicast daemon is running (flag IFF_ALLMULTI
> set in dev->flags but not dev->gflags, ie not exported to userspace) and then a
> user sets it via netlink (flag IFF_ALLMULTI set in dev->flags and dev->gflags, ie
> exported to userspace), no netlink message is sent.
> Same for IFF_PROMISC and because dev->promiscuity is exported via
> IFLA_PROMISCUITY, we may send a netlink message after each change of this
> counter.
>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Applied.
^ permalink raw reply
* Re: [PATCH] hamradio: baycom: remove deprecated IRQF_DISABLED
From: David Miller @ 2013-09-30 19:09 UTC (permalink / raw)
To: michael.opdenacker; +Cc: t.sailer, linux-hams, netdev, linux-kernel
In-Reply-To: <1380133065-13712-1-git-send-email-michael.opdenacker@free-electrons.com>
From: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Date: Wed, 25 Sep 2013 20:17:45 +0200
> This patch proposes to remove the IRQF_DISABLED flag
> from drivers/net/hamradio/baycom_*
>
> It's a NOOP since 2.6.35 and it will be removed one day.
>
> Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Applied to net-next, thanks.
^ permalink raw reply
* Re: pull request (net-next): ipsec-next 2013-09-26
From: David Miller @ 2013-09-30 19:12 UTC (permalink / raw)
To: steffen.klassert; +Cc: herbert, netdev
In-Reply-To: <1380185923-8976-1-git-send-email-steffen.klassert@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Thu, 26 Sep 2013 10:58:41 +0200
> Two patches that are left from the last development cycle.
> Manual merging of include/net/xfrm.h is needed. The conflict
> can be solved as it is currently done in linux-next.
>
> 1) We announce the creation of temporary acquire state via an asyc event,
> so the deletion should be annunced too. From Nicolas Dichtel.
>
> 2) The VTI tunnels do not real tunning, they just provide a routable
> IPsec tunnel interface. So introduce and use xfrm_tunnel_notifier
> instead of xfrm_tunnel for xfrm tunnel mode callback. From Fan Du.
>
> Please pull or let me know if there are problems.
Pulled, thanks a lot!
^ permalink raw reply
* Re: [PATCH net v6 1/1] xen-netback: Handle backend state transitions in a more robust way
From: David Miller @ 2013-09-30 19:14 UTC (permalink / raw)
To: Ian.Campbell; +Cc: paul.durrant, xen-devel, netdev, wei.liu2, david.vrabel
In-Reply-To: <1380200853.29483.83.camel@kazak.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
Date: Thu, 26 Sep 2013 14:07:33 +0100
> On Thu, 2013-09-26 at 12:09 +0100, Paul Durrant wrote:
>> When the frontend state changes netback now specifies its desired state to
>> a new function, set_backend_state(), which transitions through any
>> necessary intermediate states.
>> This fixes an issue observed with some old Windows frontend drivers where
>> they failed to transition through the Closing state and netback would not
>> behave correctly.
>>
>> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
>
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] MAINTAINERS: add myself as maintainer of xen-netback
From: David Miller @ 2013-09-30 19:16 UTC (permalink / raw)
To: Ian.Campbell; +Cc: wei.liu2, netdev, xen-devel
In-Reply-To: <1380200887.29483.84.camel@kazak.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
Date: Thu, 26 Sep 2013 14:08:07 +0100
> On Thu, 2013-09-26 at 12:41 +0100, Wei Liu wrote:
>> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
>
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
I've actually applied this to 'net', it's important that this
is accurate and it's a doc change so "safe" :-)
^ permalink raw reply
* [PATCH] isdn: eicon: free pointer after using it in log msg in divas_um_idi_delete_entity()
From: Jesper Juhl @ 2013-09-30 19:25 UTC (permalink / raw)
To: Armin Schindler; +Cc: Karsten Keil, netdev, linux-kernel
Not really a problem, but nice IMHO; the Coverity static analyzer
complains that we use the pointer 'e' after it has been freed, so move
the freeing below the final use, even if that use is just using the
value of the pointer and not actually dereferencing it.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
---
drivers/isdn/hardware/eicon/um_idi.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/isdn/hardware/eicon/um_idi.c b/drivers/isdn/hardware/eicon/um_idi.c
index 7cab5c3..e151971 100644
--- a/drivers/isdn/hardware/eicon/um_idi.c
+++ b/drivers/isdn/hardware/eicon/um_idi.c
@@ -288,9 +288,9 @@ int divas_um_idi_delete_entity(int adapter_nr, void *entity)
cleanup_entity(e);
diva_os_free(0, e->os_context);
memset(e, 0x00, sizeof(*e));
- diva_os_free(0, e);
DBG_LOG(("A(%d) remove E:%08x", adapter_nr, e));
+ diva_os_free(0, e);
return (0);
}
--
1.7.1
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.
^ permalink raw reply related
* Re: [PATCH] net: flow_dissector: fix thoff for IPPROTO_AH
From: David Miller @ 2013-09-30 19:34 UTC (permalink / raw)
To: eric.dumazet; +Cc: nikolay, dborkman, netdev, andy, fubar, vfalico
In-Reply-To: <1380210246.3165.184.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 26 Sep 2013 08:44:06 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> In commit 8ed781668dd49 ("flow_keys: include thoff into flow_keys for
> later usage"), we missed that existing code was using nhoff as a
> temporary variable that could not always contain transport header
> offset.
>
> This is not a problem for TCP/UDP because port offset (@poff)
> is 0 for these protocols.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied and queued up for -stable, thanks Eric.
^ permalink raw reply
* Re: [PATCH 0/3 - GIT PULL] include/linux: Remove externs from networking function prototypes
From: David Miller @ 2013-09-30 19:37 UTC (permalink / raw)
To: joe; +Cc: netdev, linux-kernel, linux-hippi, netfilter-devel, netfilter,
coreteam
In-Reply-To: <cover.1380233637.git.joe@perches.com>
From: Joe Perches <joe@perches.com>
Date: Thu, 26 Sep 2013 15:18:30 -0700
>
> The following changes since commit aae8c287e664d49df4aa315ad263c33b9a2af3e1:
>
> Merge branch 'bonding_neighbours' (2013-09-26 16:02:19 -0400)
>
> are available in the git repository at:
>
> git://repo.or.cz/linux-2.6/trivial-mods.git 20130926_include_linux_networking_externs
>
> for you to fetch changes up to f629d208d27a22f495b7734eede585b5d207e912:
>
> [networking]device.h: Remove extern from function prototypes (2013-09-26 15:06:58 -0700)
Pulled, thanks Joe.
^ permalink raw reply
* Re: [PATCH net-next] bonding: trivial: remove forgotten bond_next_vlan()
From: David Miller @ 2013-09-30 19:39 UTC (permalink / raw)
To: vfalico; +Cc: netdev, fubar, andy
In-Reply-To: <1380237721-8229-1-git-send-email-vfalico@redhat.com>
From: Veaceslav Falico <vfalico@redhat.com>
Date: Fri, 27 Sep 2013 01:22:01 +0200
> It's a forgotten function declaration, which was removed some time ago
> already.
>
> CC: Jay Vosburgh <fubar@us.ibm.com>
> CC: Andy Gospodarek <andy@greyhouse.net>
> Signed-off-by: Veaceslav Falico <vfalico@redhat.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 3/7] net: introduce new macro net_get_random_once
From: David Miller @ 2013-09-30 19:43 UTC (permalink / raw)
To: hannes; +Cc: netdev, edumazet
In-Reply-To: <1380236199-3726-4-git-send-email-hannes@stressinduktion.org>
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Fri, 27 Sep 2013 00:56:35 +0200
> +/* BE CAREFUL: this function is not interrupt safe */
> +#define net_get_random_once(buf, nbytes) \
> + ({ \
> + static bool ___done = false; \
> + bool ___ret = false; \
> + if (unlikely(!___done)) \
> + ___ret = __net_get_random_once(buf, \
> + nbytes, \
> + &___done); \
> + ___ret; \
> + })
I don't want to see this happening in every fast path, it's silly to test
this every time after the first iteration.
Maybe... _maybe_ I can be convinced if you use a static branch for this so
that it _really_ costs next to nothing.
But as-is I am not going to apply this series, sorry.
^ 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