linux-kernel - RE: [PATCH 1/3] PCI: hv: use the correct buffer size in new_pcichild

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: <MWHPR03MB26690DD8D1756E3202D27820BFB80@MWHPR03MB2669.namprd03.prod.outlook.com>
Date:   Thu, 10 Nov 2016 16:52:31 +0000
From:   Dexuan Cui <decui@...rosoft.com>
To:     Jake Oshins <jakeo@...rosoft.com>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        "linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
        "devel@...uxdriverproject.org" <devel@...uxdriverproject.org>
CC:     "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        KY Srinivasan <kys@...rosoft.com>,
        Haiyang Zhang <haiyangz@...rosoft.com>,
        "Stephen Hemminger" <sthemmin@...rosoft.com>,
        Hadden Hoppert <haddenh@...rosoft.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        "jasowang@...hat.com" <jasowang@...hat.com>,
        "apw@...onical.com" <apw@...onical.com>,
        "olaf@...fle.de" <olaf@...fle.de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 1/3] PCI: hv: use the correct buffer size in
 new_pcichild_device()

> 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