Re: [PATCH v2 02/16] iommu: Implement IOMMU Live update FLB callbacks

[Pranjal Shrivastava]

On Mon, May 18, 2026 at 05:20:40PM +0000, Samiullah Khawaja wrote:
> On Mon, May 18, 2026 at 12:33:25PM +0000, Pranjal Shrivastava wrote:
> > On Fri, May 01, 2026 at 09:45:19PM +0000, David Matlack wrote:
> > > On 2026-04-27 05:56 PM, Samiullah Khawaja wrote:
[snip]
> > > 
> > > > +static int iommu_liveupdate_flb_retrieve(struct liveupdate_flb_op_args *argp)
> > > > +{
> > > > +	struct iommu_flb_obj *obj;
> > > > +	struct iommu_flb_ser *ser;
> > > > +
> > > > +	obj = kzalloc_obj(*obj, GFP_KERNEL);
> > > > +	if (!obj)
> > > > +		return -ENOMEM;
> > > 
> > > Should this be considered fatal for the same reason
> > > iommu_liveupdate_restore_array() is considered fatal? If anything in
> > > iommu_liveupdate_flb_retrieve() fails then the risk of corruption as
> > > described in iommu_liveupdate_restore_array() is possible.
> > > 
> > 
> > Righ... Nice catch. I suppose we should BUG_ON() this because
> > luo_flb_file_finish_one [1] returns void. Thus, if we return -ENOMEM
> > here all we get is a WARN_ON without panic.
> 
> The error is propagated by get_flb_incoming(). The finish path has a
> WARN. But that is fine because finish won't be called as can_finish()
> will fail if FLB retrieve fails and restore cannot be done.
> 
> I will add a comment about this here.

Ack. I was looking at the finish path as it doesn't propagate the error.
but it won't be called ig. I assumed that there should be no good 
situation at boot that would cause -ENOMEM. 

In case we're not panicking for an -ENOMEM and letting the user decide,
adding a comment would be great.

Thanks,
Praan