| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <MW2PR07MB41397040310C7DF8275B2B3F8A4A0@MW2PR07MB4139.namprd07.prod.outlook.com>
Date: Mon, 25 Jun 2018 09:20:35 +0000
From: "Kalluru, Sudarsana" <Sudarsana.Kalluru@...ium.com>
To: Vishwanath Pai <vpai@...mai.com>,
"Elior, Ariel" <Ariel.Elior@...ium.com>,
Dept-Eng Everest Linux L2 <Dept-EngEverestLinuxL2@...ium.com>
CC: "davem@...emloft.net" <davem@...emloft.net>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"dbanerje@...mai.com" <dbanerje@...mai.com>,
"pai.vishwain@...il.com" <pai.vishwain@...il.com>
Subject: RE: bnx2x: kernel panic in the bnx2x driver
Hi Vishwanath,
Thanks for your help. Will plan to post the patch to net branch.
Thanks,
Sudarsana
-----Original Message-----
From: Vishwanath Pai [mailto:vpai@...mai.com]
Sent: 22 June 2018 23:58
To: Kalluru, Sudarsana <Sudarsana.Kalluru@...ium.com>; Elior, Ariel <Ariel.Elior@...ium.com>; Dept-Eng Everest Linux L2 <Dept-EngEverestLinuxL2@...ium.com>
Cc: davem@...emloft.net; netdev@...r.kernel.org; dbanerje@...mai.com; pai.vishwain@...il.com
Subject: Re: bnx2x: kernel panic in the bnx2x driver
The patch below worked for me (on 4.14.51 LTS kernel):
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c
index 1e33abd..2b3863a 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c
@@ -3387,14 +3387,20 @@ static int bnx2x_set_rss_flags(struct bnx2x *bp, struct ethtool_rxnfc *info)
DP(BNX2X_MSG_ETHTOOL,
"rss re-configured, UDP 4-tupple %s\n",
udp_rss_requested ? "enabled" : "disabled");
- return bnx2x_rss(bp, &bp->rss_conf_obj, false, true);
+ if (bp->state == BNX2X_STATE_OPEN)
+ return bnx2x_rss(bp, &bp->rss_conf_obj, false, true);
+ else
+ return 0;
} else if ((info->flow_type == UDP_V6_FLOW) &&
(bp->rss_conf_obj.udp_rss_v6 != udp_rss_requested)) {
bp->rss_conf_obj.udp_rss_v6 = udp_rss_requested;
DP(BNX2X_MSG_ETHTOOL,
"rss re-configured, UDP 4-tupple %s\n",
udp_rss_requested ? "enabled" : "disabled");
- return bnx2x_rss(bp, &bp->rss_conf_obj, false, true);
+ if (bp->state == BNX2X_STATE_OPEN)
+ return bnx2x_rss(bp, &bp->rss_conf_obj, false, true);
+ else
+ return 0;
}
return 0;
Although I think there might be another place where we may need to fix this as well:
bnx2x_config_rss_eth()
Thanks,
Vishwanath
On 06/22/2018 10:57 AM, Vishwanath Pai wrote:
> Ah, that is great! I will test it out on my machine and let you know.
>
> Thanks,
> Vishwanath
>
> On 06/22/2018 10:21 AM, Kalluru, Sudarsana wrote:
>> Hi Vishwanath,
>> The config will be cached in the device structure (bp->rss_conf_obj.udp_rss_v4) in this scenario, and will be applied in the load path (bnx2x_nic_load() --> bnx2x_init_rss()). Have unit tested the change on my setup.
>>
>> Thanks,
>> Sudarsana
>>
>> -----Original Message-----
>> From: Vishwanath Pai [mailto:vpai@...mai.com]
>> Sent: 22 June 2018 18:52
>> To: Kalluru, Sudarsana <Sudarsana.Kalluru@...ium.com>; Elior, Ariel
>> <Ariel.Elior@...ium.com>; Dept-Eng Everest Linux L2
>> <Dept-EngEverestLinuxL2@...ium.com>
>> Cc: davem@...emloft.net; netdev@...r.kernel.org; dbanerje@...mai.com;
>> pai.vishwain@...il.com
>> Subject: Re: bnx2x: kernel panic in the bnx2x driver
>>
>> Hi Sudarsana,
>>
>> Thanks for taking a look at my email. The fix you suggested would definitely fix the kernel panic, but at the same time wouldn't it also silently ignore the request by ethtool to set rx-flow-hash?
>>
>> Thanks,
>> Vishwanath
>>
>> On 06/22/2018 06:20 AM, Kalluru, Sudarsana wrote:
>>> Hi Vishwanath,
>>> Thanks for your mail, and the analysis.
>>> The fix would be to invoke bnx2x_rss() only when the device is opened,
>>> if (bp->state == BNX2X_STATE_OPEN)
>>> return bnx2x_rss(bp, &bp->rss_conf_obj, false, true);
>>> else
>>> return 0;
>>> Ariel,
>>> Could you please review the path (bnx2x_set_rss_flags()--> bnx2x_rss()) and confirm/correct on the above.
>>>
>>> Thanks,
>>> Sudarsana
>>>
>>> -----Original Message-----
>>> From: Vishwanath Pai [mailto:vpai@...mai.com]
>>> Sent: 22 June 2018 10:37
>>> To: Elior, Ariel <Ariel.Elior@...ium.com>; Dept-Eng Everest Linux L2
>>> <Dept-EngEverestLinuxL2@...ium.com>
>>> Cc: davem@...emloft.net; netdev@...r.kernel.org;
>>> dbanerje@...mai.com; pai.vishwain@...il.com
>>> Subject: bnx2x: kernel panic in the bnx2x driver
>>>
>>> External Email
>>>
>>> Hi,
>>>
>>> We recently noticed a kernel panic in the bnx2x driver when trying
>>> to set rx-flow-hash parameters via ethtool during if-pre-up.d. I am
>>> running kernel
>>> v4.17.2 from ubuntu-mainline-ppa. I have added the stack trace below:
>>>
>>> [ 18.280209] BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
>>> [ 18.280212] PGD 8000000407a79067 P4D 8000000407a79067 PUD 40ce8a067 PMD 0
>>> [ 18.280214] Oops: 0010 [#1] SMP PTI
>>> [ 18.280215] Modules linked in: intel_rapl x86_pkg_temp_thermal intel_powerclamp kvm_intel joydev input_led kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc hid_eneric aesni_intel gpio_ich aes_x86_64 usbhid lpc_ich crpto_simd ie31200_edac cryptd glue_helper intel_cstate mac_hid intel_rapl_perf bnx2x mdio tcp_bbr netconsole ipmi_devintf ipmi_msghandler i2c_i801 coretemp autofs4 raid10 raid456 libcrc32c async_raid6_recov async_memcpy async_pq async_xor xor async_tx raid6_pq raid1 raid0 multipath linear sha26_mb mcryptd sha256_ssse3 hid ast i2c_algo_bit ttm drm_kms_helper syscopyarea sysfillrect sysimgblt mpt3sas fb_sys_fops drm raid_class scsi_transport_sas ahci libahci shpchp video
>>> [ 18.280241] CPU: 6 PID: 1081 Comm: ethtool Not tainted 4.17.2-041702-generic #201806160433
>>> [ 18.280242] Hardware name: Foxconn CangJie/CangJie, BIOS CC1F108D 02/26/2014
>>> [ 18.280243] RIP: 0010: (null)
>>> [ 18.280243] RSP: 0018:ffffb84bc260b9c0 EFLAGS: 00010246
>>> [ 18.280244] RAX: 0000000000000000 RBX: ffff92f987f020f0 RCX: 0000000000000000
>>> [ 18.280245] RDX: 0000000000000000 RSI: ffffb84bc260b9f8 RDI: ffff92f987f020f0
>>> [ 18.280245] RBP: ffffb8bc260b9e8 R08: 0000000000000001 R09: 0000000000000000
>>> [ 18.280246] R10: ffffb84bc260bd20 R11: 0000000000000000 R12: ffffb84bc260b9f8
>>> [ 18.280246] R13: ffff92f987f008c0 R14: 00007ffdb75bec40 R15: 0000000000000000
>>> [ 18.280247] FS: 00007fc0e8798700(0000) GS:ffff92f99fd80000(0000) knlGS:0000000000000000
>>> [ 18.280248] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>> [ 18.280249] CR2: 0000000000000000 CR3: 0000000409b4c003 CR4: 00000000001606e0
>>> [ 18.280249] Call Trace:
>>> [ 18.280263] ? bnx2x_config_rss+0x2f/0xd0 [bnx2x]
>>> [ 18.280270] bnx2x_rss+0x1d9/0x210 [bnx2x]
>>> [ 18.280276] bnx2x_set_rxnfc+0x17d/0x380 [bnx2x]
>>> [ 18.280279] ethtool_set_rxnfc+0x9b/0x110
>>> [ 18.280281] ? __do_page_cache_readahead+0x1da/0x2c0
>>> [ 18.280283] ? security_capable+0x3c/0x60
>>> [ 18.280284] dev_ethtool+0350/0x2610
>>> [ 18.280286] ? page_cache_async_readahead+0x71/0x80
>>> [ 18.280288] ? page_add_file_rmap+0x5d/0x220
>>> [ 18.280290] ? inet_ioctl+0x182/0x1a0
>>> [ 18.280291] dev_ioctl+0x203/0x3f0
>>> [ 18.280293] ? dev_ioctl+0x203/0x3f0
>>> [ 18.280294] sock_do_ioctl+0xae/0x150
>>> [ 18.280296] sock_ioctl+0x1e2/0x330
>>> [ 18.280296] ? sock_ioctl+0x1e2/0x330
>>> [ 18.280299] do_vfs_ioctl+0xa8/0x620
>>> [ 18.280300] ? dlci_ioctl_set+0x30/0x30
>>> [ 18.280301] ? do_vfs_ioctl+0xa8/0x620
>>> [ 18.280302] ? handle_mm_fault+0xe3/0x220
>>> [ 18.280304] ksys_ioctl+0x75/0x80
>>> [ 18.280305] __x64_sys_ioctl+0x1a/0x20
>>> [ 18.280307] do_syscall_64+0x5a/0x120
>>> [ 18.280309] entry_SYSCALL_64_aftr_hwframe+0x44/0xa9
>>> [ 18.280310] RIP: 0033:0x7fc0e7fba107
>>> [ 18.280311] RSP: 002b:00007ffdb75beb78 EFLAGS: 00000206 ORIG_RAX: 0000000000000010
>>> [ 18.280312] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fc0e7fba107
>>> [ 18.280312] RDX: 00007ffdb75bed60 RSI: 0000000000008946 RDI: 0000000000000003
>>> [ 18.280313] RBP: 00007ffdb75bed50 R08: 00007ffdb75bed60 R09: 0000000000000001
>>> [ 18.280313] R10: 0000000000000541 R11: 0000000000000206 R12: 00007ffdb75beed0
>>> [ 18.280314] R13: 0000000000421020 R14: 000000000041fe28 R15: 0000000000000003
>>> [ 18.280315] Code: Bad RIP value.
>>> [ 18.280317] RIP: (null) RSP: ffffb84bc260b9c0
>>> [ 18.280318] CR2: 0000000000000000
>>> [ 18.280319] ---[ end trace 5f361db3fb9059f1 ]---
>>>
>>> To reproduce this I created a bash script in "/etc/network/if-pre-up.d/" with these two lines:
>>> ethtool -N $IFACE rx-flow-hash udp4 "sdfn"
>>> ethtool -N $IFACE rx-flow-hash udp6 "sdfn"
>>>
>>> The problem here is that rss_obj in bnx2x struct for the device
>>> hasn't been initialized yet, which causes an exception in
>>> bnx2x_config_rss() when calling "r->set_pending(r)" because
>>> r->set_pending is NULL. It looks like a lot many things haven't been
>>> initialized at this point, most of that happens in this
>>> function: "bnx2x_init_bp_objs()" which isn't called until ifup. Any thoughts on how this can be fixed? Would it be possible to safely move bnx2x_init_bp_objs() to maybe bnx2x_init_one() which runs much before ifup?
>>>
>>> Thanks,
>>> Vishwanath
>>>
>
Powered by blists - more mailing lists