From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932436AbcFALKn (ORCPT ); Wed, 1 Jun 2016 07:10:43 -0400 Received: from mail-by2on0119.outbound.protection.outlook.com ([207.46.100.119]:49189 "EHLO na01-by2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1757331AbcFALKl convert rfc822-to-8bit (ORCPT ); Wed, 1 Jun 2016 07:10:41 -0400 From: Yuval Mintz To: Arnd Bergmann CC: David Miller , Manish Chopra , Sudarsana Kalluru , netdev , linux-kernel , Ariel Elior Subject: RE: [PATCH] qed: fix qed_fill_link() error handling Thread-Topic: [PATCH] qed: fix qed_fill_link() error handling Thread-Index: AQHRuopr8dM2Bm5F7kKDXFvV0ks9JJ/RqZeQgAHl6wCAABSOAIAAzT7wgAAEFoCAAAAm8A== Date: Wed, 1 Jun 2016 11:10:30 +0000 Message-ID: References: <1464623197-2084229-1-git-send-email-arnd@arndb.de> <5288285.fZuaAytaxX@wuerfel> <8209894.K472MDjuEr@wuerfel> In-Reply-To: <8209894.K472MDjuEr@wuerfel> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: arndb.de; dkim=none (message not signed) header.d=none;arndb.de; dmarc=none action=none header.from=qlogic.com; x-originating-ip: [31.168.140.228] x-ld-processed: 0d68a1f9-1490-4d0e-8767-a87dab3ef2ba,ExtAddr,ExtAddr x-ms-office365-filtering-correlation-id: c274810e-b90a-457c-e6a4-08d38a0d57f8 x-microsoft-exchange-diagnostics: 1;CO2PR11MB0085;5:CLoZKrsFF7ePwJwO7ve+Loel6o6Qj9lifmCcq/Xt9N03szX5pPoZM7O6tUyFV2QYmKdyvKXHQTlqfpeV6CY1MWZr6Za59tFcGDBYMvaXRz+zt2pumDIlPzYfIDGTbEeqdy1KxW+7+xfXhSqEjdEX6g==;24:ubjYoB+NpcVBSolacwjChXB57f5kOsoFi2A1zWNqESjblMuiShXEw8Q27yL/tQ6HtNrnvhmr5yq6uVkiQJVKEyf35oF3i2iy5UsX3yJM8pY=;7:B8wcHpJsN8hvG5KT4Y28W49n0Q6pHKcgtVbizsrPU9GSh3oIE945ZwYSi69u9OkInwj4z72zH1kbEKMAxpjK1l3Vi+Hkd6LG92zeIIAkmQpfn77BUsgT3ttW9JRVBqu2a++mx+kPd1R/wHMUUpPI8C0lm56/Q4fEzw9pk4TFzOZYtxmlMK61GXB2VIrK9wiY;20:MiYmFZzdvE3kjXZgGM8YSn0+Zi8Q48dENtW0MeyVihEE0hln36Agu3hs5cXzvsrbklrzrSkPLPLRgOjB2cx/55bIiBTE4AEmC5ZXtsaOYghxBJCUGHROrlxYub9aSqy2AwHX7gLjgJwoFz3cB/jTz/uE1/g6tsPOr5jdGAPwvOs= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR11MB0085; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046);SRVR:CO2PR11MB0085;BCL:0;PCL:0;RULEID:;SRVR:CO2PR11MB0085; x-forefront-prvs: 096029FF66 x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(51444003)(106116001)(86362001)(4001430100002)(4326007)(122556002)(77096005)(2906002)(5008740100001)(50986999)(5002640100001)(87936001)(76176999)(54356999)(5003600100002)(2950100001)(2900100001)(586003)(9686002)(81166006)(74316001)(8936002)(5004730100002)(110136002)(6116002)(66066001)(3846002)(102836003)(99286002)(93886004)(8676002)(107886002)(92566002)(33656002)(10400500002)(76576001)(3280700002)(189998001)(3660700001);DIR:OUT;SFP:1102;SCL:1;SRVR:CO2PR11MB0085;H:CO2PR11MB0088.namprd11.prod.outlook.com;FPR:;SPF:None;MLV:sfv;LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-OriginatorOrg: qlogic.com X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jun 2016 11:10:30.1697 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0d68a1f9-1490-4d0e-8767-a87dab3ef2ba X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR11MB0085 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > > > I think we can just remove the IS_ENABLED() check there and define > > > the > > > IS_PF() macro conditionally to become 'true' if CONFIG_QED_SRIOV is > > > not set, like some other drivers do > > > > I think that would be unsafe with current qede - qede currently > > publishes its VFs' PCI device-id as part its MODULE_DEVICE_TABLE, even > > if CONFIG_QED_SRIOV isn't enabled [might be the wrong thing to do, but > > that how it goes]. > > Without changing this, if for some reason we'd have an assigned VF to > > a VM whose kernel isn't compiled with CONFIG_QED_SRIOV [which is an > > odd config], that VM is likely to miserably crash. > > Wouldn't it crash anyway if the code to handle VF devices is not present? > E.g. the warning we got here tells us that qed_get_link_data() operates on > uninitialized data when called on a VF device and SRIOV support is not built into > the driver. I haven't looked if all the other functions handle that right, but my > guess is that there are other functions with similar problems. > > Maybe it's best to remove the PCI IDs fort the virtual devices from the table if > they are not supported by the configuration. Actually, I think VF probe should gracefully fail in that case, as qed_vf_hw_prepare() would simply return -EINVAL. But I can honestly say I've never tested this flow, and I agree there's no reason to allow VF probe in case we're not supporting SRIOV. So I guess removing the PCI ID and defining IS_PF to be true in case CONFIG_QED_SRIOV isn't set is the right way to go. Do you want to revise your patch, or do you want me to do it? Thanks, Yuval