Re: [PATCH v6 05/37] fs: Convert alloc_inode_sb() to a macro

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Mar 21, 2024 at 03:09:08PM -0700, Andrew Morton wrote:
> On Thu, 21 Mar 2024 17:15:39 -0400 Kent Overstreet <kent.overstreet@xxxxxxxxx> wrote:
> 
> > On Thu, Mar 21, 2024 at 01:31:47PM -0700, Andrew Morton wrote:
> > > On Thu, 21 Mar 2024 09:36:27 -0700 Suren Baghdasaryan <surenb@xxxxxxxxxx> wrote:
> > > 
> > > > From: Kent Overstreet <kent.overstreet@xxxxxxxxx>
> > > > 
> > > > We're introducing alloc tagging, which tracks memory allocations by
> > > > callsite. Converting alloc_inode_sb() to a macro means allocations will
> > > > be tracked by its caller, which is a bit more useful.
> > > 
> > > I'd have thought that there would be many similar
> > > inlines-which-allocate-memory.  Such as, I dunno, jbd2_alloc_inode(). 
> > > Do we have to go converting things to macros as people report
> > > misleading or less useful results, or is there some more general
> > > solution to this?
> > 
> > No, this is just what we have to do.
> 
> Well, this is something we strike in other contexts - kallsyms gives us
> an inlined function and it's rarely what we wanted.
> 
> I think kallsyms has all the data which is needed to fix this - how
> hard can it be to figure out that a particular function address lies
> within an outer function?  I haven't looked...

This is different, though - even if a function is inlined in multiple
places there's only going to be one instance of a static var defined
within that function.




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux