* Re: [Patch net] rds: avoid calling sock_kfree_s() on allocation failure
From: Cong Wang @ 2014-10-14 21:27 UTC (permalink / raw)
To: David Miller; +Cc: Cong Wang, netdev, rds-devel, chien.yen, Stephen Hemminger
In-Reply-To: <20141014.170311.2104285680542945400.davem@davemloft.net>
On Tue, Oct 14, 2014 at 2:03 PM, David Miller <davem@davemloft.net> wrote:
> From: Cong Wang <xiyou.wangcong@gmail.com>
> Date: Tue, 14 Oct 2014 12:35:08 -0700
>
>> From: Cong Wang <cwang@twopensource.com>
>>
>> It is okay to free a NULL pointer but not okay to mischarge the socket optmem
>> accounting. Compile test only.
>>
>> Reported-by: rucsoftsec@gmail.com
>> Cc: Chien Yen <chien.yen@oracle.com>
>> Cc: Stephen Hemminger <stephen@networkplumber.org>
>> Signed-off-by: Cong Wang <cwang@twopensource.com>
>> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
>
> Applied, and I'm going to add the following bug check to the tree too.
>
> ====================
> [PATCH] net: Trap attempts to call sock_kfree_s() with a NULL pointer.
>
> Unlike normal kfree() it is never right to call sock_kfree_s() with
> a NULL pointer, because sock_kfree_s() also has the side effect of
> discharging the memory from the sockets quota.
>
> Signed-off-by: David S. Miller <davem@davemloft.net>
Acked-by: Cong Wang <cwang@twopensource.com>
Sounds reasonable. It could catch more bugs similar to this one.
Thanks!
^ permalink raw reply
* Re: something is wrong in commit 971f10eca1 - tcp: better TCP_SKB_CB layout to reduce cache line misses
From: Cong Wang @ 2014-10-14 21:24 UTC (permalink / raw)
To: David Miller; +Cc: Eric Dumazet, Krzysztof Kolasa, Eric Dumazet, netdev
In-Reply-To: <20141014.171559.1355616486999711590.davem@davemloft.net>
On Tue, Oct 14, 2014 at 2:15 PM, David Miller <davem@davemloft.net> wrote:
> From: Eric Dumazet <edumazet@gmail.com>
> Date: Tue, 14 Oct 2014 14:03:51 -0700
>
>> 2014-10-14 13:47 GMT-07:00 David Miller <davem@davemloft.net>:
>>>
>>>
>>> > Patch looks good, but seems a net-next candidate to me.
>>>
>>> I thought it is a potential fix for this corruption report?
>>
>>
>> Sure, but a one liner fix seemed more obvious, as it points to the problem.
>>
>> I do not particularly care, as long as we fixed the bug.
Since we are still in merge window, I don't think we have to use
a one-line fix for a bug introduced in this merge window.
>
> Ok, let's get testing feedback and then I'll look for a formal submission.
Yeah, there is no evidence to say my patch fixes the bug Krzysztof
reported before he tests it, I found it during code review.
Thanks!
^ permalink raw reply
* Re: [PATCH net] tcp: TCP Small Queues and strange attractors
From: David Miller @ 2014-10-14 21:16 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1413321018.17109.7.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 14 Oct 2014 14:10:18 -0700
> On Tue, 2014-10-14 at 15:33 -0400, David Miller wrote:
>> From: Eric Dumazet <eric.dumazet@gmail.com>
>> Date: Mon, 13 Oct 2014 06:27:47 -0700
>>
>> > diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
>> > index 8d4eac793700..4a7e97811d71 100644
>> > --- a/net/ipv4/tcp_output.c
>> > +++ b/net/ipv4/tcp_output.c
>> > @@ -839,26 +839,38 @@ void tcp_wfree(struct sk_buff *skb)
>> > {
>> ...
>> > local_irq_restore(flags);
>> > - } else {
>> > - sock_wfree(skb);
>> > + return;
>> > }
>> > +out:
>> > + sk_free(sk);
>> > }
>> >
>>
>> Why do we need to release the socket here?
>
> Thats because we had to keep a reference at the very beginning :
>
> + /* Keep one reference on sk_wmem_alloc.
> + * Will be released by sk_free() from here or tcp_tasklet_func()
> + */
> + wmem = atomic_sub_return(skb->truesize - 1, &sk->sk_wmem_alloc);
> +
>
>
> If we find that we do not arm the tasklet (and keep the reference), we
> then can remove the last ref we kept.
>
> sk_free() is essentially doing :
>
> if (atomic_dec_and_test(&sk->sk_wmem_alloc))
> __sk_free(sk)
Gotcha, now it makes sense.
Patch applied, thanks Eric.
^ permalink raw reply
* Re: something is wrong in commit 971f10eca1 - tcp: better TCP_SKB_CB layout to reduce cache line misses
From: David Miller @ 2014-10-14 21:15 UTC (permalink / raw)
To: edumazet; +Cc: cwang, kkolasa, eric.dumazet, netdev
In-Reply-To: <CAFrEnejET5wer6S6qx13tMKWMshmRj+JnQeZL-zdPGcs__9NoQ@mail.gmail.com>
From: Eric Dumazet <edumazet@gmail.com>
Date: Tue, 14 Oct 2014 14:03:51 -0700
> 2014-10-14 13:47 GMT-07:00 David Miller <davem@davemloft.net>:
>>
>>
>> > Patch looks good, but seems a net-next candidate to me.
>>
>> I thought it is a potential fix for this corruption report?
>
>
> Sure, but a one liner fix seemed more obvious, as it points to the problem.
>
> I do not particularly care, as long as we fixed the bug.
Ok, let's get testing feedback and then I'll look for a formal submission.
^ permalink raw reply
* Re: [PATCH RFC net-next] sfc: add support for skb->xmit_more
From: David Miller @ 2014-10-14 21:15 UTC (permalink / raw)
To: ecree; +Cc: dborkman, nikolay, netdev, sshah, jcooper, linux-net-drivers
In-Reply-To: <alpine.LFD.2.03.1410141933500.26972@solarflare.com>
From: Edward Cree <ecree@solarflare.com>
Date: Tue, 14 Oct 2014 19:41:37 +0100
> Don't ring the doorbell, and don't do PIO. This will also prevent
> TX Push, because there will be more than one buffer waiting when
> the doorbell is rung.
>
> Signed-off-by: Edward Cree <ecree@solarflare.com>
This looks good to me, mind if I apply this now?
^ permalink raw reply
* Re: [PATCH net] tcp: TCP Small Queues and strange attractors
From: Eric Dumazet @ 2014-10-14 21:10 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20141014.153308.2221538197341630790.davem@davemloft.net>
On Tue, 2014-10-14 at 15:33 -0400, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Mon, 13 Oct 2014 06:27:47 -0700
>
> > diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
> > index 8d4eac793700..4a7e97811d71 100644
> > --- a/net/ipv4/tcp_output.c
> > +++ b/net/ipv4/tcp_output.c
> > @@ -839,26 +839,38 @@ void tcp_wfree(struct sk_buff *skb)
> > {
> ...
> > local_irq_restore(flags);
> > - } else {
> > - sock_wfree(skb);
> > + return;
> > }
> > +out:
> > + sk_free(sk);
> > }
> >
>
> Why do we need to release the socket here?
Thats because we had to keep a reference at the very beginning :
+ /* Keep one reference on sk_wmem_alloc.
+ * Will be released by sk_free() from here or tcp_tasklet_func()
+ */
+ wmem = atomic_sub_return(skb->truesize - 1, &sk->sk_wmem_alloc);
+
If we find that we do not arm the tasklet (and keep the reference), we
then can remove the last ref we kept.
sk_free() is essentially doing :
if (atomic_dec_and_test(&sk->sk_wmem_alloc))
__sk_free(sk)
sock_wfree() is the same, its only that we know that TCP socket do not
pass this test :
if (!sock_flag(sk, SOCK_USE_WRITE_QUEUE)) {
sk->sk_write_space(sk);
}
^ permalink raw reply
* Re: [PATCH net 0/2] qlcnic: Bug fixes
From: David Miller @ 2014-10-14 21:06 UTC (permalink / raw)
To: rajesh.borundia; +Cc: netdev, Dept-HSGLinuxNICDev
In-Reply-To: <1413286906-14220-1-git-send-email-rajesh.borundia@qlogic.com>
From: Rajesh Borundia <rajesh.borundia@qlogic.com>
Date: Tue, 14 Oct 2014 07:41:44 -0400
> This series fixes following issues.
>
> * We were programming maximum number of arguments supported by
> adapter instead of required in a command.
> * Destroy tx command requires three arguments instead of two.
>
> Please apply these patches to net.
Series applied, thanks.
^ permalink raw reply
* Re: [net] genl_magic: Resolve logical-op warnings
From: David Miller @ 2014-10-14 21:04 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: mark.d.rustad, linux-kernel, johannes.berg, netdev
In-Reply-To: <1413293318-9070-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 14 Oct 2014 06:28:38 -0700
> From: Mark Rustad <mark.d.rustad@intel.com>
>
> Resolve "logical 'and' applied to non-boolean constant" warnings"
> that appear in W=2 builds by adding !! to a bit test.
>
> Signed-off-by: Mark Rustad <mark.d.rustad@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied, thanks Jeff.
^ permalink raw reply
* Re: something is wrong in commit 971f10eca1 - tcp: better TCP_SKB_CB layout to reduce cache line misses
From: Eric Dumazet @ 2014-10-14 21:03 UTC (permalink / raw)
To: David Miller; +Cc: cwang, kkolasa, Eric Dumazet, netdev
In-Reply-To: <20141014.164705.1874094084240216813.davem@davemloft.net>
2014-10-14 13:47 GMT-07:00 David Miller <davem@davemloft.net>:
>
>
> > Patch looks good, but seems a net-next candidate to me.
>
> I thought it is a potential fix for this corruption report?
Sure, but a one liner fix seemed more obvious, as it points to the problem.
I do not particularly care, as long as we fixed the bug.
Thanks !
^ permalink raw reply
* Re: [Patch net] rds: avoid calling sock_kfree_s() on allocation failure
From: David Miller @ 2014-10-14 21:03 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev, rds-devel, chien.yen, stephen, cwang
In-Reply-To: <1413315308-32288-1-git-send-email-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Tue, 14 Oct 2014 12:35:08 -0700
> From: Cong Wang <cwang@twopensource.com>
>
> It is okay to free a NULL pointer but not okay to mischarge the socket optmem
> accounting. Compile test only.
>
> Reported-by: rucsoftsec@gmail.com
> Cc: Chien Yen <chien.yen@oracle.com>
> Cc: Stephen Hemminger <stephen@networkplumber.org>
> Signed-off-by: Cong Wang <cwang@twopensource.com>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Applied, and I'm going to add the following bug check to the tree too.
====================
[PATCH] net: Trap attempts to call sock_kfree_s() with a NULL pointer.
Unlike normal kfree() it is never right to call sock_kfree_s() with
a NULL pointer, because sock_kfree_s() also has the side effect of
discharging the memory from the sockets quota.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/core/sock.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/core/sock.c b/net/core/sock.c
index b4f3ea2..15e0c67 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -1718,6 +1718,8 @@ EXPORT_SYMBOL(sock_kmalloc);
*/
void sock_kfree_s(struct sock *sk, void *mem, int size)
{
+ if (WARN_ON_ONCE(!mem))
+ return;
kfree(mem);
atomic_sub(size, &sk->sk_omem_alloc);
}
--
1.7.11.7
^ permalink raw reply related
* Re: Fwd: micrel: ksz8051 badly detected as ksz8031
From: Florian Fainelli @ 2014-10-14 20:56 UTC (permalink / raw)
To: Angelo Dureghello, netdev@vger.kernel.org
In-Reply-To: <543D7A84.4030202@gmail.com>
On 10/14/2014 12:33 PM, Angelo Dureghello wrote:
> Hi Florian,
>
>> On 10/14/2014 10:24 AM, Angelo Dureghello wrote:
>>> Dear,
>>>
>>> have to apologize for the confusion, previous patch is not the proper
>>> fix,
>>> since it is not solving completely the issue.
>>>
>>> And also, i mainly misunderstood the issue.
>>>
>>> The issue i am experiencing is :
>>>
>>> https://lkml.org/lkml/2013/9/18/259
>>>
>>> Mainly, i have Micrel chip marked KSZ8051(RNL), but the product Id in
>>> the
>>> silicon is KSZ8031 and linux detects it as KSZ8031.
>>> The attmept to mdio boot override register kill the Micrel
>>> functionality.
>> Ok, so basically your bootloader does something that Linux does, and
>> once Linux boots, it will reset the PHY to put it in a known state. If
>> you can snoop the MDIO read/writes done in your bootloader environment,
>> that might help narrow down the issue.
>>
> Bootloader is u-boot and seems it uses generic PHY setup, and so it works.
>
> Linux at boot detects the phy and does a soft_reset. If the detection
> sets the
> driver as for KSZ8031, ethernet/link will not work, becouse micrel.c uses
> the incorrect config_init function, attempts to write to the bootstrap
> override register, that can't be written for KSZ8051, and so puts the
> micrel
> chip in a broken state.
>
> The guy in this link (https://lkml.org/lkml/2013/9/18/259) seems are
> discussing a
> better solution.
>
> I patched my linux as below, but this is a fast fixup for me:
You could register a PHY fixup in your board code that does exactly what
you are you doing here, except that you would match 0x00221556,
something along those lines:
static int micrel_ipam390_phy_fixup(struct phy_device *dev)
{
if (dev->phy_id == 0x00221556)
dev->phy_id = 0x00221550;
return 0;
}
int __init micrel_ipam390_phy_fixup_register(void)
{
return phy_register_fixup_for_id(PHY_ANY_ID, micrel_ipam390);
}
>
> diff -rupN drivers/net/phy/phy_device.c
> ../linux-3.17/drivers/net/phy/phy_device.c
> --- drivers/net/phy/phy_device.c 2014-10-14 21:05:56.191117190 +0200
> +++ ../linux-3.17/drivers/net/phy/phy_device.c 2014-10-05
> 21:23:04.000000000 +0200
> @@ -310,19 +310,6 @@ static int get_phy_id(struct mii_bus *bu
>
> *phy_id |= (phy_reg & 0xffff);
>
> - /*
> - * Angelo - Barix
> - * Micrel produced chips marked KSZ8051 but with KSZ8031 id code
> - * in the silicon. After getting crazy to understand why in
> recent kernel
> - * the ethenret was not workeing, i find it out.
> - *
> - * From the schematic, we assume to use KSZ8051
> - * I hardcode the fix here for ipam390.
> - */
> -#if CONFIG_MACH_BARIX_IPAM390
> - if (*phy_id == 0x00221556) *phy_id = 0x00221550;
> -#endif
> -
> return 0;
> }
>
> Regards
> angelo
>
^ permalink raw reply
* Re: [PATCH net] cxgb4: Fix FW flash logic using ethtool
From: David Miller @ 2014-10-14 20:55 UTC (permalink / raw)
To: hariprasad; +Cc: netdev, leedom, kumaras, nirranjan, santosh, anish
In-Reply-To: <1413318254-23813-1-git-send-email-hariprasad@chelsio.com>
From: Hariprasad Shenai <hariprasad@chelsio.com>
Date: Wed, 15 Oct 2014 01:54:14 +0530
> Use t4_fw_upgrade instead of t4_load_fw to write firmware into FLASH, since
> t4_load_fw doesn't co-ordinate with the firmware and the adapter can get hosed
> enough to require a power cycle of the system.
>
> Based on original work by Casey Leedom <leedom@chelsio.com>
>
> Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
Applied.
^ permalink raw reply
* RE: ixgbe: Question about Flow Control on 10G
From: Tantilov, Emil S @ 2014-10-14 20:54 UTC (permalink / raw)
To: dom, Skidmore, Donald C, netdev@vger.kernel.org
In-Reply-To: <543D72FE.9090107@citrix.com>
>-----Original Message-----
>From: netdev-owner@vger.kernel.org [mailto:netdev-
>owner@vger.kernel.org] On Behalf Of dom
>Sent: Tuesday, October 14, 2014 12:01 PM
>To: Skidmore, Donald C; netdev@vger.kernel.org
>Subject: ixgbe: Question about Flow Control on 10G
>
>Hi
>
>I have a question about the ixgbe driver's handling of
>'ethtool -a ethX'
>when the NIC is using fibre.
>
>Specifically I don't understand the code introduced by this
>commit:
>
>commit 73d80953dfd1d5a92948005798c857c311c2834b
>Author: Don Skidmore <donald.c.skidmore@intel.com>
>Date: Wed Jul 31 02:19:24 2013 +0000
>Subject: ixgbe: fix fc autoneg ethtool reporting.
>
>The function introduced the function:
> ixgbe_device_supports_autoneg_fc()
>
>which gets called by
>ixgbe_get_pauseparam()/ixgbe_set_pauseparam().
>
>specifically there is a case in
>ixgbe_device_supports_autoneg_fc()
>
> case ixgbe_media_type_fiber_qsfp:
> case ixgbe_media_type_fiber:
> hw->mac.ops.check_link(hw, &speed, &link_up,
>false);
> /* if link is down, assume supported */
> if (link_up)
> supported = speed == IXGBE_LINK_SPEED_1GB_FULL ?
> true : false;
>
>If link_up=1 then why is supported only true for a
>speed=IXGBE_LINK_SPEED_1GB_FULL ?
>
>Why is Flow Control not supported for IXGBE_LINK_SPEED_10GB_FULL ?
For SFP modules (media_type_fiber) flow control autoneg is not supported at 10gig. You can still set flow control manually to enabled/disabled, just not autoneg.
Thanks,
Emil
^ permalink raw reply
* Re: something is wrong in commit 971f10eca1 - tcp: better TCP_SKB_CB layout to reduce cache line misses
From: David Miller @ 2014-10-14 20:47 UTC (permalink / raw)
To: edumazet; +Cc: cwang, kkolasa, eric.dumazet, netdev
In-Reply-To: <CAFrEnehWNzmzZGV-ZGbZF=wJ1q0TjFtB1yG6Dp1yVrJmBj9B7Q@mail.gmail.com>
From: Eric Dumazet <edumazet@gmail.com>
Date: Tue, 14 Oct 2014 13:42:01 -0700
> 2014-10-14 12:03 GMT-07:00 David Miller <davem@davemloft.net>:
>
>> From: Cong Wang <cwang@twopensource.com>
>> Date: Tue, 14 Oct 2014 11:59:25 -0700
>>
>> > On Tue, Oct 14, 2014 at 6:25 AM, Krzysztof Kolasa <kkolasa@winsoft.pl>
>> wrote:
>> >> W dniu 14.10.2014 o 02:09, Cong Wang pisze:
>> >>
>> >>> On Mon, Oct 13, 2014 at 4:59 PM, Cong Wang <cwang@twopensource.com>
>> wrote:
>> >>>>
>> >>>> Probably not related with this bug, but with regarding to the
>> >>>> offending commit, what's the point of the memmove() in tcp_v4_rcv()
>> >>>> since ip_rcv() already clears IPCB()?
>> >>>
>> >>> Oh, ip options are actually saved in ip_rcv_finish()... Hmm, looks
>> scary
>> >>> to play with variable-length array with memmove()....
>> >>>
>> >> On my other old laptop with 32bit kernel next and graphics card Intel
>> 945GM
>> >> just after the revert commit working OK,
>> >> before, after login to gnome shell in some seconds decorations disappear
>> >>
>> >> 32 bit Ubuntu 12.04.5 LTS, gnome shell, kernel source next 14-10-2014
>> >>
>> >> Can anyone confirm this ?
>> >>
>> >
>> > Sorry, believe it or not, for me it is hard to find a 32bit machine even
>> VM. :)
>> >
>> > Could the attached patch by any chance help? I noticed cookie_v4_check()
>> > still uses IPCB() instead of TCPCB() at TCP layer.
>>
>> Eric, please review.
>>
>
> For an unknown reason I do not see this patch on my eric.dumazet@gmail.com
>
> It seems my migration to Trusty was not a good move :(
>
> Patch looks good, but seems a net-next candidate to me.
I thought it is a potential fix for this corruption report?
^ permalink raw reply
* Re: [PATCH (net.git) 0/2] stmmac: review and fix the dwmac-sti glue-logic
From: David Miller @ 2014-10-14 20:41 UTC (permalink / raw)
To: peppe.cavallaro; +Cc: netdev, maxime.coquelin
In-Reply-To: <1413267176-325-1-git-send-email-peppe.cavallaro@st.com>
From: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Date: Tue, 14 Oct 2014 08:12:54 +0200
> This patch is to review the whole glue logic adopted on STi SoCs that
> was bugged.
> In the old glue-logic there was a lot of confusion when setup the
> retiming especially for STiD127 where, for example, the bits 6 and 7
> (in the GMAC control register) have a different meaning of what is
> used for STiH4xx SoCs. So we cannot adopt the same glue for all these
> SoCs.
> Moreover, GiGa on STiD127 didn't work and, for all the SoCs, the RGMII
> couldn't run when the speed was 10Mbps (because the clock was not properly
> managed).
> Note that the phy clock needs to be provided by the platform as well as
> documented in the related binding file (updated as consequence).
>
> The old code supported too many configurations never adopted and validated.
> This made the code very complex to maintain and debug in case of issues.
>
> The patch simplifies all the configurations as commented in the tables
> inside the file and obviously it has been tested on all the boards
> based on the SoCs mentioned.
>
> With this patch, the dwmac-sti is also ready to support new configurations that
> will be available on next SoC generations.
Series applied.
^ permalink raw reply
* Re: [PATCH (net.git)] stmmac: platform: fix FIXED_PHY support.
From: David Miller @ 2014-10-14 20:41 UTC (permalink / raw)
To: peppe.cavallaro; +Cc: netdev
In-Reply-To: <1413267114-24043-1-git-send-email-peppe.cavallaro@st.com>
From: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Date: Tue, 14 Oct 2014 08:11:54 +0200
> On several STi platforms: e.g. stihxxx-b2120 an Ethernet switch is
> embedded and connected to the stmmac via RGMII mode. So this is managed
> by using the FIXED_PHY. In that case, the support in the platform needs
> to be fixed to allow the stmmac to dialog with the switch via fixed-link
> by using phy_bus_name property.
>
> Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Applied.
^ permalink raw reply
* Re: [PATCH v9 net-next 2/4] net: filter: split filter.h and expose eBPF to user space
From: Daniel Borkmann @ 2014-10-14 20:27 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: David S. Miller, Ingo Molnar, Linus Torvalds, Andy Lutomirski,
Steven Rostedt, Hannes Frederic Sowa, Chema Gonzalez,
Eric Dumazet, Peter Zijlstra, H. Peter Anvin, Andrew Morton,
Kees Cook, Linux API, Network Development, LKML
In-Reply-To: <CAMEtUuws+AtOdwud8_YjXhs=yomt8nY+49f_UuhofcmhV58c1Q@mail.gmail.com>
On 10/14/2014 10:43 AM, Alexei Starovoitov wrote:
> On Tue, Oct 14, 2014 at 12:34 AM, Daniel Borkmann <dborkman@redhat.com> wrote:
>> On 10/13/2014 11:49 PM, Alexei Starovoitov wrote:
>>>
>>> On Mon, Oct 13, 2014 at 10:21 AM, Daniel Borkmann <dborkman@redhat.com>
>>> wrote:
>>>>
>>>> On 09/03/2014 05:46 PM, Daniel Borkmann wrote:
>>>> ...
>>>>>
>>>>> Ok, given you post the remaining two RFCs later on this window as
>>>>> you indicate, I have no objections:
>>>>>
>>>>> Acked-by: Daniel Borkmann <dborkman@redhat.com>
>>>>
>>>> Ping, Alexei, are you still sending the patch for bpf_common.h or
>>>> do you want me to take care of this?
>>>
>>> It's not forgotten.
>>> I'm not sending it only because net-next is closed
>>> and it seems to be -next material.
>>
>> Well, the point was since it's UAPI you're modifying, that it needs
>> to be shipped before it first gets exposed to user land ...
>>
>> I think that should be reason enough ... there's no point in doing
>> this at a later point in time.
>
> Moving common #defines from filter.h into bpf_common.h can
> be done at any point in time. For the sake of argument if
> there is an app that includes both filter.h and bpf.h, it will
> continue to work just fine.
Correct, but the argument was that we can _avoid_ this from the
very beginning. Thus, user space applications making use of eBPF
only need to include <linux/bpf.h>, nothing more.
Doing this at any later point in time will just lead to the need
to include both headers.
^ permalink raw reply
* Re: [PATCH] dsa: mv88e6171: Fix tag_protocol check
From: David Miller @ 2014-10-14 20:23 UTC (permalink / raw)
To: linux; +Cc: f.fainelli, netdev, linux-kernel, andrew
In-Reply-To: <1413310864-16830-1-git-send-email-linux@roeck-us.net>
From: Guenter Roeck <linux@roeck-us.net>
Date: Tue, 14 Oct 2014 11:21:04 -0700
> tag_protocol is now an enum, so drivers have to check against it.
>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Applied, thanks.
^ permalink raw reply
* [PATCH net] cxgb4: Fix FW flash logic using ethtool
From: Hariprasad Shenai @ 2014-10-14 20:24 UTC (permalink / raw)
To: netdev; +Cc: davem, leedom, kumaras, nirranjan, santosh, anish,
Hariprasad Shenai
Use t4_fw_upgrade instead of t4_load_fw to write firmware into FLASH, since
t4_load_fw doesn't co-ordinate with the firmware and the adapter can get hosed
enough to require a power cycle of the system.
Based on original work by Casey Leedom <leedom@chelsio.com>
Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 2 ++
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 14 ++++++++++++--
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 6 ++----
3 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
index 9b2c669..38d8234 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
@@ -986,6 +986,8 @@ static inline int t4_memory_write(struct adapter *adap, int mtype, u32 addr,
int t4_seeprom_wp(struct adapter *adapter, bool enable);
int get_vpd_params(struct adapter *adapter, struct vpd_params *p);
int t4_load_fw(struct adapter *adapter, const u8 *fw_data, unsigned int size);
+int t4_fw_upgrade(struct adapter *adap, unsigned int mbox,
+ const u8 *fw_data, unsigned int size, int force);
unsigned int t4_flash_cfg_addr(struct adapter *adapter);
int t4_get_fw_version(struct adapter *adapter, u32 *vers);
int t4_get_tp_version(struct adapter *adapter, u32 *vers);
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index 321f3d9..54a135d 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -2929,16 +2929,26 @@ static int set_flash(struct net_device *netdev, struct ethtool_flash *ef)
int ret;
const struct firmware *fw;
struct adapter *adap = netdev2adap(netdev);
+ unsigned int mbox = FW_PCIE_FW_MASTER_MASK + 1;
ef->data[sizeof(ef->data) - 1] = '\0';
ret = request_firmware(&fw, ef->data, adap->pdev_dev);
if (ret < 0)
return ret;
- ret = t4_load_fw(adap, fw->data, fw->size);
+ /* If the adapter has been fully initialized then we'll go ahead and
+ * try to get the firmware's cooperation in upgrading to the new
+ * firmware image otherwise we'll try to do the entire job from the
+ * host ... and we always "force" the operation in this path.
+ */
+ if (adap->flags & FULL_INIT_DONE)
+ mbox = adap->mbox;
+
+ ret = t4_fw_upgrade(adap, mbox, fw->data, fw->size, 1);
release_firmware(fw);
if (!ret)
- dev_info(adap->pdev_dev, "loaded firmware %s\n", ef->data);
+ dev_info(adap->pdev_dev, "loaded firmware %s,"
+ " reload cxgb4 driver\n", ef->data);
return ret;
}
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
index 22d7581..b659b94 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
@@ -37,8 +37,6 @@
#include "t4_regs.h"
#include "t4fw_api.h"
-static int t4_fw_upgrade(struct adapter *adap, unsigned int mbox,
- const u8 *fw_data, unsigned int size, int force);
/**
* t4_wait_op_done_val - wait until an operation is completed
* @adapter: the adapter performing the operation
@@ -3076,8 +3074,8 @@ static int t4_fw_restart(struct adapter *adap, unsigned int mbox, int reset)
* positive errno indicates that the adapter is ~probably~ intact, a
* negative errno indicates that things are looking bad ...
*/
-static int t4_fw_upgrade(struct adapter *adap, unsigned int mbox,
- const u8 *fw_data, unsigned int size, int force)
+int t4_fw_upgrade(struct adapter *adap, unsigned int mbox,
+ const u8 *fw_data, unsigned int size, int force)
{
const struct fw_hdr *fw_hdr = (const struct fw_hdr *)fw_data;
int reset, ret;
--
1.7.1
^ permalink raw reply related
* Re: [PATCH v2] ipv4: dst_entry leak in ip_append_data()
From: David Miller @ 2014-10-14 20:12 UTC (permalink / raw)
To: vvs; +Cc: netdev, kuznet, jmorris, yoshfuji, kaber, eric.dumazet
In-Reply-To: <543CAD2A.3070701@parallels.com>
From: Vasily Averin <vvs@parallels.com>
Date: Tue, 14 Oct 2014 08:57:14 +0400
> v2: adjust the indentation of the arguments __ip_append_data() call
>
> Fixes: 2e77d89b2fa8 ("net: avoid a pair of dst_hold()/dst_release() in ip_append_data()")
>
> If sk_write_queue is empty ip_append_data() executes ip_setup_cork()
> that "steals" dst entry from rt to cork. Later it calls __ip_append_data()
> that creates skb and adds it to sk_write_queue.
>
> If skb was added successfully following ip_push_pending_frames() call
> reassign dst entries from cork to skb, and kfree_skb frees dst_entry.
>
> However nobody frees stolen dst_entry if skb was not added into sk_write_queue.
>
> Signed-off-by: Vasily Averin <vvs@parallels.com>
Why doesn't ip_make_skb() need the same fix? It seems to do the same
thing.
^ permalink raw reply
* Re: [PATCH v2 0/4] Add SGMII based 1GbE support to APM X-Gene SoC ethernet driver
From: David Miller @ 2014-10-14 20:10 UTC (permalink / raw)
To: isubramanian
Cc: romieu, netdev, devicetree, linux-arm-kernel, patches, kchudgar
In-Reply-To: <1413245135-2989-1-git-send-email-isubramanian@apm.com>
From: Iyappan Subramanian <isubramanian@apm.com>
Date: Mon, 13 Oct 2014 17:05:31 -0700
> Adding SGMII based 1GbE basic support to APM X-Gene SoC ethernet driver.
>
> v2: Address comments from v1
> * Split the patchset into two, the first one being preparatory patch
> * Added link_state function pointer to the xgene_mac_ops structure
> * Added xgene_indirect_ctl structure for indirect read/write arguments
>
> v1:
> * Initial version
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net] net: filter: move common defines into bpf_common.h
From: David Miller @ 2014-10-14 20:07 UTC (permalink / raw)
To: ast-uqk4Ao+rVK5Wk0Htik3J/w
Cc: mingo-DgEjT+Ai2ygdnm+yROfE0A,
torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
luto-kltTT9wpgjJwATOyAt5JVQ, rostedt-nx8X9YLhiw1AfugRpC6u6w,
dborkman-H+wXaHxf7aLQT0dZR+AlfA,
hannes-tFNcAqjVMyqKXQKiL6tip0B+6BGkLq7r,
chema-hpIqsD4AKlfQT0dZR+AlfA, edumazet-hpIqsD4AKlfQT0dZR+AlfA,
a.p.zijlstra-/NLkJaSkS4VmR6Xm/wNWPw, hpa-YMNOUZJC4hwAvxtiuMwx3w,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
keescook-F7+t8E8rja9g9hUCZPvPmw, linux-api-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1413277734-13053-1-git-send-email-ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
From: Alexei Starovoitov <ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
Date: Tue, 14 Oct 2014 02:08:54 -0700
> userspace programs that use eBPF instruction macros need to include two files:
> uapi/linux/filter.h and uapi/linux/bpf.h
> Move common macro definitions that are shared between classic BPF and eBPF
> into uapi/linux/bpf_common.h, so that user app can include only one bpf.h file
>
> Cc: Daniel Borkmann <dborkman-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> Signed-off-by: Alexei Starovoitov <ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
> ---
>
> Daniel believes that this patch has to be done for this merge window.
> I think it can wait till next, but it won't hurt now either.
Applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH V2 2/2 net-next] caif_usb: use target structure member in memset
From: David Miller @ 2014-10-14 20:06 UTC (permalink / raw)
To: fabf; +Cc: linux-kernel, joe, dmitry.tarnyagin, netdev
In-Reply-To: <1413306074-8401-1-git-send-email-fabf@skynet.be>
From: Fabian Frederick <fabf@skynet.be>
Date: Tue, 14 Oct 2014 19:01:14 +0200
> parent cfusbl was used instead of first structure member 'layer'
>
> Suggested-by: Joe Perches <joe@perches.com>
> Signed-off-by: Fabian Frederick <fabf@skynet.be>
Applied.
^ permalink raw reply
* Re: [PATCH V2 1/2 net-next] caif_usb: remove redundant memory message
From: David Miller @ 2014-10-14 20:05 UTC (permalink / raw)
To: fabf; +Cc: linux-kernel, joe, dmitry.tarnyagin, netdev
In-Reply-To: <1413306055-8281-1-git-send-email-fabf@skynet.be>
From: Fabian Frederick <fabf@skynet.be>
Date: Tue, 14 Oct 2014 19:00:55 +0200
> Let MM subsystem display out of memory messages.
>
> Signed-off-by: Fabian Frederick <fabf@skynet.be>
> ---
> V2: add second patch with memset fix
Applied.
^ permalink raw reply
* Re: Netlink mmap tx security?
From: David Miller @ 2014-10-14 20:00 UTC (permalink / raw)
To: luto; +Cc: torvalds, kaber, netdev
In-Reply-To: <CALCETrUYBed_TBacxoDPMphM5y=iqxho2isrDruOQi=pmK2yoQ@mail.gmail.com>
From: Andy Lutomirski <luto@amacapital.net>
Date: Tue, 14 Oct 2014 12:33:43 -0700
> For full honesty, there is now the machinery developed for memfd
> sealing, but I can't imagine that this is ever faster than just
> copying the buffer.
I don't have much motivation to even check if it's a worthwhile
pursuit at this point.
Someone who wants to can :-)
> I think that the NETLINK_SKB_TX declaration in include/linux/netlink.h
> should probably go, too. And there's the last parameter to
> netlink_set_ring, too, and possibly even the nlk->tx_ring struct
> itself.
Agreed on all counts, here is the new patch:
====================
[PATCH] netlink: Remove TX mmap support.
There is no reasonable manner in which to absolutely make sure that another
thread of control cannot write to the pages in the mmap()'d area and thus
make sure that netlink messages do not change underneath us after we've
performed verifications.
Reported-by: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
include/linux/netlink.h | 5 +-
net/netlink/af_netlink.c | 161 +++++------------------------------------------
net/netlink/af_netlink.h | 1 -
3 files changed, 16 insertions(+), 151 deletions(-)
diff --git a/include/linux/netlink.h b/include/linux/netlink.h
index 9e572da..57080a9 100644
--- a/include/linux/netlink.h
+++ b/include/linux/netlink.h
@@ -17,9 +17,8 @@ static inline struct nlmsghdr *nlmsg_hdr(const struct sk_buff *skb)
enum netlink_skb_flags {
NETLINK_SKB_MMAPED = 0x1, /* Packet data is mmaped */
- NETLINK_SKB_TX = 0x2, /* Packet was sent by userspace */
- NETLINK_SKB_DELIVERED = 0x4, /* Packet was delivered */
- NETLINK_SKB_DST = 0x8, /* Dst set in sendto or sendmsg */
+ NETLINK_SKB_DELIVERED = 0x2, /* Packet was delivered */
+ NETLINK_SKB_DST = 0x4, /* Dst set in sendto or sendmsg */
};
struct netlink_skb_parms {
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index c416725..07ef0c9 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -289,11 +289,6 @@ static bool netlink_rx_is_mmaped(struct sock *sk)
return nlk_sk(sk)->rx_ring.pg_vec != NULL;
}
-static bool netlink_tx_is_mmaped(struct sock *sk)
-{
- return nlk_sk(sk)->tx_ring.pg_vec != NULL;
-}
-
static __pure struct page *pgvec_to_page(const void *addr)
{
if (is_vmalloc_addr(addr))
@@ -359,7 +354,7 @@ err1:
}
static int netlink_set_ring(struct sock *sk, struct nl_mmap_req *req,
- bool closing, bool tx_ring)
+ bool closing)
{
struct netlink_sock *nlk = nlk_sk(sk);
struct netlink_ring *ring;
@@ -368,8 +363,8 @@ static int netlink_set_ring(struct sock *sk, struct nl_mmap_req *req,
unsigned int order = 0;
int err;
- ring = tx_ring ? &nlk->tx_ring : &nlk->rx_ring;
- queue = tx_ring ? &sk->sk_write_queue : &sk->sk_receive_queue;
+ ring = &nlk->rx_ring;
+ queue = &sk->sk_receive_queue;
if (!closing) {
if (atomic_read(&nlk->mapped))
@@ -476,11 +471,9 @@ static int netlink_mmap(struct file *file, struct socket *sock,
mutex_lock(&nlk->pg_vec_lock);
expected = 0;
- for (ring = &nlk->rx_ring; ring <= &nlk->tx_ring; ring++) {
- if (ring->pg_vec == NULL)
- continue;
+ ring = &nlk->rx_ring;
+ if (ring->pg_vec)
expected += ring->pg_vec_len * ring->pg_vec_pages * PAGE_SIZE;
- }
if (expected == 0)
goto out;
@@ -490,10 +483,8 @@ static int netlink_mmap(struct file *file, struct socket *sock,
goto out;
start = vma->vm_start;
- for (ring = &nlk->rx_ring; ring <= &nlk->tx_ring; ring++) {
- if (ring->pg_vec == NULL)
- continue;
-
+ ring = &nlk->rx_ring;
+ if (ring->pg_vec) {
for (i = 0; i < ring->pg_vec_len; i++) {
struct page *page;
void *kaddr = ring->pg_vec[i];
@@ -662,13 +653,6 @@ static unsigned int netlink_poll(struct file *file, struct socket *sock,
}
spin_unlock_bh(&sk->sk_receive_queue.lock);
- spin_lock_bh(&sk->sk_write_queue.lock);
- if (nlk->tx_ring.pg_vec) {
- if (netlink_current_frame(&nlk->tx_ring, NL_MMAP_STATUS_UNUSED))
- mask |= POLLOUT | POLLWRNORM;
- }
- spin_unlock_bh(&sk->sk_write_queue.lock);
-
return mask;
}
@@ -698,104 +682,6 @@ static void netlink_ring_setup_skb(struct sk_buff *skb, struct sock *sk,
NETLINK_CB(skb).sk = sk;
}
-static int netlink_mmap_sendmsg(struct sock *sk, struct msghdr *msg,
- u32 dst_portid, u32 dst_group,
- struct sock_iocb *siocb)
-{
- struct netlink_sock *nlk = nlk_sk(sk);
- struct netlink_ring *ring;
- struct nl_mmap_hdr *hdr;
- struct sk_buff *skb;
- unsigned int maxlen;
- bool excl = true;
- int err = 0, len = 0;
-
- /* Netlink messages are validated by the receiver before processing.
- * In order to avoid userspace changing the contents of the message
- * after validation, the socket and the ring may only be used by a
- * single process, otherwise we fall back to copying.
- */
- if (atomic_long_read(&sk->sk_socket->file->f_count) > 2 ||
- atomic_read(&nlk->mapped) > 1)
- excl = false;
-
- mutex_lock(&nlk->pg_vec_lock);
-
- ring = &nlk->tx_ring;
- maxlen = ring->frame_size - NL_MMAP_HDRLEN;
-
- do {
- hdr = netlink_current_frame(ring, NL_MMAP_STATUS_VALID);
- if (hdr == NULL) {
- if (!(msg->msg_flags & MSG_DONTWAIT) &&
- atomic_read(&nlk->tx_ring.pending))
- schedule();
- continue;
- }
- if (hdr->nm_len > maxlen) {
- err = -EINVAL;
- goto out;
- }
-
- netlink_frame_flush_dcache(hdr);
-
- if (likely(dst_portid == 0 && dst_group == 0 && excl)) {
- skb = alloc_skb_head(GFP_KERNEL);
- if (skb == NULL) {
- err = -ENOBUFS;
- goto out;
- }
- sock_hold(sk);
- netlink_ring_setup_skb(skb, sk, ring, hdr);
- NETLINK_CB(skb).flags |= NETLINK_SKB_TX;
- __skb_put(skb, hdr->nm_len);
- netlink_set_status(hdr, NL_MMAP_STATUS_RESERVED);
- atomic_inc(&ring->pending);
- } else {
- skb = alloc_skb(hdr->nm_len, GFP_KERNEL);
- if (skb == NULL) {
- err = -ENOBUFS;
- goto out;
- }
- __skb_put(skb, hdr->nm_len);
- memcpy(skb->data, (void *)hdr + NL_MMAP_HDRLEN, hdr->nm_len);
- netlink_set_status(hdr, NL_MMAP_STATUS_UNUSED);
- }
-
- netlink_increment_head(ring);
-
- NETLINK_CB(skb).portid = nlk->portid;
- NETLINK_CB(skb).dst_group = dst_group;
- NETLINK_CB(skb).creds = siocb->scm->creds;
-
- err = security_netlink_send(sk, skb);
- if (err) {
- kfree_skb(skb);
- goto out;
- }
-
- if (unlikely(dst_group)) {
- atomic_inc(&skb->users);
- netlink_broadcast(sk, skb, dst_portid, dst_group,
- GFP_KERNEL);
- }
- err = netlink_unicast(sk, skb, dst_portid,
- msg->msg_flags & MSG_DONTWAIT);
- if (err < 0)
- goto out;
- len += err;
-
- } while (hdr != NULL ||
- (!(msg->msg_flags & MSG_DONTWAIT) &&
- atomic_read(&nlk->tx_ring.pending)));
-
- if (len > 0)
- err = len;
-out:
- mutex_unlock(&nlk->pg_vec_lock);
- return err;
-}
-
static void netlink_queue_mmaped_skb(struct sock *sk, struct sk_buff *skb)
{
struct nl_mmap_hdr *hdr;
@@ -842,10 +728,8 @@ static void netlink_ring_set_copied(struct sock *sk, struct sk_buff *skb)
#else /* CONFIG_NETLINK_MMAP */
#define netlink_skb_is_mmaped(skb) false
#define netlink_rx_is_mmaped(sk) false
-#define netlink_tx_is_mmaped(sk) false
#define netlink_mmap sock_no_mmap
#define netlink_poll datagram_poll
-#define netlink_mmap_sendmsg(sk, msg, dst_portid, dst_group, siocb) 0
#endif /* CONFIG_NETLINK_MMAP */
static void netlink_skb_destructor(struct sk_buff *skb)
@@ -864,16 +748,11 @@ static void netlink_skb_destructor(struct sk_buff *skb)
hdr = netlink_mmap_hdr(skb);
sk = NETLINK_CB(skb).sk;
- if (NETLINK_CB(skb).flags & NETLINK_SKB_TX) {
- netlink_set_status(hdr, NL_MMAP_STATUS_UNUSED);
- ring = &nlk_sk(sk)->tx_ring;
- } else {
- if (!(NETLINK_CB(skb).flags & NETLINK_SKB_DELIVERED)) {
- hdr->nm_len = 0;
- netlink_set_status(hdr, NL_MMAP_STATUS_VALID);
- }
- ring = &nlk_sk(sk)->rx_ring;
+ if (!(NETLINK_CB(skb).flags & NETLINK_SKB_DELIVERED)) {
+ hdr->nm_len = 0;
+ netlink_set_status(hdr, NL_MMAP_STATUS_VALID);
}
+ ring = &nlk_sk(sk)->rx_ring;
WARN_ON(atomic_read(&ring->pending) == 0);
atomic_dec(&ring->pending);
@@ -921,10 +800,7 @@ static void netlink_sock_destruct(struct sock *sk)
memset(&req, 0, sizeof(req));
if (nlk->rx_ring.pg_vec)
- netlink_set_ring(sk, &req, true, false);
- memset(&req, 0, sizeof(req));
- if (nlk->tx_ring.pg_vec)
- netlink_set_ring(sk, &req, true, true);
+ netlink_set_ring(sk, &req, true);
}
#endif /* CONFIG_NETLINK_MMAP */
@@ -2165,8 +2041,7 @@ static int netlink_setsockopt(struct socket *sock, int level, int optname,
err = 0;
break;
#ifdef CONFIG_NETLINK_MMAP
- case NETLINK_RX_RING:
- case NETLINK_TX_RING: {
+ case NETLINK_RX_RING: {
struct nl_mmap_req req;
/* Rings might consume more memory than queue limits, require
@@ -2178,8 +2053,7 @@ static int netlink_setsockopt(struct socket *sock, int level, int optname,
return -EINVAL;
if (copy_from_user(&req, optval, sizeof(req)))
return -EFAULT;
- err = netlink_set_ring(sk, &req, false,
- optname == NETLINK_TX_RING);
+ err = netlink_set_ring(sk, &req, false);
break;
}
#endif /* CONFIG_NETLINK_MMAP */
@@ -2295,13 +2169,6 @@ static int netlink_sendmsg(struct kiocb *kiocb, struct socket *sock,
goto out;
}
- if (netlink_tx_is_mmaped(sk) &&
- msg->msg_iov->iov_base == NULL) {
- err = netlink_mmap_sendmsg(sk, msg, dst_portid, dst_group,
- siocb);
- goto out;
- }
-
err = -EMSGSIZE;
if (len > sk->sk_sndbuf - 32)
goto out;
diff --git a/net/netlink/af_netlink.h b/net/netlink/af_netlink.h
index b20a173..4741b88 100644
--- a/net/netlink/af_netlink.h
+++ b/net/netlink/af_netlink.h
@@ -45,7 +45,6 @@ struct netlink_sock {
#ifdef CONFIG_NETLINK_MMAP
struct mutex pg_vec_lock;
struct netlink_ring rx_ring;
- struct netlink_ring tx_ring;
atomic_t mapped;
#endif /* CONFIG_NETLINK_MMAP */
--
1.7.11.7
^ permalink raw reply related
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