On Mon, Feb 11, 2019 at 12:08:31AM -0800, Christoph Hellwig wrote: > On Fri, Feb 08, 2019 at 07:06:24AM -0500, Brian Foster wrote: > > It's not clear to me whether you're suggesting we return 0, error or > > nothing at all here. The assert otherwise seems fine to me as I don't > > think we'd ever expect anything outside of success or -ENOMEM. > > I'm arguing that we should return nothing. > > > That said, I don't see any reason to ever leak an iu if we know it > > didn't make it into the table. I could probably go either way on whether > > we wanted to allow the filesystem to continue or not on unexpected > > insert errors. The original comment was just that we probably shouldn't > > explode on "expected" errors like -ENOSPC. > > Well, IFF the only error case that should happen is either ENOMEM or > E2BIG we don't have an allocation in that case. Everything else is > a programming bug where we should assert / shut the file system down, > in which case the tiny leak is the least of our problems. The caller allocated the object we're trying to insert. From the earlier patch in this thread: + iu = kmem_zalloc(sizeof(*iu), KM_SLEEP | KM_NOFS); + iu->iu_agino = prev_agino; + iu->iu_next_unlinked = this_agino; + + error = rhashtable_insert_fast(&pag->pagi_unlinked_hash, + &iu->iu_rhash_head, xfs_iunlink_hash_params); Brian
