From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935622AbcKJRTg (ORCPT ); Thu, 10 Nov 2016 12:19:36 -0500 Received: from mail-bl2nam02on0105.outbound.protection.outlook.com ([104.47.38.105]:62867 "EHLO NAM02-BL2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S934541AbcKJRTe (ORCPT ); Thu, 10 Nov 2016 12:19:34 -0500 X-Greylist: delayed 2204 seconds by postgrey-1.27 at vger.kernel.org; Thu, 10 Nov 2016 12:19:34 EST From: Jake Oshins To: Dexuan Cui , Bjorn Helgaas , "linux-pci@vger.kernel.org" , "devel@linuxdriverproject.org" CC: "gregkh@linuxfoundation.org" , KY Srinivasan , Haiyang Zhang , "Stephen Hemminger" , Hadden Hoppert , Vitaly Kuznetsov , "jasowang@redhat.com" , "apw@canonical.com" , "olaf@aepfle.de" , "linux-kernel@vger.kernel.org" Subject: RE: [PATCH 1/3] PCI: hv: use the correct buffer size in new_pcichild_device() Thread-Topic: [PATCH 1/3] PCI: hv: use the correct buffer size in new_pcichild_device() Thread-Index: AdI7IoRA7oW02ygCRFeoAZworZG8EQATEeQwAAC8AvAAALEsQA== Date: Thu, 10 Nov 2016 17:05:08 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jakeo@microsoft.com; x-originating-ip: [2001:4898:80e8:d::602] x-microsoft-exchange-diagnostics: 1;BLUPR0301MB2098;7:F08Gowf0KbHpMxWhQs+L4GfHiuWNXjq7OwkRSCQacohT2XfbOtOVOa62IS6ZuulrkUofjcR5HOVlK8It0lInEpVbfwOxnXkrv9JJjLAn/Mh/iiJ1nFbQj/d9WZhmYDU3HjXNYoynvomKmMd0mALodYpy5j9fSxad9Gm9e76SNqAJnUO0f2SIxU2PUUbEatZHBEcU0Z2k8ZBtKmWEsOCJrfesEoKLJhiXRAXGFU3xh8mL2wm/qPzQfi2EFq8BCwkGCV/HD0+RQUAs7HOwdVLkwyjVF6Kf/apjDTraFKowwSjnE4wduwPBWy5YgTo4hjSyunPX6mz5Zhq9xfoklKLCPkmWKtBRyOw5hWPElI4JGkV5GlIr5yuJdH8RQzaG+uDL x-ms-office365-filtering-correlation-id: bf7864ab-e0f1-44ba-5dd0-08d4098bb995 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BLUPR0301MB2098; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(61425038)(6040176)(6045074)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6046074)(6072074);SRVR:BLUPR0301MB2098;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0301MB2098; x-forefront-prvs: 01221E3973 x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(7916002)(199003)(377454003)(13464003)(189002)(106356001)(105586002)(99286002)(2900100001)(7696004)(87936001)(76576001)(189998001)(5660300001)(102836003)(10290500002)(586003)(229853002)(6116002)(92566002)(86362001)(2421001)(2201001)(86612001)(5005710100001)(77096005)(54356999)(50986999)(76176999)(2906002)(101416001)(8990500004)(122556002)(68736007)(10090500001)(2950100002)(4326007)(33656002)(81156014)(2501003)(8676002)(9686002)(81166006)(1511001)(74316002)(305945005)(7736002)(7846002)(3660700001)(3280700002)(97736004)(5001770100001)(8936002)(2561002);DIR:OUT;SFP:1102;SCL:1;SRVR:BLUPR0301MB2098;H:BLUPR0301MB1587.namprd03.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Nov 2016 17:05:08.2628 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0301MB2098 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id uAAHJfDE024969 > -----Original Message----- > > > From: Jake Oshins > > > From: Dexuan Cui > > > Sent: Wednesday, November 9, 2016 11:18 PM > > > We don't really need such a big on-stack buffer. > > > vmbus_sendpacket() here only uses sizeof(struct pci_child_message). > > > > > > @@ -1271,9 +1271,9 @@ static struct hv_pci_dev > > > *new_pcichild_device(struct hv_pcibus_device *hbus, > > > struct hv_pci_dev *hpdev; > > > struct pci_child_message *res_req; > > > struct q_res_req_compl comp_pkt; > > > - union { > > > - struct pci_packet init_packet; > > > - u8 buffer[0x100]; > > > + struct { > > > + struct pci_packet init_packet; > > > + u8 buffer[sizeof(struct pci_child_message)]; > > > } pkt; > > > unsigned long flags; > > > int ret; > > > > This change seems good to me, in that it's always a bad idea to use too > much > > stack. But this won't fix the problem with VMAP_STACK. The buffer could > still > > end up spanning two pages and the physical addresses of those pages > would > > possibly be discontiguous. Do you want to just refactor this so that it uses > a > > fixed buffer, one that will work with VMAP_STACK? Or is that coming in a > future > > patch? > > Hi Jake, I think the VMAP_STACK issue you mentioned should be another > different > issue fixed by Long Li: https://patchwork.ozlabs.org/patch/692447/. > > The VMAP_STACK issue is only an issue when we pass the buffer's physical > address > to the hypercall. > > Here the buffer is not passed to any hypercall. We just use > vmbus_sendpacket() > to memcpy the buffer into the per-channel ringbuffer. > > Thanks, > -- Dexuan Yes, you're right. This patch looks fine to me. Sorry for confusing the two issues. -- Jake