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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <MW2PR07MB4139CC84215EDFEDC980CF098A750@MW2PR07MB4139.namprd07.prod.outlook.com>
Date:   Fri, 22 Jun 2018 14:21:04 +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,
    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

Powered by Openwall GNU/*/Linux Powered by OpenVZ