* Re: [PATCH v2.39 7/7] datapath: Add basic MPLS support to kernel
From: Ben Pfaff @ 2013-09-18 0:05 UTC (permalink / raw)
To: Simon Horman
Cc: Jesse Gross, Pravin Shelar, dev@openvswitch.org, netdev, Ravi K,
Isaku Yamahata, Joe Stringer
In-Reply-To: <20130917234717.GA3675@verge.net.au>
On Tue, Sep 17, 2013 at 06:47:22PM -0500, Simon Horman wrote:
> On Mon, Sep 16, 2013 at 01:46:19PM -0700, Ben Pfaff wrote:
> > On Mon, Sep 16, 2013 at 03:38:21PM -0500, Jesse Gross wrote:
> > > - Ben, do you want to take over for the userspace portions of the
> > > series on the assumption that the above comments can be fixed fairly
> > > easily?
> >
> > Yes, that's fine. Simon, I guess that you are looking at Jesse's
> > comments about mpls_depth from earlier?
>
> Yes, I have a solution to that problem and I will post it after testing
> further. I don't think it will affect the other user-space patches
> in a material way. So I think you can review them as-is.
That sounds good, thanks.
^ permalink raw reply
* Re: [CFT][PATCH] net: Delay default_device_exit_batch until no devices are unregistering
From: David Miller @ 2013-09-18 0:15 UTC (permalink / raw)
To: ebiederm; +Cc: fruggeri, edumazet, jiri, alexander.h.duyck, amwang, netdev
In-Reply-To: <e652a11e-b23d-4a83-aaac-00c469a416f1@email.android.com>
From: "Eric W. Biederman" <ebiederm@xmission.com>
Date: Tue, 17 Sep 2013 16:41:37 -0700
> List/count I don't much care but currently we don't have a list of
> all of the devices that are unregistering.
>
> The problem with this is that netdev_run_todo moves all of the
> devices to a local list, so they are only visible from a list_head
> on the stack. Which makes sense as we run this all in the context
> of rtnl_unlock.
And when that local list is processed (the while loop completes and
has iterated over the entire list), either the global todo list is
empty, or it is not empty.
And the waked up code will check for this.
I really don't see what the problem is.
^ permalink raw reply
* Re: [PATCH] vxlan: Avoid creating fdb entry with NULL destination
From: David Miller @ 2013-09-18 0:20 UTC (permalink / raw)
To: sri; +Cc: netdev, stephen, mike.rapoport
In-Reply-To: <1379445160.21109.29.camel@sridhar.usor.ibm.com>
From: Sridhar Samudrala <sri@us.ibm.com>
Date: Tue, 17 Sep 2013 12:12:40 -0700
> Commit afbd8bae9c798c5cdbe4439d3a50536b5438247c
> vxlan: add implicit fdb entry for default destination
> creates an implicit fdb entry for default destination. This results
> in an invalid fdb entry if default destination is not specified.
> For ex:
> ip link add vxlan1 type vxlan id 100
> creates the following fdb entry
> 00:00:00:00:00:00 dev vxlan1 dst 0.0.0.0 self permanent
>
> This patch fixes this issue by creating an fdb entry only if a
> valid default destination is specified.
>
> Signed-off-by: Sridhar Samudrala <sri@us.ibm.com>
Looks reasonable, applied, thanks.
^ permalink raw reply
* Re: [PATCH 0/7] netfilter fixes for net
From: David Miller @ 2013-09-18 0:23 UTC (permalink / raw)
To: pablo; +Cc: netfilter-devel, netdev
In-Reply-To: <1379456519-4317-1-git-send-email-pablo@netfilter.org>
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Wed, 18 Sep 2013 00:21:59 +0200
> The following patchset contains Netfilter fixes for you net tree,
> mostly targeted to ipset, they are:
...
> You can pull these changes from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf.git master
Looks good, pulled, thanks a lot.
^ permalink raw reply
* Re: [PATCH v2 6/6] ipv6: Do route updating for redirect in ndisc layer
From: David Miller @ 2013-09-18 0:29 UTC (permalink / raw)
To: duanj.fnst; +Cc: netdev, hannes
In-Reply-To: <5232806B.6050601@cn.fujitsu.com>
From: Duan Jiong <duanj.fnst@cn.fujitsu.com>
Date: Fri, 13 Sep 2013 11:03:07 +0800
> From: Duan Jiong <duanj.fnst@cn.fujitsu.com>
>
> Do the whole verification and route updating in ndisc
> lay and then just call into icmpv6_notify() to notify
> the upper protocols.
>
> Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
This is completely broken, and I believe your patch set fundamentally
is too.
We absolutely _must_ handle the redirect at the socket level when
we are able to, otherwise we cannot specify the mark properly and
the mark is an essential part of the key used to find the correct
route to work with.
I am not applying this patch series until you deal with this
deficiency. I am not willing to consider changes which stop using the
more precise keying information available from a socket.
^ permalink raw reply
* Re: add ip to interface as primary ip address, not secondary ip when there is alreadly primary ip?
From: Cong Wang @ 2013-09-18 0:29 UTC (permalink / raw)
To: netdev
In-Reply-To: <CAK3+h2zPYYLaVs-WhHFaDhOsnLBB7m8vDvkTj5a16FUJ02i4KA@mail.gmail.com>
On Tue, 17 Sep 2013 at 22:31 GMT, Vincent Li <vincent.mc.li@gmail.com> wrote:
>
> ideally though, we would like to have the capability in
> kernel/userspace to specify a flag or something to add any ip as
> primary even if there is already existing primary ip address (could
> downgrade the existing primary to secondary ip). does this make sense
> ?
'ip addr' already has flags for this.
^ permalink raw reply
* Re: [PATCH net-next v4] Don't destroy the netdev until the vif is shut down
From: David Miller @ 2013-09-18 0:30 UTC (permalink / raw)
To: paul.durrant; +Cc: xen-devel, netdev, david.vrabel, wei.liu2, ian.campbell
In-Reply-To: <1379436368-6882-1-git-send-email-paul.durrant@citrix.com>
From: Paul Durrant <paul.durrant@citrix.com>
Date: Tue, 17 Sep 2013 17:46:08 +0100
> Without this patch, if a frontend cycles through states Closing
> and Closed (which Windows frontends need to do) then the netdev
> will be destroyed and requires re-invocation of hotplug scripts
> to restore state before the frontend can move to Connected. Thus
> when udev is not in use the backend gets stuck in InitWait.
>
> With this patch, the netdev is left alone whilst the backend is
> still online and is only de-registered and freed just prior to
> destroying the vif (which is also nicely symmetrical with the
> netdev allocation and registration being done during probe) so
> no re-invocation of hotplug scripts is required.
>
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Can a xen driver expert please review and give an Acked-by:?
Thanks.
^ permalink raw reply
* Re: [PATCH] USBNET: fix handling padding packet
From: David Miller @ 2013-09-18 0:33 UTC (permalink / raw)
To: ming.lei-Z7WLFzj8eWMS+FvcfC7Uqw
Cc: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, oneukum-l3A5Bk7waGM,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
oliver-GvhC2dPhHPQdnm+yROfE0A
In-Reply-To: <1379409002-7698-1-git-send-email-ming.lei-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
From: Ming Lei <ming.lei-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
Date: Tue, 17 Sep 2013 17:10:02 +0800
> Commit 638c5115a7949(USBNET: support DMA SG) introduces DMA SG
> if the usb host controller is capable of building packet from
> discontinuous buffers, but missed handling padding packet when
> building DMA SG.
>
> This patch attachs the pre-allocated padding packet at the
> end of the sg list, so padding packet can be sent to device
> if drivers require that.
>
> Reported-by: David Laight <David.Laight-JxhZ9S5GRejQT0dZR+AlfA@public.gmane.org>
> Cc: Oliver Neukum <oliver-GvhC2dPhHPQdnm+yROfE0A@public.gmane.org>
> Signed-off-by: Ming Lei <ming.lei-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
Some reviews and ACKs would be appreciated on this one, thanks.
--
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 net-next v2 1/2] ipv4: IP_TOS and IP_TTL can be specified as ancillary data
From: David Miller @ 2013-09-18 0:46 UTC (permalink / raw)
To: ffusco; +Cc: netdev
In-Reply-To: <521DAD30.1010903@redhat.com>
From: Francesco Fusco <ffusco@redhat.com>
Date: Wed, 28 Aug 2013 09:56:32 +0200
> On 08/27/2013 08:56 PM, David Miller wrote:
>> From: Francesco Fusco <ffusco@redhat.com>
>> Date: Fri, 23 Aug 2013 14:19:32 +0200
>>
>>> - changed the icmp_cookie ttl field from __s16 to __u8.
>>> A value of 0 means that the TTL has not been specified
>>
>> Sorry, I have to ask you to change the ttl field type back to __s16
>> and use "-1" to mean not-specified.
>>
>> Zero is a valid TTL setting and it means to not allow the
>> packet to leave this host.
>
> Actually setsockopt() does not allow a TTL value of zero:
>
> From net/ipv4/ip_sockglue.c::do_ip_setsockopt()
Indeed, you are right.
Please resubmit these patches for the next merge window.
Thank you.
^ permalink raw reply
* Re: [PATCH v2 6/6] ipv6: Do route updating for redirect in ndisc layer
From: Hannes Frederic Sowa @ 2013-09-18 1:39 UTC (permalink / raw)
To: David Miller; +Cc: duanj.fnst, netdev
In-Reply-To: <20130917.202936.2080212548361553334.davem@davemloft.net>
On Tue, Sep 17, 2013 at 08:29:36PM -0400, David Miller wrote:
> From: Duan Jiong <duanj.fnst@cn.fujitsu.com>
> Date: Fri, 13 Sep 2013 11:03:07 +0800
>
> > From: Duan Jiong <duanj.fnst@cn.fujitsu.com>
> >
> > Do the whole verification and route updating in ndisc
> > lay and then just call into icmpv6_notify() to notify
> > the upper protocols.
> >
> > Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
>
> This is completely broken, and I believe your patch set fundamentally
> is too.
>
> We absolutely _must_ handle the redirect at the socket level when
> we are able to, otherwise we cannot specify the mark properly and
> the mark is an essential part of the key used to find the correct
> route to work with.
>
> I am not applying this patch series until you deal with this
> deficiency. I am not willing to consider changes which stop using the
> more precise keying information available from a socket.
Oh, Duan, I am very sorry for not catching this earlier. We use the
sk->mark to select the proper routing table where we clone the rt6_info into.
And we only get that value out of the sockets. I missed that. We should leave
the redirect logic in the socket layer where it is possible.
But parts of this series are still valid. We need to fix redirects for tunnels
and I do think we can still simplify some code in the error handlers.
Thanks for pointing this out,
Hannes
^ permalink raw reply
* Re: [PATCH v2 6/6] ipv6: Do route updating for redirect in ndisc layer
From: Duan Jiong @ 2013-09-18 1:52 UTC (permalink / raw)
To: David Miller, netdev
In-Reply-To: <20130918013903.GC8947@order.stressinduktion.org>
于 2013年09月18日 09:39, Hannes Frederic Sowa 写道:
> On Tue, Sep 17, 2013 at 08:29:36PM -0400, David Miller wrote:
>> From: Duan Jiong <duanj.fnst@cn.fujitsu.com>
>> Date: Fri, 13 Sep 2013 11:03:07 +0800
>>
>>> From: Duan Jiong <duanj.fnst@cn.fujitsu.com>
>>>
>>> Do the whole verification and route updating in ndisc
>>> lay and then just call into icmpv6_notify() to notify
>>> the upper protocols.
>>>
>>> Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
>>
>> This is completely broken, and I believe your patch set fundamentally
>> is too.
>>
>> We absolutely _must_ handle the redirect at the socket level when
>> we are able to, otherwise we cannot specify the mark properly and
>> the mark is an essential part of the key used to find the correct
>> route to work with.
>>
>> I am not applying this patch series until you deal with this
>> deficiency. I am not willing to consider changes which stop using the
>> more precise keying information available from a socket.
>
> Oh, Duan, I am very sorry for not catching this earlier. We use the
> sk->mark to select the proper routing table where we clone the rt6_info into.
> And we only get that value out of the sockets. I missed that. We should leave
> the redirect logic in the socket layer where it is possible.
>
> But parts of this series are still valid. We need to fix redirects for tunnels
> and I do think we can still simplify some code in the error handlers.
>
I got it.
Thanks,
Duan
^ permalink raw reply
* [PATCH Resend 1/3] net: cdc-phonet: Staticize usbpn_probe
From: Sachin Kamat @ 2013-09-18 3:29 UTC (permalink / raw)
To: netdev; +Cc: davem, sachin.kamat, Rémi Denis-Courmont
'usbpn_probe' is referenced only in this file. Make it static.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Acked-by: Rémi Denis-Courmont <remi@remlab.net>
Cc: Rémi Denis-Courmont <remi@remlab.net>
---
drivers/net/usb/cdc-phonet.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb/cdc-phonet.c b/drivers/net/usb/cdc-phonet.c
index 7d78669..8c44f86 100644
--- a/drivers/net/usb/cdc-phonet.c
+++ b/drivers/net/usb/cdc-phonet.c
@@ -328,7 +328,8 @@ MODULE_DEVICE_TABLE(usb, usbpn_ids);
static struct usb_driver usbpn_driver;
-int usbpn_probe(struct usb_interface *intf, const struct usb_device_id *id)
+static int
+usbpn_probe(struct usb_interface *intf, const struct usb_device_id *id)
{
static const char ifname[] = "usbpn%d";
const struct usb_cdc_union_desc *union_header = NULL;
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 2/3] net: bnx2x: Staticize local symbols
From: Sachin Kamat @ 2013-09-18 3:30 UTC (permalink / raw)
To: netdev; +Cc: davem, sachin.kamat, Eilon Greenstein, Ariel Elior
In-Reply-To: <1379475001-24505-1-git-send-email-sachin.kamat@linaro.org>
Local symbols used only in this file are made static.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Cc: Eilon Greenstein <eilong@broadcom.com>
Cc: Ariel Elior <ariele@broadcom.com>
---
Changes since v1:
Changed the coding style as suggested by Ariel Elior.
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c
index 2604b62..7991f10 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c
@@ -2802,7 +2802,7 @@ struct set_vf_state_cookie {
u8 state;
};
-void bnx2x_set_vf_state(void *cookie)
+static void bnx2x_set_vf_state(void *cookie)
{
struct set_vf_state_cookie *p = (struct set_vf_state_cookie *)cookie;
@@ -3222,8 +3222,9 @@ void bnx2x_disable_sriov(struct bnx2x *bp)
pci_disable_sriov(bp->pdev);
}
-int bnx2x_vf_ndo_prep(struct bnx2x *bp, int vfidx, struct bnx2x_virtf **vf,
- struct pf_vf_bulletin_content **bulletin)
+static int bnx2x_vf_ndo_prep(struct bnx2x *bp, int vfidx,
+ struct bnx2x_virtf **vf,
+ struct pf_vf_bulletin_content **bulletin)
{
if (bp->state != BNX2X_STATE_OPEN) {
BNX2X_ERR("vf ndo called though PF is down\n");
--
1.7.9.5
^ permalink raw reply related
* [PATCH Resend 3/3] net: cxgb4vf: Staticize local symbols
From: Sachin Kamat @ 2013-09-18 3:30 UTC (permalink / raw)
To: netdev; +Cc: davem, sachin.kamat, Casey Leedom
In-Reply-To: <1379475001-24505-1-git-send-email-sachin.kamat@linaro.org>
Local symbols used only in this file are made static.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Cc: Casey Leedom <leedom@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4vf/sge.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4vf/sge.c b/drivers/net/ethernet/chelsio/cxgb4vf/sge.c
index df296af..8475c4c 100644
--- a/drivers/net/ethernet/chelsio/cxgb4vf/sge.c
+++ b/drivers/net/ethernet/chelsio/cxgb4vf/sge.c
@@ -1396,8 +1396,9 @@ static inline void copy_frags(struct sk_buff *skb,
* Builds an sk_buff from the given packet gather list. Returns the
* sk_buff or %NULL if sk_buff allocation failed.
*/
-struct sk_buff *t4vf_pktgl_to_skb(const struct pkt_gl *gl,
- unsigned int skb_len, unsigned int pull_len)
+static struct sk_buff *t4vf_pktgl_to_skb(const struct pkt_gl *gl,
+ unsigned int skb_len,
+ unsigned int pull_len)
{
struct sk_buff *skb;
@@ -1443,7 +1444,7 @@ out:
* Releases the pages of a packet gather list. We do not own the last
* page on the list and do not free it.
*/
-void t4vf_pktgl_free(const struct pkt_gl *gl)
+static void t4vf_pktgl_free(const struct pkt_gl *gl)
{
int frag;
@@ -1640,7 +1641,7 @@ static inline void rspq_next(struct sge_rspq *rspq)
* on this queue. If the system is under memory shortage use a fairly
* long delay to help recovery.
*/
-int process_responses(struct sge_rspq *rspq, int budget)
+static int process_responses(struct sge_rspq *rspq, int budget)
{
struct sge_eth_rxq *rxq = container_of(rspq, struct sge_eth_rxq, rspq);
int budget_left = budget;
@@ -1893,7 +1894,7 @@ static unsigned int process_intrq(struct adapter *adapter)
* The MSI interrupt handler handles data events from SGE response queues as
* well as error and other async events as they all use the same MSI vector.
*/
-irqreturn_t t4vf_intr_msi(int irq, void *cookie)
+static irqreturn_t t4vf_intr_msi(int irq, void *cookie)
{
struct adapter *adapter = cookie;
--
1.7.9.5
^ permalink raw reply related
* Re: [CFT][PATCH] net: Delay default_device_exit_batch until no devices are unregistering
From: Francesco Ruggeri @ 2013-09-18 3:50 UTC (permalink / raw)
To: David Miller
Cc: Eric W. Biederman, Eric Dumazet, Jiří Pírko,
Alexander Duyck, Cong Wang, netdev
In-Reply-To: <20130917.201515.1404443973169590392.davem@davemloft.net>
>> List/count I don't much care but currently we don't have a list of
>> all of the devices that are unregistering.
>>
>> The problem with this is that netdev_run_todo moves all of the
>> devices to a local list, so they are only visible from a list_head
>> on the stack. Which makes sense as we run this all in the context
>> of rtnl_unlock.
>
> And when that local list is processed (the while loop completes and
> has iterated over the entire list), either the global todo list is
> empty, or it is not empty.
>
> And the waked up code will check for this.
>
> I really don't see what the problem is.
I am not sure that would work.
list_empty(&net_todo_list) does not guarantee that there are no
unregistering devices still in flight.
Another process may have copied net_todo_run into its local list, left
net_todo_list empty and still be in the middle of processing
unregistering devices (without the rtnl lock) when
default_device_exit_batch starts executing.
> The count doesn't necessarily need to be atomic as it can be protected
> by the rtnl_lock.
If we use the rtnl_lock then we could have per-net wait queues. While
not strictly needed (since only one instance of
default_device_exit_batch can execute at a time) it would avoid
unnecessarily waking up the waiting code.
Francesco
^ permalink raw reply
* Re: [CFT][PATCH] net: Delay default_device_exit_batch until no devices are unregistering
From: David Miller @ 2013-09-18 3:52 UTC (permalink / raw)
To: fruggeri; +Cc: ebiederm, edumazet, jiri, alexander.h.duyck, amwang, netdev
In-Reply-To: <CA+HUmGgg3-0UNgfKS6Hpnczzi6PUeztk8TZ7p_97kcvtfMacJQ@mail.gmail.com>
From: Francesco Ruggeri <fruggeri@aristanetworks.com>
Date: Tue, 17 Sep 2013 20:50:41 -0700
>>> List/count I don't much care but currently we don't have a list of
>>> all of the devices that are unregistering.
>>>
>>> The problem with this is that netdev_run_todo moves all of the
>>> devices to a local list, so they are only visible from a list_head
>>> on the stack. Which makes sense as we run this all in the context
>>> of rtnl_unlock.
>>
>> And when that local list is processed (the while loop completes and
>> has iterated over the entire list), either the global todo list is
>> empty, or it is not empty.
>>
>> And the waked up code will check for this.
>>
>> I really don't see what the problem is.
>
> I am not sure that would work.
> list_empty(&net_todo_list) does not guarantee that there are no
> unregistering devices still in flight.
> Another process may have copied net_todo_run into its local list, left
> net_todo_list empty and still be in the middle of processing
> unregistering devices (without the rtnl lock) when
> default_device_exit_batch starts executing.
Ok, now I understand.
Eric B., when you get a chance can you resubmit your patch and perhaps
elaborate on the situation in the commit message.
If I was confused I'm sure other people will be if they look into
this in the future.
^ permalink raw reply
* Re: [PATCH v2 6/6] ipv6: Do route updating for redirect in ndisc layer
From: Hannes Frederic Sowa @ 2013-09-18 4:13 UTC (permalink / raw)
To: Duan Jiong; +Cc: David Miller, netdev
In-Reply-To: <5239076A.4080406@cn.fujitsu.com>
On Wed, Sep 18, 2013 at 09:52:42AM +0800, Duan Jiong wrote:
> 于 2013年09月18日 09:39, Hannes Frederic Sowa 写道:
> > On Tue, Sep 17, 2013 at 08:29:36PM -0400, David Miller wrote:
> >> From: Duan Jiong <duanj.fnst@cn.fujitsu.com>
> >> Date: Fri, 13 Sep 2013 11:03:07 +0800
> >>
> >>> From: Duan Jiong <duanj.fnst@cn.fujitsu.com>
> >>>
> >>> Do the whole verification and route updating in ndisc
> >>> lay and then just call into icmpv6_notify() to notify
> >>> the upper protocols.
> >>>
> >>> Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
> >>
> >> This is completely broken, and I believe your patch set fundamentally
> >> is too.
> >>
> >> We absolutely _must_ handle the redirect at the socket level when
> >> we are able to, otherwise we cannot specify the mark properly and
> >> the mark is an essential part of the key used to find the correct
> >> route to work with.
> >>
> >> I am not applying this patch series until you deal with this
> >> deficiency. I am not willing to consider changes which stop using the
> >> more precise keying information available from a socket.
> >
> > Oh, Duan, I am very sorry for not catching this earlier. We use the
> > sk->mark to select the proper routing table where we clone the rt6_info into.
> > And we only get that value out of the sockets. I missed that. We should leave
> > the redirect logic in the socket layer where it is possible.
> >
> > But parts of this series are still valid. We need to fix redirects for tunnels
> > and I do think we can still simplify some code in the error handlers.
> >
>
> I got it.
I gave it a bit more thought:
RFC 4861 8.3:
"
Redirect messages apply to all flows that are being sent to a given
destination. That is, upon receipt of a Redirect for a Destination
Address, all Destination Cache entries to that address should be
updated to use the specified next-hop, regardless of the contents of
the Flow Label field that appears in the Redirected Header option.
"
Especially because redirects also help in the on-link determination (same
RFC, section 8), I changed my mind and am still in favour of updating it
in the ndisc layer. In my opinion we just have to consider all routing
tables and apply the update to every one which carries a valid next hop
to the source of the redirect (under consideration of the destination).
This will be important if we actually try to get linux to correctly
implement the ipv6 subnet model (RFC 5942, Section 4 Rule 1). In that
case we are not allowed to assume nodes on-link even if they would match
the same prefix as a locally configured address.
Greetings,
Hannes
^ permalink raw reply
* Re: [RFC PATCHv2 3/4] of: provide a binding for fixed link PHYs
From: Grant Likely @ 2013-09-18 4:29 UTC (permalink / raw)
To: Thomas Petazzoni, David S. Miller, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: Lior Amsalem, Mark Rutland, Sascha Hauer, Christian Gmeiner,
Ezequiel Garcia, Gregory Clement, Florian Fainelli,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1378480701-12908-4-git-send-email-thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On Fri, 6 Sep 2013 17:18:20 +0200, Thomas Petazzoni <thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> Some Ethernet MACs have a "fixed link", and are not connected to a
> normal MDIO-managed PHY device. For those situations, a Device Tree
> binding allows to describe a "fixed link" using a special PHY node.
>
> This patch adds:
>
> * A documentation for the fixed PHY Device Tree binding.
>
> * An of_phy_is_fixed_link() function that an Ethernet driver can call
> on its PHY phandle to find out whether it's a fixed link PHY or
> not. It should typically be used to know if
> of_phy_register_fixed_link() should be called.
>
> * An of_phy_register_fixed_link() function that instantiates the
> fixed PHY into the PHY subsystem, so that when the driver calls
> of_phy_connect(), the PHY device associated to the OF node will be
> found.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Hi Thomas,
The implemenation in this series looks like it is in good shape, so I'll
restrict my comments to be binding...
> ---
> .../devicetree/bindings/net/fixed-link.txt | 34 ++++++++++++++++++++++
> drivers/of/of_mdio.c | 24 +++++++++++++++
> include/linux/of_mdio.h | 15 ++++++++++
> 3 files changed, 73 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/fixed-link.txt
>
> diff --git a/Documentation/devicetree/bindings/net/fixed-link.txt b/Documentation/devicetree/bindings/net/fixed-link.txt
> new file mode 100644
> index 0000000..9f2a1a50
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/fixed-link.txt
> @@ -0,0 +1,34 @@
> +Fixed link Device Tree binding
> +------------------------------
> +
> +Some Ethernet MACs have a "fixed link", and are not connected to a
> +normal MDIO-managed PHY device. For those situations, a Device Tree
> +binding allows to describe a "fixed link".
> +
> +Such a fixed link situation is described by creating a PHY node as a
> +sub-node of an Ethernet device, with the following properties:
> +
> +* 'fixed-link' (boolean, mandatory), to indicate that this PHY is a
> + fixed link PHY.
> +* 'speed' (integer, mandatory), to indicate the link speed. Accepted
> + values are 10, 100 and 1000
> +* 'full-duplex' (boolean, optional), to indicate that full duplex is
> + used. When absent, half duplex is assumed.
> +* 'pause' (boolean, optional), to indicate that pause should be
> + enabled.
> +* 'asym-pause' (boolean, optional), to indicate that asym_pause should
> + be enabled.
I understand what you're trying to do here, but it causes a troublesome
leakage of implementation detail into the binding, making the whole
thing look very odd. This binding tries to make a fixed link look
exactly like a real PHY even to the point of including a phandle to the
phy. But having a phandle to a node which is *always* a direct child of
the MAC node is redundant and a rather looney. Yes, doing it that way
makes it easy for of_phy_find_device() to be transparent for fixed link,
but that should *not* drive bindings, especially when that makes the
binding really rather weird.
Second, this new binding doesn't provide anything over and above the
existing fixed-link binding. It may not be pretty, but it is
estabilshed.
That said, I do agree that the current Linux implementation is not good
because it cannot handle a fixed-link property transparently. That's a
deficiency in the Linux implementation and it should be fixed.
of_phy_connect() currently requires the phy phandle to be passed in.
Part of the reason it was done this way is that some drivers connect to
multiple 'phys'. A soulition could be to make the phy handle optional.
If it is empty then go looking for either a phy-device or fixed-link
property. Otherwise use the provided node.
g.
> +
> +Example:
> +
> +ethernet@0 {
> + ...
> + phy = <&phy0>;
> + phy0: phy@0 {
> + fixed-link;
> + speed = <1000>;
> + full-duplex;
> + };
> + ...
> +};
> +
> diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
> index d5a57a9..0507f8f 100644
> --- a/drivers/of/of_mdio.c
> +++ b/drivers/of/of_mdio.c
> @@ -14,6 +14,7 @@
> #include <linux/netdevice.h>
> #include <linux/err.h>
> #include <linux/phy.h>
> +#include <linux/phy_fixed.h>
> #include <linux/of.h>
> #include <linux/of_irq.h>
> #include <linux/of_mdio.h>
> @@ -247,3 +248,26 @@ struct phy_device *of_phy_connect_fixed_link(struct net_device *dev,
> return IS_ERR(phy) ? NULL : phy;
> }
> EXPORT_SYMBOL(of_phy_connect_fixed_link);
> +
> +#if defined(CONFIG_FIXED_PHY)
> +bool of_phy_is_fixed_link(struct device_node *np)
> +{
> + return of_property_read_bool(np, "fixed-link");
> +}
> +EXPORT_SYMBOL(of_phy_is_fixed_link);
> +
> +int of_phy_register_fixed_link(struct device_node *np)
> +{
> + struct fixed_phy_status status = {};
> +
> + status.link = 1;
> + status.duplex = of_property_read_bool(np, "full-duplex");
> + if (of_property_read_u32(np, "speed", &status.speed))
> + return -EINVAL;
> + status.pause = of_property_read_bool(np, "pause");
> + status.asym_pause = of_property_read_bool(np, "asym-pause");
> +
> + return fixed_phy_register(PHY_POLL, &status, np);
> +}
> +EXPORT_SYMBOL(of_phy_register_fixed_link);
> +#endif
> diff --git a/include/linux/of_mdio.h b/include/linux/of_mdio.h
> index 8163107..2f535ee 100644
> --- a/include/linux/of_mdio.h
> +++ b/include/linux/of_mdio.h
> @@ -57,4 +57,19 @@ static inline struct mii_bus *of_mdio_find_bus(struct device_node *mdio_np)
> }
> #endif /* CONFIG_OF */
>
> +#if defined(CONFIG_OF) && defined(CONFIG_FIXED_PHY)
> +extern int of_phy_register_fixed_link(struct device_node *np);
> +extern bool of_phy_is_fixed_link(struct device_node *np);
> +#else
> +static inline int of_phy_register_fixed_link(struct device_node *np)
> +{
> + return -ENOSYS;
> +}
> +static inline bool of_phy_is_fixed_link(struct device_node *np)
> +{
> + return false;
> +}
> +#endif
> +
> +
> #endif /* __LINUX_OF_MDIO_H */
> --
> 1.8.1.2
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* 答复: [PATCH net-next] gen_estimator: change the lock order for better perfermance(Internet mail)
From: zhiguohong(洪志国) @ 2013-09-18 5:41 UTC (permalink / raw)
To: Eric Dumazet, Hong Zhiguo
Cc: netdev@vger.kernel.org, davem@davemloft.net,
stephen@networkplumber.org
In-Reply-To: <1379416308.29845.11.camel@edumazet-glaptop>
Actually I did try LOCKDEP and didn't get any warning.
Could you pointed out why it's wrong?
-----邮件原件-----
发件人: Eric Dumazet [mailto:eric.dumazet@gmail.com]
发送时间: 2013年9月17日 19:12
收件人: Hong Zhiguo
抄送: netdev@vger.kernel.org; davem@davemloft.net; stephen@networkplumber.org; zhiguohong(洪志国)
主题: Re: [PATCH net-next] gen_estimator: change the lock order for better perfermance(Internet mail)
On Tue, 2013-09-17 at 16:38 +0800, Hong Zhiguo wrote:
> From: Hong Zhiguo <zhiguohong@tencent.com>
>
> e->stats_lock is usually taken by fast path to update stats.
> In the old order, fast path should wait for write_lock(&est_lock).
> Even though it's only one line inside the write_lock(&est_lock), but
> if there's interrupt or page fault, a lot of spin on
> e->stats_lock will be wasted in fast path.
1) net-next is not open
2) There is no way a page fault can happen in this path.
3) This patch is wrong.
Current order is there for good reasons.
Have you really tried LOCKDEP, before sending a patch changing lock order ?
^ permalink raw reply
* pull request net: batman-adv 2013-09-18
From: Antonio Quartulli @ 2013-09-18 6:27 UTC (permalink / raw)
To: davem; +Cc: netdev, b.a.t.m.a.n
Hello David,
this is a very small (but important) fix intended for net/linux-3.{11,12} (since
3.12-rc1 is out I guess this patch needs to be enqueued for stable in order to
reach 3.11?)
This change fixes a regression introduced in 3.11 that prevents the Bridge Loop
Avoidance component from correctly operate on VLANs.
Please pull or let me know of any problem.
Thank you,
Antonio
The following changes since commit 1ef68ec462571955f2a667ddf1ffe279848709d7:
Merge branch 'sfc-3.12' of git://git.kernel.org/pub/scm/linux/kernel/git/bwh/sfc (2013-09-16 21:43:54 -0400)
are available in the git repository at:
git://git.open-mesh.org/linux-merge.git tags/batman-adv-fix-for-davem
for you to fetch changes up to 4c18c425b2d228415b635e97a64737d7f27c5536:
batman-adv: set the TAG flag for the vid passed to BLA (2013-09-17 21:15:16 +0200)
----------------------------------------------------------------
Included change:
- fix the Bridge Loop Avoidance component by marking the variables containing
the VLAN ID with the HAS_TAG flag when needed.
----------------------------------------------------------------
Antonio Quartulli (1):
batman-adv: set the TAG flag for the vid passed to BLA
net/batman-adv/soft-interface.c | 2 ++
1 file changed, 2 insertions(+)
^ permalink raw reply
* [PATCH] batman-adv: set the TAG flag for the vid passed to BLA
From: Antonio Quartulli @ 2013-09-18 6:27 UTC (permalink / raw)
To: davem
Cc: netdev, b.a.t.m.a.n, Antonio Quartulli, Antonio Quartulli,
Marek Lindner
In-Reply-To: <1379485658-2317-1-git-send-email-ordex@autistici.org>
From: Antonio Quartulli <antonio@open-mesh.com>
When receiving or sending a packet a packet on a VLAN, the
vid has to be marked with the TAG flag in order to make any
component in batman-adv understand that the packet is coming
from a really tagged network.
This fix the Bridge Loop Avoidance behaviour which was not
able to send announces over VLAN interfaces.
Introduced by 0b1da1765fdb00ca5d53bc95c9abc70dfc9aae5b
("batman-adv: change VID semantic in the BLA code")
Signed-off-by: Antonio Quartulli <antonio@open-mesh.org>
Acked-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: Marek Lindner <mareklindner@neomailbox.ch>
---
net/batman-adv/soft-interface.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/batman-adv/soft-interface.c b/net/batman-adv/soft-interface.c
index 4493913..813db4e 100644
--- a/net/batman-adv/soft-interface.c
+++ b/net/batman-adv/soft-interface.c
@@ -168,6 +168,7 @@ static int batadv_interface_tx(struct sk_buff *skb,
case ETH_P_8021Q:
vhdr = (struct vlan_ethhdr *)skb->data;
vid = ntohs(vhdr->h_vlan_TCI) & VLAN_VID_MASK;
+ vid |= BATADV_VLAN_HAS_TAG;
if (vhdr->h_vlan_encapsulated_proto != ethertype)
break;
@@ -331,6 +332,7 @@ void batadv_interface_rx(struct net_device *soft_iface,
case ETH_P_8021Q:
vhdr = (struct vlan_ethhdr *)skb->data;
vid = ntohs(vhdr->h_vlan_TCI) & VLAN_VID_MASK;
+ vid |= BATADV_VLAN_HAS_TAG;
if (vhdr->h_vlan_encapsulated_proto != ethertype)
break;
--
1.8.1.5
^ permalink raw reply related
* Re: mvneta: oops in __rcu_read_lock on mirabox
From: Ethan Tuttle @ 2013-09-18 6:30 UTC (permalink / raw)
To: Willy Tarreau
Cc: Russell King - ARM Linux, Thomas Petazzoni, Andrew Lunn,
Jason Cooper, netdev, Ezequiel Garcia, Gregory Clément,
linux-arm-kernel
In-Reply-To: <20130917060111.GB9325@1wt.eu>
On Mon, Sep 16, 2013 at 11:01 PM, Willy Tarreau <w@1wt.eu> wrote:
> Next step should be that you test both kernels to be sure.
Thanks for the kernel images, Willy. I'm still experimenting but
initial results are strange: I haven't seen a crash from the -ethan
image you provided, nor by a kernel with that config that I built
myself. The config is only different from my crashing config by a few
options. So perhaps some combination of options prevents the crash.
I'll see if I can narrow it down.
For a moment I thought I found a likely culprit: all along I've been
loading my kernel in to 0x02000000 in uboot, while the stock uboot env
(and Willy) uses 0x6400000. But I've seen at least one
__rcu_read_lock oops since switching to 0x6400000. So I guess I can
rule that out.
Thanks,
Ethan
^ permalink raw reply
* Re: [RFC PATCH v2 net-next 0/2] BPF and OVS extensions
From: Alexei Starovoitov @ 2013-09-18 6:58 UTC (permalink / raw)
To: David Laight
Cc: David S. Miller, netdev, Eric Dumazet, Alexey Kuznetsov,
James Morris, Hideaki YOSHIFUJI, Patrick McHardy, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, Daniel Borkmann, Paul E. McKenney,
Xi Wang, David Howells, Cong Wang, Jesse Gross, Pravin B Shelar,
Ben Pfaff, Thomas Graf, dev
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B733F@saturn3.aculab.com>
On Tue, Sep 17, 2013 at 1:40 AM, David Laight <David.Laight@aculab.com> wrote:
>
> > Patch 1/2: generic BPF extension
> > Original A and X 32-bit BPF registers are replaced with ten 64-bit registers.
> > bpf opcode encoding kept the same. load/store were generalized to access stack,
> > bpf_tables and bpf_context.
> > BPF program interfaces to outside world via tables that it can read and write,
> > and via bpf_context which is in/out blob of data.
> > Other kernel components can provide callbacks to tailor BPF to specific needs.
>
> As has been recently pointed out on some of the NetBSD lists
> one of the points about BPF is that the filters are deterministic
> and easily proven to both terminate and have no unwanted side effects.
>
> The functionality you are proposing breaks both of these assumptions.
Proposed BPF extensions keep both of these assumptions. See bpf_check.c
It guarantees that BPF program terminates, all memory/register
accesses are valid,
function arguments are verified, no unknown insns, register/stack is initialized
before read, aligned, etc
BPF checker algorithm is not as trivial as it was before, but still
straightforward and simple.
It helped us catch some interesting bugs in BPF GCC backend. In one
case we miscalculated
branch target by one insn and since register read came before it was
written, BPF checker caught it.
In another case we improperly coded branch conditions in cbranchdi4
(see gcc/config/bpf/bpf.md on github). Again it caught it.
Using compiler is not mandatory. One can code BPF in assembler in the
same way it was done before,
but doing it in C is easier to understand.
Thanks
Alexei
^ permalink raw reply
* the meaning of "shaper" in the changelog of commit baafc77b32f64
From: Duan Jiong @ 2013-09-18 7:24 UTC (permalink / raw)
To: saurabh; +Cc: netdev
Hi,
Now i'm reproducing the bug you found in commit
baafc77b32f64（"net/ipv4: ip_vti clear skb cb before tunneling"),
and i don't know the meaning of "shaper" in the changelog. can you
explain it?
Thanks，
Duan
^ permalink raw reply
* Re: [PATCH net-next v2 1/2] ipv4: IP_TOS and IP_TTL can be specified as ancillary data
From: Francesco Fusco @ 2013-09-18 8:16 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20130917.204648.339747836268253489.davem@davemloft.net>
Thanks David.
I will resubmit the patches as they are as soon as the merge window
opens again.
Best,
Francesco
On 09/18/2013 02:46 AM, David Miller wrote:
> From: Francesco Fusco <ffusco@redhat.com>
> Date: Wed, 28 Aug 2013 09:56:32 +0200
>
>> On 08/27/2013 08:56 PM, David Miller wrote:
>>> From: Francesco Fusco <ffusco@redhat.com>
>>> Date: Fri, 23 Aug 2013 14:19:32 +0200
>>>
>>>> - changed the icmp_cookie ttl field from __s16 to __u8.
>>>> A value of 0 means that the TTL has not been specified
>>>
>>> Sorry, I have to ask you to change the ttl field type back to __s16
>>> and use "-1" to mean not-specified.
>>>
>>> Zero is a valid TTL setting and it means to not allow the
>>> packet to leave this host.
>>
>> Actually setsockopt() does not allow a TTL value of zero:
>>
>> From net/ipv4/ip_sockglue.c::do_ip_setsockopt()
>
> Indeed, you are right.
>
> Please resubmit these patches for the next merge window.
>
> Thank you.
>
^ 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