 Hi everyone, I'm Hotao and I worked for Huawei in Hangzhou, China. Today I want to share and discuss a simple idea about DPR for FS iterative. And the following is the agenda for the presentation. First, I will give a short introduction about what is BPR for iterative, because maybe some FS export is not a formula with the BPR iterative. I will show some possible use cases and demos for the BPR for FAIR system and some demos. And last, I will present some problems for the BPR for FAIR system iterative, which I didn't resolve the law. Okay, let's go to the first introduction part. So what is a BPR iterative? The following text is what I copy from the color documentation. A BPR iterative is a type of BPR program that allows us to iterate over a specific type of color object. So, as we can see from the below finger, it works. First, a BPR iterative consists of one BPR program and another BPR iterative FD. First, the user space where I set up two things. First, it will load a BPR program and then it will pass something about the color object. Third, it may be a FD, it may be the FAIR script of the color object to the BPR iterative. And then when the user space application reads the BPR iterative FD, the BPR program will be invoked and it will write something into the BPR iterative FD. And then the user space application can read the content from the sixth FAIR. That is how the BPR iterative FD works. So, as we can see from the finger, unlike a normal... I forgot to mention that BPR iterative is a tracing program, unlike a tracing program. The BPR program is triggered when a specific color function or event is called, but the BPR program for BPR iterative is different. The BPR program is invoked when the user space application is trying to read the BPR iterative FD. In the next slide, I will show some examples. The following is an example of the task of FAIR iterative. And as we can see from the code on the left is the code of the BPR program. As we can see, firstly, it extracts the task and the FAIR under the FD from the past context. And then it will use some BPR papers. For example, here is a BPR synchronous printer. It will print something to the... It will write this textual content to the BPR iterative FD. And the code on the right is a schedule of the user space application. First, it will use the schedule framework to open and load the BPR program. And then it passes the PID of the task to the BPR iterative. And then it uses this level BPR API to create a BPR link. And then last, it creates a BPR iterative Shura link. So when the application is trying to read the FD, the BPR program, here is a sample task FAIR will be invoked in the corner. And the task structure and the FAIR structure and the FD will be passed to the BPR program. And the BPR program will output the interest of the task or the FAIR into the BPR synchronous FAIR. Here it's the PID, TGID, PID, and the F operation of the task. So the finger and the wrapped-up corner of the slide is an example. As we can see here, the task FAIR iterative is where we are trying to iterate or open the FAIR of one task. So as we can see, this is the FD, and then this is the FAIR operation of the FAIR related with the FAIR script. So from above two slides, we can know how BPR iterative works. And in this slide, I will show some simple demos about the BPR FAIR system iterative. And I think the main motivation for the FAIR system iterative is to provide more observability for the FAIR system object. So maybe we could iterate over all FAIR system objects. For example, or I load in one super block, or dentrace, or mount, or even the patch catch of the I load. The following is the possible use case for each. For example, we can use the FAIR system iterative to damper the folio orders of the patch catch. Whether it can be, whether the folio orders can be dumped by using PROC FAIR. And then we can use a page map and came up with a page, but I think if we can use the BPR in iterative, it will be more efficient. It will be more efficient than read and open the PROC FAIRs. And another use case is the catch status. I think some developers in the matter has proposed to add a new state score to do that. It's proposed a new state score in catch status to try to return the catch and the dirt and the write back pages of the one node. But I think with the BPR FAIR system iterative, there is a low leader to add a new state score. We can just implement it through the BPR iterative. And another possible use case is, for example, to damper mounting for a specific mount. Yeah, but it also can be used to damper or mount info. But I think it may be a little flexible than adding a new state score in FSE info. But I'm trying to say FSE info, the proposal FSE info, it also could damper mount info for specific. And it's more powerful, but I think FAIR system iterative, it will be more flexible. And another use case for us is to find these unlinked but pinned up. Can I interject for one second? So the iterator is not going to replace mount info system call in any way. That's just not going to happen. We need this for user space for separate reasons. People don't want to use this with BPF. And we have other plans with this, so this cannot be a replacement. And I have some reservations about exposing especially mount info into BPF, because then you get into really intricate locking scenarios. Namespace lock, sequence locking, lock, mount hash, mount propagation. That's all terrible machinery. That is isolated explicitly into fs-namespace.c. But I think they can provide some BPF helper for the FAIR system iterator. So this interlock can be hydro in the BPF helper. Then we continue. And another possible use case is to try to find some iLoad which is unlinked but pinned iLoad. FAIR pinned is mainly is specially pinned by the colon. The FAIR is opened by the colon. So we can use it to find out why there is a difference between the output of the DU and the DF. This is one possible use case for us. Okay, in the next slide I will show some example about the FAIR mount. It's just a simple idea. The left is the BPF program and the right is the user-based code. As we can see, how to damper the mount info and in the demo they just provide BPF helper to do that. They didn't try to do the namespace lock and other locks in the BPF. They just use a helper from the FAIR system. It just calls the mount info. And the following two lines, it's where I'm trying to type a cast as a verve as a mountain to the shocker mount. And trying to damper something about the multi-id, the mount flex of the mount. They can use it to damper or use it to damper a mount info for a specific mount FD. They pass it to the BPF program. These are intended for like, I am a kernel dev and I want to figure out why something is broken. This is not like we're expecting user space to be like, oh, I am now going to start inspecting very deep bits of how the VFS works and so on. This is all for debugging, is my understanding. Oh, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, you are right. I think it's, yeah, I think it will be mainly used for debugging to check the internals of the FAIR system object. Here is just a demo example, yeah, to show what does BPF FAIR system it really can do. This slide, it just showed what can be done for the I load in the FAIR system. In this example, I provide two things. First, I, here it uses the three BPF, BPF HEPL. First, it uses the BPF FAIR map of catch status to get the catch under the dirty pages of the specific I load. And here it is XFS FAIR system and it decides it and it's catch the page. It's trying to, it's trying to damper the folder orders of the, of the patriotic and because as we know, XF has a multi-order has, has the multi-order folder support. How, how just a time track here you, you have about one or two more minutes. Do you have something that you want to quickly web up or something that you want to discuss with the folks here. Yeah. And the next two slide. Yeah, sorry. That's okay. I think I in the, in the previous three slides I just show what can we do for the FAIR system. So I want, so but there is some problems I want to start. The first is, do they need the unprivileged BPF iterator. In my, in my perspective, yeah, you could open the FAIR doesn't mean you can retrieve all the implementation details of the FAIR. So maybe the background is now created BPF iterator means the privilege. Yeah, this is a capital BPF. So, so it will be not available for the, for the normal, for the normal use. And so I want, I wanted to, so I want, I wanted to discuss, should we, should we add a supporter for the, for the unprivileged BPF iterator. Andrew has suggested one idea to, to how to make it usable for the normal use. Yeah, it is just a vacant, vacant pin, vacant pin the BPF iterate pin the BPF link in the BPF FS and the changed and model of the FAIR. So it can be read for the normal use, but I'm not sure because as this kind, as this, as discussed just now, it's a many use, it's a many use for the, for the debugging purpose. So maybe that, that is, that is making it available only for the use is maybe it's okay. I mean, so my impression would be that I mean you would. Okay, so like user space could decide that they're going to that are going to give this information to everyone. And they can decide to go into that ship into the abyss like that they can do that if they like but it seems to me that it is very very bad idea to be like oh like oh you have an open file. I will now tell you about the kernel memory layout and like I will now let you access all these things. I understand you're saying this is like saying which like you would need to an admin would need to allow. My opinion is that an admin should not allow that even if they could because like I mean like oh I have a file I can like just to me it seems like a like a very scary proposition. Right, I mean obviously like you definitely don't allow this by default if even if an admin decides to enable this they can deal with when someone exploits it that's that's their problem. Right, like it seems like a bad idea to me. Plus it plus it's mainly for debugging and debug like if you want to debug anything you need to be a root anyway so whatever like that's that's my opinion. Yeah, I think we have to cut off here. I think we can continue how we can continue the discussion on on the maligness. I saw you have patches up there so we can I think we can continue up there. So we have to go to the next talk which will be fields. Okay. Okay. Thank you. Thank you. Thanks.