afterwards.
If init failure ought to free then it probably should unset drvdata
first like remove, and remove (and possibly many other dev_get_drvdata
calls) should check for null; otherwise it's probably best to leave it
to remove to call free exactly once...
--
Dominique Martinet | Asmadeus
priv->rings[i].evtchn = priv->rings[i].irq = 0;
Please run checkpatch on the patches you send (b4 can do it for you if
you want to start using it)
code-wise,
I also don't see where unbinf_from_irqhandler would free the evtchn, so
is it leaking here, or is it implicit from something else?
We only free it explicitly on error binding the irq.
Thanks,
--
Dominique Martinet | Asmadeus
Alexander Merritt wrote on Tue, Nov 19, 2024 at 09:16:33PM +:
> From: Alex Zenla
>
> Large amount of mount hangs observed during hotplugging of 9pfs devices. The
> 9pfs Xen driver attempts to initialize itself more than once, causing the
> frontend and backend to disagree: the backend listens
Stefano Stabellini wrote on Mon, Jun 01, 2020:
> > LGTM, I'll try to find some time to test this by the end of next week or
> > will trust you if I can't make it -- ping me around June 1st if I don't
> > reply again until then...
>
> Ping :-)
I actually did think about this patch this weekend! .
Stefano Stabellini wrote on Thu, May 21, 2020:
> From: Stefano Stabellini
>
> Increase XEN_9PFS_RING_ORDER to 9 for performance reason. Order 9 is the
> max allowed by the protocol.
>
> We can't assume that all backends will support order 9. The xenstore
> property max-ring-page-order specifies
Stefano Stabellini wrote on Wed, May 20, 2020:
> From: Stefano Stabellini
>
> Increase XEN_9PFS_RING_ORDER to 9 for performance reason. Order 9 is the
> max allowed by the protocol.
>
> We can't assume that all backends will support order 9. The xenstore
> property max-ring-page-order specifies
