linux-kernel - Re: [PATCH 4/7] xen/9pfs: connect to the backend

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: <alpine.DEB.2.10.1703081110270.8160@sstabellini-ThinkPad-X260>
Date:   Wed, 8 Mar 2017 11:22:55 -0800 (PST)
From:   Stefano Stabellini <sstabellini@...nel.org>
To:     Boris Ostrovsky <boris.ostrovsky@...cle.com>
cc:     Stefano Stabellini <sstabellini@...nel.org>,
        xen-devel@...ts.xenproject.org, linux-kernel@...r.kernel.org,
        Stefano Stabellini <stefano@...reto.com>, jgross@...e.com,
        Eric Van Hensbergen <ericvh@...il.com>,
        Ron Minnich <rminnich@...dia.gov>,
        Latchesar Ionkov <lucho@...kov.net>,
        v9fs-developer@...ts.sourceforge.net
Subject: Re: [PATCH 4/7] xen/9pfs: connect to the backend

On Wed, 8 Mar 2017, Boris Ostrovsky wrote:
> >>> +	ring->bytes = (void*)__get_free_pages(GFP_KERNEL | __GFP_ZERO, XEN_9PFS_RING_ORDER);
> >>> +	if (ring->bytes == NULL)
> >>> +		goto error;
> >>> +	for (i = 0; i < (1 << XEN_9PFS_RING_ORDER); i++)
> >>> +		ring->intf->ref[i] = gnttab_grant_foreign_access(dev->otherend_id, pfn_to_gfn(virt_to_pfn((void*)ring->bytes) + i), 0);
> >>> +	ring->ref = gnttab_grant_foreign_access(dev->otherend_id, pfn_to_gfn(virt_to_pfn((void*)ring->intf)), 0);
> >>> +	ring->ring.in = ring->bytes;
> >>> +	ring->ring.out = ring->bytes + XEN_9PFS_RING_SIZE;
> >>> +
> >>> +	ret = xenbus_alloc_evtchn(dev, &ring->evtchn);
> >>> +	if (ret)
> >>> +		goto error;
> >>> +	ring->irq = bind_evtchn_to_irqhandler(ring->evtchn, xen_9pfs_front_event_handler,
> >>> +					0, "xen_9pfs-frontend", ring);
> >>> +	if (ring->irq < 0) {
> >>> +		xenbus_free_evtchn(dev, ring->evtchn);
> >>> +		ret = ring->irq;
> >>> +		goto error;
> >>> +	}
> >>>  	return 0;
> >>> +
> >>> +error:
> >> You may need to gnttab_end_foreign_access().
> > Actually this error path is unnecessary because it will be handled by
> > xen_9pfs_front_probe, that calls xen_9pfs_front_free on errors. I'll
> > remove it.
> 
> 
> (It's a matter of personal preference but I think a routine should clean
> up its own mess whenever it can.)
>
> >
> >
> > +
> > + again:
> > +	ret = xenbus_transaction_start(&xbt);
> > +	if (ret) {
> > +		xenbus_dev_fatal(dev, ret, "starting transaction");
> > +		goto error;
> > +	}
> > +	ret = xenbus_printf(xbt, dev->nodename, "version", "%u", 1);
> > +	if (ret)
> > +		goto error_xenbus;
> > +	ret = xenbus_printf(xbt, dev->nodename, "num-rings", "%u", priv->num_rings);
> > +	if (ret)
> > +		goto error_xenbus;
> > +	for (i = 0; i < priv->num_rings; i++) {
> > +		char str[16];
> > +
> > +		priv->rings[i].priv = priv;
> > +		ret = xen_9pfs_front_alloc_dataring(dev, &priv->rings[i]);
> >> Not for -EAGAIN, I think.
> > I don't think xen_9pfs_front_alloc_dataring can return EAGAIN. EAGAIN
> > can only come from xenbus_transaction_end, the case we handle below.
> 
> I didn't mean that xen_9pfs_front_alloc_dataring() can return -EAGAIN. I
> was referring to...
> 
> >
> >
> >>> +		if (ret < 0)
> >>> +			goto error_xenbus;
> >>> +
> >>> +		sprintf(str, "ring-ref%u", i);
> >>> +		ret = xenbus_printf(xbt, dev->nodename, str, "%d", priv->rings[i].ref);
> >>> +		if (ret)
> >>> +			goto error_xenbus;
> >>> +
> >>> +		sprintf(str, "event-channel-%u", i);
> >>> +		ret = xenbus_printf(xbt, dev->nodename, str, "%u", priv->rings[i].evtchn);
> >>> +		if (ret)
> >>> +			goto error_xenbus;
> >>> +	}
> >>> +	priv->tag = xenbus_read(xbt, dev->nodename, "tag", NULL);
> >>> +	if (ret)
> >>> +		goto error_xenbus;
> >>> +	ret = xenbus_transaction_end(xbt, 0);
> >>> +	if (ret) {
> >>> +		if (ret == -EAGAIN)
> >>> +			goto again;
> 
> ... this.
> 
> Sorry for not being clear.
 
You are right! I'll move the call to xen_9pfs_front_alloc_dataring out
of the xenbus loop.