From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964850AbcKJQwh (ORCPT ); Thu, 10 Nov 2016 11:52:37 -0500 Received: from mail-by2nam01on0093.outbound.protection.outlook.com ([104.47.34.93]:61216 "EHLO NAM01-BY2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S935238AbcKJQwf (ORCPT ); Thu, 10 Nov 2016 11:52:35 -0500 X-Greylist: delayed 21549 seconds by postgrey-1.27 at vger.kernel.org; Thu, 10 Nov 2016 11:52:35 EST From: Dexuan Cui To: Jake Oshins , 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: AdI7IoRA7oW02ygCRFeoAZworZG8EQATEeQwAAC8AvA= Date: Thu, 10 Nov 2016 16:52:31 +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=decui@microsoft.com; x-originating-ip: [112.65.1.154] x-microsoft-exchange-diagnostics: 1;MWHPR03MB2493;7:w8ps8NUuN0+oU+0yAOdJ3Ctd49xsHeWzJkx8ma4GaheGWtJwFOvmmAoeoq50ink79u/UENPMkmXdpjwwgeCvBIe4hzvRfOzTsfJuNxvkkbQooELBU9nbLez8LCFt+bibGbV5od62O2JpVTAAug+7xbN6vHkHO/76S5dIZlbedlR17f1T5kDIwgvfLyYlAtuNsLV6P7JyOAuc6w1gub+AXaNi002Uf6Ns9DMnH0HAtTaFfGIIzuWJ9fWyQHBEZi6Qq4YMo2uerEO185c5qUYwt2cM6qJHIRXdtqxG7EpbdhlPVTHsy+GXEKdKg8KruHQRYAB/mYw3/vRU7GSpNUJnWIkHuLxZy4f16T9gu4G6pCBmEbirvn++gvAAodUV1FPq x-ms-office365-filtering-correlation-id: 077ded21-7ce7-47fa-7782-08d40989f67c x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:MWHPR03MB2493; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(61425038)(6045074)(6060229)(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038)(6061226)(6046074);SRVR:MWHPR03MB2493;BCL:0;PCL:0;RULEID:;SRVR:MWHPR03MB2493; x-forefront-prvs: 01221E3973 x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(979002)(6009001)(7916002)(377454003)(189002)(199003)(2201001)(5005710100001)(99286002)(76576001)(86362001)(10290500002)(8990500004)(189998001)(3280700002)(3660700001)(105586002)(76176999)(50986999)(54356999)(229853002)(106356001)(5001770100001)(101416001)(33656002)(97736004)(586003)(102836003)(3846002)(6116002)(9686002)(122556002)(1511001)(86612001)(66066001)(2421001)(2501003)(2900100001)(7696004)(8936002)(2950100002)(4326007)(5660300001)(2906002)(87936001)(68736007)(81156014)(8676002)(2561002)(81166006)(77096005)(7846002)(305945005)(10090500001)(92566002)(74316002)(7736002)(969003)(989001)(999001)(1009001)(1019001);DIR:OUT;SFP:1102;SCL:1;SRVR:MWHPR03MB2493;H:MWHPR03MB2669.namprd03.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A: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 16:52:31.5263 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR03MB2493 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 uAAGqfcA024835 > 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