* [PATCH net v2 3/3] qede: Fix possible misconfiguration of advertised autoneg value.
From: Sudarsana Reddy Kalluru @ 2017-05-04 15:15 UTC (permalink / raw)
To: davem; +Cc: netdev, Yuval.Mintz
In-Reply-To: <20170504151505.4407-1-sudarsana.kalluru@cavium.com>
Fail the configuration of advertised speed-autoneg value if the config
update is not supported.
Signed-off-by: Sudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com>
Signed-off-by: Yuval Mintz <Yuval.Mintz@cavium.com>
---
drivers/net/ethernet/qlogic/qede/qede_ethtool.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/ethernet/qlogic/qede/qede_ethtool.c b/drivers/net/ethernet/qlogic/qede/qede_ethtool.c
index b22753c..172b292 100644
--- a/drivers/net/ethernet/qlogic/qede/qede_ethtool.c
+++ b/drivers/net/ethernet/qlogic/qede/qede_ethtool.c
@@ -493,6 +493,11 @@ static int qede_set_link_ksettings(struct net_device *dev,
params.override_flags |= QED_LINK_OVERRIDE_SPEED_ADV_SPEEDS;
params.override_flags |= QED_LINK_OVERRIDE_SPEED_AUTONEG;
if (base->autoneg == AUTONEG_ENABLE) {
+ if (!(current_link.supported_caps & QED_LM_Autoneg_BIT)) {
+ DP_INFO(edev, "Auto negotiation is not supported\n");
+ return -EOPNOTSUPP;
+ }
+
params.autoneg = true;
params.forced_speed = 0;
QEDE_ETHTOOL_TO_DRV_CAPS(params.adv_speeds, cmd, advertising)
--
1.8.3.1
^ permalink raw reply related
* [PATCH net v2 2/3] qed: Fix overriding of supported autoneg value.
From: Sudarsana Reddy Kalluru @ 2017-05-04 15:15 UTC (permalink / raw)
To: davem; +Cc: netdev, Yuval.Mintz
In-Reply-To: <20170504151505.4407-1-sudarsana.kalluru@cavium.com>
Driver currently uses advertised-autoneg value to populate the
supported-autoneg field. When advertised field is updated, user gets
the same value for supported field. Supported-autoneg value need to be
populated from the link capabilities value returned by the MFW.
Signed-off-by: Sudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com>
Signed-off-by: Yuval Mintz <Yuval.Mintz@cavium.com>
---
drivers/net/ethernet/qlogic/qed/qed_dev.c | 3 +++
drivers/net/ethernet/qlogic/qed/qed_main.c | 6 +++++-
drivers/net/ethernet/qlogic/qed/qed_mcp.h | 1 +
3 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_dev.c b/drivers/net/ethernet/qlogic/qed/qed_dev.c
index 5c6874a..bb70522 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_dev.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_dev.c
@@ -2536,6 +2536,9 @@ static int qed_hw_get_nvm_info(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt)
DP_NOTICE(p_hwfn, "Unknown Speed in 0x%08x\n", link_temp);
}
+ p_hwfn->mcp_info->link_capabilities.default_speed_autoneg =
+ link->speed.autoneg;
+
link_temp &= NVM_CFG1_PORT_DRV_FLOW_CONTROL_MASK;
link_temp >>= NVM_CFG1_PORT_DRV_FLOW_CONTROL_OFFSET;
link->pause.autoneg = !!(link_temp &
diff --git a/drivers/net/ethernet/qlogic/qed/qed_main.c b/drivers/net/ethernet/qlogic/qed/qed_main.c
index a5eef1a..b7ad36b 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_main.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_main.c
@@ -1372,7 +1372,7 @@ static void qed_fill_link(struct qed_hwfn *hwfn,
/* TODO - at the moment assume supported and advertised speed equal */
if_link->supported_caps = QED_LM_FIBRE_BIT;
- if (params.speed.autoneg)
+ if (link_caps.default_speed_autoneg)
if_link->supported_caps |= QED_LM_Autoneg_BIT;
if (params.pause.autoneg ||
(params.pause.forced_rx && params.pause.forced_tx))
@@ -1382,6 +1382,10 @@ static void qed_fill_link(struct qed_hwfn *hwfn,
if_link->supported_caps |= QED_LM_Pause_BIT;
if_link->advertised_caps = if_link->supported_caps;
+ if (params.speed.autoneg)
+ if_link->advertised_caps |= QED_LM_Autoneg_BIT;
+ else
+ if_link->advertised_caps &= ~QED_LM_Autoneg_BIT;
if (params.speed.advertised_speeds &
NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_1G)
if_link->advertised_caps |= QED_LM_1000baseT_Half_BIT |
diff --git a/drivers/net/ethernet/qlogic/qed/qed_mcp.h b/drivers/net/ethernet/qlogic/qed/qed_mcp.h
index 5ae35d6..2b09b85 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_mcp.h
+++ b/drivers/net/ethernet/qlogic/qed/qed_mcp.h
@@ -61,6 +61,7 @@ struct qed_mcp_link_params {
struct qed_mcp_link_capabilities {
u32 speed_capabilities;
+ bool default_speed_autoneg;
};
struct qed_mcp_link_state {
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH] cfg80211: make RATE_INFO_BW_20 the default
From: Johannes Berg @ 2017-05-04 15:16 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, torvalds, netdev
In-Reply-To: <20170504.111333.814726752020791317.davem@davemloft.net>
On Thu, 2017-05-04 at 11:13 -0400, David Miller wrote:
>
> Johannes, would you like me to merge this in via my tree directly?
I figured I'd give Linus to a chance to try or even apply it, but I
have no objection to you applying it either. I don't have anything else
yet right now, and sending a pull request for just a single patch
would be quite pointless.
johannes
^ permalink raw reply
* Re: [PATCH iproute] tc: Reflect HW offload status
From: Simon Horman @ 2017-05-04 15:17 UTC (permalink / raw)
To: Or Gerlitz; +Cc: Stephen Hemminger, netdev, Roi Dayan, Paul Blakey
In-Reply-To: <1493903715-29664-1-git-send-email-ogerlitz@mellanox.com>
On Thu, May 04, 2017 at 04:15:15PM +0300, Or Gerlitz wrote:
> Currently there is no way of querying whether a filter is
> offloaded to HW or not when using "both" policy (where none
> of skip_sw or skip_hw flags are set by user-space).
>
> Add two new flags, "in hw" and "not in hw" such that user
> space can determine if a filter is actually offloaded to
> hw or not. The "in hw" UAPI semantics was chosen so it's
> similar to the "skip hw" flag logic.
>
> If none of these two flags are set, this signals running
> over older kernel.
>
> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
> Reviewed-by: Jiri Pirko <jiri@mellanox.com>
Reviewed-by: Simon Horman <simon.horman@netronome.com>
^ permalink raw reply
* [RFC net-next] ipv6: ext_header: add function to handle RPL extension header option 0x63
From: Andreas Bardoutsos @ 2017-05-04 15:17 UTC (permalink / raw)
To: netdev
Cc: linux-wpan, Michael Richardson, Unstrung Hackers, netdev-owner,
linux-bluetooth
Signed-off-by: Andreas Bardoutsos <bardoutsos@ceid.upatras.gr>
---
Hi all!
I have added a dump function(always return true) to recognise RPL
extension header(RFC6553)
Otherwise packet was dropped by kernel resulting in failing
communication in RPL DAG's between
linux running border routers and devices in the graph.For example
communication
with contiki OS running devices was previously impossible.
include/uapi/linux/in6.h | 1 +
net/ipv6/exthdrs.c | 13 +++++++++++++
2 files changed, 14 insertions(+)
diff --git a/include/uapi/linux/in6.h b/include/uapi/linux/in6.h
index 46444f8fbee4..5cc12d309dfe 100644
--- a/include/uapi/linux/in6.h
+++ b/include/uapi/linux/in6.h
@@ -146,6 +146,7 @@ struct in6_flowlabel_req {
#define IPV6_TLV_CALIPSO 7 /* RFC 5570 */
#define IPV6_TLV_JUMBO 194
#define IPV6_TLV_HAO 201 /* home address option */
+#define IPV6_TLV_RPL 99 /* RFC 6553 */
/*
* IPV6 socket options
diff --git a/net/ipv6/exthdrs.c b/net/ipv6/exthdrs.c
index b636f1da9aec..82ed60d3180e 100644
--- a/net/ipv6/exthdrs.c
+++ b/net/ipv6/exthdrs.c
@@ -785,6 +785,15 @@ static bool ipv6_hop_calipso(struct sk_buff *skb,
int optoff)
return false;
}
+/* RPL RFC 6553 */
+
+static bool ipv6_hop_rpl(struct sk_buff *skb, int optoff)
+{
+ /*Dump function which always return true
+ *when rpl option is detected*/
+ return true;
+}
+
static const struct tlvtype_proc tlvprochopopt_lst[] = {
{
.type = IPV6_TLV_ROUTERALERT,
@@ -798,6 +807,10 @@ static const struct tlvtype_proc
tlvprochopopt_lst[] = {
.type = IPV6_TLV_CALIPSO,
.func = ipv6_hop_calipso,
},
+ {
+ .type = IPV6_TLV_RPL,
+ .func = ipv6_hop_rpl,
+ },
{ -1, }
};
^ permalink raw reply related
* Re: [PATCH] xen-netfront: avoid crashing on resume after a failure in talk_to_netback()
From: David Miller @ 2017-05-04 15:21 UTC (permalink / raw)
To: vkuznets; +Cc: xen-devel, netdev, linux-kernel, boris.ostrovsky, jgross
In-Reply-To: <20170504122304.11735-1-vkuznets@redhat.com>
From: Vitaly Kuznetsov <vkuznets@redhat.com>
Date: Thu, 4 May 2017 14:23:04 +0200
> Unavoidable crashes in netfront_resume() and netback_changed() after a
> previous fail in talk_to_netback() (e.g. when we fail to read MAC from
> xenstore) were discovered. The failure path in talk_to_netback() does
> unregister/free for netdev but we don't reset drvdata and we try accessing
> it again after resume.
>
> Reset drvdata in netback_changed() the same way we reset it in
> netfront_probe() and check for NULL in both netfront_resume() and
> netback_changed() to properly handle the situation.
>
> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
The circumstances under which netfront_probe() NULLs out the device
private is different than what you propose here, which is to do it
on a live device in netback_changed() whilst mutliple susbsytems
have a reference to this device and can call into the driver still.
It is only legal to do this in the probe function because such
references and execution possibilities do not exist at that point.
What really needs to happen is that the xenbus_driver must be told to
unregister this xen device and stop making calls into the driver for
it before you release the netdev state.
That is the only reasonable way to fix this bug.
Thanks.
^ permalink raw reply
* Re: [PATCH] cfg80211: make RATE_INFO_BW_20 the default
From: David Miller @ 2017-05-04 15:22 UTC (permalink / raw)
To: johannes-cdvu00un1VgdHxzADdlk8Q
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1493911002.18881.0.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
From: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
Date: Thu, 04 May 2017 17:16:42 +0200
> On Thu, 2017-05-04 at 11:13 -0400, David Miller wrote:
>>
>> Johannes, would you like me to merge this in via my tree directly?
>
> I figured I'd give Linus to a chance to try or even apply it, but I
> have no objection to you applying it either. I don't have anything else
> yet right now, and sending a pull request for just a single patch
> would be quite pointless.
Ok, let's give Linus a chance to test the patch.
^ permalink raw reply
* WARNING: CPU: 2 PID: 682 at net/wireless/util.c:1236
From: Jens Axboe @ 2017-05-04 15:23 UTC (permalink / raw)
To: Kalle Valo
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, linuxwifi-ral2JQCrhuEAvxtiuMwx3w,
Johannes Berg
Hi,
Running current -git on my laptop, and I see this spew every once
in a while. This is new, haven't seen it in 4.11 or previously. Driver
is iwlwifi:
04:00.0 Network controller: Intel Corporation Wireless 8260 (rev 3a)
[ 3285.862640] IPv6: ADDRCONF(NETDEV_CHANGE): wlp4s0: link becomes ready
[ 3285.978482] ------------[ cut here ]------------
[ 3285.978501] WARNING: CPU: 2 PID: 682 at net/wireless/util.c:1236 cfg80211_calculate_bitrate+0x130/0x160 [cfg80211]
[ 3285.978502] Modules linked in: ctr ccm rfcomm fuse bnep arc4 snd_hda_codec_hdmi iwlmvm snd_hda_codec_conexant snd_hda_codec_generic mac80211 snd_hda_intel snd_hda_codec binfmt_misc snd_hwdep snd_hda_core snd_pcm x86_pkg_temp_thermal nls_iso8859_1 intel_powerclamp nls_cp437 kvm_intel vfat snd_seq_midi fat kvm iwlwifi snd_seq_midi_event btusb snd_rawmidi btintel bluetooth snd_seq uvcvideo irqbypass aesni_intel videobuf2_vmalloc videobuf2_memops snd_seq_device aes_x86_64 videobuf2_v4l2 crypto_simd snd_timer videobuf2_core cryptd glue_helper videodev cfg80211 ecdh_generic snd soundcore hid_generic usbhid hid i915 psmouse e1000e ptp pps_core xhci_pci xhci_hcd intel_gtt
[ 3285.978536] CPU: 2 PID: 682 Comm: NetworkManager Tainted: G U 4.11.0+ #59
[ 3285.978537] Hardware name: LENOVO 20FBCTO1WW/20FBCTO1WW, BIOS N1FET50W (1.24 ) 03/08/2017
[ 3285.978538] task: ffff880421de2880 task.stack: ffff8804234a8000
[ 3285.978551] RIP: 0010:cfg80211_calculate_bitrate+0x130/0x160 [cfg80211]
[ 3285.978552] RSP: 0018:ffff8804234ab638 EFLAGS: 00010293
[ 3285.978553] RAX: 0000000000000000 RBX: ffff88042df2cf00 RCX: 0000000000000002
[ 3285.978554] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8804234ab7d6
[ 3285.978555] RBP: ffff8804234ab638 R08: 0000000000000004 R09: ffff8804252c20d4
[ 3285.978556] R10: 00000000088002aa R11: ffffffffa02a6000 R12: ffff8804234ab7d6
[ 3285.978557] R13: ffff8804252c20d0 R14: ffff8804252c2030 R15: ffff880424bf0000
[ 3285.978559] FS: 00007f4e016a8940(0000) GS:ffff880441500000(0000) knlGS:0000000000000000
[ 3285.978560] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 3285.978561] CR2: 00000c5e5d540010 CR3: 000000042b626000 CR4: 00000000001406e0
[ 3285.978561] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 3285.978562] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 3285.978563] Call Trace:
[ 3285.978577] nl80211_put_sta_rate+0x4e/0x1f0 [cfg80211]
[ 3285.978591] nl80211_send_station.isra.66+0x344/0xcc0 [cfg80211]
[ 3285.978595] ? __kmalloc_track_caller+0x31/0x1a0
[ 3285.978608] nl80211_get_station+0x1d9/0x250 [cfg80211]
[ 3285.978620] genl_family_rcv_msg+0x1bf/0x380
[ 3285.978622] genl_rcv_msg+0x4c/0x90
[ 3285.978623] ? genl_family_rcv_msg+0x380/0x380
[ 3285.978629] netlink_rcv_skb+0x7f/0x110
[ 3285.978630] genl_rcv+0x28/0x40
[ 3285.978633] netlink_unicast+0x183/0x220
[ 3285.978635] netlink_sendmsg+0x293/0x390
[ 3285.978637] sock_sendmsg+0x38/0x50
[ 3285.978638] ___sys_sendmsg+0x256/0x2b0
[ 3285.978641] ? __slab_free+0x1d1/0x2c0
[ 3285.978643] ? destroy_inode+0x3b/0x60
[ 3285.978645] ? do_wp_page+0x103/0x440
[ 3285.978646] ? __handle_mm_fault+0x34e/0xa10
[ 3285.978648] ? __fget+0x6e/0x90
[ 3285.978650] __sys_sendmsg+0x45/0x80
[ 3285.978652] ? __sys_sendmsg+0x45/0x80
[ 3285.978654] SyS_sendmsg+0x12/0x20
[ 3285.978656] entry_SYSCALL_64_fastpath+0x13/0x94
[ 3285.978657] RIP: 0033:0x7f4dff521a6d
[ 3285.978658] RSP: 002b:00007ffc7507aec0 EFLAGS: 00000293 ORIG_RAX: 000000000000002e
[ 3285.978660] RAX: ffffffffffffffda RBX: 0000000002044b60 RCX: 00007f4dff521a6d
[ 3285.978661] RDX: 0000000000000000 RSI: 00007ffc7507af50 RDI: 0000000000000010
[ 3285.978661] RBP: 00007f4dff50bb20 R08: 0000000000000000 R09: 0000000000000000
[ 3285.978662] R10: 0000000001fd8df0 R11: 0000000000000293 R12: 0000000000001010
[ 3285.978663] R13: 00007f4dff50bb78 R14: 00000000000026fc R15: 0000000001ffc570
[ 3285.978664] Code: d0 f7 e1 d1 ea 8d 14 92 01 d2 81 c2 50 c3 00 00 b9 c5 5a 7c 0a 5d c1 ea 05 89 d0 f7 e1 89 d0 c1 e8 07 c3 31 c0 40 80 fe 02 74 b6 <0f> ff 31 c0 eb b0 8d 14 52 01 d2 e9 41 ff ff ff 0f ff 31 c0 5d
[ 3285.978693] ---[ end trace ae08dfa326cc120a ]---
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH net] rtnetlink: NUL-terminate IFLA_PHYS_PORT_NAME string
From: David Miller @ 2017-05-04 15:24 UTC (permalink / raw)
To: mschmidt; +Cc: netdev, thaller, dsahern
In-Reply-To: <20170504144858.1905-1-mschmidt@redhat.com>
From: Michal Schmidt <mschmidt@redhat.com>
Date: Thu, 4 May 2017 16:48:58 +0200
> IFLA_PHYS_PORT_NAME is a string attribute, so terminate it with \0.
> Otherwise libnl3 fails to validate netlink messages with this attribute.
> "ip -detail a" assumes too that the attribute is NUL-terminated when
> printing it. It often was, due to padding.
>
> I noticed this as libvirtd failing to start on a system with sfc driver
> after upgrading it to Linux 4.11, i.e. when sfc added support for
> phys_port_name.
>
> Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
Good catch, applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: WARNING: CPU: 2 PID: 682 at net/wireless/util.c:1236
From: David Miller @ 2017-05-04 15:25 UTC (permalink / raw)
To: axboe; +Cc: kvalo, linux-wireless, netdev, linuxwifi, johannes.berg
In-Reply-To: <240bae44-56e4-f342-0d1b-358a573e2eeb@kernel.dk>
From: Jens Axboe <axboe@kernel.dk>
Date: Thu, 4 May 2017 09:23:36 -0600
> Running current -git on my laptop, and I see this spew every once
> in a while. This is new, haven't seen it in 4.11 or previously. Driver
> is iwlwifi:
Please try:
http://patchwork.ozlabs.org/patch/758364/
^ permalink raw reply
* Re: WARNING: CPU: 2 PID: 682 at net/wireless/util.c:1236
From: Jens Axboe @ 2017-05-04 15:27 UTC (permalink / raw)
To: David Miller
Cc: kvalo-sgV2jX0FEOL9JmXXK+q4OQ,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, linuxwifi-ral2JQCrhuEAvxtiuMwx3w,
johannes.berg-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <20170504.112512.833061289089590605.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On 05/04/2017 09:25 AM, David Miller wrote:
> From: Jens Axboe <axboe-tSWWG44O7X1aa/9Udqfwiw@public.gmane.org>
> Date: Thu, 4 May 2017 09:23:36 -0600
>
>> Running current -git on my laptop, and I see this spew every once
>> in a while. This is new, haven't seen it in 4.11 or previously. Driver
>> is iwlwifi:
>
> Please try:
>
> http://patchwork.ozlabs.org/patch/758364/
Will do, compiling...
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH v1] ACPI: Switch to use generic UUID API
From: Benjamin Tissoires @ 2017-05-04 15:29 UTC (permalink / raw)
To: Andy Shevchenko
Cc: alsa-devel, Heikki Krogerus, Liam Girdwood, linux-pci,
Amir Goldstein, Jarkko Sakkinen, Adrian Hunter, Joerg Roedel,
linux-acpi, tpmdd-devel, Ben Skeggs, nouveau, linux-mmc,
Zhang Rui, Borislav Petkov, Yisen Zhuang, Mathias Nyman,
intel-gfx, linux-input, Mark Brown, Bjorn Helgaas, Dan Williams,
Mika Westerberg, Felipe Balbi, netdev
In-Reply-To: <20170504092151.88646-1-andriy.shevchenko@linux.intel.com>
On May 04 2017 or thereabouts, Andy Shevchenko wrote:
> acpi_evaluate_dsm() and friends take a pointer to a raw buffer of 16
> bytes. Instead we convert them to use uuid_le type. At the same time we
> convert current users.
>
> acpi_str_to_uuid() becomes useless after the conversion and it's safe to
> get rid of it.
>
> The conversion fixes a potential bug in int340x_thermal as well since
> we have to use memcmp() on binary data.
>
> Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
> Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
> Cc: Borislav Petkov <bp@suse.de>
> Cc: Dan Williams <dan.j.williams@intel.com>
> Cc: Amir Goldstein <amir73il@gmail.com>
> Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: Ben Skeggs <bskeggs@redhat.com>
> Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> Cc: Joerg Roedel <joro@8bytes.org>
> Cc: Adrian Hunter <adrian.hunter@intel.com>
> Cc: Yisen Zhuang <yisen.zhuang@huawei.com>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Zhang Rui <rui.zhang@intel.com>
> Cc: Felipe Balbi <balbi@kernel.org>
> Cc: Mathias Nyman <mathias.nyman@intel.com>
> Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>
> Cc: Liam Girdwood <lgirdwood@gmail.com>
> Cc: Mark Brown <broonie@kernel.org>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
For i2c-hid:
Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: net/smc and the RDMA core
From: Jason Gunthorpe @ 2017-05-04 15:31 UTC (permalink / raw)
To: Ursula Braun
Cc: hch@lst.de, Sagi Grimberg, Bart Van Assche, davem@davemloft.net,
netdev@vger.kernel.org, linux-rdma@vger.kernel.org
In-Reply-To: <efa9bd6d-1df9-952a-7f32-c2ee6bffcae5@linux.vnet.ibm.com>
On Thu, May 04, 2017 at 03:08:39PM +0200, Ursula Braun wrote:
>
>
> On 05/04/2017 10:48 AM, hch@lst.de wrote:
> > On Thu, May 04, 2017 at 11:43:50AM +0300, Sagi Grimberg wrote:
> >> I would also suggest that you stop exposing the DMA MR for remote
> >> access (at least by default) and use a proper reg_mr operations with a
> >> limited lifetime on a properly sized buffer.
> >
> > Yes, exposing the default DMA MR is a _major_ security risk. As soon
> > as SMC is enabled this will mean a remote system has full read/write
> > access to the local systems memory.
> >
> > There ??s a reason why I removed the ib_get_dma_mr function and replaced
> > it with the IB_PD_UNSAFE_GLOBAL_RKEY key that has _UNSAFE_ in the name
> > and a very long comment explaining why, and I'm really disappointed that
> > we got a driver merged that instead of asking on the relevant list on
> > why a change unexpertong a function it needed happened and instead
> > tried the hard way to keep a security vulnerarbility alive.
> >
> Thanks for pointing out these problems. We will address them.
So, you've created a huge security hole in the kernel, anyone who
loads your smc module is vunerable.
What are you going to do *RIGHT NOW* to mitigate this?
Jason
^ permalink raw reply
* Re: WARNING: CPU: 2 PID: 682 at net/wireless/util.c:1236
From: Jens Axboe @ 2017-05-04 15:40 UTC (permalink / raw)
To: David Miller; +Cc: kvalo, linux-wireless, netdev, linuxwifi, johannes.berg
In-Reply-To: <4ad7a627-62c7-be34-2dae-c54bb3ef0a15@kernel.dk>
On 05/04/2017 09:27 AM, Jens Axboe wrote:
> On 05/04/2017 09:25 AM, David Miller wrote:
>> From: Jens Axboe <axboe@kernel.dk>
>> Date: Thu, 4 May 2017 09:23:36 -0600
>>
>>> Running current -git on my laptop, and I see this spew every once
>>> in a while. This is new, haven't seen it in 4.11 or previously. Driver
>>> is iwlwifi:
>>
>> Please try:
>>
>> http://patchwork.ozlabs.org/patch/758364/
>
> Will do, compiling...
Yep works, thanks.
--
Jens Axboe
^ permalink raw reply
* Re: [RFC] iproute: Add support for extended ack to rtnl_talk
From: Jamal Hadi Salim @ 2017-05-04 15:50 UTC (permalink / raw)
To: David Miller, dsahern; +Cc: daniel, stephen, netdev
In-Reply-To: <20170504.104103.1628291573330660235.davem@davemloft.net>
On 17-05-04 10:41 AM, David Miller wrote:
> From: David Ahern <dsahern@gmail.com>
> Date: Thu, 4 May 2017 08:27:35 -0600
>
>> On 5/4/17 3:36 AM, Daniel Borkmann wrote:
>>> What is the clear benefit/rationale of outsourcing this to
>>> libmnl? I always was the impression we should strive for as little
>>> dependencies as possible?
>>
>> +1
>
> Agreed, all else being equal iproute2 should be as self contained
> as possible since it is such a fundamental tool.
>
True, but:->
iproute2 _already_ depends on libmnl;-> (latest user being devlink).
cheers,
jamal
^ permalink raw reply
* RE: [PATCH] x86/asm: Don't use rbp as temp register in csum_partial_copy_generic()
From: David Laight @ 2017-05-04 15:56 UTC (permalink / raw)
To: 'Josh Poimboeuf', x86@kernel.org
Cc: Andrey Konovalov, linux-kernel@vger.kernel.org, Vlad Yasevich,
Neil Horman, David S . Miller, linux-sctp@vger.kernel.org, netdev,
Marcelo Ricardo Leitner, Dmitry Vyukov, Kostya Serebryany,
syzkaller, Eric Dumazet, Cong Wang
In-Reply-To: <4b03a961efda5ec9bfe46b7b9c9ad72d1efad343.1493909486.git.jpoimboe@redhat.com>
From: Josh Poimboeuf
> Sent: 04 May 2017 15:52
> Andrey Konovalov reported the following warning while fuzzing the kernel
> with syzkaller:
>
> WARNING: kernel stack regs at ffff8800686869f8 in a.out:4933 has bad 'bp' value c3fc855a10167ec0
>
> The unwinder dump revealed that rbp had a bad value when an interrupt
> occurred in csum_partial_copy_generic().
>
> That function saves rbp on the stack and then overwrites it, using it as
> a scratch register. That's problematic because it breaks stack traces
> if an interrupt occurs in the middle of the function.
Does gcc guarantee not to use bp as a scratch register in leaf functions?
David
^ permalink raw reply
* Re: WARNING: CPU: 2 PID: 682 at net/wireless/util.c:1236
From: David Miller @ 2017-05-04 15:59 UTC (permalink / raw)
To: axboe-tSWWG44O7X1aa/9Udqfwiw
Cc: kvalo-sgV2jX0FEOL9JmXXK+q4OQ,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, linuxwifi-ral2JQCrhuEAvxtiuMwx3w,
johannes.berg-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <b25325a9-ab93-1c57-3b59-2d52a76d279a-tSWWG44O7X1aa/9Udqfwiw@public.gmane.org>
From: Jens Axboe <axboe-tSWWG44O7X1aa/9Udqfwiw@public.gmane.org>
Date: Thu, 4 May 2017 09:40:08 -0600
> On 05/04/2017 09:27 AM, Jens Axboe wrote:
>> On 05/04/2017 09:25 AM, David Miller wrote:
>>> From: Jens Axboe <axboe-tSWWG44O7X1aa/9Udqfwiw@public.gmane.org>
>>> Date: Thu, 4 May 2017 09:23:36 -0600
>>>
>>>> Running current -git on my laptop, and I see this spew every once
>>>> in a while. This is new, haven't seen it in 4.11 or previously. Driver
>>>> is iwlwifi:
>>>
>>> Please try:
>>>
>>> http://patchwork.ozlabs.org/patch/758364/
>>
>> Will do, compiling...
>
> Yep works, thanks.
Thanks for testing.
^ permalink raw reply
* Re: [RFC net-next] ipv6: ext_header: add function to handle RPL extension header option 0x63
From: Jiri Pirko @ 2017-05-04 16:00 UTC (permalink / raw)
To: Andreas Bardoutsos
Cc: netdev, linux-wpan, Michael Richardson, Unstrung Hackers,
netdev-owner, linux-bluetooth
In-Reply-To: <dca567582f1979384fb1f3c3d1411349@ceid.upatras.gr>
Thu, May 04, 2017 at 05:17:18PM CEST, bardoutsos@ceid.upatras.gr wrote:
>Signed-off-by: Andreas Bardoutsos <bardoutsos@ceid.upatras.gr>
>---
>Hi all!
>
>I have added a dump function(always return true) to recognise RPL extension
>header(RFC6553)
>Otherwise packet was dropped by kernel resulting in failing communication in
>RPL DAG's between
>linux running border routers and devices in the graph.For example
>communication
>with contiki OS running devices was previously impossible.
>
> include/uapi/linux/in6.h | 1 +
> net/ipv6/exthdrs.c | 13 +++++++++++++
> 2 files changed, 14 insertions(+)
>
>diff --git a/include/uapi/linux/in6.h b/include/uapi/linux/in6.h
>index 46444f8fbee4..5cc12d309dfe 100644
>--- a/include/uapi/linux/in6.h
>+++ b/include/uapi/linux/in6.h
>@@ -146,6 +146,7 @@ struct in6_flowlabel_req {
> #define IPV6_TLV_CALIPSO 7 /* RFC 5570 */
> #define IPV6_TLV_JUMBO 194
> #define IPV6_TLV_HAO 201 /* home address option */
>+#define IPV6_TLV_RPL 99 /* RFC 6553 */
>
> /*
> * IPV6 socket options
>diff --git a/net/ipv6/exthdrs.c b/net/ipv6/exthdrs.c
>index b636f1da9aec..82ed60d3180e 100644
>--- a/net/ipv6/exthdrs.c
>+++ b/net/ipv6/exthdrs.c
>@@ -785,6 +785,15 @@ static bool ipv6_hop_calipso(struct sk_buff *skb, int
>optoff)
> return false;
> }
>
>+/* RPL RFC 6553 */
>+
>+static bool ipv6_hop_rpl(struct sk_buff *skb, int optoff)
>+{
>+ /*Dump function which always return true
>+ *when rpl option is detected*/
This is definitelly wrong formatting of comment. Did you run checkpatch?
>+ return true;
>+}
>+
> static const struct tlvtype_proc tlvprochopopt_lst[] = {
> {
> .type = IPV6_TLV_ROUTERALERT,
>@@ -798,6 +807,10 @@ static const struct tlvtype_proc tlvprochopopt_lst[] = {
> .type = IPV6_TLV_CALIPSO,
> .func = ipv6_hop_calipso,
> },
>+ {
>+ .type = IPV6_TLV_RPL,
>+ .func = ipv6_hop_rpl,
>+ },
> { -1, }
> };
>
^ permalink raw reply
* [net-ipv4] question about arguments position
From: Gustavo A. R. Silva @ 2017-05-04 16:07 UTC (permalink / raw)
To: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy
Cc: netdev, linux-kernel
Hello everybody,
While looking into Coverity ID 1357474 I ran into the following piece
of code at net/ipv4/inet_diag.c:392:
struct sock *inet_diag_find_one_icsk(struct net *net,
struct inet_hashinfo *hashinfo,
const struct inet_diag_req_v2 *req)
{
struct sock *sk;
rcu_read_lock();
if (req->sdiag_family == AF_INET)
sk = inet_lookup(net, hashinfo, NULL, 0, req->id.idiag_dst[0],
req->id.idiag_dport, req->id.idiag_src[0],
req->id.idiag_sport, req->id.idiag_if);
#if IS_ENABLED(CONFIG_IPV6)
else if (req->sdiag_family == AF_INET6) {
if (ipv6_addr_v4mapped((struct in6_addr
*)req->id.idiag_dst) &&
ipv6_addr_v4mapped((struct in6_addr *)req->id.idiag_src))
sk = inet_lookup(net, hashinfo, NULL, 0,
req->id.idiag_dst[3],
req->id.idiag_dport,
req->id.idiag_src[3],
req->id.idiag_sport,
req->id.idiag_if);
else
sk = inet6_lookup(net, hashinfo, NULL, 0,
(struct in6_addr
*)req->id.idiag_dst,
req->id.idiag_dport,
(struct in6_addr
*)req->id.idiag_src,
req->id.idiag_sport,
req->id.idiag_if);
}
#endif
The issue here is that the position of arguments in the call to
inet_lookup() and inet6_lookup() functions do not match the order of
the parameters:
req->id.idiag_dport is passed to sport
req->id.idiag_sport is passed to dport
These are the function prototypes:
static inline struct sock *inet_lookup(struct net *net,
struct inet_hashinfo *hashinfo,
struct sk_buff *skb, int doff,
const __be32 saddr, const __be16 sport,
const __be32 daddr, const __be16 dport,
const int dif)
struct sock *inet6_lookup(struct net *net, struct inet_hashinfo *hashinfo,
struct sk_buff *skb, int doff,
const struct in6_addr *saddr, const __be16 sport,
const struct in6_addr *daddr, const __be16 dport,
const int dif)
My question here is if this is intentional?
In case it is not, I will send a patch to fix it. But first it would
be great to hear any comment about it.
Thank you!
--
Gustavo A. R. Silva
^ permalink raw reply
* Re: [PATCH] x86/asm: Don't use rbp as temp register in csum_partial_copy_generic()
From: Josh Poimboeuf @ 2017-05-04 16:11 UTC (permalink / raw)
To: David Laight
Cc: x86@kernel.org, Andrey Konovalov, linux-kernel@vger.kernel.org,
Vlad Yasevich, Neil Horman, David S . Miller,
linux-sctp@vger.kernel.org, netdev, Marcelo Ricardo Leitner,
Dmitry Vyukov, Kostya Serebryany, syzkaller, Eric Dumazet,
Cong Wang
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6DCFFE581C@AcuExch.aculab.com>
On Thu, May 04, 2017 at 03:56:49PM +0000, David Laight wrote:
> From: Josh Poimboeuf
> > Sent: 04 May 2017 15:52
> > Andrey Konovalov reported the following warning while fuzzing the kernel
> > with syzkaller:
> >
> > WARNING: kernel stack regs at ffff8800686869f8 in a.out:4933 has bad 'bp' value c3fc855a10167ec0
> >
> > The unwinder dump revealed that rbp had a bad value when an interrupt
> > occurred in csum_partial_copy_generic().
> >
> > That function saves rbp on the stack and then overwrites it, using it as
> > a scratch register. That's problematic because it breaks stack traces
> > if an interrupt occurs in the middle of the function.
>
> Does gcc guarantee not to use bp as a scratch register in leaf functions?
At least in practice, gcc doesn't touch rbp in leaf functions. (I don't
know about guarantees.)
--
Josh
^ permalink raw reply
* Re: [PATCH net] rtnetlink: NUL-terminate IFLA_PHYS_PORT_NAME string
From: David Ahern @ 2017-05-04 16:14 UTC (permalink / raw)
To: Michal Schmidt, netdev; +Cc: Thomas Haller
In-Reply-To: <20170504144858.1905-1-mschmidt@redhat.com>
On 5/4/17 8:48 AM, Michal Schmidt wrote:
> IFLA_PHYS_PORT_NAME is a string attribute, so terminate it with \0.
> Otherwise libnl3 fails to validate netlink messages with this attribute.
> "ip -detail a" assumes too that the attribute is NUL-terminated when
> printing it. It often was, due to padding.
>
> I noticed this as libvirtd failing to start on a system with sfc driver
> after upgrading it to Linux 4.11, i.e. when sfc added support for
> phys_port_name.
>
> Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
> ---
> net/core/rtnetlink.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
> index c4e84c5582..69daf393cb 100644
> --- a/net/core/rtnetlink.c
> +++ b/net/core/rtnetlink.c
> @@ -1056,7 +1056,7 @@ static int rtnl_phys_port_name_fill(struct sk_buff *skb, struct net_device *dev)
> return err;
> }
>
> - if (nla_put(skb, IFLA_PHYS_PORT_NAME, strlen(name), name))
> + if (nla_put_string(skb, IFLA_PHYS_PORT_NAME, name))
> return -EMSGSIZE;
>
> return 0;
>
Thanks for fixing.
^ permalink raw reply
* [PATCH] aquantia: Fix "ethtool -S" crash when adapter down.
From: Pavel Belous @ 2017-05-04 16:33 UTC (permalink / raw)
To: David S . Miller; +Cc: netdev, David Arcari
From: Pavel Belous <pavel.belous@aquantia.com>
This patch fixes the crash that happens when driver tries to collect statistics
from already released "aq_vec" object.
Fixes: 97bde5c4f909 ("net: ethernet: aquantia: Support for NIC-specific code")
Signed-off-by: Pavel Belous <pavel.belous@aquantia.com>
---
drivers/net/ethernet/aquantia/atlantic/aq_nic.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/aquantia/atlantic/aq_nic.c b/drivers/net/ethernet/aquantia/atlantic/aq_nic.c
index cdb0299..3a32573 100644
--- a/drivers/net/ethernet/aquantia/atlantic/aq_nic.c
+++ b/drivers/net/ethernet/aquantia/atlantic/aq_nic.c
@@ -755,7 +755,7 @@ void aq_nic_get_stats(struct aq_nic_s *self, u64 *data)
count = 0U;
for (i = 0U, aq_vec = self->aq_vec[0];
- self->aq_vecs > i; ++i, aq_vec = self->aq_vec[i]) {
+ aq_vec && self->aq_vecs > i; ++i, aq_vec = self->aq_vec[i]) {
data += count;
aq_vec_get_sw_stats(aq_vec, data, &count);
}
@@ -961,6 +961,7 @@ void aq_nic_free_hot_resources(struct aq_nic_s *self)
for (i = AQ_DIMOF(self->aq_vec); i--;) {
if (self->aq_vec[i])
aq_vec_free(self->aq_vec[i]);
+ self->aq_vec[i] = NULL;
}
err_exit:;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] iproute2: hide devices starting with period by default
From: David Ahern @ 2017-05-04 16:37 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: David Miller, stephen, netdev
In-Reply-To: <0635d3bb-0d8d-7ab6-fb53-4d84f979a023@6wind.com>
On 5/4/17 9:15 AM, Nicolas Dichtel wrote:
> Le 24/02/2017 à 16:52, David Ahern a écrit :
>> On 2/23/17 8:12 PM, David Miller wrote:
>>> This really need to be a fundamental facility, so that it transparently
>>> works for NetworkManager, router daemons, everything. Not just iproute2
>>> and "ls".
>>
>> I'll rebase my patch and send out as RFC.
>>
> David, did you finally send those patches?
>
No, but for a few reasons.
It is easy to hide devices in a dump:
https://github.com/dsahern/linux/commit/48a80a00eac284e58bae04af10a5a932dd7aee00
But I think those devices should also not exist in sysfs or procfs which
overlaps what I would like to see for lightweight netdevices:
https://github.com/dsahern/linux/commit/70574be699cf252e77f71e3df11192438689f976
and to be complete, hidden devices should not be allowed to have a
network address or transmit packets which is the L2 only intent from
Florian:
https://www.spinics.net/lists/netdev/msg340808.html
^ permalink raw reply
* Re: [PATCH net v2 0/3] qed*: Bug fix series.
From: David Miller @ 2017-05-04 16:37 UTC (permalink / raw)
To: sudarsana.kalluru; +Cc: netdev, Yuval.Mintz
In-Reply-To: <20170504151505.4407-1-sudarsana.kalluru@cavium.com>
From: Sudarsana Reddy Kalluru <sudarsana.kalluru@cavium.com>
Date: Thu, 4 May 2017 08:15:02 -0700
> From: Sudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com>
>
> The series contains minor bug fixes for qed/qede drivers.
>
> Please consider applying it to 'net' branch.
Series applied, thanks.
^ permalink raw reply
* Re: [RFC] iproute: Add support for extended ack to rtnl_talk
From: Stephen Hemminger @ 2017-05-04 16:42 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: netdev
In-Reply-To: <590AF624.6090808@iogearbox.net>
On Thu, 04 May 2017 11:36:36 +0200
Daniel Borkmann <daniel@iogearbox.net> wrote:
> On 05/04/2017 01:56 AM, Stephen Hemminger wrote:
> > Add support for extended ack error reporting via libmnl. This
> > is a better alternative to use existing library and not copy/paste
> > code from the kernel. Also make arguments const where possible.
> >
> > Add a new function rtnl_talk_extack that takes a callback as an input
> > arg. If a netlink response contains extack attributes, the callback is
> > is invoked with the the err string, offset in the message and a pointer
> > to the message returned by the kernel.
> >
> > Adding a new function allows commands to be moved over to the
> > extended error reporting over time.
> >
> > For feedback, compile tested only.
>
> Just out of curiosity, what is the plan regarding converting iproute2
> over to libmnl (ip, tc, ss, ...)? In 2015, tipc tool was the first
> user merged that requires libmnl, the only other user today in the
> tree is devlink, which even seems to define its own libmnl library
> helpers. What is the clear benefit/rationale of outsourcing this to
> libmnl? I always was the impression we should strive for as little
> dependencies as possible?
>
> I don't really like that we make extended ack reporting now dependent
> on libmnl, which further diverts from iproute's native nl library vs
> requiring to install another nl library, making the current status
> quo even worse ... :/
>
> Thanks,
> Daniel
No rush for migration. just slow migration as time permits.
This would be good kernel janitor type project.
^ 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