On 4/25/21 9:33 AM, Mike Rapoport wrote: > On Thu, Apr 22, 2021 at 02:08:51PM +0000, Peter.Enderborg@xxxxxxxx wrote: >> On 4/22/21 10:06 AM, Mike Rapoport wrote: >>> So the flow is like this: >>> >>> * a user has a problem and reports it to an application developer; at best >>> the user runs simple and limited app to collect some data >>> * if the application developer considers this issue as a system related >>> they can open adb and collect some more information about the system >>> using non-root shell with selinux policy restrictions and send this >>> information to the device manufacturer. >>> * the manufacturer continues to debug the issue and at this point as much >>> information is possible would have been useful. >>> >>> In this flow I still fail to understand why the manufacturer cannot provide >>> userspace tools that will be able to collect the required information. >>> These tools not necessarily need to target the end user, they may be only >>> intended for the application developers, e.g. policy could allow such tool >>> to access some of the system data only when the system is in developer >>> mode. >>> >> The manufacture is trying to get the tool to work. This is what the >> patch is about. Even for a application developer a commercial >> phone is locked down. > Right, but it's still in full control of the manufacturer what's flashed > there, isn't it? No. There is a lot of restrictions, and Google will provide a binary kernel that is used on android devices that is the one hat MUST be used on commercial models. It is called GKI. > So there could be some tools that are only available in the developer mode? > These tools could have different permissions etc. > >> Many vendors allow that you flash some other software like a AOSP. But >> that can be very different. Like installing a ubuntu on a PC to debug a >> Fedora issue. >> >> And sure we can pickup parts of what using the dma-buf. But >> we can not get the total and be sure that is the total without a >> proper counter. > If I understand you correctly, a user space tool that scans fdinfo and > accumulates dma-buf size from there is not accurate enough, that's why an > atomic counter exposed by kernel is a must. And it is lightweight. > But if the changes in consumption of dma-bufs are that frequent, I cannot > see how a global counter will help to identify an issue. Same goes for all memory counters. You can sample the counters and build statistics when you have many devices. Statistics change you usually see leaks. > And if this counter is needed to see if there is a memory leak, summing > sizes of dma-bufs from fdinfo will identify a leak. > > What am I missing? > I think you can only see dma-buf that is mapped to a process with that method, we have buffers that goes to other subsystems like audiodsp. And processing all fd's on a system frequently and sort out all duplicates is not light, and it sill will not be a total. Nor is it a snapshot. When it is about to find the leaks, kmemleak works fine with kernel leaks, and page_owner (also only in debugfs) is a good tool.
