On Wed, Jan 20, 2016 at 11:53:54AM -0800, Darrick J. Wong wrote: > On Wed, Jan 20, 2016 at 11:59:09AM -0600, Eric Sandeen wrote: > > I had a request for the kmem_alloc deadlock warning to print the > > filesystem involved. > > > > Any objections to passing mp into kmem_alloc() and friends whenever > > it's reasonably available from the caller? > > > > It'd be a big mechanical change, don't want to embark on that unless > > it seems acceptable & useful. > > > > I think we generally know the root causes of the most common deadlock > > warnings, but it's a warm fuzzy to give as much info as possible. > > > > Heck, I almost wonder if passing a descriptive string in, for at > > least the problematic cases we know about, i.e. "extent map realloc" > > so we'd get something like: > > > > XFS (sdb1): myprocess(123) possible memory allocation deadlock size 12345 during extent map realloc in kmem_alloc (mode:0x250) > > > > I dunno ... too much? :) > > Not enough? What about putting in just enough macro madness to report > the name & line number of the calling function in the message? > > XFS (sdb1): myprocess(123) possible kmem_alloc deadlock in > xfs_eat_my_data.c:5135 (size:12345 mode:0x250) Problem with that is the the return address will often just point to a higher level wrapper function, and we are still without any caller context. e.g. if we find the caller is xfs_buf_alloc_maps(), what operation was being performed that needed a new buffer allocated? IMO, the only thing that will actually be useful for debugging at this point is a full stack dump.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
