lkml.org 
[lkml]   [2016]   [Nov]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [PATCH 1/3] PCI: hv: use the correct buffer size in new_pcichild_device()
Date
> 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

\
 
 \ /
  Last update: 2016-11-10 17:53    [W:1.278 / U:0.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site