* [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 1/3] qed*: Fix possible overflow for status block id field.
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>
Value for status block id could be more than 256 in 100G mode, need to
update its data type from u8 to u16.
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 | 8 ++++----
drivers/net/ethernet/qlogic/qed/qed_dev_api.h | 4 ++--
drivers/net/ethernet/qlogic/qed/qed_main.c | 2 +-
drivers/net/ethernet/qlogic/qede/qede_ethtool.c | 5 ++---
include/linux/qed/qed_if.h | 2 +-
5 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_dev.c b/drivers/net/ethernet/qlogic/qed/qed_dev.c
index 5f31140..5c6874a 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_dev.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_dev.c
@@ -3586,7 +3586,7 @@ static int qed_set_coalesce(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt,
}
int qed_set_rxq_coalesce(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt,
- u16 coalesce, u8 qid, u16 sb_id)
+ u16 coalesce, u16 qid, u16 sb_id)
{
struct ustorm_eth_queue_zone eth_qzone;
u8 timeset, timer_res;
@@ -3607,7 +3607,7 @@ int qed_set_rxq_coalesce(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt,
}
timeset = (u8)(coalesce >> timer_res);
- rc = qed_fw_l2_queue(p_hwfn, (u16)qid, &fw_qid);
+ rc = qed_fw_l2_queue(p_hwfn, qid, &fw_qid);
if (rc)
return rc;
@@ -3628,7 +3628,7 @@ int qed_set_rxq_coalesce(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt,
}
int qed_set_txq_coalesce(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt,
- u16 coalesce, u8 qid, u16 sb_id)
+ u16 coalesce, u16 qid, u16 sb_id)
{
struct xstorm_eth_queue_zone eth_qzone;
u8 timeset, timer_res;
@@ -3649,7 +3649,7 @@ int qed_set_txq_coalesce(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt,
}
timeset = (u8)(coalesce >> timer_res);
- rc = qed_fw_l2_queue(p_hwfn, (u16)qid, &fw_qid);
+ rc = qed_fw_l2_queue(p_hwfn, qid, &fw_qid);
if (rc)
return rc;
diff --git a/drivers/net/ethernet/qlogic/qed/qed_dev_api.h b/drivers/net/ethernet/qlogic/qed/qed_dev_api.h
index cefe3ee..12d16c0 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_dev_api.h
+++ b/drivers/net/ethernet/qlogic/qed/qed_dev_api.h
@@ -454,7 +454,7 @@ int qed_final_cleanup(struct qed_hwfn *p_hwfn,
* @return int
*/
int qed_set_rxq_coalesce(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt,
- u16 coalesce, u8 qid, u16 sb_id);
+ u16 coalesce, u16 qid, u16 sb_id);
/**
* @brief qed_set_txq_coalesce - Configure coalesce parameters for a Tx queue
@@ -471,7 +471,7 @@ int qed_set_rxq_coalesce(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt,
* @return int
*/
int qed_set_txq_coalesce(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt,
- u16 coalesce, u8 qid, u16 sb_id);
+ u16 coalesce, u16 qid, u16 sb_id);
const char *qed_hw_get_resc_name(enum qed_resources res_id);
#endif
diff --git a/drivers/net/ethernet/qlogic/qed/qed_main.c b/drivers/net/ethernet/qlogic/qed/qed_main.c
index 59992cf..a5eef1a 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_main.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_main.c
@@ -1521,7 +1521,7 @@ static void qed_get_coalesce(struct qed_dev *cdev, u16 *rx_coal, u16 *tx_coal)
}
static int qed_set_coalesce(struct qed_dev *cdev, u16 rx_coal, u16 tx_coal,
- u8 qid, u16 sb_id)
+ u16 qid, u16 sb_id)
{
struct qed_hwfn *hwfn;
struct qed_ptt *ptt;
diff --git a/drivers/net/ethernet/qlogic/qede/qede_ethtool.c b/drivers/net/ethernet/qlogic/qede/qede_ethtool.c
index 4dcfe96..b22753c 100644
--- a/drivers/net/ethernet/qlogic/qede/qede_ethtool.c
+++ b/drivers/net/ethernet/qlogic/qede/qede_ethtool.c
@@ -706,8 +706,7 @@ static int qede_set_coalesce(struct net_device *dev,
{
struct qede_dev *edev = netdev_priv(dev);
int i, rc = 0;
- u16 rxc, txc;
- u8 sb_id;
+ u16 rxc, txc, sb_id;
if (!netif_running(dev)) {
DP_INFO(edev, "Interface is down\n");
@@ -729,7 +728,7 @@ static int qede_set_coalesce(struct net_device *dev,
for_each_queue(i) {
sb_id = edev->fp_array[i].sb_info->igu_sb_id;
rc = edev->ops->common->set_coalesce(edev->cdev, rxc, txc,
- (u8)i, sb_id);
+ (u16)i, sb_id);
if (rc) {
DP_INFO(edev, "Set coalesce error, rc = %d\n", rc);
return rc;
diff --git a/include/linux/qed/qed_if.h b/include/linux/qed/qed_if.h
index 5544d7b..c70ac13 100644
--- a/include/linux/qed/qed_if.h
+++ b/include/linux/qed/qed_if.h
@@ -635,7 +635,7 @@ struct qed_common_ops {
* @return 0 on success, error otherwise.
*/
int (*set_coalesce)(struct qed_dev *cdev, u16 rx_coal, u16 tx_coal,
- u8 qid, u16 sb_id);
+ u16 qid, u16 sb_id);
/**
* @brief set_led - Configure LED mode
--
1.8.3.1
^ permalink raw reply related
* [PATCH net v2 0/3] qed*: Bug fix series.
From: Sudarsana Reddy Kalluru @ 2017-05-04 15:15 UTC (permalink / raw)
To: davem; +Cc: netdev, Yuval.Mintz, Sudarsana Reddy Kalluru
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.
Changes from previous versions:
-------------------------------
v2: Removed the incorrect comment message.
Sudarsana Reddy Kalluru (3):
qed*: Fix possible overflow for status block id field.
qed: Fix overriding of supported autoneg value.
qede: Fix possible misconfiguration of advertised autoneg value.
drivers/net/ethernet/qlogic/qed/qed_dev.c | 11 +++++++----
drivers/net/ethernet/qlogic/qed/qed_dev_api.h | 4 ++--
drivers/net/ethernet/qlogic/qed/qed_main.c | 8 ++++++--
drivers/net/ethernet/qlogic/qed/qed_mcp.h | 1 +
drivers/net/ethernet/qlogic/qede/qede_ethtool.c | 10 +++++++---
include/linux/qed/qed_if.h | 2 +-
6 files changed, 24 insertions(+), 12 deletions(-)
--
1.8.3.1
^ permalink raw reply
* Re: [PATCH] iproute2: hide devices starting with period by default
From: Nicolas Dichtel @ 2017-05-04 15:15 UTC (permalink / raw)
To: David Ahern; +Cc: David Miller, stephen, netdev
In-Reply-To: <0a8e1cf0-9f30-2356-5168-a97abb86d5c2@cumulusnetworks.com>
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?
Thank you,
Nicolas
^ permalink raw reply
* Re: [PATCH] cfg80211: make RATE_INFO_BW_20 the default
From: David Miller @ 2017-05-04 15:13 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, torvalds, netdev, johannes.berg
In-Reply-To: <20170504064230.22058-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Thu, 4 May 2017 08:42:30 +0200
> From: Johannes Berg <johannes.berg@intel.com>
>
> Due to the way I did the RX bitrate conversions in mac80211 with
> spatch, going setting flags to setting the value, many drivers now
> don't set the bandwidth value for 20 MHz, since with the flags it
> wasn't necessary to (there was no 20 MHz flag, only the others.)
>
> Rather than go through and try to fix up all the drivers, instead
> renumber the enum so that 20 MHz, which is the typical bandwidth,
> actually has the value 0, making those drivers all work again.
>
> If VHT was hit used with a driver not reporting it, e.g. iwlmvm,
> this manifested in hitting the bandwidth warning in
> cfg80211_calculate_bitrate_vht().
>
> Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Johannes, would you like me to merge this in via my tree directly?
Thanks.
^ permalink raw reply
* Re: [net-next] net: remove duplicate add_device_randomness() call
From: David Miller @ 2017-05-04 15:13 UTC (permalink / raw)
To: zhangshengju; +Cc: netdev, edumazet
In-Reply-To: <1493869242-65468-1-git-send-email-zhangshengju@cmss.chinamobile.com>
From: Zhang Shengju <zhangshengju@cmss.chinamobile.com>
Date: Thu, 4 May 2017 11:40:42 +0800
> Since register_netdevice() already call add_device_randomness() and
> dev_set_mac_address() will call it after mac address change.
> It's not necessary to call at device UP.
>
> Signed-off-by: Zhang Shengju <zhangshengju@cmss.chinamobile.com>
The net-next tree is closed, please resubmit this when the net-next
tree opens back up.
^ permalink raw reply
* Re: [PATCH net] netvsc: make sure napi enabled before vmbus_open
From: David Miller @ 2017-05-04 15:08 UTC (permalink / raw)
To: stephen; +Cc: netdev, sthemmin
In-Reply-To: <20170503235921.31407-1-sthemmin@microsoft.com>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Wed, 3 May 2017 16:59:21 -0700
> This fixes a race where vmbus callback for new packet arriving
> could occur before NAPI is initialized.
>
> Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
Applied, thanks Stephen.
^ permalink raw reply
* Re: [PATCH v2] aquantia: Fix driver name reported by ethtool
From: David Miller @ 2017-05-04 15:07 UTC (permalink / raw)
To: Pavel.Belous; +Cc: netdev, darcari
In-Reply-To: <2082aed4d8196250542cf9a73f3d9a49eb96af21.1493835234.git.pavel.belous@aquantia.com>
From: Pavel Belous <Pavel.Belous@aquantia.com>
Date: Wed, 3 May 2017 21:17:44 +0300
> From: Pavel Belous <pavel.belous@aquantia.com>
>
> V2: using "aquantia" subsystem tag.
>
> The command "ethtool -i ethX" should display driver name (driver: atlantic)
> instead vendor name (driver: aquantia).
>
> Signed-off-by: Pavel Belous <pavel.belous@aquantia.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] ipv4, ipv6: ensure raw socket message is big enough to hold an IP header
From: David Miller @ 2017-05-04 15:07 UTC (permalink / raw)
To: glider; +Cc: dvyukov, kcc, edumazet, kuznet, linux-kernel, netdev
In-Reply-To: <20170503150658.44421-1-glider@google.com>
From: Alexander Potapenko <glider@google.com>
Date: Wed, 3 May 2017 17:06:58 +0200
> raw_send_hdrinc() and rawv6_send_hdrinc() expect that the buffer copied
> from the userspace contains the IPv4/IPv6 header, so if too few bytes are
> copied, parts of the header may remain uninitialized.
>
> This bug has been detected with KMSAN.
>
> Signed-off-by: Alexander Potapenko <glider@google.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH] net/sched: remove redundant null check on head
From: David Miller @ 2017-05-04 15:01 UTC (permalink / raw)
To: colin.king
Cc: jhs, xiyou.wangcong, jiri, netdev, kernel-janitors, linux-kernel
In-Reply-To: <20170503135040.32023-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Wed, 3 May 2017 14:50:40 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> head is previously null checked and so the 2nd null check on head
> is redundant and therefore can be removed.
>
> Detected by CoverityScan, CID#1399505 ("Logically dead code")
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2 net] tcp: do not inherit fastopen_req from parent
From: David Miller @ 2017-05-04 15:00 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, weiwan, andreyknvl
In-Reply-To: <1493818771.7796.13.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 03 May 2017 06:39:31 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> Under fuzzer stress, it is possible that a child gets a non NULL
> fastopen_req pointer from its parent at accept() time, when/if parent
> morphs from listener to active session.
>
> We need to make sure this can not happen, by clearing the field after
> socket cloning.
...
> Fixes: e994b2f0fb92 ("tcp: do not lock listener to process SYN packets")
> Fixes: 7db92362d2fe ("tcp: fix potential double free issue for fastopen_req")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: Andrey Konovalov <andreyknvl@google.com>
Applied and queued up for -stable, thanks Eric.
^ permalink raw reply
* Re: [PATCH 1/1] forcedeth: remove unnecessary carrier status check
From: David Miller @ 2017-05-04 14:58 UTC (permalink / raw)
To: yanjun.zhu; +Cc: netdev
In-Reply-To: <1493786622-16654-1-git-send-email-yanjun.zhu@oracle.com>
From: Zhu Yanjun <yanjun.zhu@oracle.com>
Date: Wed, 3 May 2017 00:43:42 -0400
> Since netif_carrier_on() will do nothing if device's
> carrier is already on, so it's unnecessary to do
> carrier status check.
>
> It's the same for netif_carrier_off().
>
> Signed-off-by: Zhu Yanjun <yanjun.zhu@oracle.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] net:ethernet:aquantia:atlantic: Switch to use napi_gro_receive
From: Pavel Belous @ 2017-05-04 14:53 UTC (permalink / raw)
To: David Miller; +Cc: netdev, darcari
In-Reply-To: <20170504.104257.1536182180703411206.davem@davemloft.net>
On 04.05.2017 17:42, David Miller wrote:
> From: Pavel Belous <Pavel.Belous@aquantia.com>
> Date: Wed, 3 May 2017 19:57:10 +0300
>
>> From: Pavel Belous <pavel.belous@aquantia.com>
>>
>> Add support for GRO (generic receive offload) for aQuantia Atlantic driver.
>> This results in a perfomance improvement when GRO is enabled.
>>
>> Signed-off-by: Pavel Belous <pavel.belous@aquantia.com>
>
> Please format your Subject line properly.
>
> You have _way_ too many subsystem prefixes, and when there are more
> than one they should be separated by spaces like "a: b: c:"
>
> In this case an appropriate Subject line would be:
>
> [PATCH net-next] aquantia: Switch to use napi_gro_receive().
>
> But since this is a new feature, and the net-next tree is currently
> closed, you will have to resubmit this when the net-next tree
> opens.
>
> Thank you.
>
Ok. I will re-submit the patch when net-next tree opens.
Thank you,
Pavel
^ permalink raw reply
* [PATCH] x86/asm: Don't use rbp as temp register in csum_partial_copy_generic()
From: Josh Poimboeuf @ 2017-05-04 14:51 UTC (permalink / raw)
To: x86
Cc: Andrey Konovalov, linux-kernel, Vlad Yasevich, Neil Horman,
David S . Miller, linux-sctp, netdev, Marcelo Ricardo Leitner,
Dmitry Vyukov, Kostya Serebryany, syzkaller, Eric Dumazet,
Cong Wang
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.
Replace the usage of rbp with another callee-saved register (r15) so
stack traces are no longer be affected.
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Tested-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
---
arch/x86/lib/csum-copy_64.S | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/x86/lib/csum-copy_64.S b/arch/x86/lib/csum-copy_64.S
index 7e48807..45a53df 100644
--- a/arch/x86/lib/csum-copy_64.S
+++ b/arch/x86/lib/csum-copy_64.S
@@ -55,7 +55,7 @@ ENTRY(csum_partial_copy_generic)
movq %r12, 3*8(%rsp)
movq %r14, 4*8(%rsp)
movq %r13, 5*8(%rsp)
- movq %rbp, 6*8(%rsp)
+ movq %r15, 6*8(%rsp)
movq %r8, (%rsp)
movq %r9, 1*8(%rsp)
@@ -74,7 +74,7 @@ ENTRY(csum_partial_copy_generic)
/* main loop. clear in 64 byte blocks */
/* r9: zero, r8: temp2, rbx: temp1, rax: sum, rcx: saved length */
/* r11: temp3, rdx: temp4, r12 loopcnt */
- /* r10: temp5, rbp: temp6, r14 temp7, r13 temp8 */
+ /* r10: temp5, r15: temp6, r14 temp7, r13 temp8 */
.p2align 4
.Lloop:
source
@@ -89,7 +89,7 @@ ENTRY(csum_partial_copy_generic)
source
movq 32(%rdi), %r10
source
- movq 40(%rdi), %rbp
+ movq 40(%rdi), %r15
source
movq 48(%rdi), %r14
source
@@ -103,7 +103,7 @@ ENTRY(csum_partial_copy_generic)
adcq %r11, %rax
adcq %rdx, %rax
adcq %r10, %rax
- adcq %rbp, %rax
+ adcq %r15, %rax
adcq %r14, %rax
adcq %r13, %rax
@@ -121,7 +121,7 @@ ENTRY(csum_partial_copy_generic)
dest
movq %r10, 32(%rsi)
dest
- movq %rbp, 40(%rsi)
+ movq %r15, 40(%rsi)
dest
movq %r14, 48(%rsi)
dest
@@ -203,7 +203,7 @@ ENTRY(csum_partial_copy_generic)
movq 3*8(%rsp), %r12
movq 4*8(%rsp), %r14
movq 5*8(%rsp), %r13
- movq 6*8(%rsp), %rbp
+ movq 6*8(%rsp), %r15
addq $7*8, %rsp
ret
--
2.7.4
^ permalink raw reply related
* [PATCH net] rtnetlink: NUL-terminate IFLA_PHYS_PORT_NAME string
From: Michal Schmidt @ 2017-05-04 14:48 UTC (permalink / raw)
To: netdev; +Cc: Thomas Haller, David Ahern
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;
--
2.12.2
^ permalink raw reply related
* Re: [PATCH] net:ethernet:aquantia:atlantic: Switch to use napi_gro_receive
From: David Miller @ 2017-05-04 14:42 UTC (permalink / raw)
To: Pavel.Belous; +Cc: netdev, darcari
In-Reply-To: <16bc94e6bb9cc977a9a9e0cac48ae91ff7198f05.1493829200.git.pavel.belous@aquantia.com>
From: Pavel Belous <Pavel.Belous@aquantia.com>
Date: Wed, 3 May 2017 19:57:10 +0300
> From: Pavel Belous <pavel.belous@aquantia.com>
>
> Add support for GRO (generic receive offload) for aQuantia Atlantic driver.
> This results in a perfomance improvement when GRO is enabled.
>
> Signed-off-by: Pavel Belous <pavel.belous@aquantia.com>
Please format your Subject line properly.
You have _way_ too many subsystem prefixes, and when there are more
than one they should be separated by spaces like "a: b: c:"
In this case an appropriate Subject line would be:
[PATCH net-next] aquantia: Switch to use napi_gro_receive().
But since this is a new feature, and the net-next tree is currently
closed, you will have to resubmit this when the net-next tree
opens.
Thank you.
^ permalink raw reply
* Re: [RFC] iproute: Add support for extended ack to rtnl_talk
From: David Miller @ 2017-05-04 14:41 UTC (permalink / raw)
To: dsahern; +Cc: daniel, stephen, netdev
In-Reply-To: <7315b681-9c78-4bc1-ab74-64509ab5887d@gmail.com>
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.
^ permalink raw reply
* Re: [RFC] iproute: Add support for extended ack to rtnl_talk
From: Leon Romanovsky @ 2017-05-04 14:37 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: Stephen Hemminger, netdev
In-Reply-To: <590AF624.6090808@iogearbox.net>
[-- Attachment #1: Type: text/plain, Size: 1988 bytes --]
On Thu, May 04, 2017 at 11:36:36AM +0200, Daniel Borkmann 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?
And I would like to get direction for the RDMA tool [1] which I'm
working on it now.
The overall decision was to use netlink and put it under iproute2
umbrella. Currently, I have working RFC which is based on
legacy sysfs interface to ensure that we are converging on
user-experience even before moving to actual netlink defines.
An I would like to continue to work on netlink interface, but which lib interface
should I need to base rdmatool's netlink code?
[1] https://www.mail-archive.com/netdev@vger.kernel.org/msg148523.html
>
> 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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [RFC] iproute: Add support for extended ack to rtnl_talk
From: David Ahern @ 2017-05-04 14:27 UTC (permalink / raw)
To: Daniel Borkmann, Stephen Hemminger; +Cc: netdev
In-Reply-To: <590AF624.6090808@iogearbox.net>
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
^ permalink raw reply
* Re: net/ipv4: use-after-free in ip_queue_xmit
From: Andrey Konovalov @ 2017-05-04 14:20 UTC (permalink / raw)
To: Cong Wang
Cc: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, LKML, Eric Dumazet,
Dmitry Vyukov, Kostya Serebryany, syzkaller
In-Reply-To: <CAAeHK+xZG+V8W85=bzpj0EgbmZo0c2Sq6e0LxtHMZM8wje-yPA@mail.gmail.com>
On Mon, Apr 10, 2017 at 7:46 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> On Mon, Apr 10, 2017 at 7:42 PM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
>> On Mon, Apr 10, 2017 at 7:40 AM, Andrey Konovalov <andreyknvl@google.com> wrote:
>>> Hi,
>>>
>>> I've got the following error report while fuzzing the kernel with syzkaller.
>>>
>>> On commit 39da7c509acff13fc8cb12ec1bb20337c988ed36 (4.11-rc6).
>>>
>>> Unfortunately it's not reproducible.
>>>
>>> BUG: KASAN: use-after-free in ip_select_ttl include/net/dst.h:176
>>> [inline] at addr ffff88006ab3602c
>>> BUG: KASAN: use-after-free in ip_queue_xmit+0x1817/0x1a30
>>> net/ipv4/ip_output.c:485 at addr ffff88006ab3602c
>>> Read of size 4 by task syz-executor1/12627
>>> CPU: 3 PID: 12627 Comm: syz-executor1 Not tainted 4.11.0-rc6+ #206
>>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>>> Call Trace:
>>> __dump_stack lib/dump_stack.c:16 [inline]
>>> dump_stack+0x292/0x398 lib/dump_stack.c:52
>>> kasan_object_err+0x1c/0x70 mm/kasan/report.c:164
>>> print_address_description mm/kasan/report.c:202 [inline]
>>> kasan_report_error mm/kasan/report.c:291 [inline]
>>> kasan_report+0x252/0x510 mm/kasan/report.c:347
>>> __asan_report_load4_noabort+0x14/0x20 mm/kasan/report.c:367
>>> ip_select_ttl include/net/dst.h:176 [inline]
>>
>> Probably same as the one you reported on ipv4_mtu(), it would
>> be nice if you could test the patch I proposed:
>>
>> https://patchwork.ozlabs.org/patch/747556/
>
> Applied your patch.
>
> The bug gets triggered very rarely (only twice so far), but I'll let
> you know if I see it again.
Hi Cong,
I haven't seen those report any more.
Could you mail the patch?
Thanks!
>
> Thanks!
>
>>
>>
>> Thanks!
>>
>>> ip_queue_xmit+0x1817/0x1a30 net/ipv4/ip_output.c:485
>>> sctp_v4_xmit+0x10d/0x140 net/sctp/protocol.c:994
>>> sctp_packet_transmit+0x215c/0x3560 net/sctp/output.c:637
>>> sctp_outq_flush+0xade/0x3f90 net/sctp/outqueue.c:885
>>> sctp_outq_uncork+0x5a/0x70 net/sctp/outqueue.c:750
>>> sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1773 [inline]
>>> sctp_side_effects net/sctp/sm_sideeffect.c:1175 [inline]
>>> sctp_do_sm+0x5a0/0x6a50 net/sctp/sm_sideeffect.c:1147
>>> sctp_primitive_ASSOCIATE+0x9d/0xd0 net/sctp/primitive.c:88
>>> sctp_sendmsg+0x270d/0x3b50 net/sctp/socket.c:1954
>>> inet_sendmsg+0x164/0x5b0 net/ipv4/af_inet.c:762
>>> sock_sendmsg_nosec net/socket.c:633 [inline]
>>> sock_sendmsg+0xca/0x110 net/socket.c:643
>>> SYSC_sendto+0x660/0x810 net/socket.c:1696
>>> SyS_sendto+0x40/0x50 net/socket.c:1664
>>> entry_SYSCALL_64_fastpath+0x1f/0xc2
>>> RIP: 0033:0x4458d9
>>> RSP: 002b:00007fdceca85b58 EFLAGS: 00000282 ORIG_RAX: 000000000000002c
>>> RAX: ffffffffffffffda RBX: 0000000000000016 RCX: 00000000004458d9
>>> RDX: 0000000000000087 RSI: 0000000020003000 RDI: 0000000000000016
>>> RBP: 00000000006e2fe0 R08: 0000000020003000 R09: 0000000000000010
>>> R10: 0000000000040841 R11: 0000000000000282 R12: 00000000007080a8
>>> R13: 000000000000000a R14: 0000000000000005 R15: 0000000000000084
>>> Object at ffff88006ab36008, in cache kmalloc-64 size: 64
>>> Allocated:
>>> PID = 7243
>>> save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
>>> save_stack+0x43/0xd0 mm/kasan/kasan.c:513
>>> set_track mm/kasan/kasan.c:525 [inline]
>>> kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:616
>>> kmem_cache_alloc_trace+0x82/0x270 mm/slub.c:2745
>>> kmalloc include/linux/slab.h:490 [inline]
>>> kzalloc include/linux/slab.h:663 [inline]
>>> fib_create_info+0x8e0/0x3a30 net/ipv4/fib_semantics.c:1040
>>> fib_table_insert+0x1a5/0x1550 net/ipv4/fib_trie.c:1221
>>> ip_rt_ioctl+0xddc/0x1590 net/ipv4/fib_frontend.c:597
>>> inet_ioctl+0xf2/0x1c0 net/ipv4/af_inet.c:882
>>> sock_do_ioctl+0x65/0xb0 net/socket.c:906
>>> sock_ioctl+0x28f/0x440 net/socket.c:1004
>>> vfs_ioctl fs/ioctl.c:45 [inline]
>>> do_vfs_ioctl+0x1bf/0x1780 fs/ioctl.c:685
>>> SYSC_ioctl fs/ioctl.c:700 [inline]
>>> SyS_ioctl+0x8f/0xc0 fs/ioctl.c:691
>>> entry_SYSCALL_64_fastpath+0x1f/0xc2
>>> Freed:
>>> PID = 12622
>>> save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
>>> save_stack+0x43/0xd0 mm/kasan/kasan.c:513
>>> set_track mm/kasan/kasan.c:525 [inline]
>>> kasan_slab_free+0x73/0xc0 mm/kasan/kasan.c:589
>>> slab_free_hook mm/slub.c:1357 [inline]
>>> slab_free_freelist_hook mm/slub.c:1379 [inline]
>>> slab_free mm/slub.c:2961 [inline]
>>> kfree+0xe8/0x2b0 mm/slub.c:3882
>>> free_fib_info_rcu+0x4ba/0x5e0 net/ipv4/fib_semantics.c:218
>>> __rcu_reclaim kernel/rcu/rcu.h:118 [inline]
>>> rcu_do_batch.isra.64+0x947/0xcc0 kernel/rcu/tree.c:2879
>>> invoke_rcu_callbacks kernel/rcu/tree.c:3142 [inline]
>>> __rcu_process_callbacks kernel/rcu/tree.c:3109 [inline]
>>> rcu_process_callbacks+0x2cc/0xb90 kernel/rcu/tree.c:3126
>>> __do_softirq+0x2fb/0xb7d kernel/softirq.c:284
>>> Memory state around the buggy address:
>>> ffff88006ab35f00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>> ffff88006ab35f80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>>>ffff88006ab36000: fc fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc
>>> ^
>>> ffff88006ab36080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>>> ffff88006ab36100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>>> ==================================================================
>>
>> --
>> You received this message because you are subscribed to the Google Groups "syzkaller" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller+unsubscribe@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: net: possible deadlock in skb_queue_tail
From: Paolo Abeni @ 2017-05-04 14:05 UTC (permalink / raw)
To: Andrey Konovalov, Florian Westphal
Cc: Pablo Neira Ayuso, Jozsef Kadlecsik, David S. Miller,
netfilter-devel, netdev, LKML, Dmitry Vyukov, Kostya Serebryany,
Eric Dumazet, syzkaller
In-Reply-To: <CAAeHK+wNPLWKy7q-mpPFrgK6pvnGYA9aPc_rs5d4sSvpvtoxDA@mail.gmail.com>
On Thu, 2017-05-04 at 15:49 +0200, Andrey Konovalov wrote:
> On Fri, Feb 24, 2017 at 3:56 AM, Florian Westphal <fw@strlen.de> wrote:
> > Andrey Konovalov <andreyknvl@google.com> wrote:
> >
> > [ CC Paolo ]
> >
> > > I've got the following error report while fuzzing the kernel with syzkaller.
> > >
> > > On commit c470abd4fde40ea6a0846a2beab642a578c0b8cd (4.10).
> > >
> > > Unfortunately I can't reproduce it.
> >
> > This needs NETLINK_BROADCAST_ERROR enabled on a netlink socket
> > that then subscribes to netfilter conntrack (ctnetlink) events.
> > probably syzkaller did this by accident -- impressive.
> >
> > (one task is the ctnetlink event redelivery worker
> > which won't be scheduled otherwise).
> >
> > > ======================================================
> > > [ INFO: possible circular locking dependency detected ]
> > > 4.10.0-rc8+ #201 Not tainted
> > > -------------------------------------------------------
> > > kworker/0:2/1404 is trying to acquire lock:
> > > (&(&list->lock)->rlock#3){+.-...}, at: [<ffffffff8335b23f>]
> > > skb_queue_tail+0xcf/0x2f0 net/core/skbuff.c:2478
> > >
> > > but task is already holding lock:
> > > (&(&pcpu->lock)->rlock){+.-...}, at: [<ffffffff8366b55f>] spin_lock
> > > include/linux/spinlock.h:302 [inline]
> > > (&(&pcpu->lock)->rlock){+.-...}, at: [<ffffffff8366b55f>]
> > > ecache_work_evict_list+0xaf/0x590
> > > net/netfilter/nf_conntrack_ecache.c:48
> > >
> > > which lock already depends on the new lock.
> >
> > Cong is correct, this is a false positive.
> >
> > However we should fix this splat.
> >
> > Paolo, this happens since 7c13f97ffde63cc792c49ec1513f3974f2f05229
> > ('udp: do fwd memory scheduling on dequeue'), before this
> > commit kfree_skb() was invoked outside of the locked section in
> > first_packet_length().
> >
> > cpu 0 call chain:
> > - first_packet_length (hold udp sk_receive_queue lock)
> > - kfree_skb
> > - nf_conntrack_destroy
> > - spin_lock(net->ct.pcpu->lock)
> >
> > cpu 1 call chain:
> > - ecache_work_evict_list
> > - spin_lock( net->ct.pcpu->lock)
> > - nf_conntrack_event
> > - aquire netlink socket sk_receive_queue
> >
> > So this could only ever deadlock if a netlink socket
> > calls kfree_skb while holding its sk_receive_queue lock, but afaics
> > this is never the case.
> >
> > There are two ways to avoid this splat (other than lockdep annotation):
> >
> > 1. re-add the list to first_packet_length() and free the
> > skbs outside of locked section.
> >
> > 2. change ecache_work_evict_list to not call nf_conntrack_event()
> > while holding the pcpu lock.
> >
> > doing #2 might be a good idea anyway to avoid potential deadlock
> > when kfree_skb gets invoked while other cpu holds its sk_receive_queue
> > lock, I'll have a look if this is feasible.
>
> Hi!
>
> Any updates on this?
>
> I might have missed the patch if there was one.
>
> Thanks!
That has should be fixed via lockdep annotation with
581319c58600b54612c417aff32ae9bbd79f4cdb
Paolo
^ permalink raw reply
* Re: [Patch net] ipv6: reorder ip6_route_dev_notifier after ipv6_dev_notf
From: David Ahern @ 2017-05-04 14:04 UTC (permalink / raw)
To: Cong Wang, netdev; +Cc: andreyknvl
In-Reply-To: <1493874452-3050-2-git-send-email-xiyou.wangcong@gmail.com>
On 5/3/17 11:07 PM, Cong Wang wrote:
> For each netns (except init_net), we initialize its null entry
> in 3 places:
>
> 1) The template itself, as we use kmemdup()
> 2) Code around dst_init_metrics() in ip6_route_net_init()
> 3) ip6_route_dev_notify(), which is supposed to initialize it after
> loopback registers
>
> Unfortunately the last one still happens in a wrong order because
> we expect to initialize net->ipv6.ip6_null_entry->rt6i_idev to
> net->loopback_dev's idev, so we have to do that after we add
> idev to it. However, this notifier has priority == 0 same as
> ipv6_dev_notf, and ipv6_dev_notf is registered after
> ip6_route_dev_notifier so it is called actually after
> ip6_route_dev_notifier.
>
> Fix it by specifying a smaller priority for ip6_route_dev_notifier.
>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
> ---
> net/ipv6/route.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> index 2f11366..4dbf7e2 100644
> --- a/net/ipv6/route.c
> +++ b/net/ipv6/route.c
> @@ -4024,7 +4024,7 @@ static struct pernet_operations ip6_route_net_late_ops = {
>
> static struct notifier_block ip6_route_dev_notifier = {
> .notifier_call = ip6_route_dev_notify,
> - .priority = 0,
> + .priority = -10, /* Must be called after addrconf_notify!! */
> };
>
> void __init ip6_route_init_special_entries(void)
>
And I see a refcnt problem with this change:
root@kenny-jessie2:~# unshare -n
root@kenny-jessie2:~# logout
root@kenny-jessie2:~# unshare -n
Message from syslogd@kenny-jessie2 at May 4 07:04:38 ...
kernel:[ 62.581552] unregister_netdevice: waiting for lo to become
free. Usage count = 1
^ permalink raw reply
* Re: [Patch net] ipv6: reorder ip6_route_dev_notifier after ipv6_dev_notf
From: David Ahern @ 2017-05-04 14:00 UTC (permalink / raw)
To: Cong Wang, netdev; +Cc: andreyknvl
In-Reply-To: <1493874452-3050-2-git-send-email-xiyou.wangcong@gmail.com>
On 5/3/17 11:07 PM, Cong Wang wrote:
> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> index 2f11366..4dbf7e2 100644
> --- a/net/ipv6/route.c
> +++ b/net/ipv6/route.c
> @@ -4024,7 +4024,7 @@ static struct pernet_operations ip6_route_net_late_ops = {
>
> static struct notifier_block ip6_route_dev_notifier = {
> .notifier_call = ip6_route_dev_notify,
> - .priority = 0,
> + .priority = -10, /* Must be called after addrconf_notify!! */
> };
>
> void __init ip6_route_init_special_entries(void)
>
That should be codified such that if someone changes the priority of the
addrconf notifier, it fixes up the route notifier as well. e.g.,
diff --git a/include/net/addrconf.h b/include/net/addrconf.h
index 1aeb25dd42a7..6c0ee3ccbe0f 100644
--- a/include/net/addrconf.h
+++ b/include/net/addrconf.h
@@ -20,6 +20,8 @@
#define ADDRCONF_TIMER_FUZZ (HZ / 4)
#define ADDRCONF_TIMER_FUZZ_MAX (HZ)
+#define ADDRCONF_NOTIFY_PRIORITY 0
+
#include <linux/in.h>
#include <linux/in6.h>
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index a2a370b71249..7a4e6b2996a1 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -3548,6 +3548,7 @@ static int addrconf_notify(struct notifier_block
*this, unsigned long event,
*/
static struct notifier_block ipv6_dev_notf = {
.notifier_call = addrconf_notify,
+ .priority = ADDRCONF_NOTIFY_PRIORITY,
};
static void addrconf_type_change(struct net_device *dev, unsigned long
event)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index a1bf426c959b..e0d83f8bc01a 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -4024,7 +4024,7 @@ static struct pernet_operations
ip6_route_net_late_ops = {
static struct notifier_block ip6_route_dev_notifier = {
.notifier_call = ip6_route_dev_notify,
- .priority = 0,
+ .priority = ADDRCONF_NOTIFY_PRIORITY - 10,
};
And you marked this as a patch for net; I think this should go into
net-next.
^ permalink raw reply related
* Re: net/dccp: dccp_create_openreq_child freed held lock
From: Andrey Konovalov @ 2017-05-04 13:54 UTC (permalink / raw)
To: David Miller
Cc: Arnaldo Carvalho de Melo, Arnaldo Carvalho de Melo, Dmitry Vyukov,
Gerrit Renker, dccp, netdev, LKML, Eric Dumazet, Cong Wang,
syzkaller
In-Reply-To: <20170504.095319.42169195176229264.davem@davemloft.net>
On Thu, May 4, 2017 at 3:53 PM, David Miller <davem@davemloft.net> wrote:
> From: Andrey Konovalov <andreyknvl@google.com>
> Date: Thu, 4 May 2017 15:36:37 +0200
>
>> On Wed, Mar 1, 2017 at 4:40 PM, Arnaldo Carvalho de Melo
>> <acme@kernel.org> wrote:
>>> Em Wed, Mar 01, 2017 at 12:35:10PM -0300, Arnaldo Carvalho de Melo escreveu:
>>>> Em Wed, Mar 01, 2017 at 10:38:54AM +0100, Dmitry Vyukov escreveu:
>>>> > Hello,
>>>> >
>>>> > I've got the following report while running syzkaller fuzzer on
>>>> > 86292b33d4b79ee03e2f43ea0381ef85f077c760:
>>>> >
>>>> >
>>>> > It seems that dccp_create_openreq_child needs to unlock the sock if
>>>> > dccp_feat_activate_values fails.
>>>>
>>>> Yeah, can you please use the patch below, that mimics the error paths in
>>>> sk_clone_new(), from where I think even the comment about it being a raw
>>>
>>> Argh, s/sk_clone_new()/sk_clone_lock()/g
>>
>> Hi Arnaldo,
>>
>> Could you send the patch?
>>
>> We haven't seen these reports since we applied it.
>
> It isn't necessary in the current tree.
>
> Arnaldo created a helper sk_free_unlock_clone() which handles this situation
> properly, and calls it from dccp_create_openreq_child().
OK, great, thanks!
^ permalink raw reply
* Re: net/dccp: dccp_create_openreq_child freed held lock
From: David Miller @ 2017-05-04 13:53 UTC (permalink / raw)
To: andreyknvl
Cc: acme, arnaldo.melo, dvyukov, gerrit, dccp, netdev, linux-kernel,
edumazet, xiyou.wangcong, syzkaller
In-Reply-To: <CAAeHK+wSrkrooaK=d6Od85hNNQbTSuPxe55DFFYWEuE5zSqmSw@mail.gmail.com>
From: Andrey Konovalov <andreyknvl@google.com>
Date: Thu, 4 May 2017 15:36:37 +0200
> On Wed, Mar 1, 2017 at 4:40 PM, Arnaldo Carvalho de Melo
> <acme@kernel.org> wrote:
>> Em Wed, Mar 01, 2017 at 12:35:10PM -0300, Arnaldo Carvalho de Melo escreveu:
>>> Em Wed, Mar 01, 2017 at 10:38:54AM +0100, Dmitry Vyukov escreveu:
>>> > Hello,
>>> >
>>> > I've got the following report while running syzkaller fuzzer on
>>> > 86292b33d4b79ee03e2f43ea0381ef85f077c760:
>>> >
>>> >
>>> > It seems that dccp_create_openreq_child needs to unlock the sock if
>>> > dccp_feat_activate_values fails.
>>>
>>> Yeah, can you please use the patch below, that mimics the error paths in
>>> sk_clone_new(), from where I think even the comment about it being a raw
>>
>> Argh, s/sk_clone_new()/sk_clone_lock()/g
>
> Hi Arnaldo,
>
> Could you send the patch?
>
> We haven't seen these reports since we applied it.
It isn't necessary in the current tree.
Arnaldo created a helper sk_free_unlock_clone() which handles this situation
properly, and calls it from dccp_create_openreq_child().
^ 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