* 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
* [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
* 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
* 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 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 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 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] 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
* [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] 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 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
* [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 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 4/6] niu: Use eth_skb_pad helper
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>
Replace the standard layout for padding an ethernet frame with the
eth_skb_pad call.
Signed-off-by: Alexander Duyck <alexander.h.duyck@redhat.com>
---
drivers/net/ethernet/sun/niu.c | 9 ++-------
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/sun/niu.c b/drivers/net/ethernet/sun/niu.c
index 904fd1a..4aaa324 100644
--- a/drivers/net/ethernet/sun/niu.c
+++ b/drivers/net/ethernet/sun/niu.c
@@ -6651,13 +6651,8 @@ static netdev_tx_t niu_start_xmit(struct sk_buff *skb,
return NETDEV_TX_BUSY;
}
- if (skb->len < ETH_ZLEN) {
- unsigned int pad_bytes = ETH_ZLEN - skb->len;
-
- if (skb_pad(skb, pad_bytes))
- goto out;
- skb_put(skb, pad_bytes);
- }
+ if (eth_skb_pad(skb))
+ goto out;
len = sizeof(struct tx_pkt_hdr) + 15;
if (skb_headroom(skb) < len) {
^ permalink raw reply related
* [PATCH v2 5/6] myri10ge: use eth_skb_pad helper
From: Alexander Duyck @ 2014-12-03 16:17 UTC (permalink / raw)
To: netdev; +Cc: Hyong-Youb Kim, davem
In-Reply-To: <20141203161440.9223.39633.stgit@ahduyck-vm-fedora20>
Update myri10ge to use eth_skb_pad helper. This also corrects a minor
issue as the driver was updating length without updating the tail pointer.
Cc: Hyong-Youb Kim <hykim@myri.com>
Signed-off-by: Alexander Duyck <alexander.h.duyck@redhat.com>
---
drivers/net/ethernet/myricom/myri10ge/myri10ge.c | 15 +++++----------
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/myricom/myri10ge/myri10ge.c b/drivers/net/ethernet/myricom/myri10ge/myri10ge.c
index 9e7e3f1..af09905 100644
--- a/drivers/net/ethernet/myricom/myri10ge/myri10ge.c
+++ b/drivers/net/ethernet/myricom/myri10ge/myri10ge.c
@@ -2913,16 +2913,11 @@ again:
flags |= MXGEFW_FLAGS_SMALL;
/* pad frames to at least ETH_ZLEN bytes */
- if (unlikely(skb->len < ETH_ZLEN)) {
- if (skb_padto(skb, ETH_ZLEN)) {
- /* The packet is gone, so we must
- * return 0 */
- ss->stats.tx_dropped += 1;
- return NETDEV_TX_OK;
- }
- /* adjust the len to account for the zero pad
- * so that the nic can know how long it is */
- skb->len = ETH_ZLEN;
+ if (eth_skb_pad(skb)) {
+ /* The packet is gone, so we must
+ * return 0 */
+ ss->stats.tx_dropped += 1;
+ return NETDEV_TX_OK;
}
}
^ permalink raw reply related
* [PATCH v2 6/6] r8169: Use eth_skb_pad function
From: Alexander Duyck @ 2014-12-03 16:18 UTC (permalink / raw)
To: netdev; +Cc: Realtek linux nic maintainers, davem
In-Reply-To: <20141203161440.9223.39633.stgit@ahduyck-vm-fedora20>
Replace rtl_skb_pad with eth_skb_pad since they do the same thing.
Cc: Realtek linux nic maintainers <nic_swsd@realtek.com>
Signed-off-by: Alexander Duyck <alexander.h.duyck@redhat.com>
---
drivers/net/ethernet/realtek/r8169.c | 12 ++----------
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index cf154f7..e9b44fc 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -6832,14 +6832,6 @@ err_out:
return -EIO;
}
-static bool rtl_skb_pad(struct sk_buff *skb)
-{
- if (skb_padto(skb, ETH_ZLEN))
- return false;
- skb_put(skb, ETH_ZLEN - skb->len);
- return true;
-}
-
static bool rtl_test_hw_pad_bug(struct rtl8169_private *tp, struct sk_buff *skb)
{
return skb->len < ETH_ZLEN && tp->mac_version == RTL_GIGA_MAC_VER_34;
@@ -6980,7 +6972,7 @@ static bool rtl8169_tso_csum_v2(struct rtl8169_private *tp,
u8 ip_protocol;
if (unlikely(rtl_test_hw_pad_bug(tp, skb)))
- return skb_checksum_help(skb) == 0 && rtl_skb_pad(skb);
+ return !(skb_checksum_help(skb) || eth_skb_pad(skb));
if (transport_offset > TCPHO_MAX) {
netif_warn(tp, tx_err, tp->dev,
@@ -7015,7 +7007,7 @@ static bool rtl8169_tso_csum_v2(struct rtl8169_private *tp,
opts[1] |= transport_offset << TCPHO_SHIFT;
} else {
if (unlikely(rtl_test_hw_pad_bug(tp, skb)))
- return rtl_skb_pad(skb);
+ return !eth_skb_pad(skb);
}
return true;
^ permalink raw reply related
* Re: [PATCH] SSB / B44: fix WOL for BCM4401
From: Michael Büsch @ 2014-12-03 16:23 UTC (permalink / raw)
To: John W. Linville
Cc: Larry Finger, Andrey Skvortsov, Rafael J. Wysocki, Gary.Zambrano,
netdev, linux-kernel, b43-dev, Rafał Miłecki
In-Reply-To: <20141203161452.GD2896@tuxdriver.com>
[-- Attachment #1: Type: text/plain, Size: 2714 bytes --]
On Wed, 3 Dec 2014 11:14:52 -0500
"John W. Linville" <linville@tuxdriver.com> wrote:
> 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?
I think we could even wait for 3.20.
--
Michael
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH v2 2/6] ethernet/intel: Use eth_skb_pad and skb_put_padto helpers
From: Alexander Duyck @ 2014-12-03 16:17 UTC (permalink / raw)
To: netdev; +Cc: Jeff Kirsher, davem
In-Reply-To: <20141203161440.9223.39633.stgit@ahduyck-vm-fedora20>
Update the Intel Ethernet drivers to use eth_skb_pad() and skb_put_padto
instead of doing their own implementations of the function.
Also this cleans up two other spots where skb_pad was called but the length
and tail pointers were being manipulated directly instead of just having
the padding length added via __skb_put.
Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Alexander Duyck <alexander.h.duyck@redhat.com>
---
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 +++--------
7 files changed, 22 insertions(+), 62 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000/e1000_main.c b/drivers/net/ethernet/intel/e1000/e1000_main.c
index 24f3986..862d198 100644
--- a/drivers/net/ethernet/intel/e1000/e1000_main.c
+++ b/drivers/net/ethernet/intel/e1000/e1000_main.c
@@ -3136,12 +3136,8 @@ static netdev_tx_t e1000_xmit_frame(struct sk_buff *skb,
* packets may get corrupted during padding by HW.
* To WA this issue, pad all small packets manually.
*/
- if (skb->len < ETH_ZLEN) {
- if (skb_pad(skb, ETH_ZLEN - skb->len))
- return NETDEV_TX_OK;
- skb->len = ETH_ZLEN;
- skb_set_tail_pointer(skb, ETH_ZLEN);
- }
+ if (eth_skb_pad(skb))
+ return NETDEV_TX_OK;
mss = skb_shinfo(skb)->gso_size;
/* The controller does a simple calculation to
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
index 370cfa2..88936aa 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -5554,12 +5554,8 @@ static netdev_tx_t e1000_xmit_frame(struct sk_buff *skb,
/* The minimum packet size with TCTL.PSP set is 17 bytes so
* pad skb in order to meet this minimum size requirement
*/
- if (unlikely(skb->len < 17)) {
- if (skb_pad(skb, 17 - skb->len))
- return NETDEV_TX_OK;
- skb->len = 17;
- skb_set_tail_pointer(skb, 17);
- }
+ if (skb_put_padto(skb, 17))
+ return NETDEV_TX_OK;
mss = skb_shinfo(skb)->gso_size;
if (mss) {
diff --git a/drivers/net/ethernet/intel/fm10k/fm10k_main.c b/drivers/net/ethernet/intel/fm10k/fm10k_main.c
index 8c8deec..a05d228 100644
--- a/drivers/net/ethernet/intel/fm10k/fm10k_main.c
+++ b/drivers/net/ethernet/intel/fm10k/fm10k_main.c
@@ -578,14 +578,9 @@ static bool fm10k_cleanup_headers(struct fm10k_ring *rx_ring,
if (skb_is_nonlinear(skb))
fm10k_pull_tail(rx_ring, rx_desc, skb);
- /* if skb_pad returns an error the skb was freed */
- if (unlikely(skb->len < 60)) {
- int pad_len = 60 - skb->len;
-
- if (skb_pad(skb, pad_len))
- return true;
- __skb_put(skb, pad_len);
- }
+ /* if eth_skb_pad returns an error the skb was freed */
+ if (eth_skb_pad(skb))
+ return true;
return false;
}
diff --git a/drivers/net/ethernet/intel/i40e/i40e_txrx.c b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
index 3195d82..04b4414 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_txrx.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
@@ -2399,12 +2399,8 @@ netdev_tx_t i40e_lan_xmit_frame(struct sk_buff *skb, struct net_device *netdev)
/* hardware can't handle really short frames, hardware padding works
* beyond this point
*/
- if (unlikely(skb->len < I40E_MIN_TX_LEN)) {
- if (skb_pad(skb, I40E_MIN_TX_LEN - skb->len))
- return NETDEV_TX_OK;
- skb->len = I40E_MIN_TX_LEN;
- skb_set_tail_pointer(skb, I40E_MIN_TX_LEN);
- }
+ if (skb_put_padto(skb, I40E_MIN_TX_LEN))
+ return NETDEV_TX_OK;
return i40e_xmit_frame_ring(skb, tx_ring);
}
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
index 6261399..36467cf 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -5091,12 +5091,8 @@ static netdev_tx_t igb_xmit_frame(struct sk_buff *skb,
/* The minimum packet size with TCTL.PSP set is 17 so pad the skb
* in order to meet this minimum size requirement.
*/
- if (unlikely(skb->len < 17)) {
- if (skb_pad(skb, 17 - skb->len))
- return NETDEV_TX_OK;
- skb->len = 17;
- skb_set_tail_pointer(skb, 17);
- }
+ if (skb_put_padto(skb, 17))
+ return NETDEV_TX_OK;
return igb_xmit_frame_ring(skb, igb_tx_queue_mapping(adapter, skb));
}
@@ -6847,14 +6843,9 @@ static bool igb_cleanup_headers(struct igb_ring *rx_ring,
if (skb_is_nonlinear(skb))
igb_pull_tail(rx_ring, rx_desc, skb);
- /* if skb_pad returns an error the skb was freed */
- if (unlikely(skb->len < 60)) {
- int pad_len = 60 - skb->len;
-
- if (skb_pad(skb, pad_len))
- return true;
- __skb_put(skb, pad_len);
- }
+ /* if eth_skb_pad returns an error the skb was freed */
+ if (eth_skb_pad(skb))
+ return true;
return false;
}
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 23d72a2..702cc64 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -1755,14 +1755,9 @@ static bool ixgbe_cleanup_headers(struct ixgbe_ring *rx_ring,
return false;
#endif
- /* if skb_pad returns an error the skb was freed */
- if (unlikely(skb->len < 60)) {
- int pad_len = 60 - skb->len;
-
- if (skb_pad(skb, pad_len))
- return true;
- __skb_put(skb, pad_len);
- }
+ /* if eth_skb_pad returns an error the skb was freed */
+ if (eth_skb_pad(skb))
+ return true;
return false;
}
@@ -7248,12 +7243,8 @@ static netdev_tx_t __ixgbe_xmit_frame(struct sk_buff *skb,
* The minimum packet size for olinfo paylen is 17 so pad the skb
* in order to meet this minimum size requirement.
*/
- if (unlikely(skb->len < 17)) {
- if (skb_pad(skb, 17 - skb->len))
- return NETDEV_TX_OK;
- skb->len = 17;
- skb_set_tail_pointer(skb, 17);
- }
+ if (skb_put_padto(skb, 17))
+ return NETDEV_TX_OK;
tx_ring = ring ? ring : adapter->tx_ring[skb->queue_mapping];
diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
index 755f71f..465d6a8 100644
--- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
+++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
@@ -612,14 +612,9 @@ static bool ixgbevf_cleanup_headers(struct ixgbevf_ring *rx_ring,
if (skb_is_nonlinear(skb))
ixgbevf_pull_tail(rx_ring, skb);
- /* if skb_pad returns an error the skb was freed */
- if (unlikely(skb->len < 60)) {
- int pad_len = 60 - skb->len;
-
- if (skb_pad(skb, pad_len))
- return true;
- __skb_put(skb, pad_len);
- }
+ /* if eth_skb_pad returns an error the skb was freed */
+ if (eth_skb_pad(skb))
+ return true;
return false;
}
^ permalink raw reply related
* Fw: [Bug 89201] New: sendto changes buffer used by recvfrom of other proccesses
From: Stephen Hemminger @ 2014-12-03 16:32 UTC (permalink / raw)
To: netdev
Begin forwarded message:
Date: Wed, 3 Dec 2014 05:51:34 -0800
From: "bugzilla-daemon@bugzilla.kernel.org" <bugzilla-daemon@bugzilla.kernel.org>
To: "stephen@networkplumber.org" <stephen@networkplumber.org>
Subject: [Bug 89201] New: sendto changes buffer used by recvfrom of other proccesses
https://bugzilla.kernel.org/show_bug.cgi?id=89201
Bug ID: 89201
Summary: sendto changes buffer used by recvfrom of other
proccesses
Product: Networking
Version: 2.5
Kernel Version: 3.4.0-perf-ga6edd5e
Hardware: All
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Other
Assignee: shemminger@linux-foundation.org
Reporter: tuxmind.bug@gmail.com
Regression: No
hi,
i found a bug with recvfrom/sendto.
the affected kernel is the android one, sources can be found there:
https://android.googlesource.com/kernel/msm/+/android-msm-mako-3.4-kitkat-mr2
configuration:
https://android.googlesource.com/kernel/msm/+/android-msm-mako-3.4-kitkat-mr2/arch/arm/configs/mako_defconfig
description:
when a process call recvfrom on a PF_PACKET/SOCK_RAW socket when another
process
call sendto/write on a socket that use the same interface, the ethernet address
is weird.
recvfrom returns the following ethernet header:
UU:XX:00:00:00:00:AA:AA:03:00:00:00:YY:ZZ
instead of
UU:XX:VV:VV:VV:VV:HH:HH:HH:HH:HH:HH:YY:ZZ
where:
HH:HH:HH:HH:HH:HH is the source MAC address
UU:XX:VV:VV:VV:VV is the destination MAC address
YY:ZZ is the ethernet type
i think that recvfrom save the user buffer pointer somewhere because
perform some 'long' work on the buffer ( like using a printf to debug this
problem ) increase the error rate from 2/9480 bad headers to about 779/4301.
i already opened various bug reports and questions.
external references:
http://stackoverflow.com/questions/27251904/recvfrom-read-wrong-ethernet-address-from-raw-socket
https://code.google.com/p/android/issues/detail?id=81370
step to reproduce:
sample program: http://pastebin.com/kkjUrft9
( you have to change the hardcoded ip address )
> gcc -g -o -DSENDER main.c -o sender
> gcc -g -o main.c -o receiver
> ./receiver wlan0 &
> ./sender wlan0
> Ctrl+C ( SIGINT ) after a while
> fg
> Ctrl+C ( SIGINT )
you should see the amount of sniffed packets and the amount of bad ones.
commenting out the fprintf/fflush calls drastically reduce bad packets count.
thanks in advance for any help.
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* Re: What's the concern about setting irq thread's policy as SCHED_FIFO
From: Rick Jones @ 2014-12-03 16:51 UTC (permalink / raw)
To: Qin Chuanyu, netdev; +Cc: linux-kernel
In-Reply-To: <547EC4A3.6060408@huawei.com>
On 12/03/2014 12:06 AM, Qin Chuanyu wrote:
> I am doing network performance test under suse11sp3 and intel 82599 nic,
> Becasuse the softirq is out of schedule policy's control, so netserver
> thread couldn't always get 100% cpu usage, then packet dropped in kernel
> udp socket's receive queue.
>
> In order to get a stable result, I did some patch in ixgbe driver and
> then use irq_thread instead of softirq to handle rx.
> It seems work well, but irq_thread's SCHED_FIFO schedule policy cause
> that when the cpu is limited, netserver couldn't work at all.
I cannot speak to any scheduling issues/questions, but can ask if you
tried binding netserver to a CPU other than the one servicing the
interrupts via the -T option on the netperf command line:
netperf -T <netperfCPU>,<netserverCPU> ...
http://www.netperf.org/svn/netperf2/trunk/doc/netperf.html#index-g_t_002dT_002c-Global-41
happy benchnmarking,
rick jones
>
> So I change the irq_thread's schedule policy from SCHED_FIFO to
> SCHED_NORMAL, then the irq_thread could share the cpu usage with
> netserver thread.
>
> the question is:
> What's the concrete reason about setting irq thread's policy as SCHED_FIFO?
> Except the priority affecting the cpu usage, any function would be
> broken if irq thread change to SCHED_NORMAL?
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: ovs datapath complains on unexpected mask for netlink commands
From: Or Gerlitz @ 2014-12-03 17:01 UTC (permalink / raw)
To: Jesse Gross; +Cc: Or Gerlitz, Pravin Shelar, netdev@vger.kernel.org
In-Reply-To: <CAEP_g=-g7hH2NtOzdzRMiv+1onk74e0Tny8H0v7zHoqqTvog7Q@mail.gmail.com>
On Tue, Dec 2, 2014 at 1:39 AM, Jesse Gross <jesse@nicira.com> wrote:
> On Thu, Nov 27, 2014 at 9:20 AM, Or Gerlitz <ogerlitz@mellanox.com> wrote:
>> Hi Jesse,
>>
>> I am running with net-next as of commit 2ad7bf36 "ipvlan: Initial check-in
>> [...]"
>> and user-space OVS v2.0.90 built from the upstream git.
>>
>> I suddenly realized that my kernel logs gets filled with the below
>> prints which effectively take place for each ovs-vsctl command I run...
>>
>> openvswitch: netlink: Unexpected mask (mask=1205c, allowed=19805c)
>> openvswitch: netlink: Unexpected mask (mask=1205c, allowed=19805c)
>> openvswitch: netlink: Unexpected mask (mask=1205c, allowed=19805c)
>> openvswitch: netlink: Unexpected mask (mask=1205c, allowed=19805c)
>> openvswitch: netlink: Unexpected mask (mask=1205c, allowed=19805c)
>
> Thanks I see the problem. It looks like Pravin just sent out a patch
> to fix this issue last night - "[PATCH net] openvswitch: Fix flow mask
> validation.".
I see, now (I know the patch wasn't applied yet) on my net clone, the
complaint is a bit different...
openvswitch: netlink: Contain more than allowed mask fields
(mask_attrs=1205c, mask_allowed=19805c).
openvswitch: netlink: Contain more than allowed mask fields
(mask_attrs=19a05c, mask_allowed=19805c).
so same fix for that too?
^ permalink raw reply
* Re: [PATCH v2 4/7] fs/proc/task_mmu.c: shift mm_access() from m_start() to proc_maps_open()
From: Eric W. Biederman @ 2014-12-03 16:59 UTC (permalink / raw)
To: Kirill A. Shutemov
Cc: Oleg Nesterov, David S. Miller, Linus Torvalds, Andrew Morton,
Alexander Viro, Cyrill Gorcunov, David Howells,
Kirill A. Shutemov, Peter Zijlstra, Sasha Levin, linux-fsdevel,
linux-kernel, Alexey Dobriyan, netdev
In-Reply-To: <20141203141433.GA25683@node.dhcp.inet.fi>
"Kirill A. Shutemov" <kirill@shutemov.name> writes:
> 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?
I don't think there are any good reasons for allowing chmod +x for the
proc generic files. Certainly executing any of them is nonsense.
I do recall some weird conner cases existing. I think they resulted
in a need to preserve chmod if not chmod +x. This is just me saying
tread carefully before you change anything.
It really should be safe to tweak proc_notify_change to not allow
messing with the executable bits of proc files.
> [ 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
^ permalink raw reply
* Re: ovs datapath complains on unexpected mask for netlink commands
From: Jesse Gross @ 2014-12-03 17:09 UTC (permalink / raw)
To: Or Gerlitz; +Cc: Or Gerlitz, Pravin Shelar, netdev@vger.kernel.org
In-Reply-To: <CAJ3xEMjL-ngoniJP9Lrw-UYMuHfQsEB8+OoR7W1GRQDD8aOnmw@mail.gmail.com>
On Wed, Dec 3, 2014 at 9:01 AM, Or Gerlitz <gerlitz.or@gmail.com> wrote:
> On Tue, Dec 2, 2014 at 1:39 AM, Jesse Gross <jesse@nicira.com> wrote:
>> On Thu, Nov 27, 2014 at 9:20 AM, Or Gerlitz <ogerlitz@mellanox.com> wrote:
>>> Hi Jesse,
>>>
>>> I am running with net-next as of commit 2ad7bf36 "ipvlan: Initial check-in
>>> [...]"
>>> and user-space OVS v2.0.90 built from the upstream git.
>>>
>>> I suddenly realized that my kernel logs gets filled with the below
>>> prints which effectively take place for each ovs-vsctl command I run...
>>>
>>> openvswitch: netlink: Unexpected mask (mask=1205c, allowed=19805c)
>>> openvswitch: netlink: Unexpected mask (mask=1205c, allowed=19805c)
>>> openvswitch: netlink: Unexpected mask (mask=1205c, allowed=19805c)
>>> openvswitch: netlink: Unexpected mask (mask=1205c, allowed=19805c)
>>> openvswitch: netlink: Unexpected mask (mask=1205c, allowed=19805c)
>>
>> Thanks I see the problem. It looks like Pravin just sent out a patch
>> to fix this issue last night - "[PATCH net] openvswitch: Fix flow mask
>> validation.".
>
> I see, now (I know the patch wasn't applied yet) on my net clone, the
> complaint is a bit different...
>
> openvswitch: netlink: Contain more than allowed mask fields
> (mask_attrs=1205c, mask_allowed=19805c).
> openvswitch: netlink: Contain more than allowed mask fields
> (mask_attrs=19a05c, mask_allowed=19805c).
>
> so same fix for that too?
It's the same problem, only the text string was changed in the meantime.
^ permalink raw reply
* Re: [PATCH iproute2] ip monitor: Fixed printing timestamp few times
From: Stephen Hemminger @ 2014-12-03 17:13 UTC (permalink / raw)
To: Vadim Kochan; +Cc: netdev
In-Reply-To: <1417389262-25189-1-git-send-email-vadim4j@gmail.com>
On Mon, 1 Dec 2014 01:14:22 +0200
Vadim Kochan <vadim4j@gmail.com> wrote:
> Another fix when timestamp is printed few times
> before the event message.
>
> Fixed by skipping the message types which are not supported.
>
> Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
I don't see how you could get into accept_msg and cause this.
The filtering should already be done by kernel for most things.
The code already filters TC messages in kernel. Other types
should be done as well.
Ps: this code is crying to be a switch statement.
^ permalink raw reply
* Re: [PATCH iproute2] ip route: don't assume default route
From: Stephen Hemminger @ 2014-12-03 17:17 UTC (permalink / raw)
To: Pavel Šimerda; +Cc: netdev
In-Reply-To: <20141202164510.GA9005@mole.pavlix.net>
On Tue, 2 Dec 2014 17:45:10 +0100
=?UTF-8?q?Pavel=20=C5=A0imerda?= <psimerda@redhat.com> wrote:
> Just print the help when "ip route del" is called without any other
> arguments.
>
> Resolves:
>
> * https://bugzilla.redhat.com/show_bug.cgi?id=997965
>
> Signed-off-by: Pavel Šimerda <psimerda@redhat.com>
> ---
> ip/iproute.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/ip/iproute.c b/ip/iproute.c
> index d77b1e3..c171f29 100644
> --- a/ip/iproute.c
> +++ b/ip/iproute.c
> @@ -975,6 +975,9 @@ static int iproute_modify(int cmd, unsigned flags, int argc, char **argv)
> argc--; argv++;
> }
>
> + if (!dst_ok)
> + usage();
> +
> if (d || nhs_ok) {
> int idx;
>
Good catch. Applied
^ 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