* Re: [PATCH net-next 1/2] PPC: net: bpf_jit_comp: add XOR instruction for BPF JIT
From: Benjamin Herrenschmidt @ 2012-11-10 1:50 UTC (permalink / raw)
To: David Miller; +Cc: dxchgb, matt, netdev
In-Reply-To: <20121109.164019.1147290535167723496.davem@davemloft.net>
On Fri, 2012-11-09 at 16:40 -0500, David Miller wrote:
> From: Daniel Borkmann <dxchgb@gmail.com>
> Date: Thu, 8 Nov 2012 22:39:41 +0100
>
> > This patch is a follow-up for patch "filter: add XOR instruction for use
> > with X/K" that implements BPF PowerPC JIT parts for the BPF XOR operation.
> >
> > Signed-off-by: Daniel Borkmann <daniel.borkmann@tik.ee.ethz.ch>
>
> Could a powerpc person please review these two patches so that I can
> toss them into net-next (where the dependency is)?
Sure, travelling right now, will try to find somebody or will do it
myself some time next week.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH net-next] 8021q: validate SAN MAC address
From: Michael Chan @ 2012-11-10 0:44 UTC (permalink / raw)
To: Ben Hutchings; +Cc: davem, netdev
In-Reply-To: <1352507762.3159.26.camel@bwh-desktop.uk.solarflarecom.com>
On Sat, 2012-11-10 at 00:36 +0000, Ben Hutchings wrote:
> On Fri, 2012-11-09 at 16:25 -0800, Michael Chan wrote:
> > On Fri, 2012-11-09 at 23:02 +0000, Ben Hutchings wrote:
> > > > Some bnx2x multi-function devices are configured for FCoE only in
> > > > a PCI function and only has a SAN MAC address. The current code
> > > > will fail ->ndo_validate_addr() when a VLAN device is brought up
> > > > over such a device.
> > > >
> > > > Check the real device's dev_addrs[] for a valid SAN MAC address
> > > > when validating the MAC address if the regular MAC address is not
> > > > valid.
> > >
> > > So the VLAN device's own address is being completely ignored?
> >
> > No, it is not being ignored. We validate the VLAN's regular MAC address
> > first. If it is invalid, check further to see if the real device has a
> > SAN MAC address.
>
> Sure, but in the case that the VLAN device is layered on one of these
> FCoE SAN devices, the VLAN device's address isn't validated. Which
> presumably means it's not going to be used at all...
>
> What does the VLAN device actually do in this case? Is it a way of
> setting a VID to be used for the FCoE encapsulation?
Yeah, fcoemon first gets the SAN MAC from the physical device (using
DCBNL) and uses it send out packets for VLAN discovery. After the VLAN
has been discovered, it will create the VLAN device over the physical
device and will try to bring it up. After that, fcoemon will continue
to use the SAN MAC over the VLAN device.
^ permalink raw reply
* Re: [PATCH net-next 0/3] Advertise tunnel parameters via netlink
From: David Miller @ 2012-11-10 0:36 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: eric.dumazet, netdev
In-Reply-To: <1352477401-19044-1-git-send-email-nicolas.dichtel@6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Fri, 9 Nov 2012 17:09:58 +0100
> The goal of this serie is to advertise tunnel parameters via netlink.
>
> It is usefull for daemons that monitor link event to have the full parameters
> of these interfaces.
>
> The patch against iproute2 will be sent once the patches are included and
> net-next merged. I can send it on demand.
>
> v2: remove last patch of the serie, which was a bug fix.
> enhance commit log.
>
> Comments are welcome.
Really nice, all applied, thanks Nicolas.
^ permalink raw reply
* Re: [PATCH net-next] 8021q: validate SAN MAC address
From: Ben Hutchings @ 2012-11-10 0:36 UTC (permalink / raw)
To: Michael Chan; +Cc: davem, netdev
In-Reply-To: <1352507122.6276.2.camel@LTIRV-MCHAN1.corp.ad.broadcom.com>
On Fri, 2012-11-09 at 16:25 -0800, Michael Chan wrote:
> On Fri, 2012-11-09 at 23:02 +0000, Ben Hutchings wrote:
> > > Some bnx2x multi-function devices are configured for FCoE only in
> > > a PCI function and only has a SAN MAC address. The current code
> > > will fail ->ndo_validate_addr() when a VLAN device is brought up
> > > over such a device.
> > >
> > > Check the real device's dev_addrs[] for a valid SAN MAC address
> > > when validating the MAC address if the regular MAC address is not
> > > valid.
> >
> > So the VLAN device's own address is being completely ignored?
>
> No, it is not being ignored. We validate the VLAN's regular MAC address
> first. If it is invalid, check further to see if the real device has a
> SAN MAC address.
Sure, but in the case that the VLAN device is layered on one of these
FCoE SAN devices, the VLAN device's address isn't validated. Which
presumably means it's not going to be used at all...
What does the VLAN device actually do in this case? Is it a way of
setting a VID to be used for the FCoE encapsulation?
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 net-next] 8021q: validate SAN MAC address
From: Michael Chan @ 2012-11-10 0:25 UTC (permalink / raw)
To: Ben Hutchings; +Cc: davem, netdev
In-Reply-To: <1352502165.3159.21.camel@bwh-desktop.uk.solarflarecom.com>
On Fri, 2012-11-09 at 23:02 +0000, Ben Hutchings wrote:
> > Some bnx2x multi-function devices are configured for FCoE only in
> > a PCI function and only has a SAN MAC address. The current code
> > will fail ->ndo_validate_addr() when a VLAN device is brought up
> > over such a device.
> >
> > Check the real device's dev_addrs[] for a valid SAN MAC address
> > when validating the MAC address if the regular MAC address is not
> > valid.
>
> So the VLAN device's own address is being completely ignored?
No, it is not being ignored. We validate the VLAN's regular MAC address
first. If it is invalid, check further to see if the real device has a
SAN MAC address.
^ permalink raw reply
* [PATCH] vxlan: Fix error that was resulting in VXLAN MTU size being 10 bytes too large
From: Alexander Duyck @ 2012-11-09 23:35 UTC (permalink / raw)
To: netdev; +Cc: davem, shemminger
This change fixes an issue I found where VXLAN frames were fragmented when
they were up to the VXLAN MTU size. I root caused the issue to the fact that
the headroom was 4 + 20 + 8 + 8. This math doesn't appear to be correct
because we are not inserting a VLAN header, but instead a 2nd Ethernet header.
As such the math for the overhead should be 20 + 8 + 8 + 14 to account for the
extra headers that are inserted for VXLAN.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
---
drivers/net/vxlan.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index 410ebc8..0b75c19 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -51,8 +51,8 @@
#define VXLAN_N_VID (1u << 24)
#define VXLAN_VID_MASK (VXLAN_N_VID - 1)
-/* VLAN + IP header + UDP + VXLAN */
-#define VXLAN_HEADROOM (4 + 20 + 8 + 8)
+/* IP header + UDP + VXLAN + Ethernet header */
+#define VXLAN_HEADROOM (20 + 8 + 8 + 14)
#define VXLAN_FLAGS 0x08000000 /* struct vxlanhdr.vx_flags required value. */
^ permalink raw reply related
* Re: [PATCH net-next] 8021q: validate SAN MAC address
From: Ben Hutchings @ 2012-11-09 23:02 UTC (permalink / raw)
To: Michael Chan; +Cc: davem, netdev
In-Reply-To: <1352501644-8444-1-git-send-email-mchan@broadcom.com>
On Fri, 2012-11-09 at 14:54 -0800, Michael Chan wrote:
> Some bnx2x multi-function devices are configured for FCoE only in
> a PCI function and only has a SAN MAC address. The current code
> will fail ->ndo_validate_addr() when a VLAN device is brought up
> over such a device.
>
> Check the real device's dev_addrs[] for a valid SAN MAC address
> when validating the MAC address if the regular MAC address is not
> valid.
So the VLAN device's own address is being completely ignored?
Ben.
> Signed-off-by: Michael Chan <mchan@broadcom.com>
> ---
> net/8021q/vlan_dev.c | 25 ++++++++++++++++++++++++-
> 1 files changed, 24 insertions(+), 1 deletions(-)
>
> diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
> index 6da96d4..9ef2d2e 100644
> --- a/net/8021q/vlan_dev.c
> +++ b/net/8021q/vlan_dev.c
> @@ -346,6 +346,29 @@ static int vlan_dev_stop(struct net_device *dev)
> return 0;
> }
>
> +static int vlan_dev_validate_addr(struct net_device *dev)
> +{
> + if (!is_valid_ether_addr(dev->dev_addr)) {
> + struct net_device *real_dev = vlan_dev_priv(dev)->real_dev;
> +
> + if (real_dev) {
> + struct netdev_hw_addr *ha;
> +
> + rcu_read_lock();
> + for_each_dev_addr(real_dev, ha) {
> + if ((ha->type == NETDEV_HW_ADDR_T_SAN) &&
> + (is_valid_ether_addr(ha->addr))) {
> + rcu_read_unlock();
> + return 0;
> + }
> + }
> + rcu_read_unlock();
> + }
> + return -EADDRNOTAVAIL;
> + }
> + return 0;
> +}
> +
> static int vlan_dev_set_mac_address(struct net_device *dev, void *p)
> {
> struct net_device *real_dev = vlan_dev_priv(dev)->real_dev;
> @@ -734,7 +757,7 @@ static const struct net_device_ops vlan_netdev_ops = {
> .ndo_open = vlan_dev_open,
> .ndo_stop = vlan_dev_stop,
> .ndo_start_xmit = vlan_dev_hard_start_xmit,
> - .ndo_validate_addr = eth_validate_addr,
> + .ndo_validate_addr = vlan_dev_validate_addr,
> .ndo_set_mac_address = vlan_dev_set_mac_address,
> .ndo_set_rx_mode = vlan_dev_set_rx_mode,
> .ndo_change_rx_flags = vlan_dev_change_rx_flags,
--
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
* [PATCH net-next] 8021q: validate SAN MAC address
From: Michael Chan @ 2012-11-09 22:54 UTC (permalink / raw)
To: davem; +Cc: netdev, Michael Chan
Some bnx2x multi-function devices are configured for FCoE only in
a PCI function and only has a SAN MAC address. The current code
will fail ->ndo_validate_addr() when a VLAN device is brought up
over such a device.
Check the real device's dev_addrs[] for a valid SAN MAC address
when validating the MAC address if the regular MAC address is not
valid.
Signed-off-by: Michael Chan <mchan@broadcom.com>
---
net/8021q/vlan_dev.c | 25 ++++++++++++++++++++++++-
1 files changed, 24 insertions(+), 1 deletions(-)
diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
index 6da96d4..9ef2d2e 100644
--- a/net/8021q/vlan_dev.c
+++ b/net/8021q/vlan_dev.c
@@ -346,6 +346,29 @@ static int vlan_dev_stop(struct net_device *dev)
return 0;
}
+static int vlan_dev_validate_addr(struct net_device *dev)
+{
+ if (!is_valid_ether_addr(dev->dev_addr)) {
+ struct net_device *real_dev = vlan_dev_priv(dev)->real_dev;
+
+ if (real_dev) {
+ struct netdev_hw_addr *ha;
+
+ rcu_read_lock();
+ for_each_dev_addr(real_dev, ha) {
+ if ((ha->type == NETDEV_HW_ADDR_T_SAN) &&
+ (is_valid_ether_addr(ha->addr))) {
+ rcu_read_unlock();
+ return 0;
+ }
+ }
+ rcu_read_unlock();
+ }
+ return -EADDRNOTAVAIL;
+ }
+ return 0;
+}
+
static int vlan_dev_set_mac_address(struct net_device *dev, void *p)
{
struct net_device *real_dev = vlan_dev_priv(dev)->real_dev;
@@ -734,7 +757,7 @@ static const struct net_device_ops vlan_netdev_ops = {
.ndo_open = vlan_dev_open,
.ndo_stop = vlan_dev_stop,
.ndo_start_xmit = vlan_dev_hard_start_xmit,
- .ndo_validate_addr = eth_validate_addr,
+ .ndo_validate_addr = vlan_dev_validate_addr,
.ndo_set_mac_address = vlan_dev_set_mac_address,
.ndo_set_rx_mode = vlan_dev_set_rx_mode,
.ndo_change_rx_flags = vlan_dev_change_rx_flags,
--
1.7.1
^ permalink raw reply related
* Re: essentially offline...
From: Hannes Frederic Sowa @ 2012-11-09 22:30 UTC (permalink / raw)
To: David Miller; +Cc: netdev, netfilter-devel, linux-wireless
In-Reply-To: <20121108.150930.2104308040240146535.davem@davemloft.net>
On Thu, Nov 08, 2012 at 03:09:30PM -0500, David Miller wrote:
> Don't ask about patch status, that's what the heck patchwork
> is for. If you're patch isn't there and active and you think
> it needs to bee considered seriously, REPOST it, DON'T ASK ME
> about a patch I already moved out of my TODO list. That's more
> work for me.
Actually, thanks for using patchwork and providing timely feedback on nearly
every patch which gets posted here!
^ permalink raw reply
* Re: [PATCH] [trivial] isdn: Fix typo in drivers/isdn
From: David Miller @ 2012-11-09 22:12 UTC (permalink / raw)
To: standby24x7; +Cc: linux-kernel, trivial, isdn, netdev
In-Reply-To: <1352473369-13613-1-git-send-email-standby24x7@gmail.com>
From: Masanari Iida <standby24x7@gmail.com>
Date: Sat, 10 Nov 2012 00:02:49 +0900
> Correct spelling typo in printk within drivers/isdn
>
> Signed-off-by: Masanari Iida <standby24x7@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] gre6: fix rtnl dump messages
From: David Miller @ 2012-11-09 22:11 UTC (permalink / raw)
To: eric.dumazet; +Cc: nicolas.dichtel, netdev
In-Reply-To: <1352477346.19779.710.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 09 Nov 2012 08:09:06 -0800
> On Fri, 2012-11-09 at 16:34 +0100, Nicolas Dichtel wrote:
>> Spotted after a code review.
>> Introduced by c12b395a46646bab69089ce7016ac78177f6001f (gre: Support GRE over
>> IPv6).
>>
>> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
>> ---
>> v2: rebase the patch against net
>> add the commit that introduces the bug
>
> Thanks !
>
> Acked-by: Eric Dumazet <edumazet@google.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH] gianfar: ethernet vanishes after restoring from hibernation
From: David Miller @ 2012-11-09 22:08 UTC (permalink / raw)
To: paul.gortmaker; +Cc: netdev, dongsheng.wang, claudiu.manoil
In-Reply-To: <1352472231-17927-1-git-send-email-paul.gortmaker@windriver.com>
From: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Fri, 9 Nov 2012 09:43:51 -0500
> From: Wang Dongsheng <dongsheng.wang@freescale.com>
>
> If a gianfar ethernet device is down prior to hibernating a
> system, it will no longer be present upon system restore.
>
> For example:
>
> ~# ifconfig eth0 down
> ~# echo disk > /sys/power/state
>
> <trigger a restore from hibernation>
>
> ~# ifconfig eth0 up
> SIOCSIFFLAGS: No such device
>
> This happens because the restore function bails out early upon
> finding devices that were not up at hibernation. In doing so,
> it never gets to the netif_device_attach call at the end of
> the restore function. Adding the netif_device_attach as done
> here also makes the gfar_restore code consistent with what is
> done in the gfar_resume code.
>
> Cc: Claudiu Manoil <claudiu.manoil@freescale.com>
> Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com>
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH][net-next v2] gianfar: Fix alloc_skb_resources on -ENOMEM cleanup path
From: David Miller @ 2012-11-09 22:08 UTC (permalink / raw)
To: claudiu.manoil; +Cc: netdev, paul.gortmaker
In-Reply-To: <1352448701-14041-1-git-send-email-claudiu.manoil@freescale.com>
From: Claudiu Manoil <claudiu.manoil@freescale.com>
Date: Fri, 9 Nov 2012 10:11:41 +0200
> Should gfar_init_bds() return with -ENOMEM inside gfar_alloc_skb_resources(),
> free_skb_resources() will be called twice in a row on the "cleanup" path,
> leading to duplicate kfree() calls for rx_|tx_queue->rx_|tx_skbuff resulting
> in segmentation fault.
> This patch prevents the segmentation fault to happen in the future
> (rx_|tx_sbkbuff set to NULL), and corrects the error path handling
> for gfar_init_bds().
>
> Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
>
> Signed-off-by: Claudiu Manoil <claudiu.manoil@freescale.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] virtio_net: use net_*_ratelimited() helpers
From: David Miller @ 2012-11-09 22:05 UTC (permalink / raw)
To: amwang; +Cc: netdev, rusty, mst
In-Reply-To: <1352432848-16747-1-git-send-email-amwang@redhat.com>
From: Cong Wang <amwang@redhat.com>
Date: Fri, 9 Nov 2012 11:47:28 +0800
> These can be converted to net_*_ratelimited().
>
> Cc: Rusty Russell <rusty@rustcorp.com.au>
> Cc: "Michael S. Tsirkin" <mst@redhat.com>
> Cc: David Miller <davem@davemloft.net>
> Signed-off-by: Cong Wang <amwang@redhat.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] vmxnet3: convert BUG_ON(true) into a simple BUG()
From: David Miller @ 2012-11-09 22:03 UTC (permalink / raw)
To: sbhatewara; +Cc: sasha.levin, pv-drivers, netdev, linux-kernel
In-Reply-To: <967392202.19635700.1352440936686.JavaMail.root@vmware.com>
From: Shreyas Bhatewara <sbhatewara@vmware.com>
Date: Thu, 8 Nov 2012 22:02:16 -0800 (PST)
>
> ----- Original Message -----
>> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
>> ---
>> drivers/net/vmxnet3/vmxnet3_drv.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Signed-off-by: Shreyas N Bhatewara <sbhatewara@vmware.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] ipip: add GSO support
From: David Miller @ 2012-11-09 22:01 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, maze, therbert, willemb
In-Reply-To: <1352404792.19779.88.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 08 Nov 2012 11:59:52 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> In commit 6b78f16e4b (gre: add GSO support) we added GSO support to GRE
> tunnels.
>
> This patch does the same for IPIP tunnels.
>
> Performance of single TCP flow over an IPIP tunnel is increased by 40%
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] usbnet: ratelimit kevent may have been dropped warnings
From: David Miller @ 2012-11-09 22:00 UTC (permalink / raw)
To: steve.glendinning; +Cc: oneukum, netdev
In-Reply-To: <1352391981-15692-1-git-send-email-steve.glendinning@shawell.net>
From: Steve Glendinning <steve.glendinning@shawell.net>
Date: Thu, 8 Nov 2012 16:26:21 +0000
> when something goes wrong, a flood of these messages can be
> generated by usbnet (thousands per second). This doesn't
> generally *help* the condition so this patch ratelimits the
> rate of their generation.
>
> There's an underlying problem in usbnet's kevent deferral
> mechanism which needs fixing, specifically that events *can*
> get dropped and not handled. This patch doesn't address this,
> but just mitigates fallout caused by the current implemention.
>
> Signed-off-by: Steve Glendinning <steve.glendinning@shawell.net>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] ipv4: Handle very small SO_SNDTIMEOs
From: David Miller @ 2012-11-09 21:58 UTC (permalink / raw)
To: andi; +Cc: netdev, ak
In-Reply-To: <1352389908-28587-1-git-send-email-andi@firstfloor.org>
From: Andi Kleen <andi@firstfloor.org>
Date: Thu, 8 Nov 2012 07:51:48 -0800
> From: Andi Kleen <ak@linux.intel.com>
>
> When the SO_SNDTIMEO timeout is short enough it may round down to zero
> jiffies. This causes unexpected behaviour because the socket
> essentially becomes always non blocking.
>
> Round up the timeout to at least two jiffies, so that
> we guarantee waiting for at least some time. With one jiffie
> we could potentially still wait zero time because we might
> be just at the edge of the jiffie, and if it flips over
> in the middle of the check it could be still zero.
>
> This has been observed in a real application.
>
> Signed-off-by: Andi Kleen <ak@linux.intel.com>
Please use usecs_to_jiffies() and, if necessary, implement the policy
there.
I'm sure that things like poll() et al. have similar if not identical
issues. Therefore it's better to have some generic spot deal with
this problem generically.
^ permalink raw reply
* Re: [PATCH net-next] doc: packet_mmap: update doc to implementation status
From: David Miller @ 2012-11-09 21:46 UTC (permalink / raw)
To: dxchgb; +Cc: ronny.meeus, uaca, johann.baudy, netdev
In-Reply-To: <20121108123700.GA25799@thinkbox>
From: Daniel Borkmann <dxchgb@gmail.com>
Date: Thu, 8 Nov 2012 13:37:01 +0100
> This improves the packet_mmap.txt document in the following ways:
>
> * Add initial information about different TPACKET versions
> * Add initial information about packet fanout
> * Add pointer to BPF document (since this also could be of interest)
> * 'Fix' minor, rather cosmetic things
>
> Information partially taken from related commit messages.
>
> Reported-by: Ronny Meeus <ronny.meeus@gmail.com>
> Signed-off-by: Daniel Borkmann <daniel.borkmann@tik.ee.ethz.ch>
Thanks for doing this, applied.
^ permalink raw reply
* Re: [PATCH net-next 1/2] PPC: net: bpf_jit_comp: add XOR instruction for BPF JIT
From: David Miller @ 2012-11-09 21:40 UTC (permalink / raw)
To: dxchgb; +Cc: matt, benh, netdev
In-Reply-To: <20121108213939.GA29696@thinkbox>
From: Daniel Borkmann <dxchgb@gmail.com>
Date: Thu, 8 Nov 2012 22:39:41 +0100
> This patch is a follow-up for patch "filter: add XOR instruction for use
> with X/K" that implements BPF PowerPC JIT parts for the BPF XOR operation.
>
> Signed-off-by: Daniel Borkmann <daniel.borkmann@tik.ee.ethz.ch>
Could a powerpc person please review these two patches so that I can
toss them into net-next (where the dependency is)?
Thanks!
^ permalink raw reply
* Re: [PATCH net-next 1/2] ARM: net: bpf_jit_32: add XOR instruction for BPF JIT
From: David Miller @ 2012-11-09 21:39 UTC (permalink / raw)
To: dxchgb; +Cc: mgherzan, arnd, netdev, linux-arm-kernel
In-Reply-To: <20121108012828.GA23143@thinkbox>
From: Daniel Borkmann <dxchgb@gmail.com>
Date: Thu, 8 Nov 2012 02:28:28 +0100
> This patch is a follow-up for patch "filter: add XOR instruction for use
> with X/K" that implements BPF ARM JIT parts for the BPF XOR operation.
>
> Signed-off-by: Daniel Borkmann <daniel.borkmann@tik.ee.ethz.ch>
> Cc: Mircea Gherzan <mgherzan@gmail.com>
> Cc: Arnd Bergmann <arnd@arndb.de>
Could an ARM person please review and ACK these two patches so that
I can toss them into net-next (where the dependency is)?
Thanks!
^ permalink raw reply
* Re: [PATCH net-next] phylib: mdio: Add sysfs attribute for PHY identifiers.
From: David Miller @ 2012-11-09 21:38 UTC (permalink / raw)
To: nbowler; +Cc: netdev
In-Reply-To: <1352305234-22340-1-git-send-email-nbowler@elliptictech.com>
From: Nick Bowler <nbowler@elliptictech.com>
Date: Wed, 7 Nov 2012 11:20:34 -0500
> This adds a phy_id sysfs attribute to MDIO devices, containing the
> 32-bit PHY identifier reported by the device. This attribute can
> be useful when debugging problems related to phy drivers. Other
> enumerable buses already have similar attributes.
>
> Signed-off-by: Nick Bowler <nbowler@elliptictech.com>
Seems reasonable, applied, thanks.
^ permalink raw reply
* Re: [PATCH v3 8/7] pppoatm: fix missing wakeup in pppoatm_send()
From: David Miller @ 2012-11-09 21:30 UTC (permalink / raw)
To: dwmw2; +Cc: krzysiek, netdev, linux-kernel, chas
In-Reply-To: <1352292734.7340.35.camel@shinybook.infradead.org>
From: David Woodhouse <dwmw2@infradead.org>
Date: Wed, 07 Nov 2012 12:52:14 +0000
> Now that we can return zero from pppoatm_send() for reasons *other* than
> the queue being full, that means we can't depend on a subsequent call to
> pppoatm_pop() waking the queue, and we might leave it stalled
> indefinitely.
>
> Fix this by immediately scheduling the wakeup tasklet. As documented
> already elsewhere, the PPP channel's ->downl lock protects against the
> wakeup happening too soon and effectively being missed.
>
> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
> ----
> Untested.
> With this sorted, Acked-By: David Woodhouse <David.Woodhouse@intel.com<
> to the other seven. Thanks.
I don't know what to do with this patch because I don't have any
context whatsoever.
So I'm tossing it, please resubmit it when it's meant to be
applied, and with some context.
^ permalink raw reply
* Re: [PATCH 4/4] Make the wanxl firmware array const
From: David Miller @ 2012-11-09 21:29 UTC (permalink / raw)
To: dhowells; +Cc: khc, netdev, linux
In-Reply-To: <20121107123731.4147.57657.stgit@warthog.procyon.org.uk>
From: David Howells <dhowells@redhat.com>
Date: Wed, 07 Nov 2012 12:37:31 +0000
> Make the wanxl firmware array const so that it goes in the read-only section.
>
> Signed-off-by: David Howells <dhowells@redhat.com>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH 3/4] Fix the wanxl firmware to include missing constants
From: David Miller @ 2012-11-09 21:29 UTC (permalink / raw)
To: dhowells; +Cc: khc, netdev, linux
In-Reply-To: <20121107123724.4147.98542.stgit@warthog.procyon.org.uk>
From: David Howells <dhowells@redhat.com>
Date: Wed, 07 Nov 2012 12:37:24 +0000
> Fix the wanxl firmware to include missing constants such as PARITY_NONE. It
> should be #including the linux/hdlc/ioctl.h header.
>
> To make this work, we also have to guard parts of ioctl.h with !__ASSEMBLY__.
>
> Signed-off-by: David Howells <dhowells@redhat.com>
Applied to net-next.
^ 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