* Re: [PATCH net-next] of: mdio: honor flags passed to of_phy_connect
From: David Miller @ 2014-09-16 20:39 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, devicetree
In-Reply-To: <1410889776-11107-1-git-send-email-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Tue, 16 Sep 2014 10:49:36 -0700
> Commit f9a8f83b04e0 ("net: phy: remove flags argument from phy_{attach,
> connect, connect_direct}") removed the flags argument to the PHY library
> calls to: phy_{attach,connect,connect_direct}.
>
> Most Device Tree aware drivers call of_phy_connect() with the flag
> argument set to 0, but some of them might want to set a different value
> there in order for the PHY driver to key a specific behavior based on
> the phy_device::dev_flags value.
>
> Allow such drivers to set custom dev_flags as part of the
> of_phy_connect() call since of_phy_connect() does start the PHY state
> machine, it will call into the PHY driver config_init() callback which
> is usually where a specific phy_flags value is important.
>
> Fixes: f9a8f83b04e0 ("net: phy: remove flags argument from phy_{attach, connect, connect_direct}")
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
I do not see anyone passing non-zero in as the flags argument.
It is difficult for me to determine the impact of this patch,
whether it should really go to 'net' and/or 'stable', etc.
if you don't tell me who this could possibly break.
It's even worse when I do all of the searching around and
cannot find a breakage case myself. :-/
^ permalink raw reply
* Re: [PATCH v2 net-next 0/7] net: foo-over-udp (fou)
From: Tom Herbert @ 2014-09-16 20:35 UTC (permalink / raw)
To: Or Gerlitz; +Cc: David Miller, Linux Netdev List
In-Reply-To: <CAJ3xEMhax-S1KneM-cpRS9r4yi==JwqaGtMYJ127Ka2tynhHMw@mail.gmail.com>
On Tue, Sep 16, 2014 at 1:04 PM, Or Gerlitz <gerlitz.or@gmail.com> wrote:
> On Tue, Sep 16, 2014 at 6:00 PM, Tom Herbert <therbert@google.com> wrote:
>> [...] Fortunately, we'll be able to code
>> around mosts of the limitations of deployed NICs that don't implement
>> generic mechanisms (with UDP RSS, checksum conversions, remote
>> checksum offload) [...]
>
> So UDP RSS is a clear requirement and NICs have it by now.
>
> Re checksum conversions, I assume you mean the ability on the RX path
> to report CHECKSUM_COMPLETE on any sort of IP packet potentially
> having multiple encapsulations, right? how would you phrase (and
> model) the other way around, e.g what is the generic requirement on
> the TX path w.r.t checksum offload?
>
> And I wasn't sure what do you mean by remote checksum offload, can you clarify?
>
This is the part intend to solve TX checksum offload for encapsulation
for "dumb" devices. Unlike, checksum conversion, this one requires a
bit of protocol support so we need an extensible encapsulation header.
http://tools.ietf.org/html/draft-herbert-remotecsumoffload-00
> Or.
^ permalink raw reply
* Re: [PATCH net] sfc: fix addr_list_lock spinlock use before init
From: David Miller @ 2014-09-16 20:33 UTC (permalink / raw)
To: ecree; +Cc: nikolay, netdev, ben, sshah, linux-net-drivers
In-Reply-To: <alpine.LFD.2.03.1409161704180.25290@solarflare.com>
From: Edward Cree <ecree@solarflare.com>
Date: Tue, 16 Sep 2014 17:05:21 +0100
> Reported by Nikolay Aleksandrov. In efx_init_port() we call
> efx_mac_reconfigure() to work around a Falcon/A1 limitation, and this calls
> efx_{arch}_filter_sync_rx_mode(), which takes the addr_list_lock; but this
> lock is uninitialised, because we haven't called register_netdevice() yet.
> So, in efx_farch_filter_sync_rx_mode(), check efx_dev_registered() before
> doing anything else.
> The EF10 equivalent, efx_ef10_filter_sync_rx_mode(), already has the
> corresponding check.
>
> Signed-off-by: Edward Cree <ecree@solarflare.com>
> Tested-by: Nikolay Aleksandrov <nikolay@redhat.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 09/28] Remove ATHEROS_AR231X
From: John W. Linville @ 2014-09-16 20:33 UTC (permalink / raw)
To: Paul Bolle
Cc: Sergey Ryazanov, Jiri Slaby, Nick Kossifidis, Luis R. Rodriguez,
Oleksij Rempel, Richard Weinberger, Jonathan Bither,
Hauke Mehrtens, ath5k-devel, open,
list@hauke-m.de:NETWORKING DRIVERS, antonynpavlov@gmail.com,
OpenWrt Development List, linux-wireless@vger.kernel.org,
list@hauke-m.de:NETWORKING DRIVERS, open list
In-Reply-To: <1410899219.31130.81.camel@x220>
On Tue, Sep 16, 2014 at 10:26:59PM +0200, Paul Bolle wrote:
> On Mon, 2014-09-15 at 14:45 -0400, John W. Linville wrote:
> > FYI -- Sergey posted a series to linux-mips on 14 September 2014 that
> > touches the symbol in question. For whatever reason, it is posted
> > there as RFC.
>
> Thanks for passing that on.
>
> > Does this satisfy the interested parties??
>
> In case I qualify as an interested party: resolving this by, in short,
> making AHB support actually buildable is of course the preferable
> solution.
>
> Whether or not we should drop my patch while waiting for that series to
> land in linux-next is not my call. But if it hasn't landed by, say,
> about the time v3.18-rc3 is released I might raise this issue again.
>
> I must say that I'm a bit puzzled why people have resisted this rather
> small cleanup for years. How did having unbuildable AHB support in
> mainline benefit anyone? Couldn't the revert of this cleanup also be
> handled out of tree? Note that the revert is only "6 files changed, 3
> insertions(+), 294 deletions(-)", while the series is "39 files changed,
> 3911 insertions(+), 10 deletions(-)".
I think it got added with the notion that the code was "coming soon".
As you have tried to remove it, the "coming soon" refrain continued.
I'm still inclined to merge your patch. An RFC series posted to
another mailing list doesn't really change my mind.
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH -net] scsi: fix users of SCSI_FC_ATTRS to depend on NET
From: David Miller @ 2014-09-16 20:31 UTC (permalink / raw)
To: rdunlap; +Cc: netdev, linux-scsi, jbottomley, fengguang.wu
In-Reply-To: <54189C8E.5030409@infradead.org>
From: Randy Dunlap <rdunlap@infradead.org>
Date: Tue, 16 Sep 2014 13:24:46 -0700
> typo: depends on SCSI_FC_ATTRS
>
> No, I certainly have no objection and prefer depends over select anyway.
Ok, then please send me a patch which fixes things that way.
Thanks!
^ permalink raw reply
* Re: [PATCH v2 net-next 0/7] net: foo-over-udp (fou)
From: Tom Herbert @ 2014-09-16 20:31 UTC (permalink / raw)
To: Or Gerlitz; +Cc: Jesse Gross, David Miller, Linux Netdev List
In-Reply-To: <CAJ3xEMghyiuo3TOdsiSBOBBOk21zSfso6fdt-jEqY5ifA2Q1vg@mail.gmail.com>
On Tue, Sep 16, 2014 at 12:14 PM, Or Gerlitz <gerlitz.or@gmail.com> wrote:
> On Tue, Sep 16, 2014 at 9:34 PM, Tom Herbert <therbert@google.com> wrote:
>> On Tue, Sep 16, 2014 at 5:44 AM, Or Gerlitz <gerlitz.or@gmail.com> wrote:
>>> On Tue, Sep 16, 2014 at 1:44 AM, Jesse Gross <jesse@nicira.com> wrote:
>>>> On Mon, Sep 15, 2014 at 12:15 PM, Tom Herbert <therbert@google.com> wrote:
>>>
>>>>> My interpretation is that NETIF_F_GSO_UDP_TUNNEL means L3/L4
>>>>> encapsulation over UDP, not VXLAN.
>>>>> If the NIC implements things properly following the generic interface then I believe it should work
>>>>> with various flavors of UDP encapsulation (FOU, GUE, VXLAN, VXLAN-gpe,
>>>>> geneve, LISP, L2TP, nvgre, or whatever else people might dream up).
>>>>> This presumes that any encapsulation headers doesn't require any per
>>>>> segment update (so no GRE csum for instance). The stack will set up
>>>>> inner headers as needed, which should enough to provide to devices the
>>>>> offsets inner IP and TCP header which are needed for the the TSO
>>>>> operation (outer IP and UDP can be deduced also).
>>>
>>>
>>>
>>>> From the NICs that I am familiar with this is mostly true. The main
>>>> part that is missing from the current implementation is a length
>>>> limit: just because the hardware can skip over headers to an offset
>>>> doesn't mean that it can do so to an arbitrary depth. For example, in
>>>> the NICs that are exposing VXLAN as NETIF_F_GSO_UDP_TUNNEL we can
>>>> probably assume that this is limited to 8 bytes. With the Intel NICs
>>>> that were just announced with Geneve support, this limit has been
>>>> increased to 64. If we add a parameter to the driver interface to
>>>> expose this then it should be generic across tunnels.
>>>
>>> I'm not sure to see why the length limit became our primary concern here...
>
>> Like Jesse mentioned above, looks like some NICs may have assumed all
>> encapsulation headers are eight bytes (which allows HW to implement
>> everything in fixed offsets). But this length is not a universal
>> constant: FOU is zero length encapsulation headers, GUE or geneve is
>> variable. The driver should really be checking if NIC can handle the
>> length and if it can't perform GSO in software-- I don't think we'll
>> need to expose this in the features.
>
> I understand that for some NICs there's a claim saying the essence of
> the limitation lies in an assumption on fixed length of the
> encapsulation headers -- and BTW for VXLAN it's 50 (= 14 + 20 + 8 +
> 8) bytes, not eight. So newer NICs or new brands of existing NICs
> should be more flexible.
>
> If I correctly read your comment "The driver should really be checking
> if NIC can handle the length and if it can't perform GSO in software"
> as saying that a SW GSO call should be made from within the driver
> when they can't serve GSO under some encap scheme -- I don't think
> this is the correct track, the driver should advertize up what they
> can do in HW so the stack does in SW what's not supported.
>
The problem is that it is likely impractical for drivers to advertise
all possible constraints of their HW. Right now we have the features
flags, but that is very limited and we really can't afford to add a
new value for every permutation. There are just to many dimensions.
Some devices might expect fixed length headers, some might not but
might have other length constraints. Some may perfectly happy with
v4/v4 but maybe choke on combinations with IPv6. Others may not mind
IP options or extension headers, some might be okay. Some devices
might not like certain packet layouts, etc.
There is precedent for the driver punting to software mechanisms when
it can't handle something. For instance, cxgb veth call
skb_checksum_help for resolving UDP checksums, myri10ge and marvell
controller call it for headers that are too large. gianfar calls it
per some errata condition...
If we can't do GSO from within the drivers, then another alternative
would be to add an ndo_gso_check function to call when stack is
deciding whether to do SW GSO.
> Another clarification - so FOU doesn't supersedes GUE? what's their
> difference...?
>
FOU is direct encapsulation of IP protocol packets in UDP payload. GUE
is an encapsulation header between UDP and the encapsulated IP
protocol packet. http://tools.ietf.org/html/draft-herbert-gue-01
Tom
> Or.
^ permalink raw reply
* Re: bisected regression: 3c59x corrupts packets in 3.17-rc5
From: David Miller @ 2014-09-16 20:29 UTC (permalink / raw)
To: nhorman; +Cc: mroos, klassert, netdev, linux-kernel
In-Reply-To: <20140916101704.GA3792@hmsreliant.think-freely.org>
From: Neil Horman <nhorman@tuxdriver.com>
Date: Tue, 16 Sep 2014 06:17:04 -0400
> I'm guessing the above change has uncovered another bug,
Neil, read your patch carefully, I think it added the bug.
The ->page_offset of the frag gets applied two times.
skb_dma_map_frag() already takes frag->page_offset into consideration,
you then pass it in as the 'offset' argument and it then gets added to
itself to compute th final offset.
^ permalink raw reply
* Re: [net-next PATCH v2 4/4] net: sched: cls_fw: add missing tcf_exts_init call in fw_change()
From: John Fastabend @ 2014-09-16 20:27 UTC (permalink / raw)
To: David Miller, john.fastabend; +Cc: xiyou.wangcong, eric.dumazet, netdev, jhs
In-Reply-To: <20140916.160020.819013213102038048.davem@davemloft.net>
On 09/16/2014 01:00 PM, David Miller wrote:
> From: John Fastabend <john.fastabend@gmail.com>
> Date: Mon, 15 Sep 2014 23:31:42 -0700
>
>> When allocating a new structure we also need to call tcf_exts_init
>> to initialize exts.
>>
>> A follow up patch might be in order to remove some of this code
>> and do tcf_exts_assign(). With this we could remove the
>> tcf_exts_init/tcf_exts_change pattern for some of the classifiers.
>> As part of the future tcf_actions RCU series this will need to be
>> done. For now fix the call here.
>>
>> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
>
> Applied.
Great thanks. A couple more patches for cls_u32 coming next. I'm
fairly sure I broke the selector keys usage and the change filter
case is not completely RCU safe yet depending on the netlink
attributes.
Thanks!
John
^ permalink raw reply
* Re: [PATCH 09/28] Remove ATHEROS_AR231X
From: Paul Bolle @ 2014-09-16 20:26 UTC (permalink / raw)
To: John W. Linville
Cc: Sergey Ryazanov, Jiri Slaby, Nick Kossifidis, Luis R. Rodriguez,
Oleksij Rempel, Richard Weinberger, Jonathan Bither,
Hauke Mehrtens, ath5k-devel, open,
list@hauke-m.de:NETWORKING DRIVERS, antonynpavlov@gmail.com,
OpenWrt Development List, linux-wireless@vger.kernel.org,
list@hauke-m.de:NETWORKING DRIVERS, open list
In-Reply-To: <20140915184546.GB3891@tuxdriver.com>
On Mon, 2014-09-15 at 14:45 -0400, John W. Linville wrote:
> FYI -- Sergey posted a series to linux-mips on 14 September 2014 that
> touches the symbol in question. For whatever reason, it is posted
> there as RFC.
Thanks for passing that on.
> Does this satisfy the interested parties??
In case I qualify as an interested party: resolving this by, in short,
making AHB support actually buildable is of course the preferable
solution.
Whether or not we should drop my patch while waiting for that series to
land in linux-next is not my call. But if it hasn't landed by, say,
about the time v3.18-rc3 is released I might raise this issue again.
I must say that I'm a bit puzzled why people have resisted this rather
small cleanup for years. How did having unbuildable AHB support in
mainline benefit anyone? Couldn't the revert of this cleanup also be
handled out of tree? Note that the revert is only "6 files changed, 3
insertions(+), 294 deletions(-)", while the series is "39 files changed,
3911 insertions(+), 10 deletions(-)".
Paul Bolle
^ permalink raw reply
* Re: [net-next PATCH] net: sched: cls_cgroup need tcf_exts_init in all cases
From: David Miller @ 2014-09-16 20:26 UTC (permalink / raw)
To: john.fastabend; +Cc: xiyou.wangcong, eric.dumazet, netdev, jhs
In-Reply-To: <20140916073341.2597.36240.stgit@nitbit.x32>
From: John Fastabend <john.fastabend@gmail.com>
Date: Tue, 16 Sep 2014 00:33:42 -0700
> This ensures the tcf_exts_init() is called for all cases.
>
> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
Applied, thanks.
^ permalink raw reply
* Re: [GIT net-next v3] Open vSwitch
From: David Miller @ 2014-09-16 20:25 UTC (permalink / raw)
To: pshelar; +Cc: netdev
In-Reply-To: <1410852209-1456-1-git-send-email-pshelar@nicira.com>
From: Pravin B Shelar <pshelar@nicira.com>
Date: Tue, 16 Sep 2014 00:23:29 -0700
> Following patches adds recirculation and hash action to OVS.
> First patch removes pointer to stack object. Next three patches
> does code restructuring which is required for last patch.
> Recirculation implementation is changed, according to comments from
> David Miller, to avoid using recursive calls in OVS. It is using
> queue to record recirc action and deferred recirc is executed at
> the end of current actions execution.
>
> v1-v2:
> Changed subsystem name in subject to openvswitch
> v2-v3:
> Added patch to remove pkt_key pointer from skb->cb.
Pulled, thanks Pravin.
^ permalink raw reply
* Re: [PATCH -net] scsi: fix users of SCSI_FC_ATTRS to depend on NET
From: Randy Dunlap @ 2014-09-16 20:24 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-scsi, jbottomley, fengguang.wu
In-Reply-To: <20140916.161518.620276378147910368.davem@davemloft.net>
On 09/16/14 13:15, David Miller wrote:
> From: Randy Dunlap <rdunlap@infradead.org>
> Date: Mon, 15 Sep 2014 23:35:21 -0700
>
>> From: Randy Dunlap <rdunlap@infradead.org>
>>
>> There are other kconfig symbols which select SCSI_FC_ATTRS,
>> so they also need to depend on NET to fix kconfig warnings and
>> build errors:
>>
>> warning: (LIBFC && SCSI_IBMVFC && SCSI_QLA_FC && SCSI_LPFC && ZFCP && SCSI_BFA_FC && SCSI_CHELSIO_FCOE && FUSION_FC) selects SCSI_FC_ATTRS which has unmet direct dependencies (SCSI && NET)
>> drivers/scsi/scsi_transport_fc.c: In function 'fc_host_post_event':
>> drivers/scsi/scsi_transport_fc.c:543:7: error: 'scsi_nl_sock' undeclared (first use in this function)
>> drivers/scsi/scsi_transport_fc.c: In function 'fc_host_post_vendor_event':
>> drivers/scsi/scsi_transport_fc.c:611:7: error: 'scsi_nl_sock' undeclared (first use in this function)
>>
>> Reported-by: Fengguang Wu <fengguang.wu@intel.com> [0-day test robot]
>> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
>
> Randy, this is starting to get convoluted.
Yes, I'm not happy about it either.
> It's pretty much pointless for SCSI_FC_ATTRS to depend on NET itself
> if we have to explicitly place a NET dependency on every single user
> of SCSI_FC_ATTRS.
>
> We have expressed a proper dependency for SCSI_FC_ATTRS only to have
> it forcefully bypassed by every single user because we 'select' it
> instead of using 'depends'.
>
> Can we just change these 'select' operations on SCSI_FC_ATTRS to just
> be 'depends' instead?
>
> I really wouldn't mind if select had the effect of force enabling the
> dependencies of the select'd Kconfig symbol. Then it really does what
> we use it for (keeping the user from having to know obscure
> dependencies just to enable the feature they want) without the ugly
> side effect of dependency bypassing.
>
> So a "select" would do a recursive "select" on all the dependencies
> needed to turn on the select'd object.
>
> I doubt it would even need to recurse often at all, the ways we use
> this is almost always to turn on some top level major piece of
> infrastructure.
>
> Anyways, that's a longer term thing and we need to fix this now, any
> opinions on just using 'depend SCSI_FX_ATTRS' to fix this?
typo: depends on SCSI_FC_ATTRS
No, I certainly have no objection and prefer depends over select anyway.
--
~Randy
^ permalink raw reply
* Re: [PATCH v2 net-next 0/7] net: foo-over-udp (fou)
From: David Miller @ 2014-09-16 20:16 UTC (permalink / raw)
To: gerlitz.or; +Cc: therbert, netdev
In-Reply-To: <CAJ3xEMhax-S1KneM-cpRS9r4yi==JwqaGtMYJ127Ka2tynhHMw@mail.gmail.com>
From: Or Gerlitz <gerlitz.or@gmail.com>
Date: Tue, 16 Sep 2014 23:04:30 +0300
> And I wasn't sure what do you mean by remote checksum offload, can
> you clarify?
http://vger.kernel.org/encapsulation_offloads.pdf
Page 14.
^ permalink raw reply
* Re: [PATCH -net] scsi: fix users of SCSI_FC_ATTRS to depend on NET
From: David Miller @ 2014-09-16 20:15 UTC (permalink / raw)
To: rdunlap; +Cc: netdev, linux-scsi, jbottomley, fengguang.wu
In-Reply-To: <5417DA29.4060205@infradead.org>
From: Randy Dunlap <rdunlap@infradead.org>
Date: Mon, 15 Sep 2014 23:35:21 -0700
> From: Randy Dunlap <rdunlap@infradead.org>
>
> There are other kconfig symbols which select SCSI_FC_ATTRS,
> so they also need to depend on NET to fix kconfig warnings and
> build errors:
>
> warning: (LIBFC && SCSI_IBMVFC && SCSI_QLA_FC && SCSI_LPFC && ZFCP && SCSI_BFA_FC && SCSI_CHELSIO_FCOE && FUSION_FC) selects SCSI_FC_ATTRS which has unmet direct dependencies (SCSI && NET)
> drivers/scsi/scsi_transport_fc.c: In function 'fc_host_post_event':
> drivers/scsi/scsi_transport_fc.c:543:7: error: 'scsi_nl_sock' undeclared (first use in this function)
> drivers/scsi/scsi_transport_fc.c: In function 'fc_host_post_vendor_event':
> drivers/scsi/scsi_transport_fc.c:611:7: error: 'scsi_nl_sock' undeclared (first use in this function)
>
> Reported-by: Fengguang Wu <fengguang.wu@intel.com> [0-day test robot]
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Randy, this is starting to get convoluted.
It's pretty much pointless for SCSI_FC_ATTRS to depend on NET itself
if we have to explicitly place a NET dependency on every single user
of SCSI_FC_ATTRS.
We have expressed a proper dependency for SCSI_FC_ATTRS only to have
it forcefully bypassed by every single user because we 'select' it
instead of using 'depends'.
Can we just change these 'select' operations on SCSI_FC_ATTRS to just
be 'depends' instead?
I really wouldn't mind if select had the effect of force enabling the
dependencies of the select'd Kconfig symbol. Then it really does what
we use it for (keeping the user from having to know obscure
dependencies just to enable the feature they want) without the ugly
side effect of dependency bypassing.
So a "select" would do a recursive "select" on all the dependencies
needed to turn on the select'd object.
I doubt it would even need to recurse often at all, the ways we use
this is almost always to turn on some top level major piece of
infrastructure.
Anyways, that's a longer term thing and we need to fix this now, any
opinions on just using 'depend SCSI_FX_ATTRS' to fix this?
^ permalink raw reply
* Re: [PATCH v2 net-next 0/7] net: foo-over-udp (fou)
From: Or Gerlitz @ 2014-09-16 20:04 UTC (permalink / raw)
To: Tom Herbert; +Cc: David Miller, Linux Netdev List
In-Reply-To: <CA+mtBx9d4wkcfmbPXm8m-Uz8K=_hjb3Q_a-0YNY4Yhz4cYoD5Q@mail.gmail.com>
On Tue, Sep 16, 2014 at 6:00 PM, Tom Herbert <therbert@google.com> wrote:
> [...] Fortunately, we'll be able to code
> around mosts of the limitations of deployed NICs that don't implement
> generic mechanisms (with UDP RSS, checksum conversions, remote
> checksum offload) [...]
So UDP RSS is a clear requirement and NICs have it by now.
Re checksum conversions, I assume you mean the ability on the RX path
to report CHECKSUM_COMPLETE on any sort of IP packet potentially
having multiple encapsulations, right? how would you phrase (and
model) the other way around, e.g what is the generic requirement on
the TX path w.r.t checksum offload?
And I wasn't sure what do you mean by remote checksum offload, can you clarify?
Or.
^ permalink raw reply
* Re: [net-next PATCH v2 4/4] net: sched: cls_fw: add missing tcf_exts_init call in fw_change()
From: David Miller @ 2014-09-16 20:00 UTC (permalink / raw)
To: john.fastabend; +Cc: xiyou.wangcong, eric.dumazet, netdev, jhs
In-Reply-To: <20140916063141.2905.59421.stgit@nitbit.x32>
From: John Fastabend <john.fastabend@gmail.com>
Date: Mon, 15 Sep 2014 23:31:42 -0700
> When allocating a new structure we also need to call tcf_exts_init
> to initialize exts.
>
> A follow up patch might be in order to remove some of this code
> and do tcf_exts_assign(). With this we could remove the
> tcf_exts_init/tcf_exts_change pattern for some of the classifiers.
> As part of the future tcf_actions RCU series this will need to be
> done. For now fix the call here.
>
> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next PATCH v2 3/4] net: sched: cls_cgroup fix possible memory leak of 'new'
From: David Miller @ 2014-09-16 20:00 UTC (permalink / raw)
To: john.fastabend; +Cc: xiyou.wangcong, eric.dumazet, netdev, jhs
In-Reply-To: <20140916063115.2905.53827.stgit@nitbit.x32>
From: John Fastabend <john.fastabend@gmail.com>
Date: Mon, 15 Sep 2014 23:31:17 -0700
> tree: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git master
> head: 54996b529ab70ca1d6f40677cd2698c4f7127e87
> commit: c7953ef23042b7c4fc2be5ecdd216aacff6df5eb [625/646] net: sched: cls_cgroup use RCU
>
> net/sched/cls_cgroup.c:130 cls_cgroup_change() warn: possible memory leak of 'new'
> net/sched/cls_cgroup.c:135 cls_cgroup_change() warn: possible memory leak of 'new'
> net/sched/cls_cgroup.c:139 cls_cgroup_change() warn: possible memory leak of 'new'
>
> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next PATCH v2 2/4] net: sched: cls_u32 add missing rcu_assign_pointer and annotation
From: David Miller @ 2014-09-16 20:00 UTC (permalink / raw)
To: john.fastabend; +Cc: xiyou.wangcong, eric.dumazet, netdev, jhs
In-Reply-To: <20140916063048.2905.92612.stgit@nitbit.x32>
From: John Fastabend <john.fastabend@gmail.com>
Date: Mon, 15 Sep 2014 23:30:49 -0700
> Add missing rcu_assign_pointer and missing annotation for ht_up
> in cls_u32.c
>
> Caught by kbuild bot,
...
> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2] net: rfkill: gpio: Enable module auto-loading for ACPI based switches
From: John W. Linville @ 2014-09-16 19:59 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Johannes Berg, linux-wireless, netdev
In-Reply-To: <1410551368-37316-1-git-send-email-marcel@holtmann.org>
I'm merging this to the wireless tree...
On Fri, Sep 12, 2014 at 09:49:28PM +0200, Marcel Holtmann wrote:
> For the ACPI based switches the MODULE_DEVICE_TABLE is missing to
> export the entries for module auto-loading.
>
> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
> ---
> net/rfkill/rfkill-gpio.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/net/rfkill/rfkill-gpio.c b/net/rfkill/rfkill-gpio.c
> index 02a86a27fd84..5fa54dd78e25 100644
> --- a/net/rfkill/rfkill-gpio.c
> +++ b/net/rfkill/rfkill-gpio.c
> @@ -163,6 +163,7 @@ static const struct acpi_device_id rfkill_acpi_match[] = {
> { "LNV4752", RFKILL_TYPE_GPS },
> { },
> };
> +MODULE_DEVICE_TABLE(acpi, rfkill_acpi_match);
> #endif
>
> static struct platform_driver rfkill_gpio_driver = {
> --
> 1.9.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [net-next PATCH v2 1/4] net: sched: fix unsued cpu variable
From: David Miller @ 2014-09-16 20:00 UTC (permalink / raw)
To: john.fastabend; +Cc: xiyou.wangcong, eric.dumazet, netdev, jhs
In-Reply-To: <20140916063024.2905.55403.stgit@nitbit.x32>
From: John Fastabend <john.fastabend@gmail.com>
Date: Mon, 15 Sep 2014 23:30:26 -0700
> kbuild test robot reported an unused variable cpu in cls_u32.c
> after the patch below. This happens when PERF and MARK config
> variables are disabled
>
> Fix this is to use separate variables for perf and mark
> and define the cpu variable inside the ifdef logic.
>
> 'commit 459d5f626da7 ("net: sched: make cls_u32 per cpu")'
>
> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] r8169: adjust __rtl8169_set_features
From: David Miller @ 2014-09-16 19:56 UTC (permalink / raw)
To: hayeswang; +Cc: netdev, nic_swsd, linux-kernel, romieu
In-Reply-To: <1394712342-15778-42-Taiwan-albertk@realtek.com>
From: Hayes Wang <hayeswang@realtek.com>
Date: Tue, 16 Sep 2014 11:40:47 +0800
> Remove the "changed" test in __rtl8169_set_features(). Instead, do
> simple test in rtl8169_set_features().
>
> Set the RxChkSum and RxVlan through __rtl8169_set_features() in
> rtl_open().
>
> Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
> Signed-off-by: Hayes Wang <hayeswang@realtek.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCHv2] ipv4: Do not cache routing failures due to disabled forwarding.
From: Nicolas Cavallari @ 2014-09-16 19:52 UTC (permalink / raw)
To: David Miller; +Cc: netdev, kuznet, jmorris, yoshfuji, kaber
In-Reply-To: <20140916.145435.714034191389495557.davem@davemloft.net>
On 16/09/2014 20:54, David Miller wrote:
> From: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
> Date: Mon, 15 Sep 2014 12:28:13 +0200
>
>> If we cache them, the kernel will reuse them, independently of
>> whether forwarding is enabled or not. Which means that if forwarding is
>> disabled on the input interface where the first routing request comes
>> from, then that unreachable result will be cached and reused for
>> other interfaces, even if forwarding is enabled on them.
>>
>> This can be verified with two interfaces A and B and an output interface
>> C, where B has forwarding enabled, but not A and trying
>> ip route get $dst iif A from $src && ip route get $dst iif B from $src
>>
>> Signed-off-by: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
>> ---
>> v2: simplify patch using julian anastasov's suggestion.
>
> This also disables caching for the cases of a simple fib lookup failure.
Caching is already not done on a fib lookup failure. On which fib_info
would you cache anyway ? res.fi is already NULL in this case.
> Handle cached route invalidation the way it's meant to be, by bumping
> the rt_genid.
>
> diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
> index 214882e..aa4e63c 100644
> --- a/net/ipv4/devinet.c
> +++ b/net/ipv4/devinet.c
> @@ -1965,6 +1965,8 @@ static void inet_forward_change(struct net *net)
> }
> rcu_read_unlock();
> }
> +
> + rt_cache_flush(net);
> }
>
> static int devinet_conf_ifindex(struct net *net, struct ipv4_devconf *cnf)
This doesn't solve the problem. Flushing the cache only changes how the
bug manifests:
ip route flush cache
ip route get 10.0.0.1 from 10.0.0.2 iif A
# unreachable (because forwarding on A is disabled). This is cached.
ip route get 10.0.0.1 from 10.0.0.2 iif B
# unreachable (at first fib_lookup finds it reachable and forwarding on
B is enabled. And then there is a valid cache entry, which is reused
blindly even if it says "unreachable").
ip route flush cache
ip route get 10.0.0.1 from 10.0.0.2 iif B
# reachable (because forwarding on B is enabled). This is cached
ip route get 10.0.0.1 from 10.0.0.2 iif A
# reachable (forwarding on A is disabled, so it is unreachable
initially. But there is a valid cache entry, which says "reachable",
which is reused)
^ permalink raw reply
* Re: [PATCH v3 net-next 2/7] fou: Support for foo-over-udp RX path
From: David Miller @ 2014-09-16 19:42 UTC (permalink / raw)
To: therbert; +Cc: netdev
In-Reply-To: <1410838224-19777-3-git-send-email-therbert@google.com>
From: Tom Herbert <therbert@google.com>
Date: Mon, 15 Sep 2014 20:30:19 -0700
> +static inline struct fou *fou_from_sock(struct sock *sk)
> +{
> + return (struct fou *)sk->sk_user_data;
> +}
Void pointers never need explicit casts, please remove it.
> +static int fou_create(struct net *net, struct fou_cfg *cfg,
> + struct socket **sockp)
> +{
...
> + /* Mark socket as an encapsulation socket. See net/ipv4/udp.c */
> + fou->protocol = cfg->protocol;
> + fou->port = cfg->udp_config.local_udp_port;
Hmmm...
> + u16 port = htons(cfg->udp_config.local_udp_port);
> + int err = -EINVAL;
> +
> + spin_lock(&fou_lock);
> + list_for_each_entry(fou, &fou_list, list) {
Why different endianness for create and destroy? Please make both
operations use the same endianness for the port.
> + if (fou->port == port) {
^ permalink raw reply
* [Patch net-next 1/1] net: fec: fix build error at m68k platform
From: Frank.Li @ 2014-09-16 18:34 UTC (permalink / raw)
To: b38611, davem, netdev, lznuaa; +Cc: shawn.guo, linux-arm-kernel, Frank Li
From: Frank Li <Frank.Li@freescale.com>
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 4d494cdc92b3b9a0f5fb9e1560810fa27d5a0489
make.cross ARCH=m68k m5272c3_defconfig
make.cross ARCH=m68k
drivers/net/ethernet/freescale/fec.h:262:0: warning: "FEC_R_DES_START" redefined
#define FEC_R_DES_START(X) ((X == 1) ? FEC_R_DES_START_1 : \
^
drivers/net/ethernet/freescale/fec.h:158:0: note: this is the location of the previous definition
#define FEC_R_DES_START 0x3d0 /* Receive descriptor ring */
^
drivers/net/ethernet/freescale/fec.h:265:0: warning: "FEC_X_DES_START" redefined
#define FEC_X_DES_START(X) ((X == 1) ? FEC_X_DES_START_1 : \
...
Signed-off-by: Frank Li <Frank.Li@freescale.com>
---
This patch based on previous interrupt coalescence patches
drivers/net/ethernet/freescale/fec.h | 30 +++++++++++++++++++++++++-----
1 file changed, 25 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec.h b/drivers/net/ethernet/freescale/fec.h
index 2814610..de86d61 100644
--- a/drivers/net/ethernet/freescale/fec.h
+++ b/drivers/net/ethernet/freescale/fec.h
@@ -140,8 +140,12 @@
#define FEC_IEVENT 0x004 /* Interrupt even reg */
#define FEC_IMASK 0x008 /* Interrupt mask reg */
#define FEC_IVEC 0x00c /* Interrupt vec status reg */
-#define FEC_R_DES_ACTIVE 0x010 /* Receive descriptor reg */
-#define FEC_X_DES_ACTIVE 0x014 /* Transmit descriptor reg */
+#define FEC_R_DES_ACTIVE_0 0x010 /* Receive descriptor reg */
+#define FEC_R_DES_ACTIVE_1 FEC_R_DES_ACTIVE_0
+#define FEC_R_DES_ACTIVE_2 FEC_R_DES_ACTIVE_0
+#define FEC_X_DES_ACTIVE_0 0x014 /* Transmit descriptor reg */
+#define FEC_X_DES_ACTIVE_1 FEC_X_DES_ACTIVE_0
+#define FEC_X_DES_ACTIVE_2 FEC_X_DES_ACTIVE_0
#define FEC_MII_DATA 0x040 /* MII manage frame reg */
#define FEC_MII_SPEED 0x044 /* MII speed control reg */
#define FEC_R_BOUND 0x08c /* FIFO receive bound reg */
@@ -155,11 +159,27 @@
#define FEC_ADDR_HIGH 0x3c4 /* High 16bits MAC address */
#define FEC_GRP_HASH_TABLE_HIGH 0x3c8 /* High 32bits hash table */
#define FEC_GRP_HASH_TABLE_LOW 0x3cc /* Low 32bits hash table */
-#define FEC_R_DES_START 0x3d0 /* Receive descriptor ring */
-#define FEC_X_DES_START 0x3d4 /* Transmit descriptor ring */
+#define FEC_R_DES_START_0 0x3d0 /* Receive descriptor ring */
+#define FEC_R_DES_START_1 FEC_R_DES_START_0
+#define FEC_R_DES_START_2 FEC_R_DES_START_0
+#define FEC_X_DES_START_0 0x3d4 /* Transmit descriptor ring */
+#define FEC_X_DES_START_1 FEC_X_DES_START_0
+#define FEC_X_DES_START_2 FEC_X_DES_START_0
#define FEC_R_BUFF_SIZE 0x3d8 /* Maximum receive buff size */
#define FEC_FIFO_RAM 0x400 /* FIFO RAM buffer */
-
+/* Not existed in real chip
+ * Just for pass build.
+ */
+#define FEC_RCMR_1 0xFFF
+#define FEC_RCMR_2 0xFFF
+#define FEC_DMA_CFG_1 0xFFF
+#define FEC_DMA_CFG_2 0xFFF
+#define FEC_TXIC0 0xFFF
+#define FEC_TXIC1 0xFFF
+#define FEC_TXIC2 0xFFF
+#define FEC_RXIC0 0xFFF
+#define FEC_RXIC1 0xFFF
+#define FEC_RXIC2 0xFFF
#endif /* CONFIG_M5272 */
--
1.9.1
^ permalink raw reply related
* [PATCH net-next] sparc: bpf_jit: add SKF_AD_PKTTYPE support to JIT
From: Alexei Starovoitov @ 2014-09-16 19:35 UTC (permalink / raw)
To: David S. Miller; +Cc: Daniel Borkmann, Hannes Frederic Sowa, netdev
commit 233577a22089 ("net: filter: constify detection of pkt_type_offset")
allows us to implement simple PKTTYPE support in sparc JIT
Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
---
arch/sparc/net/bpf_jit_comp.c | 9 ++-------
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/arch/sparc/net/bpf_jit_comp.c b/arch/sparc/net/bpf_jit_comp.c
index b2ad9dc5425e..2dde48bdcc42 100644
--- a/arch/sparc/net/bpf_jit_comp.c
+++ b/arch/sparc/net/bpf_jit_comp.c
@@ -579,16 +579,11 @@ void bpf_jit_compile(struct bpf_prog *fp)
case BPF_ANC | SKF_AD_PROTOCOL:
emit_skb_load16(protocol, r_A);
break;
-#if 0
- /* GCC won't let us take the address of
- * a bit field even though we very much
- * know what we are doing here.
- */
case BPF_ANC | SKF_AD_PKTTYPE:
- __emit_skb_load8(pkt_type, r_A);
+ __emit_skb_load8(__pkt_type_offset, r_A);
+ emit_andi(r_A, PKT_TYPE_MAX, r_A);
emit_alu_K(SRL, 5);
break;
-#endif
case BPF_ANC | SKF_AD_IFINDEX:
emit_skb_loadptr(dev, r_A);
emit_cmpi(r_A, 0);
--
1.7.9.5
^ 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