* [PATCH v2 3/6] emulex: Use skb_put_padto instead of skb_padto() and skb->len assignment
From: Alexander Duyck @ 2014-12-03 16:17 UTC (permalink / raw)
To: netdev; +Cc: davem
In-Reply-To: <20141203161440.9223.39633.stgit@ahduyck-vm-fedora20>
Signed-off-by: Alexander Duyck <alexander.h.duyck@redhat.com>
---
drivers/net/ethernet/emulex/benet/be_main.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
index e0ab767..9461ad8 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -1017,9 +1017,8 @@ static struct sk_buff *be_xmit_workarounds(struct be_adapter *adapter,
* to pad short packets (<= 32 bytes) to a 36-byte length.
*/
if (unlikely(!BEx_chip(adapter) && skb->len <= 32)) {
- if (skb_padto(skb, 36))
+ if (skb_put_padto(skb, 36))
return NULL;
- skb->len = 36;
}
if (BEx_chip(adapter) || lancer_chip(adapter)) {
^ permalink raw reply related
* [PATCH v2 1/6] net: Add functions for handling padding frame and adding to length
From: Alexander Duyck @ 2014-12-03 16:17 UTC (permalink / raw)
To: netdev; +Cc: davem
In-Reply-To: <20141203161440.9223.39633.stgit@ahduyck-vm-fedora20>
This patch adds two new helper functions skb_put_padto and eth_skb_pad.
These functions deviate from the standard skb_pad or skb_padto in that they
will also update the length and tail pointers so that they reflect the
padding added to the frame.
The eth_skb_pad helper is meant to be used with Ethernet devices to update
either Rx or Tx frames so that they report the correct size. The
skb_put_padto helper is meant to be used primarily in the transmit path for
network devices that need frames to be padded up to some minimum size and
don't wish to simply update the length somewhere external to the frame.
The motivation behind this is that there are a number of implementations
throughout the network device drivers that are all doing the same thing,
but each a little bit differently and as a result several implementations
contain bugs such as updating the length without updating the tail offset
and other similar issues.
Signed-off-by: Alexander Duyck <alexander.h.duyck@redhat.com>
---
include/linux/etherdevice.h | 12 ++++++++++++
include/linux/skbuff.h | 24 +++++++++++++++++++++++-
2 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/include/linux/etherdevice.h b/include/linux/etherdevice.h
index 733980f..41c891d 100644
--- a/include/linux/etherdevice.h
+++ b/include/linux/etherdevice.h
@@ -392,4 +392,16 @@ static inline unsigned long compare_ether_header(const void *a, const void *b)
#endif
}
+/**
+ * eth_skb_pad - Pad buffer to mininum number of octets for Ethernet frame
+ * @skb: Buffer to pad
+ *
+ * An Ethernet frame should have a minimum size of 60 bytes. This function
+ * takes short frames and pads them with zeros up to the 60 byte limit.
+ */
+static inline int eth_skb_pad(struct sk_buff *skb)
+{
+ return skb_put_padto(skb, ETH_ZLEN);
+}
+
#endif /* _LINUX_ETHERDEVICE_H */
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 7691ad5..d1e25750 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -2461,7 +2461,6 @@ static inline int skb_cow_head(struct sk_buff *skb, unsigned int headroom)
* is untouched. Otherwise it is extended. Returns zero on
* success. The skb is freed on error.
*/
-
static inline int skb_padto(struct sk_buff *skb, unsigned int len)
{
unsigned int size = skb->len;
@@ -2470,6 +2469,29 @@ static inline int skb_padto(struct sk_buff *skb, unsigned int len)
return skb_pad(skb, len - size);
}
+/**
+ * skb_put_padto - increase size and pad an skbuff up to a minimal size
+ * @skb: buffer to pad
+ * @len: minimal length
+ *
+ * Pads up a buffer to ensure the trailing bytes exist and are
+ * blanked. If the buffer already contains sufficient data it
+ * is untouched. Otherwise it is extended. Returns zero on
+ * success. The skb is freed on error.
+ */
+static inline int skb_put_padto(struct sk_buff *skb, unsigned int len)
+{
+ unsigned int size = skb->len;
+
+ if (unlikely(size < len)) {
+ len -= size;
+ if (skb_pad(skb, len))
+ return -ENOMEM;
+ __skb_put(skb, len);
+ }
+ return 0;
+}
+
static inline int skb_add_data(struct sk_buff *skb,
char __user *from, int copy)
{
^ permalink raw reply related
* [PATCH v2 0/6] net: Add helper for padding short Ethernet frames
From: Alexander Duyck @ 2014-12-03 16:17 UTC (permalink / raw)
To: netdev; +Cc: davem
This patch series adds a pair of helpers to pad short Ethernet frames. The
general idea is to clean up a number of code paths that were all writing
their own versions of the same or similar function.
An added advantage is that this will help to discourage introducing new
bugs as in at least one case I found the skb->len had been updated, but the
tail pointer update was overlooked.
v2: Added skb_put_padto for cases where length is not ETH_ZLEN
Updated intel drivers and emulex driver to use skb_put_padto
Updated eth_skb_pad to use skb_put_padto
---
Alexander Duyck (6):
net: Add functions for handling padding frame and adding to length
ethernet/intel: Use eth_skb_pad and skb_put_padto helpers
emulex: Use skb_put_padto instead of skb_padto() and skb->len assignment
niu: Use eth_skb_pad helper
myri10ge: use eth_skb_pad helper
r8169: Use eth_skb_pad function
drivers/net/ethernet/emulex/benet/be_main.c | 3 +--
drivers/net/ethernet/intel/e1000/e1000_main.c | 8 ++-----
drivers/net/ethernet/intel/e1000e/netdev.c | 8 ++-----
drivers/net/ethernet/intel/fm10k/fm10k_main.c | 11 +++-------
drivers/net/ethernet/intel/i40e/i40e_txrx.c | 8 ++-----
drivers/net/ethernet/intel/igb/igb_main.c | 19 ++++-------------
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 19 ++++-------------
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 11 +++-------
drivers/net/ethernet/myricom/myri10ge/myri10ge.c | 15 ++++---------
drivers/net/ethernet/realtek/r8169.c | 12 ++---------
drivers/net/ethernet/sun/niu.c | 9 ++------
include/linux/etherdevice.h | 12 +++++++++++
include/linux/skbuff.h | 24 ++++++++++++++++++++-
13 files changed, 67 insertions(+), 92 deletions(-)
--
^ permalink raw reply
* Re: [PATCH] SSB / B44: fix WOL for BCM4401
From: John W. Linville @ 2014-12-03 16:14 UTC (permalink / raw)
To: Michael Büsch
Cc: Larry Finger, Andrey Skvortsov, Rafael J. Wysocki, Gary.Zambrano,
netdev, linux-kernel, b43-dev, Rafał Miłecki
In-Reply-To: <20141203161855.50951aa8@wiggum>
On Wed, Dec 03, 2014 at 04:18:55PM +0100, Michael Büsch wrote:
> On Tue, 02 Dec 2014 16:23:49 -0600
> Larry Finger <Larry.Finger@lwfinger.net> wrote:
>
> > On 12/02/2014 02:12 PM, Michael Büsch wrote:
> > > On Tue, 2 Dec 2014 23:01:29 +0300
> > > Andrey Skvortsov <andrej.skvortzov@gmail.com> wrote:
> > >
> > >> On Mon, Dec 01, 2014 at 10:10:23PM +0100, Michael Büsch wrote:
> > >>> On Mon, 1 Dec 2014 23:46:38 +0300
> > >>> Andrey Skvortsov <andrej.skvortzov@gmail.com> wrote:
> > >>>
> > >>>> Wake On Lan was not working on laptop DELL Vostro 1500.
> > >>>> If WOL was turned on, BCM4401 was powered up in suspend mode. LEDs blinked.
> > >>>> But the laptop could not be woken up with the Magic Packet. The reason for
> > >>>> that was that PCIE was not enabled as a system wakeup source and
> > >>>> therefore the host PCI bridge was not powered up in suspend mode.
> > >>>> PCIE was not enabled in suspend by PM because no child devices were
> > >>>> registered as wakeup source during suspend process.
> > >>>> On laptop BCM4401 is connected through the SSB bus, that is connected to the
> > >>>> PCI-Express bus. SSB and B44 did not use standard PM wakeup functions
> > >>>> and did not forward wakeup settings to their parents.
> > >>>> To fix that B44 driver enables PM wakeup and registers new wakeup source
> > >>>> using device_set_wakeup_enable(). Wakeup is automatically reported to the parent SSB
> > >>>> bus via power.wakeup_path. SSB bus enables wakeup for the parent PCI bridge, if there is any
> > >>>> child devices with enabled wakeup functionality. All other steps are
> > >>>> done by PM core code.
> > >>>
> > >>> Thanks, this looks good.
> > >>> I assume you tested this (I currently don't have a device to test this).
> > >>
> > >> Sure, I've tested it. WOL from suspend is working and after resume from hibernate Ethernet is working too.
> > >
> > > That sounds good, indeed.
> > > I'd still prefer, if someone with b43 (wireless) would test it, too.
> >
> > I did a partial test with my PowerBook G4. With the patch installed, it would
> > both suspend and hibernate, but WOL would be impossible. This computer uses a
> > PCMCIA version of the BCM4318, and power is turned off to the PCMCIA card when
> > suspended or hibernating.
>
> Thanks for testing.
>
> John, can you take this one? Or do we need to split the b44 part out?
> I added my Signed-off.
Um, sure...3.19 is OK I presume?
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* [PATCH net-next] tipc: fix missing spinlock init and nullptr oops
From: erik.hugne @ 2014-12-03 15:58 UTC (permalink / raw)
To: netdev, tipc-discussion, jon.maloy, ying.xue, richard.alpe; +Cc: Erik Hugne
From: Erik Hugne <erik.hugne@ericsson.com>
commit 908344cdda80 ("tipc: fix bug in multicast congestion
handling") introduced two bugs with the bclink wakeup
function. This commit fixes the missing spinlock init for the
waiting_sks list. We also eliminate the race condition
between the waiting_sks length check/dequeue operations in
tipc_bclink_wakeup_users by simply removing the redundant
length check.
Signed-off-by: Erik Hugne <erik.hugne@ericsson.com>
Acked-by: Tero Aho <Tero.Aho@coriant.com>
---
net/tipc/bcast.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/net/tipc/bcast.c b/net/tipc/bcast.c
index f0761c7..96ceefe 100644
--- a/net/tipc/bcast.c
+++ b/net/tipc/bcast.c
@@ -233,8 +233,11 @@ static void bclink_retransmit_pkt(u32 after, u32 to)
*/
void tipc_bclink_wakeup_users(void)
{
- while (skb_queue_len(&bclink->link.waiting_sks))
- tipc_sk_rcv(skb_dequeue(&bclink->link.waiting_sks));
+ struct sk_buff *skb;
+
+ while ((skb = skb_dequeue(&bclink->link.waiting_sks)))
+ tipc_sk_rcv(skb);
+
}
/**
@@ -950,7 +953,7 @@ int tipc_bclink_init(void)
spin_lock_init(&bclink->lock);
__skb_queue_head_init(&bcl->outqueue);
__skb_queue_head_init(&bcl->deferred_queue);
- __skb_queue_head_init(&bcl->waiting_sks);
+ skb_queue_head_init(&bcl->waiting_sks);
bcl->next_out_no = 1;
spin_lock_init(&bclink->node.lock);
__skb_queue_head_init(&bclink->node.waiting_sks);
--
2.1.3
^ permalink raw reply related
* Re: [PATCH] bpf: arm64: lift restriction on last instruction
From: Alexei Starovoitov @ 2014-12-03 15:54 UTC (permalink / raw)
To: Zi Shen Lim
Cc: David S. Miller, Catalin Marinas, Will Deacon, Daniel Borkmann,
Network Development, linux-arm-kernel@lists.infradead.org, LKML
In-Reply-To: <1417595881-32218-1-git-send-email-zlim.lnx@gmail.com>
On Wed, Dec 3, 2014 at 12:38 AM, Zi Shen Lim <zlim.lnx@gmail.com> wrote:
> Earlier implementation assumed last instruction is BPF_EXIT.
> Since this is no longer a restriction in eBPF, we remove this
> limitation.
>
> Per Alexei Starovoitov [1]:
>> classic BPF has a restriction that last insn is always BPF_RET.
>> eBPF doesn't have BPF_RET instruction and this restriction.
>> It has BPF_EXIT insn which can appear anywhere in the program
>> one or more times and it doesn't have to be last insn.
>
> [1] https://lkml.org/lkml/2014/11/27/2
>
> Fixes: e54bcde3d69d ("arm64: eBPF JIT compiler")
> Signed-off-by: Zi Shen Lim <zlim.lnx@gmail.com>
yours is cleaner than my own attempt to fix it.
Thanks!
Acked-by: Alexei Starovoitov <ast@plumgrid.com>
^ permalink raw reply
* Re: [PATCH v2 net] bpf: x86: fix epilogue generation for eBPF programs
From: Alexei Starovoitov @ 2014-12-03 15:51 UTC (permalink / raw)
To: Z Lim
Cc: David S. Miller, Eric Dumazet, Daniel Borkmann, H. Peter Anvin,
Thomas Gleixner, Ingo Molnar, Network Development, LKML
In-Reply-To: <CABg9mcso+YeS-sgAQmAu6MvsfNnzrKYuUG8m+WYJmxdaxbGmPA@mail.gmail.com>
On Tue, Dec 2, 2014 at 10:38 PM, Z Lim <zlim.lnx@gmail.com> wrote:
> Hi Alexei,
>
> On Sat, Nov 29, 2014 at 2:46 PM, Alexei Starovoitov <ast@plumgrid.com> wrote:
>> classic BPF has a restriction that last insn is always BPF_RET.
>> eBPF doesn't have BPF_RET instruction and this restriction.
>> It has BPF_EXIT insn which can appear anywhere in the program
>> one or more times and it doesn't have to be last insn.
>
> Just to confirm, in valid eBPF, BPF_EXIT *must* be present at least
> once, correct?
> Does an eBPF JIT implementation need to check for it?
yes. of course. At least one bpf_exit is always there
and there are no loops. verifier is checking for it.
So no need for jit to check it again.
> I'll cook up a patch for arm64 if you haven't already done so.
> Any related test case I should run through?
Pending socket samples are generating such code by llvm.
I was planning to add an explicit test to test_bpf, but feel free
to beat me to it.
^ permalink raw reply
* Re: [PATCH net] net: sctp: use MAX_HEADER for headroom reserve in output path
From: Vlad Yasevich @ 2014-12-03 15:32 UTC (permalink / raw)
To: Daniel Borkmann, davem; +Cc: linux-sctp, netdev, robert
In-Reply-To: <1417605238-9936-1-git-send-email-dborkman@redhat.com>
On 12/03/2014 06:13 AM, Daniel Borkmann wrote:
> To accomodate for enough headroom for tunnels, use MAX_HEADER instead
> of LL_MAX_HEADER. Robert reported that he has hit after roughly 40hrs
> of trinity an skb_under_panic() via SCTP output path (see reference).
> I couldn't reproduce it from here, but not using MAX_HEADER as elsewhere
> in other protocols might be one possible cause for this.
>
> In any case, it looks like accounting on chunks themself seems to look
> good as the skb already passed the SCTP output path and did not hit
> any skb_over_panic(). Given tunneling was enabled in his .config, the
> headroom would have been expanded by MAX_HEADER in this case.
>
> Reported-by: Robert Święcki <robert@swiecki.net>
> Reference: https://lkml.org/lkml/2014/12/1/507
> Fixes: 594ccc14dfe4d ("[SCTP] Replace incorrect use of dev_alloc_skb with alloc_skb in sctp_packet_transmit().")
> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Looks right. If sctp path is over any kind of L3 tunnel, we'll see this.
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
-vlad
> ---
> net/sctp/output.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/net/sctp/output.c b/net/sctp/output.c
> index 42dffd4..fc5e45b 100644
> --- a/net/sctp/output.c
> +++ b/net/sctp/output.c
> @@ -401,12 +401,12 @@ int sctp_packet_transmit(struct sctp_packet *packet)
> sk = chunk->skb->sk;
>
> /* Allocate the new skb. */
> - nskb = alloc_skb(packet->size + LL_MAX_HEADER, GFP_ATOMIC);
> + nskb = alloc_skb(packet->size + MAX_HEADER, GFP_ATOMIC);
> if (!nskb)
> goto nomem;
>
> /* Make sure the outbound skb has enough header room reserved. */
> - skb_reserve(nskb, packet->overhead + LL_MAX_HEADER);
> + skb_reserve(nskb, packet->overhead + MAX_HEADER);
>
> /* Set the owning socket so that we know where to get the
> * destination IP address.
>
^ permalink raw reply
* Re: [patch net-next 3/6] net_sched: cls_bpf: remove faulty use of list_for_each_entry_rcu
From: Jiri Pirko @ 2014-12-03 15:20 UTC (permalink / raw)
To: Jamal Hadi Salim; +Cc: netdev, davem
In-Reply-To: <547F203A.3080208@mojatatu.com>
Wed, Dec 03, 2014 at 03:37:46PM CET, jhs@mojatatu.com wrote:
>On 12/03/14 08:26, Jiri Pirko wrote:
>>Wed, Dec 03, 2014 at 01:51:15PM CET, jhs@mojatatu.com wrote:
>
>>>I think this may be problematic. Doesnt a flush operation also use the
>>>walker?
>>
>>I don't believe so. Just look at tc_dump_tfilter.
>>
>
>Actually we cant flush filters (we could actions).
>
>>But even if that would the the case, _rcu variant is wrong (yep, it
>>would have to be replaced by _safe variant then).
>>
>
>Sorry, still humping on the get part:
>that gets invoked for del for a filter that may be in use in the
>datapath. del uses rcu - should get not use rcu in such a case?
Yep, but this is updater, protected by rtnl. _rcu list travelsal variant
should be used by reader only (classify callback in cls case).
get op is only called from tc_ctl_tfilter which is always called with
rtnl held.
>
>cheers,
>jamal
^ permalink raw reply
* Re: [PATCH] SSB / B44: fix WOL for BCM4401
From: Michael Büsch @ 2014-12-03 15:18 UTC (permalink / raw)
To: Larry Finger, John W. Linville
Cc: Andrey Skvortsov, Rafael J. Wysocki, Gary.Zambrano, netdev,
linux-kernel, b43-dev, Rafał Miłecki
In-Reply-To: <547E3BF5.5060201@lwfinger.net>
[-- Attachment #1.1: Type: text/plain, Size: 2302 bytes --]
On Tue, 02 Dec 2014 16:23:49 -0600
Larry Finger <Larry.Finger@lwfinger.net> wrote:
> On 12/02/2014 02:12 PM, Michael Büsch wrote:
> > On Tue, 2 Dec 2014 23:01:29 +0300
> > Andrey Skvortsov <andrej.skvortzov@gmail.com> wrote:
> >
> >> On Mon, Dec 01, 2014 at 10:10:23PM +0100, Michael Büsch wrote:
> >>> On Mon, 1 Dec 2014 23:46:38 +0300
> >>> Andrey Skvortsov <andrej.skvortzov@gmail.com> wrote:
> >>>
> >>>> Wake On Lan was not working on laptop DELL Vostro 1500.
> >>>> If WOL was turned on, BCM4401 was powered up in suspend mode. LEDs blinked.
> >>>> But the laptop could not be woken up with the Magic Packet. The reason for
> >>>> that was that PCIE was not enabled as a system wakeup source and
> >>>> therefore the host PCI bridge was not powered up in suspend mode.
> >>>> PCIE was not enabled in suspend by PM because no child devices were
> >>>> registered as wakeup source during suspend process.
> >>>> On laptop BCM4401 is connected through the SSB bus, that is connected to the
> >>>> PCI-Express bus. SSB and B44 did not use standard PM wakeup functions
> >>>> and did not forward wakeup settings to their parents.
> >>>> To fix that B44 driver enables PM wakeup and registers new wakeup source
> >>>> using device_set_wakeup_enable(). Wakeup is automatically reported to the parent SSB
> >>>> bus via power.wakeup_path. SSB bus enables wakeup for the parent PCI bridge, if there is any
> >>>> child devices with enabled wakeup functionality. All other steps are
> >>>> done by PM core code.
> >>>
> >>> Thanks, this looks good.
> >>> I assume you tested this (I currently don't have a device to test this).
> >>
> >> Sure, I've tested it. WOL from suspend is working and after resume from hibernate Ethernet is working too.
> >
> > That sounds good, indeed.
> > I'd still prefer, if someone with b43 (wireless) would test it, too.
>
> I did a partial test with my PowerBook G4. With the patch installed, it would
> both suspend and hibernate, but WOL would be impossible. This computer uses a
> PCMCIA version of the BCM4318, and power is turned off to the PCMCIA card when
> suspended or hibernating.
Thanks for testing.
John, can you take this one? Or do we need to split the b44 part out?
I added my Signed-off.
--
Michael
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: b44_wol.patch --]
[-- Type: text/x-patch, Size: 4400 bytes --]
From: Andrey Skvortsov <andrej.skvortzov@gmail.com>
Subject: [PATCH] SSB / B44: fix WOL for BCM4401
Wake On Lan was not working on laptop DELL Vostro 1500.
If WOL was turned on, BCM4401 was powered up in suspend mode. LEDs blinked.
But the laptop could not be woken up with the Magic Packet. The reason for
that was that PCIE was not enabled as a system wakeup source and
therefore the host PCI bridge was not powered up in suspend mode.
PCIE was not enabled in suspend by PM because no child devices were
registered as wakeup source during suspend process.
On laptop BCM4401 is connected through the SSB bus, that is connected to the
PCI-Express bus. SSB and B44 did not use standard PM wakeup functions
and did not forward wakeup settings to their parents.
To fix that B44 driver enables PM wakeup and registers new wakeup source
using device_set_wakeup_enable(). Wakeup is automatically reported to the parent SSB
bus via power.wakeup_path. SSB bus enables wakeup for the parent PCI bridge, if there is any
child devices with enabled wakeup functionality. All other steps are
done by PM core code.
Signed-off-by: Andrey Skvortsov <Andrej.Skvortzov@gmail.com>
Signed-off-by: Michael Buesch <m@bues.ch>
---
drivers/net/ethernet/broadcom/b44.c | 2 ++
drivers/ssb/pcihost_wrapper.c | 33 ++++++++++++++++++++++-----------
2 files changed, 24 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/b44.c b/drivers/net/ethernet/broadcom/b44.c
index 416620f..ffeaf47 100644
--- a/drivers/net/ethernet/broadcom/b44.c
+++ b/drivers/net/ethernet/broadcom/b44.c
@@ -2104,6 +2104,7 @@ static int b44_set_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
bp->flags &= ~B44_FLAG_WOL_ENABLE;
spin_unlock_irq(&bp->lock);
+ device_set_wakeup_enable(bp->sdev->dev, wol->wolopts & WAKE_MAGIC);
return 0;
}
@@ -2452,6 +2453,7 @@ static int b44_init_one(struct ssb_device *sdev,
}
}
+ device_set_wakeup_capable(sdev->dev, true);
netdev_info(dev, "%s %pM\n", DRV_DESCRIPTION, dev->dev_addr);
return 0;
diff --git a/drivers/ssb/pcihost_wrapper.c b/drivers/ssb/pcihost_wrapper.c
index 69161bb..410215c 100644
--- a/drivers/ssb/pcihost_wrapper.c
+++ b/drivers/ssb/pcihost_wrapper.c
@@ -11,15 +11,17 @@
* Licensed under the GNU/GPL. See COPYING for details.
*/
+#include <linux/pm.h>
#include <linux/pci.h>
#include <linux/export.h>
#include <linux/slab.h>
#include <linux/ssb/ssb.h>
-#ifdef CONFIG_PM
-static int ssb_pcihost_suspend(struct pci_dev *dev, pm_message_t state)
+#ifdef CONFIG_PM_SLEEP
+static int ssb_pcihost_suspend(struct device *d)
{
+ struct pci_dev *dev = to_pci_dev(d);
struct ssb_bus *ssb = pci_get_drvdata(dev);
int err;
@@ -28,17 +30,23 @@ static int ssb_pcihost_suspend(struct pci_dev *dev, pm_message_t state)
return err;
pci_save_state(dev);
pci_disable_device(dev);
- pci_set_power_state(dev, pci_choose_state(dev, state));
+
+ /* if there is a wakeup enabled child device on ssb bus,
+ enable pci wakeup posibility. */
+ device_set_wakeup_enable(d, d->power.wakeup_path);
+
+ pci_prepare_to_sleep(dev);
return 0;
}
-static int ssb_pcihost_resume(struct pci_dev *dev)
+static int ssb_pcihost_resume(struct device *d)
{
+ struct pci_dev *dev = to_pci_dev(d);
struct ssb_bus *ssb = pci_get_drvdata(dev);
int err;
- pci_set_power_state(dev, PCI_D0);
+ pci_back_from_sleep(dev);
err = pci_enable_device(dev);
if (err)
return err;
@@ -49,10 +57,12 @@ static int ssb_pcihost_resume(struct pci_dev *dev)
return 0;
}
-#else /* CONFIG_PM */
-# define ssb_pcihost_suspend NULL
-# define ssb_pcihost_resume NULL
-#endif /* CONFIG_PM */
+
+static const struct dev_pm_ops ssb_pcihost_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(ssb_pcihost_suspend, ssb_pcihost_resume)
+};
+
+#endif /* CONFIG_PM_SLEEP */
static int ssb_pcihost_probe(struct pci_dev *dev,
const struct pci_device_id *id)
@@ -115,8 +125,9 @@ int ssb_pcihost_register(struct pci_driver *driver)
{
driver->probe = ssb_pcihost_probe;
driver->remove = ssb_pcihost_remove;
- driver->suspend = ssb_pcihost_suspend;
- driver->resume = ssb_pcihost_resume;
+#ifdef CONFIG_PM_SLEEP
+ driver->driver.pm = &ssb_pcihost_pm_ops;
+#endif
return pci_register_driver(driver);
}
--
1.7.2.5
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply related
* Re: [PATCH iproute2] ip link: Show devices by link type
From: Vadim Kochan @ 2014-12-03 15:08 UTC (permalink / raw)
To: Roopa Prabhu; +Cc: netdev@vger.kernel.org
In-Reply-To: <CAMw6YJKxPK_MKbCdxVwGSBXbZ7MqtXBA3FJ_ovw4-8heB6ci9w@mail.gmail.com>
I have sent v2 with subject "ip link: Show devices by type"
Regards,
Vadim
On Wed, Dec 3, 2014 at 4:47 PM, Vadim Kochan <vadim4j@gmail.com> wrote:
> OK, I can use it)
>
> Thanks,
>
> On Wed, Dec 3, 2014 at 4:40 PM, Roopa Prabhu <roopa@cumulusnetworks.com> wrote:
>> On 12/2/14, 5:13 PM, vadim4j@gmail.com wrote:
>>>
>>> On Tue, Dec 02, 2014 at 04:55:44PM -0800, Roopa Prabhu wrote:
>>>>>
>>>>> int master;
>>>>> + char *link_kind;
>>>>
>>>> The name can be just "kind", given all the others dont use the link
>>>> prefix
>>>>>
>>>>> } filter;
>>>
>>> OK
>>>
>>>>> + if (filter.link_kind && tb[IFLA_LINKINFO]) {
>>>>> + char *link_kind = parse_link_kind(tb[IFLA_LINKINFO]);
>>>>> + if (strcmp(link_kind, filter.link_kind)) {
>>>>> + return -1;
>>>>> + }
>>>>
>>>> you can skip the braces
>>>>>
>>>>> + } else if (filter.link_kind)
>>>>
>>>> you have if (filter.link_kind) twice, you can use a single if without the
>>>> else.
>>>>>
>>>>> + return -1;
>>>>> +
>>>
>>> I need to skip interfaces which has not IFLA_LINKINFO attribute,
>>> w/o "else if(...)" I get bridges with normal ether devices:
>>> bash# ip link show type bridge
>>>
>>> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
>>> mode DEFAULT group default
>>> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>>> 2: enp0s25: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc
>>> pfifo_fast state DOWN mode DEFAULT group default qlen 1000
>>> link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
>>> 5: br0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
>>> DEFAULT group default
>>> link/ether 6e:02:f9:17:7f:10 brd ff:ff:ff:ff:ff:ff
>>>
>>> but expected result should be only bridges.
>>
>>
>> I was just saying, it could be:
>>
>> if (filter.link_kind) {
>> if (tb[IFLA_LINKINFO]) {
>> char *kind = parse_link_kind(tb[IFLA_LINKINFO]);
>> if (strcmp(kind, filter.kind))
>> return -1;
>> } else {
>> return -1;
>> }
>> }
^ permalink raw reply
* [PATCH iproute2 v2] ip link: Show devices by type
From: Vadim Kochan @ 2014-12-03 14:56 UTC (permalink / raw)
To: netdev; +Cc: Vadim Kochan
Added new option 'type' to 'ip link show'
command which allows to filter devices by type:
ip link show type bridge
ip link show type vlan
Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
---
ip/ipaddress.c | 26 ++++++++++++++++++++++++++
ip/iplink.c | 2 +-
man/man8/ip-link.8.in | 20 +++++++++++++++++++-
3 files changed, 46 insertions(+), 2 deletions(-)
diff --git a/ip/ipaddress.c b/ip/ipaddress.c
index 4d99324..4ffac81 100644
--- a/ip/ipaddress.c
+++ b/ip/ipaddress.c
@@ -57,6 +57,7 @@ static struct
int flushe;
int group;
int master;
+ char *kind;
} filter;
static int do_link;
@@ -189,6 +190,18 @@ static void print_linkmode(FILE *f, struct rtattr *tb)
fprintf(f, "mode %s ", link_modes[mode]);
}
+static char *parse_link_kind(struct rtattr *tb)
+{
+ struct rtattr *linkinfo[IFLA_INFO_MAX+1];
+
+ parse_rtattr_nested(linkinfo, IFLA_INFO_MAX, tb);
+
+ if (linkinfo[IFLA_INFO_KIND])
+ return RTA_DATA(linkinfo[IFLA_INFO_KIND]);
+
+ return "";
+}
+
static void print_linktype(FILE *fp, struct rtattr *tb)
{
struct rtattr *linkinfo[IFLA_INFO_MAX+1];
@@ -551,6 +564,16 @@ int print_linkinfo(const struct sockaddr_nl *who,
else if (filter.master > 0)
return -1;
+ if (filter.kind) {
+ if (tb[IFLA_LINKINFO]) {
+ char *kind = parse_link_kind(tb[IFLA_LINKINFO]);
+ if (strcmp(kind, filter.kind))
+ return -1;
+ } else {
+ return -1;
+ }
+ }
+
if (n->nlmsg_type == RTM_DELLINK)
fprintf(fp, "Deleted ");
@@ -1293,6 +1316,9 @@ static int ipaddr_list_flush_or_save(int argc, char **argv, int action)
if (!ifindex)
invarg("Device does not exist\n", *argv);
filter.master = ifindex;
+ } else if (do_link && strcmp(*argv, "type") == 0) {
+ NEXT_ARG();
+ filter.kind = *argv;
} else {
if (strcmp(*argv, "dev") == 0) {
NEXT_ARG();
diff --git a/ip/iplink.c b/ip/iplink.c
index ce6eb3e..f9a75d5 100644
--- a/ip/iplink.c
+++ b/ip/iplink.c
@@ -82,7 +82,7 @@ void iplink_usage(void)
fprintf(stderr, " [ master DEVICE ]\n");
fprintf(stderr, " [ nomaster ]\n");
fprintf(stderr, " [ addrgenmode { eui64 | none } ]\n");
- fprintf(stderr, " ip link show [ DEVICE | group GROUP ] [up] [master DEV]\n");
+ fprintf(stderr, " ip link show [ DEVICE | group GROUP ] [up] [master DEV] [type TYPE]\n");
if (iplink_have_newlink()) {
fprintf(stderr, " ip link help [ TYPE ]\n");
diff --git a/man/man8/ip-link.8.in b/man/man8/ip-link.8.in
index 9d4e3da..7678065 100644
--- a/man/man8/ip-link.8.in
+++ b/man/man8/ip-link.8.in
@@ -148,7 +148,9 @@ ip-link \- network device configuration
.IR GROUP " | "
.BR up " | "
.B master
-.IR DEVICE " ]"
+.IR DEVICE " | "
+.B type
+.IR TYPE " ]"
.ti -8
.B ip link help
@@ -688,6 +690,12 @@ only display running interfaces.
.I DEVICE
specifies the master device which enslaves devices to show.
+.TP
+.BI type " TYPE "
+.I TYPE
+specifies the type of devices to show.
+
+.TP
The show command has additional formatting options:
.TP
@@ -719,6 +727,16 @@ ip link show
Shows the state of all network interfaces on the system.
.RE
.PP
+ip link show type bridge
+.RS 4
+Shows the bridge devices.
+.RE
+.PP
+ip link show type vlan
+.RS 4
+Shows the vlan devices.
+.RE
+.PP
ip link set dev ppp0 mtu 1400
.RS 4
Change the MTU the ppp0 device.
--
2.1.3
^ permalink raw reply related
* 3.12.33 - BUG xfrm_selector_match+0x25/0x2f6
From: Smart Weblications GmbH - Florian Wiessner @ 2014-12-03 14:55 UTC (permalink / raw)
To: netdev, LKML, stable
Hi list,
[16623.095403] BUG: unable to handle kernel paging request at 00000000010600d0
[16623.095445] IP: [<ffffffff81547767>] xfrm_selector_match+0x25/0x2f6
[16623.095480] PGD aeaea067 PUD 85d95067 PMD 0
[16623.095513] Oops: 0000 [#1] SMP
[16623.095543] Modules linked in: netconsole xt_nat xt_multiport veth ip_vs_rr
nfsd lockd nfs_acl auth_rpcgss sunrpc oid_registry iptable_mangle xt_mark
nf_conntrack_netlink nfnetlink ipt_MASQUERADE iptable_nat nf_nat_ipv4
nf_conntrack_ipv4 nf_defrag_ipv4 ipt_REJECT xt_tcpudp iptable_filter ip_tables
cpufreq_ondemand cpufreq_powersave cpufreq_conservative cpufreq_userspace
ocfs2_stack_o2cb ocfs2_dlm bridge stp llc bonding fuse nf_conntrack_ftp 8021q
openvswitch gre vxlan xt_conntrack x_tables ocfs2_dlmfs dlm sctp ocfs2
ocfs2_nodemanager ocfs2_stackglue configfs rbd kvm_intel kvm coretemp ip_vs_ftp
ip_vs nf_nat nf_conntrack ctr twofish_generic twofish_x86_64 twofish_common
camellia_generic serpent_generic blowfish_generic blowfish_common cast5_generic
cast_common xcbc sha512_generic crypto_null af_key xfrm_algo psmouse serio_raw
i2c_i801 lpc_ich mfd_core evdev btrfs lzo_decompress lzo_compress
[16623.096062] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.12.33 #1
[16623.096091] Hardware name: Supermicro X9SCI/X9SCA/X9SCI/X9SCA, BIOS 1.1a
09/28/2011
[16623.096137] task: ffffffff81804450 ti: ffffffff817f4000 task.ti: ffffffff817f4000
[16623.096182] RIP: 0010:[<ffffffff81547767>] [<ffffffff81547767>]
xfrm_selector_match+0x25/0x2f6
[16623.096233] RSP: 0018:ffff88083fc03900 EFLAGS: 00010246
[16623.096261] RAX: 0000000000000001 RBX: ffff88083fc03a20 RCX: ffff880787fb1200
[16623.096292] RDX: 0000000000000002 RSI: ffff88083fc03a20 RDI: 00000000010600a6
[16623.096323] RBP: 00000000010600a6 R08: 0000000000000000 R09: ffff88083fc039a0
[16623.096353] R10: 0000000000000000 R11: 0000000000000001 R12: ffff88083fc03a20
[16623.096383] R13: 0000000000000001 R14: ffffffff818a9700 R15: ffffffffa01c73e0
[16623.096414] FS: 0000000000000000(0000) GS:ffff88083fc00000(0000)
knlGS:0000000000000000
[16623.096469] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[16623.096498] CR2: 00000000010600d0 CR3: 0000000085f0b000 CR4: 00000000000407f0
[16623.096528] Stack:
[16623.096550] 0000000000000000 0000000001060002 ffff880787fb1200 ffff88083fc03a20
[16623.096602] 0000000000000001 ffffffff81547a7c 0000000000000000 ffff8800baad5480
[16623.096655] ffffffff81804450 ffffffff818a9700 000000003c9041bc ffffffff81547ef7
[16623.096721] Call Trace:
[16623.096744] <IRQ>
[16623.096749] [<ffffffff81547a7c>] ? xfrm_sk_policy_lookup+0x44/0x9b
[16623.096802] [<ffffffff81547ef7>] ? xfrm_lookup+0x91/0x446
[16623.096832] [<ffffffff81541316>] ? ip_route_me_harder+0x150/0x1b0
[16623.096865] [<ffffffffa01b6457>] ? ip_vs_route_me_harder+0x86/0x91 [ip_vs]
[16623.096899] [<ffffffffa01b797a>] ? ip_vs_out+0x2d3/0x5bc [ip_vs]
[16623.096930] [<ffffffff81501420>] ? ip_rcv_finish+0x2b8/0x2b8
[16623.096959] [<ffffffff814fc2d3>] ? nf_iterate+0x42/0x80
[16623.096989] [<ffffffff814fc37a>] ? nf_hook_slow+0x69/0xff
[16623.097017] [<ffffffff81501420>] ? ip_rcv_finish+0x2b8/0x2b8
[16623.097047] [<ffffffff81501744>] ? ip_local_deliver+0x6f/0x7e
[16623.097078] [<ffffffff814d82a6>] ? __netif_receive_skb_core+0x5f0/0x66c
[16623.097108] [<ffffffff814d84b7>] ? process_backlog+0x13e/0x13e
[16623.097140] [<ffffffffa04b4e09>] ? br_handle_frame_finish+0x382/0x382 [bridge]
[16623.097187] [<ffffffff814d8503>] ? netif_receive_skb+0x4c/0x7d
[16623.097218] [<ffffffffa04b4d95>] ? br_handle_frame_finish+0x30e/0x382 [bridge]
[16623.097265] [<ffffffffa04b4fda>] ? br_handle_frame+0x1d1/0x217 [bridge]
[16623.097297] [<ffffffffa048e4aa>] ? bond_handle_frame+0x86/0x1bd [bonding]
[16623.097328] [<ffffffff814d8155>] ? __netif_receive_skb_core+0x49f/0x66c
[16623.097358] [<ffffffff814d8503>] ? netif_receive_skb+0x4c/0x7d
[16623.097388] [<ffffffff814d9091>] ? napi_gro_receive+0x35/0x76
[16623.097418] [<ffffffff813eae17>] ? e1000_clean_rx_irq+0x26d/0x2f5
[16623.097448] [<ffffffff813ef48e>] ? e1000e_poll+0x65/0x23d
[16623.097477] [<ffffffff814d8709>] ? net_rx_action+0xa2/0x1c0
[16623.097507] [<ffffffff8136895c>] ? credit_entropy_bits.part.7+0x127/0x168
[16623.097540] [<ffffffff8103cd9c>] ? __do_softirq+0xe8/0x201
[16623.097569] [<ffffffff815ae61c>] ? call_softirq+0x1c/0x30
[16623.097599] [<ffffffff810042ad>] ? do_softirq+0x2c/0x5f
[16623.097627] [<ffffffff8103cf7a>] ? irq_exit+0x3b/0x7f
[16623.097655] [<ffffffff81003d90>] ? do_IRQ+0x91/0xa8
[16623.097684] [<ffffffff815ac7ea>] ? common_interrupt+0x6a/0x6a
[16623.097713] <EOI>
[16623.097718] [<ffffffff8105549a>] ? enqueue_hrtimer+0x36/0x6d
[16623.097771] [<ffffffff814a904d>] ? cpuidle_enter_state+0x43/0xa6
[16623.097801] [<ffffffff814a9046>] ? cpuidle_enter_state+0x3c/0xa6
[16623.097831] [<ffffffff814a91a2>] ? cpuidle_idle_call+0xf2/0x19e
[16623.097862] [<ffffffff8100a2b8>] ? arch_cpu_idle+0x6/0x17
[16623.097892] [<ffffffff81071715>] ? cpu_startup_entry+0x119/0x1a8
[16623.097921] [<ffffffff818f6cf3>] ? start_kernel+0x3ca/0x3d5
[16623.097951] [<ffffffff818f673f>] ? repair_env_string+0x57/0x57
[16623.097979] Code: 5d 41 5e 41 5f c3 41 55 66 83 fa 02 41 54 55 48 89 fd 53 48
89 f3 41 50 74 11 31 c0 66 83 fa 0a 0f 85 ce 02 00 00 e9 fd 00 00 00 <0f> b6 47
2a 8b 17 8b 76 18 84 c0 74 1a b9 20 00 00 00 31 f2 29
[16623.098244] RIP [<ffffffff81547767>] xfrm_selector_match+0x25/0x2f6
[16623.098459] RSP <ffff88083fc03900>
[16623.098484] CR2: 00000000010600d0
[16623.098903] ---[ end trace 36545dfc8f7672ee ]---
[16623.098996] Kernel panic - not syncing: Fatal exception in interrupt
[16623.099085] Rebooting in 10 seconds..
[16633.158496] ACPI MEMORY or I/O RESET_REG.
This happens again and again with 3.12.33
see also: http://www.spinics.net/lists/netdev/msg306283.html
is this already fixed somehow?
--
Mit freundlichen Grüßen,
Florian Wiessner
Smart Weblications GmbH
Martinsberger Str. 1
D-95119 Naila
fon.: +49 9282 9638 200
fax.: +49 9282 9638 205
24/7: +49 900 144 000 00 - 0,99 EUR/Min*
http://www.smart-weblications.de
--
Sitz der Gesellschaft: Naila
Geschäftsführer: Florian Wiessner
HRB-Nr.: HRB 3840 Amtsgericht Hof
*aus dem dt. Festnetz, ggf. abweichende Preise aus dem Mobilfunknetz
^ permalink raw reply
* Re: linux-next Problems with VPN tunnel - no packets sent
From: Valdis.Kletnieks @ 2014-12-03 14:51 UTC (permalink / raw)
To: Jason Wang; +Cc: Herbert Xu, davem, netdev, linux-kernel
In-Reply-To: <1417576339.19959.0@smtp.corp.redhat.com>
[-- Attachment #1: Type: text/plain, Size: 571 bytes --]
On Wed, 03 Dec 2014 03:20:19 +0008, Jason Wang said:
> > Still broken in next-20141201, and bisection fingers this commit:
> >
> > commit e0b46d0ee9c240c7430a47e9b0365674d4a04522
> > Author: Herbert Xu <herbert@gondor.apana.org.au>
> > Date: Fri Nov 7 21:22:23 2014 +0800
> >
> > tun: Use iovec iterators
> > What's the best way to proceed?
>
> See another fixes from Herbert, it probably fixes your issue:
>
> http://marc.info/?l=linux-netdev&m=141734182302021&w=2
Unfortunately, I'm still seeing the same behavior with that patch
applied to next-20141201....
[-- Attachment #2: Type: application/pgp-signature, Size: 848 bytes --]
^ permalink raw reply
* Re: [PATCH iproute2] ip link: Show devices by link type
From: Vadim Kochan @ 2014-12-03 14:47 UTC (permalink / raw)
To: Roopa Prabhu; +Cc: netdev@vger.kernel.org
In-Reply-To: <547F20CA.4060501@cumulusnetworks.com>
OK, I can use it)
Thanks,
On Wed, Dec 3, 2014 at 4:40 PM, Roopa Prabhu <roopa@cumulusnetworks.com> wrote:
> On 12/2/14, 5:13 PM, vadim4j@gmail.com wrote:
>>
>> On Tue, Dec 02, 2014 at 04:55:44PM -0800, Roopa Prabhu wrote:
>>>>
>>>> int master;
>>>> + char *link_kind;
>>>
>>> The name can be just "kind", given all the others dont use the link
>>> prefix
>>>>
>>>> } filter;
>>
>> OK
>>
>>>> + if (filter.link_kind && tb[IFLA_LINKINFO]) {
>>>> + char *link_kind = parse_link_kind(tb[IFLA_LINKINFO]);
>>>> + if (strcmp(link_kind, filter.link_kind)) {
>>>> + return -1;
>>>> + }
>>>
>>> you can skip the braces
>>>>
>>>> + } else if (filter.link_kind)
>>>
>>> you have if (filter.link_kind) twice, you can use a single if without the
>>> else.
>>>>
>>>> + return -1;
>>>> +
>>
>> I need to skip interfaces which has not IFLA_LINKINFO attribute,
>> w/o "else if(...)" I get bridges with normal ether devices:
>> bash# ip link show type bridge
>>
>> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
>> mode DEFAULT group default
>> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>> 2: enp0s25: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc
>> pfifo_fast state DOWN mode DEFAULT group default qlen 1000
>> link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
>> 5: br0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
>> DEFAULT group default
>> link/ether 6e:02:f9:17:7f:10 brd ff:ff:ff:ff:ff:ff
>>
>> but expected result should be only bridges.
>
>
> I was just saying, it could be:
>
> if (filter.link_kind) {
> if (tb[IFLA_LINKINFO]) {
> char *kind = parse_link_kind(tb[IFLA_LINKINFO]);
> if (strcmp(kind, filter.kind))
> return -1;
> } else {
> return -1;
> }
> }
^ permalink raw reply
* Re: [PATCH iproute2] ip link: Show devices by link type
From: Roopa Prabhu @ 2014-12-03 14:40 UTC (permalink / raw)
To: vadim4j; +Cc: netdev
In-Reply-To: <20141203011305.GA5945@angus-think.lan>
On 12/2/14, 5:13 PM, vadim4j@gmail.com wrote:
> On Tue, Dec 02, 2014 at 04:55:44PM -0800, Roopa Prabhu wrote:
>>> int master;
>>> + char *link_kind;
>> The name can be just "kind", given all the others dont use the link prefix
>>> } filter;
> OK
>
>>> + if (filter.link_kind && tb[IFLA_LINKINFO]) {
>>> + char *link_kind = parse_link_kind(tb[IFLA_LINKINFO]);
>>> + if (strcmp(link_kind, filter.link_kind)) {
>>> + return -1;
>>> + }
>> you can skip the braces
>>> + } else if (filter.link_kind)
>> you have if (filter.link_kind) twice, you can use a single if without the
>> else.
>>> + return -1;
>>> +
> I need to skip interfaces which has not IFLA_LINKINFO attribute,
> w/o "else if(...)" I get bridges with normal ether devices:
>
> bash# ip link show type bridge
>
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> 2: enp0s25: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
> link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
> 5: br0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default
> link/ether 6e:02:f9:17:7f:10 brd ff:ff:ff:ff:ff:ff
>
> but expected result should be only bridges.
I was just saying, it could be:
if (filter.link_kind) {
if (tb[IFLA_LINKINFO]) {
char *kind = parse_link_kind(tb[IFLA_LINKINFO]);
if (strcmp(kind, filter.kind))
return -1;
} else {
return -1;
}
}
^ permalink raw reply
* Re: [patch net-next 6/6] net_sched: cls_cgroup: remove unnecessary if
From: Jiri Pirko @ 2014-12-03 14:39 UTC (permalink / raw)
To: Jamal Hadi Salim; +Cc: netdev, davem
In-Reply-To: <547F1E98.1050704@mojatatu.com>
Wed, Dec 03, 2014 at 03:30:48PM CET, jhs@mojatatu.com wrote:
>On 12/03/14 08:18, Jiri Pirko wrote:
>
>>>
>>>Hrm. head could be NULL, no?
>>
>>Sure it can. But that is not a problem. Not sure what you are trying to
>>point at...
>>
>
>I suppose head->handle MUST always be equal to handle for the change to
>work. So doesnt matter if handle is null or not. Too clever for me.
Exactly. That is what I tried to say in patch desc :)
>
>Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
>
>cheers,
>jamal
^ permalink raw reply
* Re: [patch net-next 3/6] net_sched: cls_bpf: remove faulty use of list_for_each_entry_rcu
From: Jamal Hadi Salim @ 2014-12-03 14:37 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, davem
In-Reply-To: <20141203132635.GH1860@nanopsycho.orion>
On 12/03/14 08:26, Jiri Pirko wrote:
> Wed, Dec 03, 2014 at 01:51:15PM CET, jhs@mojatatu.com wrote:
>> I think this may be problematic. Doesnt a flush operation also use the
>> walker?
>
> I don't believe so. Just look at tc_dump_tfilter.
>
Actually we cant flush filters (we could actions).
> But even if that would the the case, _rcu variant is wrong (yep, it
> would have to be replaced by _safe variant then).
>
Sorry, still humping on the get part:
that gets invoked for del for a filter that may be in use in the
datapath. del uses rcu - should get not use rcu in such a case?
cheers,
jamal
^ permalink raw reply
* [PATCH net v2 2/2] amd-xgbe: Associate Tx SKB with proper ring descriptor
From: Tom Lendacky @ 2014-12-03 14:36 UTC (permalink / raw)
To: netdev; +Cc: David Miller
In-Reply-To: <20141203143630.25084.91079.stgit@tlendack-t1.amdoffice.net>
The SKB for a Tx packet is associated with an xgbe_ring_data structure
in the xgbe_map_tx_skb function. However, it is being saved in the
structure after the last structure used when the SKB is mapped. Use
the last used structure to save the SKB value.
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
drivers/net/ethernet/amd/xgbe/xgbe-desc.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-desc.c b/drivers/net/ethernet/amd/xgbe/xgbe-desc.c
index 43b7d2e..b15551b 100644
--- a/drivers/net/ethernet/amd/xgbe/xgbe-desc.c
+++ b/drivers/net/ethernet/amd/xgbe/xgbe-desc.c
@@ -480,7 +480,11 @@ static int xgbe_map_tx_skb(struct xgbe_channel *channel, struct sk_buff *skb)
}
}
- /* Save the skb address in the last entry */
+ /* Save the skb address in the last entry. We always have some data
+ * that has been mapped so rdata is always advanced past the last
+ * piece of mapped data - use the entry pointed to by cur_index - 1.
+ */
+ rdata = XGBE_GET_DESC_DATA(ring, cur_index - 1);
rdata->skb = skb;
/* Save the number of descriptor entries used */
^ permalink raw reply related
* [PATCH net v2 1/2] amd-xgbe: Do not clear interrupt indicator
From: Tom Lendacky @ 2014-12-03 14:36 UTC (permalink / raw)
To: netdev; +Cc: David Miller
In-Reply-To: <20141203143630.25084.91079.stgit@tlendack-t1.amdoffice.net>
The interrupt value within the xgbe_ring_data structure is used as an
indicator of which Rx descriptor should have the INTE bit set to
generate an interrupt when that Rx descriptor is used. This bit was
mistakenly cleared when unmapping the associated ring data, effectively
nullifying the ethtool rx-frames support.
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
drivers/net/ethernet/amd/xgbe/xgbe-desc.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-desc.c b/drivers/net/ethernet/amd/xgbe/xgbe-desc.c
index 6fc5da0..43b7d2e 100644
--- a/drivers/net/ethernet/amd/xgbe/xgbe-desc.c
+++ b/drivers/net/ethernet/amd/xgbe/xgbe-desc.c
@@ -356,7 +356,6 @@ static void xgbe_unmap_skb(struct xgbe_prv_data *pdata,
rdata->tso_header = 0;
rdata->len = 0;
- rdata->interrupt = 0;
rdata->mapped_as_page = 0;
if (rdata->state_saved) {
^ permalink raw reply related
* [PATCH net v2 0/2] amd-xgbe: AMD XGBE driver fixes 2014-12-02
From: Tom Lendacky @ 2014-12-03 14:36 UTC (permalink / raw)
To: netdev; +Cc: David Miller
The following series of patches includes two bug fixes. Unfortunately,
the first patch will create a conflict when eventually merged into
net-next but should be very easy to resolve.
- Do not clear the interrupt bit in the xgbe_ring_data structure
- Associate a Tx SKB with the proper xgbe_ring_data structure
This patch series is based on net.
Changes from v1:
- Update the commit message associated with the first patch
---
Tom Lendacky (2):
amd-xgbe: Do not clear interrupt indicator
amd-xgbe: Associate Tx SKB with proper ring descriptor
drivers/net/ethernet/amd/xgbe/xgbe-desc.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
--
Tom Lendacky
^ permalink raw reply
* Re: [PATCH net-next 2/4] vlan: Fix mac_len adjustment.
From: Jiri Benc @ 2014-12-03 14:32 UTC (permalink / raw)
To: Pravin B Shelar; +Cc: davem, netdev
In-Reply-To: <1417473038-2165-1-git-send-email-pshelar@nicira.com>
On Mon, 1 Dec 2014 14:30:38 -0800, Pravin B Shelar wrote:
> skb_reset_mac_len() sets length according to ethernet and network
> offsets, but mpls expects mac-length to be offset to mpls header (ref.
> skb_mpls_header()). Therefore rather than reset we need to subtract
> VLAN_HLEN from mac_len.
>
> Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
> ---
> net/core/skbuff.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index 92116df..c45888f 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -4178,7 +4178,7 @@ static int __skb_vlan_pop(struct sk_buff *skb, u16 *vlan_tci)
> if (skb_network_offset(skb) < ETH_HLEN)
> skb_set_network_header(skb, ETH_HLEN);
>
> - skb_reset_mac_len(skb);
> + skb->mac_len -= VLAN_HLEN;
> pull:
> __skb_pull(skb, offset);
>
See my previous explanation why this patch is wrong with the current
code: http://article.gmane.org/gmane.linux.network/339457
Jiri
--
Jiri Benc
^ permalink raw reply
* Re: [patch net-next 6/6] net_sched: cls_cgroup: remove unnecessary if
From: Jamal Hadi Salim @ 2014-12-03 14:30 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, davem
In-Reply-To: <20141203131815.GF1860@nanopsycho.orion>
On 12/03/14 08:18, Jiri Pirko wrote:
>>
>> Hrm. head could be NULL, no?
>
> Sure it can. But that is not a problem. Not sure what you are trying to
> point at...
>
I suppose head->handle MUST always be equal to handle for the change to
work. So doesnt matter if handle is null or not. Too clever for me.
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
cheers,
jamal
^ permalink raw reply
* Re: [PATCH net v1 1/2] amd-xgbe: Do not clear interrupt indicator
From: Tom Lendacky @ 2014-12-03 14:27 UTC (permalink / raw)
To: Sergei Shtylyov, netdev; +Cc: David Miller
In-Reply-To: <547EF54B.1050308@cogentembedded.com>
On 12/03/2014 05:34 AM, Sergei Shtylyov wrote:
> Hello.
>
> On 12/3/2014 3:16 AM, Tom Lendacky wrote:
>
>> The interrupt value within the xgbe_ring_data structure is used as an
>> indicator of which Rx descriptor should have the INTE bit set to
>> generate an interrupt when that Rx descriptor is used. This bit was
>> mistakenly cleared in the xgbe_unmap_rdata function, effectively
>
> Not xgbe_unmap_skb() (as seems to follow from the patch)?
Yup, I'm mixing up my versions between net-next and net. I'll send
an updated version with a more appropriate comment.
Thanks,
Tom
>
>> nullifying the ethtool rx-frames support.
>
>> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
>> ---
>> drivers/net/ethernet/amd/xgbe/xgbe-desc.c | 1 -
>> 1 file changed, 1 deletion(-)
>
>> diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-desc.c
>> b/drivers/net/ethernet/amd/xgbe/xgbe-desc.c
>> index 6fc5da0..43b7d2e 100644
>> --- a/drivers/net/ethernet/amd/xgbe/xgbe-desc.c
>> +++ b/drivers/net/ethernet/amd/xgbe/xgbe-desc.c
>> @@ -356,7 +356,6 @@ static void xgbe_unmap_skb(struct xgbe_prv_data
>> *pdata,
>>
>> rdata->tso_header = 0;
>> rdata->len = 0;
>> - rdata->interrupt = 0;
>> rdata->mapped_as_page = 0;
>>
>> if (rdata->state_saved) {
>
> WBR, Sergei
>
^ permalink raw reply
* Re: [PATCH v2 4/7] fs/proc/task_mmu.c: shift mm_access() from m_start() to proc_maps_open()
From: Kirill A. Shutemov @ 2014-12-03 14:14 UTC (permalink / raw)
To: Oleg Nesterov, David S. Miller, Linus Torvalds
Cc: Andrew Morton, Alexander Viro, Cyrill Gorcunov, David Howells,
Eric W. Biederman, Kirill A. Shutemov, Peter Zijlstra,
Sasha Levin, linux-fsdevel, linux-kernel, Alexey Dobriyan, netdev
In-Reply-To: <20140805194655.GA30728@redhat.com>
On Tue, Aug 05, 2014 at 09:46:55PM +0200, Oleg Nesterov wrote:
> A simple test-case from Kirill Shutemov
>
> cat /proc/self/maps >/dev/null
> chmod +x /proc/self/net/packet
> exec /proc/self/net/packet
>
> makes lockdep unhappy, cat/exec take seq_file->lock + cred_guard_mutex in
> the opposite order.
Oleg, I see it again with almost the same test-case:
cat /proc/self/stack >/dev/null
chmod +x /proc/self/net/packet
exec /proc/self/net/packet
Looks like bunch of proc files were converted to use seq_file by Alexey
Dobriyan around the same time you've fixed the issue for /proc/pid/maps.
More generic test-case:
find /proc/self/ -type f -exec dd if='{}' of=/dev/null bs=1 count=1 ';' 2>/dev/null
chmod +x /proc/self/net/packet
exec /proc/self/net/packet
David, any justification for allowing chmod +x for files under
/proc/pid/net?
[ 2.042212] ======================================================
[ 2.042930] [ INFO: possible circular locking dependency detected ]
[ 2.043648] 3.18.0-rc7-00003-g3a18ca061311-dirty #237 Not tainted
[ 2.044350] -------------------------------------------------------
[ 2.045054] sh/94 is trying to acquire lock:
[ 2.045546] (&p->lock){+.+.+.}, at: [<ffffffff811e12fd>] seq_read+0x3d/0x3e0
[ 2.045781]
[ 2.045781] but task is already holding lock:
[ 2.045781] (&sig->cred_guard_mutex){+.+.+.}, at: [<ffffffff811c0e3d>] prepare_bprm_creds+0x2d/0x90
[ 2.045781]
[ 2.045781] which lock already depends on the new lock.
[ 2.045781]
[ 2.045781]
[ 2.045781] the existing dependency chain (in reverse order) is:
[ 2.045781]
-> #1 (&sig->cred_guard_mutex){+.+.+.}:
[ 2.045781] [<ffffffff810a6e99>] __lock_acquire+0x4d9/0xd40
[ 2.045781] [<ffffffff810a7ff2>] lock_acquire+0xd2/0x2a0
[ 2.045781] [<ffffffff81849da6>] mutex_lock_killable_nested+0x66/0x460
[ 2.045781] [<ffffffff81229de4>] lock_trace+0x24/0x70
[ 2.045781] [<ffffffff81229e8f>] proc_pid_stack+0x5f/0xe0
[ 2.045781] [<ffffffff81227244>] proc_single_show+0x54/0xa0
[ 2.045781] [<ffffffff811e13a0>] seq_read+0xe0/0x3e0
[ 2.045781] [<ffffffff811b9377>] vfs_read+0x97/0x180
[ 2.045781] [<ffffffff811b9f5d>] SyS_read+0x4d/0xc0
[ 2.045781] [<ffffffff8184e492>] system_call_fastpath+0x12/0x17
[ 2.045781]
-> #0 (&p->lock){+.+.+.}:
[ 2.045781] [<ffffffff810a389f>] validate_chain.isra.36+0xfff/0x1400
[ 2.045781] [<ffffffff810a6e99>] __lock_acquire+0x4d9/0xd40
[ 2.045781] [<ffffffff810a7ff2>] lock_acquire+0xd2/0x2a0
[ 2.045781] [<ffffffff81849629>] mutex_lock_nested+0x69/0x3c0
[ 2.045781] [<ffffffff811e12fd>] seq_read+0x3d/0x3e0
[ 2.045781] [<ffffffff81226428>] proc_reg_read+0x48/0x70
[ 2.045781] [<ffffffff811b9377>] vfs_read+0x97/0x180
[ 2.045781] [<ffffffff811bf1a8>] kernel_read+0x48/0x60
[ 2.045781] [<ffffffff811bfb2c>] prepare_binprm+0xdc/0x180
[ 2.045781] [<ffffffff811c139a>] do_execve_common.isra.29+0x4fa/0x960
[ 2.045781] [<ffffffff811c1818>] do_execve+0x18/0x20
[ 2.045781] [<ffffffff811c1b05>] SyS_execve+0x25/0x30
[ 2.045781] [<ffffffff8184ea49>] stub_execve+0x69/0xa0
[ 2.045781]
[ 2.045781] other info that might help us debug this:
[ 2.045781]
[ 2.045781] Possible unsafe locking scenario:
[ 2.045781]
[ 2.045781] CPU0 CPU1
[ 2.045781] ---- ----
[ 2.045781] lock(&sig->cred_guard_mutex);
[ 2.045781] lock(&p->lock);
[ 2.045781] lock(&sig->cred_guard_mutex);
[ 2.045781] lock(&p->lock);
[ 2.045781]
[ 2.045781] *** DEADLOCK ***
[ 2.045781]
[ 2.045781] 1 lock held by sh/94:
[ 2.045781] #0: (&sig->cred_guard_mutex){+.+.+.}, at: [<ffffffff811c0e3d>] prepare_bprm_creds+0x2d/0x90
[ 2.045781]
[ 2.045781] stack backtrace:
[ 2.045781] CPU: 0 PID: 94 Comm: sh Not tainted 3.18.0-rc7-00003-g3a18ca061311-dirty #237
[ 2.045781] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014
[ 2.045781] ffffffff82a48d50 ffff88085427bad8 ffffffff81844a85 0000000000000cac
[ 2.045781] ffffffff82a654a0 ffff88085427bb28 ffffffff810a1b03 0000000000000000
[ 2.045781] ffff88085427bb68 ffff88085427bb28 ffff8808547f1500 ffff8808547f1c40
[ 2.045781] Call Trace:
[ 2.045781] [<ffffffff81844a85>] dump_stack+0x4e/0x68
[ 2.045781] [<ffffffff810a1b03>] print_circular_bug+0x203/0x310
[ 2.045781] [<ffffffff810a389f>] validate_chain.isra.36+0xfff/0x1400
[ 2.045781] [<ffffffff8108fa76>] ? local_clock+0x16/0x30
[ 2.045781] [<ffffffff810a6e99>] __lock_acquire+0x4d9/0xd40
[ 2.045781] [<ffffffff810a7ff2>] lock_acquire+0xd2/0x2a0
[ 2.045781] [<ffffffff811e12fd>] ? seq_read+0x3d/0x3e0
[ 2.045781] [<ffffffff81849629>] mutex_lock_nested+0x69/0x3c0
[ 2.045781] [<ffffffff811e12fd>] ? seq_read+0x3d/0x3e0
[ 2.045781] [<ffffffff8108f9f8>] ? sched_clock_cpu+0x98/0xc0
[ 2.045781] [<ffffffff811e12fd>] ? seq_read+0x3d/0x3e0
[ 2.045781] [<ffffffff814050b9>] ? lockref_put_or_lock+0x29/0x40
[ 2.045781] [<ffffffff811e12fd>] seq_read+0x3d/0x3e0
[ 2.045781] [<ffffffff814050b9>] ? lockref_put_or_lock+0x29/0x40
[ 2.045781] [<ffffffff81226428>] proc_reg_read+0x48/0x70
[ 2.045781] [<ffffffff811b9377>] vfs_read+0x97/0x180
[ 2.045781] [<ffffffff811bf1a8>] kernel_read+0x48/0x60
[ 2.045781] [<ffffffff811bfb2c>] prepare_binprm+0xdc/0x180
[ 2.045781] [<ffffffff811c139a>] do_execve_common.isra.29+0x4fa/0x960
[ 2.092142] tsc: Refined TSC clocksource calibration: 2693.484 MHz
[ 2.045781] [<ffffffff811c0fd3>] ? do_execve_common.isra.29+0x133/0x960
[ 2.045781] [<ffffffff8184f04d>] ? retint_swapgs+0xe/0x13
[ 2.045781] [<ffffffff811c1818>] do_execve+0x18/0x20
[ 2.045781] [<ffffffff811c1b05>] SyS_execve+0x25/0x30
[ 2.045781] [<ffffffff8184ea49>] stub_execve+0x69/0xa0
--
Kirill A. Shutemov
^ 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