* Re: [patch net-next v2 00/15] net: introduce upper device lists and remove dev->master
From: Andy Gospodarek @ 2012-08-14 20:19 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
edumazet-hpIqsD4AKlfQT0dZR+AlfA,
faisal.latif-ral2JQCrhuEAvxtiuMwx3w,
roland-DgEjT+Ai2ygdnm+yROfE0A, sean.hefty-ral2JQCrhuEAvxtiuMwx3w,
hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w,
fubar-r/Jw6+rmf7HQT0dZR+AlfA, andy-QlMahl40kYEqcZcGjlUOXw,
divy-ut6Up61K2wZBDgjK7y7TUQ,
jitendra.kalsaria-h88ZbnxC6KDQT0dZR+AlfA,
sony.chacko-h88ZbnxC6KDQT0dZR+AlfA,
linux-driver-h88ZbnxC6KDQT0dZR+AlfA, kaber-dcUjhNyLwpNeoWH0uzbU5w,
ursula.braun-tA70FqPdS9bQT0dZR+AlfA,
blaschka-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
linux390-tA70FqPdS9bQT0dZR+AlfA,
shemminger-ZtmgI6mnKB3QT0dZR+AlfA,
bhutchings-s/n/eUQHGBpZroRs9YW3xA,
therbert-hpIqsD4AKlfQT0dZR+AlfA,
xiyou.wangcong-Re5JQEeQqe8AvxtiuMwx3w, joe-6d6DIl74uiNBDgjK7y7TUQ,
gregory.v.rose-ral2JQCrhuEAvxtiuMwx3w,
john.r.fastabend-ral2JQCrhuEAvxtiuMwx3w,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-s390-u79uwXL29TY76Z2rM5mHXA,
bridge-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
fbl-H+wXaHxf7aLQT0dZR+AlfA
In-Reply-To: <1344956748-2099-1-git-send-email-jiri-rHqAuBHg3fBzbRFIqnYvSA@public.gmane.org>
On Tue, Aug 14, 2012 at 05:05:33PM +0200, Jiri Pirko wrote:
> Hi all.
>
> Recent discussion around
> "[net-next] bonding: don't allow the master to become its slave"
> forced me to think about upper<->lower device connections.
>
> This patchset adds a possibility to record upper device linkage.
> All upper<->lower devices are converted to use this mechanism right after.
> That leads to dev->master removal because this info becomes redundant since
> "unique links" have the same value.
>
> After all changes, there is no longer possible to do:
> "bond->someotherdevice->samebond"
>
> Also I think that drivers like cxgb3, qlcnic, qeth would benefit by this
> in future by being able to get more appropriate info about l3 addresses.
>
> v1->v2:
> - s/unique/master/ better naming + stays closer to the history
> - fixed vlan err goto
> - original patch 15 (WARN_ON change) is squashed into the first patch
> - fixed netdev_unique_upper_dev_get_rcu() case of upper==NULL
I just started to review v1 when v2 came out, but luckily the changes
were not too significant that I need to start all over.
The first note is that I didn't like the use of the term 'upper' -- it
seems like 'stacked' might be a better alternative as these are stacked
devices.
One thing to note is that I don't see any clear changelog that states
the current goals for this. You have stated in several places that it
will no longer be possible to create bonds of bonds, but there are
probably a few more things it might be wise to intentionally outlaw.
What about teams of teams? Or teams of bonds? Or bonds of teams?
Bonds of vlans?
>
> Jiri Pirko (15):
> net: introduce upper device lists
> macvlan: add link to upper device
> vlan: add link to upper device
> rtnetlink: remove usage of dev->master
> team: remove usage of netdev_set_master()
> bridge: remove usage of netdev_set_master()
> netpoll: remove usage of dev->master
> cxgb3: remove usage of dev->master
> qlcnic: guard __vlan_find_dev_deep() by rcu_read_lock
> qeth: ensure that __vlan_find_dev_deep() is called with rcu_read_lock
> vlan: remove usage of dev->master in __vlan_find_dev_deep()
> nes: remove usage of dev->master
> bonding: remove usage of dev->master
> net: remove no longer used netdev_set_bond_master() and
> netdev_set_master()
> net: kill dev->master
>
> drivers/infiniband/hw/nes/nes.c | 8 +-
> drivers/infiniband/hw/nes/nes_cm.c | 2 +-
> drivers/net/bonding/bond_3ad.c | 30 +--
> drivers/net/bonding/bond_alb.c | 6 +-
> drivers/net/bonding/bond_main.c | 94 ++++----
> drivers/net/bonding/bonding.h | 14 +-
> drivers/net/ethernet/chelsio/cxgb3/cxgb3_offload.c | 11 +-
> drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c | 2 +
> drivers/net/macvlan.c | 9 +-
> drivers/net/team/team.c | 13 +-
> drivers/s390/net/qeth_l3_main.c | 21 +-
> include/linux/netdevice.h | 22 +-
> net/8021q/vlan.c | 10 +-
> net/8021q/vlan_core.c | 18 +-
> net/bridge/br_if.c | 6 +-
> net/core/dev.c | 239 +++++++++++++++++---
> net/core/netpoll.c | 8 +-
> net/core/rtnetlink.c | 45 ++--
> 18 files changed, 391 insertions(+), 167 deletions(-)
>
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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 net-next v2 00/15] net: introduce upper device lists and remove dev->master
From: Ben Hutchings @ 2012-08-14 20:32 UTC (permalink / raw)
To: Andy Gospodarek
Cc: bridge, ursula.braun, john.r.fastabend, edumazet, shemminger,
sean.hefty, therbert, roland, linux-s390, linux-rdma, fubar, fbl,
hal.rosenstock, Jiri Pirko, faisal.latif, blaschka, sony.chacko,
linux-driver, xiyou.wangcong, jitendra.kalsaria, divy,
gregory.v.rose, netdev, linux-kernel, kaber, joe, linux390, davem
In-Reply-To: <20120814201950.GA17781@quad.redhat.com>
On Tue, 2012-08-14 at 16:19 -0400, Andy Gospodarek wrote:
> On Tue, Aug 14, 2012 at 05:05:33PM +0200, Jiri Pirko wrote:
> > Hi all.
> >
> > Recent discussion around
> > "[net-next] bonding: don't allow the master to become its slave"
> > forced me to think about upper<->lower device connections.
> >
> > This patchset adds a possibility to record upper device linkage.
> > All upper<->lower devices are converted to use this mechanism right after.
> > That leads to dev->master removal because this info becomes redundant since
> > "unique links" have the same value.
> >
> > After all changes, there is no longer possible to do:
> > "bond->someotherdevice->samebond"
> >
> > Also I think that drivers like cxgb3, qlcnic, qeth would benefit by this
> > in future by being able to get more appropriate info about l3 addresses.
> >
> > v1->v2:
> > - s/unique/master/ better naming + stays closer to the history
> > - fixed vlan err goto
> > - original patch 15 (WARN_ON change) is squashed into the first patch
> > - fixed netdev_unique_upper_dev_get_rcu() case of upper==NULL
> I just started to review v1 when v2 came out, but luckily the changes
> were not too significant that I need to start all over.
>
> The first note is that I didn't like the use of the term 'upper' -- it
> seems like 'stacked' might be a better alternative as these are stacked
> devices.
When linking any two devices in a stack, one will be upper and the other
lower. The lower device might itself be stacked on top of a further
device, so 'stacked' is not a useful distinguishing adjective in
variable names. It might be a useful term in the commit messages and
kernel-doc, though.
> One thing to note is that I don't see any clear changelog that states
> the current goals for this. You have stated in several places that it
> will no longer be possible to create bonds of bonds, but there are
> probably a few more things it might be wise to intentionally outlaw.
>
> What about teams of teams? Or teams of bonds? Or bonds of teams?
> Bonds of vlans?
[...]
It doesn't disallow bonds of bonds (unless I'm missing something). It
disallows loops that involve any or all of those types of stacked
devices.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: Do I need to skb_put() Ethernet frames to a minimum of 60 bytes?
From: Ben Hutchings @ 2012-08-14 20:35 UTC (permalink / raw)
To: Arvid Brodin; +Cc: netdev@vger.kernel.org, Nicolas Ferre
In-Reply-To: <502A9EC4.4040208@xdin.com>
On Tue, 2012-08-14 at 18:53 +0000, Arvid Brodin wrote:
> Hi,
>
> If I create an sk_buff with a payload of less than 28 bytes (ethheader + data),
> and send it using the cadence/macb (Ethernet) driver, I get
>
> eth0: TX underrun, resetting buffers
>
> Now I know the minimum Ethernet frame size is 64 bytes (including the 4-byte
> FCS), but whose responsibility is it to pad the frame to this size if necessary?
> Mine or the driver's - i.e. should I just skb_put() to the minimum size or
> should I report the underrun as a driver bug?
If the hardware doesn't pad frames automatically then it's the driver's
reponsibility to do so.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH 0/5] Call netif_carrier_off() after register_netdev()
From: David Miller @ 2012-08-14 21:00 UTC (permalink / raw)
To: shchepetkov; +Cc: netdev, linux-kernel, ldv-project
In-Reply-To: <1344940135-17079-1-git-send-email-shchepetkov@ispras.ru>
From: Ilya Shchepetkov <shchepetkov@ispras.ru>
Date: Tue, 14 Aug 2012 14:28:50 +0400
> Hi,
>
> There are several patches on the subject:
>
> 31bde1ceaa873bcaecd49e829bfabceacc4c512d
> c55ad8e56b983f03589b38b4504b5d1f41161ff8
> e826eafa65c6f1f7c8db5a237556cebac57ebcc5
> 0d672e9f8ac320c6d1ea9103db6df7f99ea20361
> 6a3c869a6021f4abcd69aa5fbb15c63f69eb36fe
>
> In 2008, David Miller wrote in his commit:
> (b47300168e770b60ab96c8924854c3b0eb4260eb)
>
>>net: Do not fire linkwatch events until the device is registered.
>
>>Several device drivers try to do things like netif_carrier_off()
>>before register_netdev() is invoked. This is bogus, but too many
>>drivers do this to fix them all up in one go.
>
> But I don't understand what will happen in this case?
Sigh... I would strongly suggest that when you don't understand
something you leave it alone until you do.
You can't do the netif_carrier_off() after the device register because
at the precise moment the device is registered it can be openned in
parallel on another cpu and thus cause the entire carrier state
to be changed.
Therefore if you do the netif_carrier_off() afterwards, it might
be overwriting state changes made in another context.
Please just leave this code alone.
^ permalink raw reply
* Re: [PATCH v3 6/6] cgroup: Assign subsystem IDs during compile time
From: Daniel Wagner @ 2012-08-14 21:01 UTC (permalink / raw)
To: Tejun Heo
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, cgroups-u79uwXL29TY76Z2rM5mHXA,
Daniel Wagner, David S. Miller, Andrew Morton, Eric Dumazet,
Gao feng, Glauber Costa, Jamal Hadi Salim, John Fastabend,
Kamezawa Hiroyuki, Li Zefan, Neil Horman
In-Reply-To: <20120814172749.GL25632-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Hi Tejun,
On 08/14/2012 07:27 PM, Tejun Heo wrote:
> On Tue, Aug 14, 2012 at 03:02:23PM +0200, Daniel Wagner wrote:
>> From: Daniel Wagner <daniel.wagner-98C5kh4wR6ohFhg+JK9F0w@public.gmane.org>
>>
>> We are able to safe some space when we assign the subsystem
>> IDs at compile time. Instead of allocating per cgroup
>> cgroup->subsys[CGROUP_SUBSYS_COUNT] where CGROUP_SUBSYS_COUNT is
>> always 64, we allocate 12 + 1 at max (at this point there are 12
>> subsystem). The additinal one is the price we have to pay to
>> distinguish between builtin and module subsystems.
>>
>> We should only access task_cls_classid() and task_netprioidx()
>> if the subsystem is ready to be used using jump labels for this.
>
> I think I want to like this patch but it's kinda confusing to review.
> Is there any reasonable way that you can split the core changes from
> net_cls ones?
My bad, sorry about that. Sure, I'll split the patches into smaller
pieces and remove net_cls updating part as Neil has requested. You will
get someting to review on Thursday, since tomorrow I am out of office.
thanks,
daniel
^ permalink raw reply
* Re: [PATCH] netdev/phy: skip disabled mdio-mux nodes
From: David Miller @ 2012-08-14 21:07 UTC (permalink / raw)
To: B04825; +Cc: david.daney, netdev
In-Reply-To: <CAOZdJXUB7jLZ_p3TmOs+p=jQM4Xs0a=HUdFia5N46M--LYyXJg@mail.gmail.com>
From: Tabi Timur-B04825 <B04825@freescale.com>
Date: Tue, 14 Aug 2012 19:19:58 +0000
> On Tue, Aug 7, 2012 at 11:51 AM, Timur Tabi <timur@freescale.com> wrote:
>> The mdio-mux driver scans all child mdio nodes, without regard to whether
>> the node is actually used. Some device trees include all possible
>> mdio-mux nodes and rely on the boot loader to disable those that are not
>> present, based on some run-time configuration. Those nodes need to be
>> skipped.
>>
>> Signed-off-by: Timur Tabi <timur@freescale.com>
>> ---
>
> Any chance this patch can get into 3.6? I don't know if it qualifies
> as a fix or not, but getting it into 3.6 would make it easier for me
> to apply other patches to the powerpc tree.
>
I want you to implement it the way David Daney said to do so.
And you never need to ask me questions like this, I clearly mark the
state of your patch:
http://patchwork.ozlabs.org/patch/175750/
So that you can just monitor it instead of wasting my time asking what
is happening to your patch.
Time of mine you consume forcing me to reply to you in situations like
this, which you could handle on your own, is time that I can't spend
reviewing patches from oher people that really are ready to go into
the tree.
^ permalink raw reply
* Re: [PATCH] netdev/phy: skip disabled mdio-mux nodes
From: Timur Tabi @ 2012-08-14 21:12 UTC (permalink / raw)
To: David Miller; +Cc: david.daney, netdev
In-Reply-To: <20120814.140736.812697309119422215.davem@davemloft.net>
David Miller wrote:
>> Any chance this patch can get into 3.6? I don't know if it qualifies
>> as a fix or not, but getting it into 3.6 would make it easier for me
>> to apply other patches to the powerpc tree.
>>
>
> I want you to implement it the way David Daney said to do so.
So you're saying that you don't want this fixed for 3.6? Because David
Daney's suggestion would require me to introduce a new device tree
function, and that won't be accepted until 3.7 at the earliest.
> And you never need to ask me questions like this, I clearly mark the
> state of your patch:
>
> http://patchwork.ozlabs.org/patch/175750/
>
> So that you can just monitor it instead of wasting my time asking what
> is happening to your patch.
Sorry.
> Time of mine you consume forcing me to reply to you in situations like
> this, which you could handle on your own, is time that I can't spend
> reviewing patches from oher people that really are ready to go into
> the tree.
>
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH net-next 0/7] sctp: network namespace support Part 2: per net tunables
From: David Miller @ 2012-08-14 21:14 UTC (permalink / raw)
To: ebiederm
Cc: vyasevich, linux-sctp, netdev, linux-kernel, jan.ariyasu,
jan.ariyasu, nhorman, tgraf, xi.wang
In-Reply-To: <20120808.232058.1128673474849407813.davem@davemloft.net>
Come on Vlad, please review this stuff some time this century. If you
want inclusion to be dependent upon your review, then the onus is on
you to review it in a timely manner. And you are not doing so here.
I'm not letting Eric's patches rot in patchwork for more than a week,
this is completely unacceptable.
^ permalink raw reply
* Re: [PATCH] netdev/phy: skip disabled mdio-mux nodes
From: David Miller @ 2012-08-14 21:16 UTC (permalink / raw)
To: timur; +Cc: david.daney, netdev
In-Reply-To: <502ABF2A.9070605@freescale.com>
From: Timur Tabi <timur@freescale.com>
Date: Tue, 14 Aug 2012 16:12:10 -0500
> David Miller wrote:
>
>>> Any chance this patch can get into 3.6? I don't know if it qualifies
>>> as a fix or not, but getting it into 3.6 would make it easier for me
>>> to apply other patches to the powerpc tree.
>>>
>>
>> I want you to implement it the way David Daney said to do so.
>
> So you're saying that you don't want this fixed for 3.6? Because David
> Daney's suggestion would require me to introduce a new device tree
> function, and that won't be accepted until 3.7 at the earliest.
If it is infrastrucure needed to fix a bug, it would be accepted. Stop
talking nonsense.
^ permalink raw reply
* Re: [PATCH v2] net-tcp: TCP/IP stack bypass for loopback connections
From: David Miller @ 2012-08-14 21:22 UTC (permalink / raw)
To: brutus; +Cc: edumazet, netdev
In-Reply-To: <1344559958-29162-1-git-send-email-brutus@google.com>
Bruce, could you integrate (and unlike your submission, actually build
and run test) Weiping's bug fixes?
Actually, I'm actually a little bit alarmed at Weiping's fixes,
because it makes it look as if you didn't test things at all under
net-next, as it appears that without his fixes any loopback TCP
connection would OOPS the kernel.
In fact, it wouldn't even build without the sysctl_tcp_friends typo.
Indeed:
net/ipv4/tcp.c: In function ‘tcp_recvmsg’:
net/ipv4/tcp.c:1935:35: error: ‘friends’ undeclared (first use in this function)
net/ipv4/tcp.c:1935:35: note: each undeclared identifier is reported only once for each function it appears in
I hope I don't need to tell you how unacceptable this is.
That also means that all of your measurements in the commit message
weren't even made in the context where this patch will be applied.
Also unacceptable.
All of this makes for an extremely poor quality submission, please
correct these issues.
^ permalink raw reply
* Re: [PATCH 1/2] net: move and rename netif_notify_peers()
From: David Miller @ 2012-08-14 21:28 UTC (permalink / raw)
To: amwang; +Cc: netdev, Ian.Campbell
In-Reply-To: <1344586497-2702-1-git-send-email-amwang@redhat.com>
From: Cong Wang <amwang@redhat.com>
Date: Fri, 10 Aug 2012 16:14:56 +0800
> I believe net/core/dev.c is a better place for netif_notify_peers(),
> because other net event notify functions also stay in this file.
>
> And rename it to netdev_notify_peers().
>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: Ian Campbell <Ian.Campbell@citrix.com>
> Signed-off-by: Cong Wang <amwang@redhat.com>
Applied to net-next
^ permalink raw reply
* Re: [PATCH 2/2] net: remove netdev_bonding_change()
From: David Miller @ 2012-08-14 21:29 UTC (permalink / raw)
To: amwang; +Cc: netdev
In-Reply-To: <1344586497-2702-2-git-send-email-amwang@redhat.com>
From: Cong Wang <amwang@redhat.com>
Date: Fri, 10 Aug 2012 16:14:57 +0800
> I don't see any benifits to use netdev_bonding_change() than
> using call_netdevice_notifiers() directly.
>
> Cc: David S. Miller <davem@davemloft.net>
> Signed-off-by: Cong Wang <amwang@redhat.com>
Applied to net-next
^ permalink raw reply
* Re: [PATCH RESEND net-next v3] GRE over IPv6
From: David Miller @ 2012-08-14 21:29 UTC (permalink / raw)
To: xeb; +Cc: netdev
In-Reply-To: <5380798.tqMsGTAipf@dima>
From: Kozlov Dmitry <xeb@mail.ru>
Date: Fri, 10 Aug 2012 14:51:50 +0400
> GRE over IPv6 implementation.
>
> Signed-off-by: Dmitry Kozlov <xeb@mail.ru>
> ---
> Changes: fixed 'new blank line at EOF' issue.
>
Applied to net-next
^ permalink raw reply
* Re: [PATCH v5 00/15] some netpoll and netconsole fixes
From: David Miller @ 2012-08-14 21:41 UTC (permalink / raw)
To: amwang; +Cc: netdev
In-Reply-To: <1344597891-32242-1-git-send-email-amwang@redhat.com>
From: Cong Wang <amwang@redhat.com>
Date: Fri, 10 Aug 2012 19:24:36 +0800
> This patchset fixes serval problems in netconsole and netpoll.
>
> I ran this patchset in my KVM guest with some netpoll test cases,
> even covered with some corner cases, everything worked as expected.
Ok looks good, applied to 'net', thanks.
^ permalink raw reply
* Re: [PATCH v2] net-tcp: TCP/IP stack bypass for loopback connections
From: Bruce Curtis @ 2012-08-14 21:45 UTC (permalink / raw)
To: David Miller; +Cc: edumazet, netdev
In-Reply-To: <20120814.142228.85041202742435369.davem@davemloft.net>
On Tue, Aug 14, 2012 at 2:22 PM, David Miller <davem@davemloft.net> wrote:
>
> Bruce, could you integrate (and unlike your submission, actually build
> and run test) Weiping's bug fixes?
>
> Actually, I'm actually a little bit alarmed at Weiping's fixes,
> because it makes it look as if you didn't test things at all under
> net-next, as it appears that without his fixes any loopback TCP
> connection would OOPS the kernel.
>
??? rebase, build, boot a dev machine, run several hours of testing,
take numbers from test and updated commit message (commit message test
results changed from patch to patch submit because of this) so ???
> In fact, it wouldn't even build without the sysctl_tcp_friends typo.
> Indeed:
>
> net/ipv4/tcp.c: In function ‘tcp_recvmsg’:
> net/ipv4/tcp.c:1935:35: error: ‘friends’ undeclared (first use in this function)
> net/ipv4/tcp.c:1935:35: note: each undeclared identifier is reported only once for each function it appears in
>
Didn't build with CONFIG_NET_DMA and wasn't caught as part of
rebase/local var name change.
> I hope I don't need to tell you how unacceptable this is.
>
> That also means that all of your measurements in the commit message
> weren't even made in the context where this patch will be applied.
>
> Also unacceptable.
>
I stand by my numbers!!!
> All of this makes for an extremely poor quality submission, please
> correct these issues.
Looking into Weiping's bug, can't simple use
lock_sock()/release_sock() due to A<>B locking issues (i.e.
bi-directional socket I/O).
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/85xx: add Fman MDIO muxing support to the P4080DS
From: Kumar Gala @ 2012-08-14 21:45 UTC (permalink / raw)
To: Timur Tabi; +Cc: Andy Fleming, Scott Wood, ddaney.cavm, linuxppc-dev, netdev
In-Reply-To: <1344637896-14267-2-git-send-email-timur@freescale.com>
On Aug 10, 2012, at 5:31 PM, Timur Tabi wrote:
> diff --git a/arch/powerpc/platforms/85xx/corenet_ds.c b/arch/powerpc/platforms/85xx/corenet_ds.c
> index 925b028..a79fc79 100644
> --- a/arch/powerpc/platforms/85xx/corenet_ds.c
> +++ b/arch/powerpc/platforms/85xx/corenet_ds.c
> @@ -106,6 +106,13 @@ static const struct of_device_id of_device_ids[] __devinitconst = {
> {
> .name = "handles",
> },
> + {
> + /*
> + * Warning: this entry might need to be located before those
> + * for the Fman Ethernet nodes.
> + */
> + .compatible = "mdio-mux",
> + },
> {}
> };
Under what condition would that be the case?
- k
^ permalink raw reply
* Re: [PATCH] net: Fix incorrect comment in netif_tx_stop_queue()
From: David Miller @ 2012-08-14 21:46 UTC (permalink / raw)
To: shchepetkov; +Cc: netdev, linux-kernel, ldv-project
In-Reply-To: <1344869014-7110-1-git-send-email-shchepetkov@ispras.ru>
From: Ilya Shchepetkov <shchepetkov@ispras.ru>
Date: Mon, 13 Aug 2012 18:43:34 +0400
> netif_stop_queue() can be called before register_netdev() because now
> TX queues are allocated inside alloc_netdev_mqs().
>
> (since ed9af2e839c06c18f721da2c768fbb444c4a10e5 commit)
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Ilya Shchepetkov <shchepetkov@ispras.ru>
You're not changing a "comment", you're changing a kernel log message.
Have you actually triggered this condition?
I doubt it, and I'm not applying this patch.
^ permalink raw reply
* Re: [PATCH net 0/3] qmi_wwan: simplify device matching and add a few new devices
From: David Miller @ 2012-08-14 21:46 UTC (permalink / raw)
To: bjorn; +Cc: netdev, linux-usb
In-Reply-To: <1344798992-10176-1-git-send-email-bjorn@mork.no>
From: Bjørn Mork <bjorn@mork.no>
Date: Sun, 12 Aug 2012 21:16:29 +0200
> The home cooked whitelisting code can be removed now that
> the USB core supports interface number matching.
>
> The second patch adds a few new devices.
>
> The third patch improves device list readability by using
> existing macros where possible.
>
> I hope this can go in 3.6-rc2/3. The series is based on
> the current net/master (commit 2359a476)
Ok I changed my mind and applied this to 'net'.
^ permalink raw reply
* Re: [PATCH net] net: sierra_net: replace whitelist with ifnumber match
From: David Miller @ 2012-08-14 21:47 UTC (permalink / raw)
To: bjorn-yOkvZcmFvRU
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1344801218-11041-1-git-send-email-bjorn-yOkvZcmFvRU@public.gmane.org>
From: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
Date: Sun, 12 Aug 2012 21:53:38 +0200
> Signed-off-by: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
Applied to 'net'
--
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] ipv4: Cache local output routes
From: David Miller @ 2012-08-14 21:47 UTC (permalink / raw)
To: zheng.z.yan; +Cc: netdev, alex.shi
In-Reply-To: <50289A37.6000209@intel.com>
From: "Yan, Zheng" <zheng.z.yan@intel.com>
Date: Mon, 13 Aug 2012 14:09:59 +0800
> Commit caacf05e5ad1abf causes big drop of UDP loop back performance.
> The cause of the regression is that we do not cache the local output
> routes. Each time we send a datagram from unconnected UDP socket,
> the kernel allocates a dst_entry and adds it to the rt_uncached_list.
> It creates lock contention on the rt_uncached_lock.
>
> Reported-by: Alex Shi <alex.shi@intel.com>
> Signed-off-by: Yan, Zheng <zheng.z.yan@intel.com>
I was pretty sure not using 'fi' was necessary for semantic
reasons here, but I can't find any such requirement, so I've
applied this, thanks.
^ permalink raw reply
* Re: [PATCH net] net: ipv6: proc: Fix error handling
From: David Miller @ 2012-08-14 21:47 UTC (permalink / raw)
To: igorm; +Cc: netdev
In-Reply-To: <1344846718-4263-1-git-send-email-igorm@etf.rs>
From: igorm@etf.rs
Date: Mon, 13 Aug 2012 10:31:58 +0200
> From: Igor Maravic <igorm@etf.rs>
>
> Fix error handling in case making of dir dev_snmp6 failes
>
> Signed-off-by: Igor Maravic <igorm@etf.rs>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/85xx: add Fman MDIO muxing support to the P4080DS
From: Timur Tabi @ 2012-08-14 21:48 UTC (permalink / raw)
To: Kumar Gala; +Cc: Andy Fleming, Scott Wood, ddaney.cavm, linuxppc-dev, netdev
In-Reply-To: <5F0028FE-C555-47DE-B69A-888E7322A6E1@kernel.crashing.org>
Kumar Gala wrote:
>> > + {
>> > + /*
>> > + * Warning: this entry might need to be located before those
>> > + * for the Fman Ethernet nodes.
>> > + */
>> > + .compatible = "mdio-mux",
>> > + },
>> > {}
>> > };
> Under what condition would that be the case?
We had this discussion already. In my tests, I had to locate this entry
before these entries:
{
.compatible = "fsl,dpaa"
},
{
.compatible = "fsl,srio",
},
otherwise, the mdio-mux code would not prepare the mdio mus in time, and
there would be initialization failures. Now maybe this goes away with
-EPROBE_DEFER, or maybe it doesn't. But until we push the DPAA drivers
upstream, we won't know.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH v2] net-tcp: TCP/IP stack bypass for loopback connections
From: David Miller @ 2012-08-14 21:50 UTC (permalink / raw)
To: brutus; +Cc: edumazet, netdev
In-Reply-To: <CAEkNxbETGxFAHoNDK5qEmGo+PfLxmhCniLnOTkWxpK8Ycj_r0A@mail.gmail.com>
From: Bruce Curtis <brutus@google.com>
Date: Tue, 14 Aug 2012 14:45:09 -0700
> On Tue, Aug 14, 2012 at 2:22 PM, David Miller <davem@davemloft.net> wrote:
>>
>> Bruce, could you integrate (and unlike your submission, actually build
>> and run test) Weiping's bug fixes?
>>
>> Actually, I'm actually a little bit alarmed at Weiping's fixes,
>> because it makes it look as if you didn't test things at all under
>> net-next, as it appears that without his fixes any loopback TCP
>> connection would OOPS the kernel.
>>
> ??? rebase, build, boot a dev machine, run several hours of testing,
> take numbers from test and updated commit message (commit message test
> results changed from patch to patch submit because of this) so ???
I did it for every round of the patch series removing the entire
routing cache, so these kinds of excuses are going to fall on deaf
ears.
It's part of doing responsible development, and it's especially
critical when you are touching core parts of the kernel everyone
uses.
>
>> In fact, it wouldn't even build without the sysctl_tcp_friends typo.
>> Indeed:
>>
>> net/ipv4/tcp.c: In function ‘tcp_recvmsg’:
>> net/ipv4/tcp.c:1935:35: error: ‘friends’ undeclared (first use in this function)
>> net/ipv4/tcp.c:1935:35: note: each undeclared identifier is reported only once for each function it appears in
>>
> Didn't build with CONFIG_NET_DMA and wasn't caught as part of
> rebase/local var name change.
'allmodconfig' builds take less than 10 minutes on current hardware,
and should be part of your patch validation.
Especially because this is the first thing I'm personally going to
do with your patch.
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/85xx: add Fman MDIO muxing support to the P4080DS
From: Scott Wood @ 2012-08-14 21:53 UTC (permalink / raw)
To: Timur Tabi; +Cc: Kumar Gala, Andy Fleming, ddaney.cavm, linuxppc-dev, netdev
In-Reply-To: <502AC7C3.9030902@freescale.com>
On 08/14/2012 04:48 PM, Timur Tabi wrote:
> Kumar Gala wrote:
>>>> + {
>>>> + /*
>>>> + * Warning: this entry might need to be located before those
>>>> + * for the Fman Ethernet nodes.
>>>> + */
>>>> + .compatible = "mdio-mux",
>>>> + },
>>>> {}
>>>> };
>> Under what condition would that be the case?
>
> We had this discussion already.
I think that was internally, and not on this specific comment wording.
I don't think that code comment adequately explains things.
> otherwise, the mdio-mux code would not prepare the mdio mus in time, and
> there would be initialization failures. Now maybe this goes away with
> -EPROBE_DEFER, or maybe it doesn't. But until we push the DPAA drivers
> upstream, we won't know.
Do you know if it's theoretically supposed to be fixed and just can't
test it, or are you unsure of whether it's even supposed to work?
I don't think we should be relying on the order of this list to
determine probe order. For one thing, it won't work if the drivers
register after you create the platform devices (e.g. they're modules).
-Scott
^ permalink raw reply
* Re: [PATCH] XFRM: remove redundant parameter "int dir" in struct xfrm_mgr.acquire
From: David Miller @ 2012-08-14 21:56 UTC (permalink / raw)
To: fan.du; +Cc: steffen.klassert, netdev
In-Reply-To: <5028AB5D.9040200@windriver.com>
From: Fan Du <fan.du@windriver.com>
Date: Mon, 13 Aug 2012 15:23:09 +0800
>
>
> On 2012年08月13日 15:08, Steffen Klassert wrote:
>> On Mon, Aug 13, 2012 at 02:25:57PM +0800, Fan Du wrote:
>>>
>>> static int xfrm_send_acquire(struct xfrm_state *x, struct xfrm_tmpl
>>> *xt,
>>> - struct xfrm_policy *xp, int dir)
>>> + struct xfrm_policy *xp)
>>> {
>>> struct net *net = xs_net(x);
>>> struct sk_buff *skb;
>>> @@ -2614,7 +2614,7 @@ static int xfrm_send_acquire(struct xfrm_state
>>> *x, struct xfrm_tmpl *xt,
>>> if (skb == NULL)
>>> return -ENOMEM;
>>>
>>> - if (build_acquire(skb, x, xt, xp, dir)< 0)
>>> + if (build_acquire(skb, x, xt, xp, XFRM_POLICY_OUT)< 0)
>>> BUG();
>>
>> xfrm_send_acquire() is the only caller of build_acquire().
>> So if you remove the dir parameter from xfrm_send_acquire(),
>> you can remove it from build_acquire() too.
>>
> Yep, looks like we can only remove "dir" at build_acquire, not into
> copy_to_user_policy anymore :)
>
> I will adopt your approach in v2 if Dave say *YES* about this patch.
> thanks anyway.
Looks find to me.
^ 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