On Thu, May 5, 2022 at 6:28 AM guowei du <duguoweisz@xxxxxxxxx> wrote: > > thanks very much for your replay. > > I am a starter for kernel filesystem study, i see the newest plan with the 'pre modify events', > I think the plan is great and meaningful,I am looking forward to it. Welcome. Since you are new let me start with some basics. I don't know what generated the long list of CC that you used, I suppose it was get_maintainer.pl - this list is way too long and irrelevant I cut it down to the list and maintainers listed in the MAINTAINERS file. > > for the legacy modify events, i mean to implement most blocking events which are not yet > done for now, maybe the permission model is old or legacy, and,sure ,expending the > blocking events such as unlink/rmdir/rename will do pollute EVENTS namespace in part. > but, it is only a little ,maybe all usual blocking events are open/access/rmdir/unlink/rename, > they cover some usecases,and other modify events can be only audited or notified. Sorry, I don't understand what you mean. > > With the fanotify, open/access/rmdir/unlink/rename need to occupy a fsnotify bit to explicitly > separate from others.if Blocking event is denied,then there will be no normal events to notify. > Sorry, I don't understand what you mean. What I meant is that adding different bits for FAN_OPEN and FAN_OPEN_PERM was a mistake that was done a long time ago and we need to live with it. We do NOT need to repeat the same mistake again. We need to initialize fanotify with class FAN_CLASS_PERM and then when setting events FAN_UNLINK|FAN_RMDIR in mask they will be blocking events which reader will need to allow/deny. Here is my old example implementation of dir modify permission events that use just one more bit in mask: https://github.com/amir73il/linux/commits/fsnotify_dirent_perm This was never designed to be exported to users via fanotify, but it could be extended. I also did not think yet how this could be combined with pre-modify events that have different implementations. I am just giving that as an example of how only a single new bit can be used to describe blocking events for all the legacy notification events. > By now ,fanotify is a way that userspace could make choice to allow or deny some events,so > I expand fsnotify and use fanotify to do some work. > > so,that is why I expand the fsnotify blocking events. Since you are new, I will try to be very clear about expectations. In order to get the requested changes into the kernel you will have to address the comments that we gave you. If you do not understand the comments, please ask for clarifications. These will not be the last comments that you will get. Other people may also have more comments on your patches. You will be asked to write tests. Thanks, Amir.
