From: Amir Goldstein <amir73il@gmail.com> Date: 2020-02-17 13:15:35
Jan,
This is v2 of the fanotify name info series.
The user requirement for the name info feature, as well as early UAPI
discussions can be found in this [1] lore thread.
The "prep" part of v1 was posted to the list [2] and includes two
minor bug fixes, but I decided not to split the submission into
two series this posting.
The patches are also available on my github branch fanotify_name [3]
along with LTP tests [4], man page draft [5] and a demo [6].
Patches 1-7 are cleanup and minor re-factoring in prep for the name
info patches.
Patches 8-9 are fixes for minor bug that I found during the work.
The referred LTP branch [4] includes improvements to ltp tests fanotify09
and fanotify15 to cover these bugs. I did not mark those patches for
stable, because backporting is not trivial and the bugs are really minor.
For the same reason, I did not bother to provide bug fix patches that are
not dependent on the cleanup patches.
Patches 10-13 implement the new event type FAN_DIR_MODIFY per your
suggestion, which includes the directory fid and entry name info.
Patches 14-15 implement the FAN_REPORT_NAME init flag for reporting
name info on path type events.
Patch 16 is a "bonus" patch that implements an unprivileged fanotify
watch. It is not proposed for merging at this time, but is provided
in order to demonstrate how name info reporting is applicable for an
unprivileged watcher, should we decide to implement the feature.
LTP tests, man page draft for unprivileged fanotify written by Matthew
Bobrowski are available on fanotify_unpriv branches in respective trees.
The inotify demo branch [6] includes a script test_demo.sh whose
output [7] can be seen here below. The demo generates filesystem
events including file and directory renames, sleeps 2 seconds and
then reads the events from the queue and generates a report on
changes in the filesystem.
At event report time, the watcher uses open_by_handle_at(2) to report
up-to-date paths for parent dirs. The last name element in the path
is reported as it was recorded at event time, but the watcher uses
fstatat(2) to check whether the reported entry is negative or positive.
Negative entry paths are annotated with "(deleted)" postfix.
The idea is that file change monitors will use this information to
query the content of modified directories and file and update a
secondary data structure or take other actions.
The demo scripts can run as root and non-root user. When run as
non-root user, if the bonus FAN_UNPRIVILEGED patch is applied, it
demonstrates the unprivileged fanotify recursive watcher and produces
the exact same report information as the privileged filesystem watcher.
Thanks,
Amir.
Changes since v1:
- A few more cleanup patches
- Drop the abstract take_name_snapshot() vfs interface change
- Do not obfuscate event type for path type events
- Deal with the corner cases of event on root and disconnected dentry
- Bonus FAN_UNPRIVILEGED patch
[1] https://lore.kernel.org/linux-fsdevel/CADKPpc2RuncyN+ZONkwBqtW7iBb5ep_3yQN7PKe7ASn8DpNvBw@mail.gmail.com/
[2] https://lore.kernel.org/linux-fsdevel/20200114151655.29473-1-amir73il@gmail.com/
[3] https://github.com/amir73il/linux/commits/fanotify_name
[4] https://github.com/amir73il/ltp/commits/fanotify_name
[5] https://github.com/amir73il/man-pages/commits/fanotify_name
[6] https://github.com/amir73il/inotify-tools/commits/fanotify_name
[7] Demo run of inotifywatch race free monitor
==============================================
~# ./test_demo.sh /vdf
+ WD=/vdf
+ cd /vdf
+ rm -rf a
+ mkdir -p a/b/c/d/e/f/g/
+ touch a/b/c/0 a/b/c/1 a/b/c/d/e/f/g/0
+ id -u
+ [ 0 = 0 ]
+ MODE=--global
+ EVENTS=-e dir_modify -e modify -e attrib -e close_write
+ sleep 1
+ inotifywatch --global -e dir_modify -e modify -e attrib -e
close_write --timeout -2 /vdf
Establishing filesystem global watch...
Finished establishing watches, now collecting statistics.
Sleeping for 2 seconds...
+
+ t=Create files and dirs...
+ touch a/0 a/1 a/2 a/3
+ mkdir a/dir0 a/dir1 a/dir2
+
+ t=Rename files and dirs...
+ mv a/0 a/3
+ mv a/dir0 a/dir3
+
+ t=Delete files and dirs...
+ rm a/1
+ rmdir a/dir1
+
+ t=Modify files and dirs...
+ chmod +x a/b/c/d
+ echo
+
+ t=Move files and dirs...
+ mv a/b/c/1 a/b/c/d/e/f/g/1
+ mv a/b/c/d/e/f/g a/b/c/d/e/G
+
[fid=fd50.0.2007403;name='0'] /vdf/a/0 (deleted)
[fid=fd50.0.2007403;name='1'] /vdf/a/1 (deleted)
[fid=fd50.0.2007403;name='2'] /vdf/a/2
[fid=fd50.0.2007403;name='3'] /vdf/a/3
[fid=fd50.0.2007403;name='dir0'] /vdf/a/dir0 (deleted)
[fid=fd50.0.2007403;name='dir1'] /vdf/a/dir1 (deleted)
[fid=fd50.0.2007403;name='dir2'] /vdf/a/dir2
[fid=fd50.0.2007403;name='dir3'] /vdf/a/dir3
[fid=fd50.0.86;name='d'] /vdf/a/b/c/d
[fid=fd50.0.86;name='0'] /vdf/a/b/c/0
[fid=fd50.0.86;name='1'] /vdf/a/b/c/1 (deleted)
[fid=fd50.0.87;name='1'] /vdf/a/b/c/d/e/G/1
[fid=fd50.0.3000083;name='g'] /vdf/a/b/c/d/e/f/g (deleted)
[fid=fd50.0.2007404;name='G'] /vdf/a/b/c/d/e/G
total modify attrib close_write dir_modify filename
3 0 1 1 2 /vdf/a/0 (deleted)
3 0 1 1 2 /vdf/a/1 (deleted)
3 0 1 1 2 /vdf/a/3
2 0 1 1 1 /vdf/a/2
2 0 0 0 2 /vdf/a/dir0 (deleted)
2 0 0 0 2 /vdf/a/dir1 (deleted)
1 0 0 0 1 /vdf/a/dir2
1 0 0 0 1 /vdf/a/dir3
1 0 1 0 0 /vdf/a/b/c/d
1 1 0 1 0 /vdf/a/b/c/0
1 0 0 0 1 /vdf/a/b/c/1 (deleted)
1 0 0 0 1 /vdf/a/b/c/d/e/G/1
1 0 0 0 1 /vdf/a/b/c/d/e/f/g (deleted)
1 0 0 0 1 /vdf/a/b/c/d/e/G
==============================================
Amir Goldstein (16):
fsnotify: tidy up FS_ and FAN_ constants
fsnotify: factor helpers fsnotify_dentry() and fsnotify_file()
fsnotify: funnel all dirent events through fsnotify_name()
fsnotify: use helpers to access data by data_type
fsnotify: simplify arguments passing to fsnotify_parent()
fsnotify: pass dentry instead of inode for events possible on child
fsnotify: replace inode pointer with tag
fanotify: merge duplicate events on parent and child
fanotify: fix merging marks masks with FAN_ONDIR
fanotify: send FAN_DIR_MODIFY event flavor with dir inode and name
fanotify: prepare to encode both parent and child fid's
fanotify: record name info for FAN_DIR_MODIFY event
fanotify: report name info for FAN_DIR_MODIFY event
fanotify: report parent fid + name with FAN_REPORT_NAME
fanotify: refine rules for when name is reported
fanotify: support limited functionality for unprivileged users
fs/notify/fanotify/fanotify.c | 231 +++++++++++++++++++++------
fs/notify/fanotify/fanotify.h | 111 ++++++++++---
fs/notify/fanotify/fanotify_user.c | 182 +++++++++++++++++----
fs/notify/fsnotify.c | 22 +--
fs/notify/inotify/inotify_fsnotify.c | 10 +-
include/linux/fanotify.h | 21 ++-
include/linux/fsnotify.h | 135 +++++++---------
include/linux/fsnotify_backend.h | 87 +++++++---
include/uapi/linux/fanotify.h | 11 +-
kernel/audit_fsnotify.c | 13 +-
kernel/audit_watch.c | 16 +-
11 files changed, 584 insertions(+), 255 deletions(-)
base-commit: 11a48a5a18c63fd7621bb050228cebf13566e4d8
--
2.17.1
From: Amir Goldstein <amir73il@gmail.com> Date: 2020-02-17 13:15:28
Report event FAN_DIR_MODIFY with name in a variable length record similar
to how fid's are reported. With name info reporting implemented, setting
FAN_DIR_MODIFY in mark mask is now allowed.
When events are reported with name, the reported fid identifies the
directory and the name follows the fid. The info record type for this
event info is FAN_EVENT_INFO_TYPE_DFID_NAME.
For now, all reported events have at most one info record which is
either FAN_EVENT_INFO_TYPE_FID or FAN_EVENT_INFO_TYPE_DFID_NAME (for
FAN_DIR_MODIFY). Later on, events "on child" will report both records.
There are several ways that an application can use this information:
1. When watching a single directory, the name is always relative to
the watched directory, so application need to fstatat(2) the name
relative to the watched directory.
2. When watching a set of directories, the application could keep a map
of dirfd for all watched directories and hash the map by fid obtained
with name_to_handle_at(2). When getting a name event, the fid in the
event info could be used to lookup the base dirfd in the map and then
call fstatat(2) with that dirfd.
3. When watching a filesystem (FAN_MARK_FILESYSTEM) or a large set of
directories, the application could use open_by_handle_at(2) with the fid
in event info to obtain dirfd for the directory where event happened and
call fstatat(2) with this dirfd.
The last option scales better for a large number of watched directories.
The first two options may be available in the future also for non
privileged fanotify watchers, because open_by_handle_at(2) requires
the CAP_DAC_READ_SEARCH capability.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
---
fs/notify/fanotify/fanotify.c | 2 +-
fs/notify/fanotify/fanotify_user.c | 120 ++++++++++++++++++++++-------
include/linux/fanotify.h | 3 +-
include/uapi/linux/fanotify.h | 1 +
4 files changed, 98 insertions(+), 28 deletions(-)
@@ -253,14 +282,33 @@ static int copy_fid_to_user(__kernel_fsid_t *fsid, struct fanotify_fid_hdr *fh,if(copy_to_user(buf,data,fh_len))return-EFAULT;-/* Pad with 0's */buf+=fh_len;len-=fh_len;++if(name_len){+/* Copy the filename with terminating null */+name_len++;+if(WARN_ON_ONCE(len<name_len))+return-EFAULT;++data=name->name;+if(name_len<=DNAME_INLINE_LEN){+memcpy(bounce,data,name_len);+data=bounce;+}+if(copy_to_user(buf,data,name_len))+return-EFAULT;++buf+=name_len;+len-=name_len;+}++/* Pad with 0's */WARN_ON_ONCE(len<0||len>=FANOTIFY_EVENT_ALIGN);if(len>0&&clear_user(buf,len))return-EFAULT;-return0;+returninfo_len;}staticssize_tcopy_event_to_user(structfsnotify_group*group,
@@ -302,16 +350,36 @@ static ssize_t copy_event_to_user(struct fsnotify_group *group,if(copy_to_user(buf,&metadata,FAN_EVENT_METADATA_LEN))gotoout_close_fd;+buf+=FAN_EVENT_METADATA_LEN;+count-=FAN_EVENT_METADATA_LEN;+if(fanotify_is_perm_event(event->mask))FANOTIFY_PE(fsn_event)->fd=fd;-if(fanotify_event_has_path(event)){+if(f)fd_install(fd,f);-}elseif(fanotify_event_has_fid(event)){-ret=copy_fid_to_user(&event->fsid,&event->fh,&event->fid,-buf+FAN_EVENT_METADATA_LEN);++/* Event info records order is: dir fid + name, child fid */+if(fanotify_event_has_dfid_name(event)){+structfanotify_name_event*fne=FANOTIFY_NE(fsn_event);++ret=copy_info_to_user(&event->fsid,&event->dfh,&fne->dfid,+&fne->name,buf,count);if(ret<0)returnret;++buf+=ret;+count-=ret;+}++if(fanotify_event_has_fid(event)){+ret=copy_info_to_user(&event->fsid,&event->fh,&event->fid,+NULL,buf,count);+if(ret<0)+returnret;++buf+=ret;+count-=ret;}returnmetadata.event_len;
@@ -47,7 +47,8 @@*Directoryentrymodificationevents-reportedonlytodirectory*whereentryismodifiedandnottoawatchingparent.*/-#define FANOTIFY_DIRENT_EVENTS (FAN_MOVE | FAN_CREATE | FAN_DELETE)+#define FANOTIFY_DIRENT_EVENTS (FAN_MOVE | FAN_CREATE | FAN_DELETE | \+FAN_DIR_MODIFY)/* Events that can only be reported with data type FSNOTIFY_EVENT_INODE */#define FANOTIFY_INODE_EVENTS (FANOTIFY_DIRENT_EVENTS | \
From: Amir Goldstein <amir73il@gmail.com> Date: 2020-02-17 13:15:29
For a group with fanotify_init() flag FAN_REPORT_NAME, we report the
parent fid and name for events possible "on child" (e.g. FAN_MODIFY)
in addition to reporting the child fid.
The flag FAN_REPORT_NAME requires the flag FAN_REPORT_FID and there is
a constant for setting both flags named FAN_REPORT_FID_NAME.
The parent fid and name are reported with an info record of type
FAN_EVENT_INFO_TYPE_DFID_NAME, similar to the way that name info is
reported for FAN_DIR_MODIFY events.
The child fid is reported with another info record of type
FAN_EVENT_INFO_TYPE_FID that follows the first info record, with the
same fid info that is reported to a group with FAN_REPORT_FID flag.
Events with name are reported the same way when reported to sb, mount
or inode marks and when reported to a directory watching children.
Events not possible "on child" (e.g. FAN_DELETE_SELF) are reported
with a single FAN_EVENT_INFO_TYPE_FID record, same as they are reported
to a group with FAN_REPORT_FID flag.
If parent is unknown (dentry is disconnected) or parent is not on the
same filesystem as child (dentry is sb root), event is also reported
with a single FAN_EVENT_INFO_TYPE_FID record.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
---
fs/notify/fanotify/fanotify.c | 25 +++++++++++++++++++++++--
fs/notify/fanotify/fanotify_user.c | 6 +++++-
include/linux/fanotify.h | 2 +-
include/uapi/linux/fanotify.h | 4 ++++
4 files changed, 33 insertions(+), 4 deletions(-)
@@ -54,6 +54,10 @@/* Flags to determine fanotify event format */#define FAN_REPORT_TID 0x00000100 /* event->pid is thread id */#define FAN_REPORT_FID 0x00000200 /* Report unique file id */+#define FAN_REPORT_NAME 0x00000400 /* Report events with name */++/* Convenience macro - FAN_REPORT_NAME requires FAN_REPORT_FID */+#define FAN_REPORT_FID_NAME (FAN_REPORT_FID | FAN_REPORT_NAME)/* Deprecated - do not use this in programs and do not add new flags here! */#define FAN_ALL_INIT_FLAGS (FAN_CLOEXEC | FAN_NONBLOCK | \
From: Amir Goldstein <amir73il@gmail.com> Date: 2020-02-17 13:15:31
Add support for new fanotify_init() flag FAN_UNPRIVILEGED.
User may request an unprivileged event listener using this flag even if
user is privileged.
An unprivileged event listener does not get an open file descriptor in
the event nor the process pid of another process. An unprivileged event
listener cannot request permission events, cannot set mount/filesystem
marks and cannot request unlimited queue/marks.
This enables the limited functionality similar to inotify when watching a
set of files and directories for OPEN/ACCESS/MODIFY/CLOSE events, without
requiring SYS_CAP_ADMIN privileges.
The FAN_DIR_MODIFY event and FAN_REPORT_FID_NAME init flag, provide a
method for an unprivileged event listener watching a set of directories
(with FAN_EVENT_ON_CHILD) to monitor all changes inside those directories.
This typically requires that the listener keeps a map of watched
directory fid to dirfd (O_PATH), where fid is obtained with
name_to_handle_at() before starting to watch for changes.
When getting an event, the reported fid of the parent should be resolved
to dirfd and fstatsat(2) with dirfd and name should be used to query the
state of the filesystem entry.
Note that even though events do not report the event creator pid,
fanotify does not merge similar events on the same object that were
generated by different processes. This is aligned with exiting behavior
when generating processes are outside of the listener pidns (which
results in reporting 0 pid to listener).
Cc: <redacted>
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
---
fs/notify/fanotify/fanotify_user.c | 42 ++++++++++++++++++++++++++----
include/linux/fanotify.h | 16 +++++++++++-
include/uapi/linux/fanotify.h | 1 +
3 files changed, 53 insertions(+), 6 deletions(-)
From: Amir Goldstein <amir73il@gmail.com> Date: 2020-02-17 13:15:32
Dirent events are going to be supported in two flavors:
1. Directory fid info + mask that includes the specific event types
(e.g. FAN_CREATE) and an optional FAN_ONDIR flag.
2. Directory fid info + name + mask that includes only FAN_DIR_MODIFY.
To request the second event flavor, user needs to set the event type
FAN_DIR_MODIFY in the mark mask.
The first flavor is supported since kernel v5.1 for groups initialized
with flag FAN_REPORT_FID. It is intended to be used for watching
directories in "batch mode" - the watcher is notified when directory is
changed and re-scans the directory content in response. This event
flavor is stored more compactly in the event queue, so it is optimal
for workloads with frequent directory changes.
The second event flavor is intended to be used for watching large
directories, where the cost of re-scan of the directory on every change
is considered too high. The watcher getting the event with the directory
fid and entry name is expected to call fstatat(2) to query the content of
the entry after the change.
Legacy inotify events are reported with name and event mask (e.g. "foo",
FAN_CREATE | FAN_ONDIR). That can lead users to the conclusion that
there is *currently* an entry "foo" that is a sub-directory, when in fact
"foo" may be negative or non-dir by the time user gets the event.
To make it clear that the current state of the named entry is unknown,
when reporting an event with name info, fanotify obfuscates the specific
event types (e.g. create,delete,rename) and uses a common event type -
FAN_DIR_MODIFY to decribe the change. This should make it harder for
users to make wrong assumptions and write buggy filesystem monitors.
At this point, name info reporting is not yet implemented, so trying to
set FAN_DIR_MODIFY in mark mask will return -EINVAL.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
---
fs/notify/fanotify/fanotify.c | 7 ++++---
fs/notify/fsnotify.c | 2 +-
include/linux/fsnotify.h | 6 ++++++
include/linux/fsnotify_backend.h | 4 +++-
include/uapi/linux/fanotify.h | 1 +
5 files changed, 15 insertions(+), 5 deletions(-)
@@ -47,6 +47,7 @@#define FS_OPEN_PERM 0x00010000 /* open event in an permission hook */#define FS_ACCESS_PERM 0x00020000 /* access event in a permissions hook */#define FS_OPEN_EXEC_PERM 0x00040000 /* open/exec event in a permission hook */+#define FS_DIR_MODIFY 0x00080000 /* Directory entry was modified */#define FS_EXCL_UNLINK 0x04000000 /* do not send events if object is unlinked *//* This inode cares about things that happen to its children. Always set for
From: kbuild test robot <hidden> Date: 2020-02-19 09:44:01
Hi Amir,
I love your patch! Perhaps something to improve:
[auto build test WARNING on 11a48a5a18c63fd7621bb050228cebf13566e4d8]
url: https://github.com/0day-ci/linux/commits/Amir-Goldstein/Fanotify-event-with-name-info/20200219-160517
base: 11a48a5a18c63fd7621bb050228cebf13566e4d8
config: c6x-randconfig-a001-20200219 (attached as .config)
compiler: c6x-elf-gcc (GCC) 7.5.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.5.0 make.cross ARCH=c6x
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <redacted>
All warnings (new ones prefixed by >>):
In file included from include/linux/kernel.h:15:0,
from include/linux/list.h:9,
from include/linux/preempt.h:11,
from include/linux/spinlock.h:51,
from include/linux/seqlock.h:36,
from include/linux/time.h:6,
from include/linux/stat.h:19,
from include/linux/fcntl.h:5,
from fs/notify/fanotify/fanotify_user.c:3:
fs/notify/fanotify/fanotify_user.c: In function 'copy_info_to_user':
quoted
fs/notify/fanotify/fanotify_user.c:238:11: warning: format '%lu' expects argument of type 'long unsigned int', but argument 4 has type 'size_t {aka unsigned int}' [-Wformat=]
pr_debug("%s: fh_len=%lu name_len=%lu, info_len=%lu, count=%lu\n",
^
include/linux/printk.h:288:21: note: in definition of macro 'pr_fmt'
#define pr_fmt(fmt) fmt
^~~
include/linux/dynamic_debug.h:143:2: note: in expansion of macro '__dynamic_func_call'
__dynamic_func_call(__UNIQUE_ID(ddebug), fmt, func, ##__VA_ARGS__)
^~~~~~~~~~~~~~~~~~~
include/linux/dynamic_debug.h:153:2: note: in expansion of macro '_dynamic_func_call'
_dynamic_func_call(fmt, __dynamic_pr_debug, \
^~~~~~~~~~~~~~~~~~
include/linux/printk.h:335:2: note: in expansion of macro 'dynamic_pr_debug'
dynamic_pr_debug(fmt, ##__VA_ARGS__)
^~~~~~~~~~~~~~~~
fs/notify/fanotify/fanotify_user.c:238:2: note: in expansion of macro 'pr_debug'
pr_debug("%s: fh_len=%lu name_len=%lu, info_len=%lu, count=%lu\n",
^~~~~~~~
fs/notify/fanotify/fanotify_user.c:238:11: warning: format '%lu' expects argument of type 'long unsigned int', but argument 5 has type 'size_t {aka unsigned int}' [-Wformat=]
pr_debug("%s: fh_len=%lu name_len=%lu, info_len=%lu, count=%lu\n",
^
include/linux/printk.h:288:21: note: in definition of macro 'pr_fmt'
#define pr_fmt(fmt) fmt
^~~
include/linux/dynamic_debug.h:143:2: note: in expansion of macro '__dynamic_func_call'
__dynamic_func_call(__UNIQUE_ID(ddebug), fmt, func, ##__VA_ARGS__)
^~~~~~~~~~~~~~~~~~~
include/linux/dynamic_debug.h:153:2: note: in expansion of macro '_dynamic_func_call'
_dynamic_func_call(fmt, __dynamic_pr_debug, \
^~~~~~~~~~~~~~~~~~
include/linux/printk.h:335:2: note: in expansion of macro 'dynamic_pr_debug'
dynamic_pr_debug(fmt, ##__VA_ARGS__)
^~~~~~~~~~~~~~~~
fs/notify/fanotify/fanotify_user.c:238:2: note: in expansion of macro 'pr_debug'
pr_debug("%s: fh_len=%lu name_len=%lu, info_len=%lu, count=%lu\n",
^~~~~~~~
fs/notify/fanotify/fanotify_user.c:238:11: warning: format '%lu' expects argument of type 'long unsigned int', but argument 6 has type 'size_t {aka unsigned int}' [-Wformat=]
pr_debug("%s: fh_len=%lu name_len=%lu, info_len=%lu, count=%lu\n",
^
include/linux/printk.h:288:21: note: in definition of macro 'pr_fmt'
#define pr_fmt(fmt) fmt
^~~
include/linux/dynamic_debug.h:143:2: note: in expansion of macro '__dynamic_func_call'
__dynamic_func_call(__UNIQUE_ID(ddebug), fmt, func, ##__VA_ARGS__)
^~~~~~~~~~~~~~~~~~~
include/linux/dynamic_debug.h:153:2: note: in expansion of macro '_dynamic_func_call'
_dynamic_func_call(fmt, __dynamic_pr_debug, \
^~~~~~~~~~~~~~~~~~
include/linux/printk.h:335:2: note: in expansion of macro 'dynamic_pr_debug'
dynamic_pr_debug(fmt, ##__VA_ARGS__)
^~~~~~~~~~~~~~~~
fs/notify/fanotify/fanotify_user.c:238:2: note: in expansion of macro 'pr_debug'
pr_debug("%s: fh_len=%lu name_len=%lu, info_len=%lu, count=%lu\n",
^~~~~~~~
fs/notify/fanotify/fanotify_user.c:238:11: warning: format '%lu' expects argument of type 'long unsigned int', but argument 7 has type 'size_t {aka unsigned int}' [-Wformat=]
pr_debug("%s: fh_len=%lu name_len=%lu, info_len=%lu, count=%lu\n",
^
include/linux/printk.h:288:21: note: in definition of macro 'pr_fmt'
#define pr_fmt(fmt) fmt
^~~
include/linux/dynamic_debug.h:143:2: note: in expansion of macro '__dynamic_func_call'
__dynamic_func_call(__UNIQUE_ID(ddebug), fmt, func, ##__VA_ARGS__)
^~~~~~~~~~~~~~~~~~~
include/linux/dynamic_debug.h:153:2: note: in expansion of macro '_dynamic_func_call'
_dynamic_func_call(fmt, __dynamic_pr_debug, \
^~~~~~~~~~~~~~~~~~
include/linux/printk.h:335:2: note: in expansion of macro 'dynamic_pr_debug'
dynamic_pr_debug(fmt, ##__VA_ARGS__)
^~~~~~~~~~~~~~~~
fs/notify/fanotify/fanotify_user.c:238:2: note: in expansion of macro 'pr_debug'
pr_debug("%s: fh_len=%lu name_len=%lu, info_len=%lu, count=%lu\n",
^~~~~~~~
vim +238 fs/notify/fanotify/fanotify_user.c
224
225 static int copy_info_to_user(__kernel_fsid_t *fsid, struct fanotify_fid_hdr *fh,
226 struct fanotify_fid *fid, const struct qstr *name,
227 char __user *buf, size_t count)
228 {
229 struct fanotify_event_info_fid info = { };
230 struct file_handle handle = { };
231 unsigned char bounce[max(FANOTIFY_INLINE_FH_LEN, DNAME_INLINE_LEN)];
232 const unsigned char *data;
233 size_t fh_len = fh->len;
234 size_t name_len = name ? name->len : 0;
235 size_t info_len = fanotify_fid_info_len(fh_len, name_len);
236 size_t len = info_len;
237
> 238 pr_debug("%s: fh_len=%lu name_len=%lu, info_len=%lu, count=%lu\n",
239 __func__, fh_len, name_len, info_len, count);
240
241 if (!fh_len || (name && !name_len))
242 return 0;
243
244 if (WARN_ON_ONCE(len < sizeof(info) || len > count))
245 return -EFAULT;
246
247 /*
248 * Copy event info fid header followed by vaiable sized file handle
249 * and optionally followed by vaiable sized filename.
250 */
251 info.hdr.info_type = name_len ? FAN_EVENT_INFO_TYPE_DFID_NAME :
252 FAN_EVENT_INFO_TYPE_FID;
253 info.hdr.len = len;
254 info.fsid = *fsid;
255 if (copy_to_user(buf, &info, sizeof(info)))
256 return -EFAULT;
257
258 buf += sizeof(info);
259 len -= sizeof(info);
260 if (WARN_ON_ONCE(len < sizeof(handle)))
261 return -EFAULT;
262
263 handle.handle_type = fh->type;
264 handle.handle_bytes = fh_len;
265 if (copy_to_user(buf, &handle, sizeof(handle)))
266 return -EFAULT;
267
268 buf += sizeof(handle);
269 len -= sizeof(handle);
270 if (WARN_ON_ONCE(len < fh_len))
271 return -EFAULT;
272
273 /*
274 * For an inline fh and inline file name, copy through stack to exclude
275 * the copy from usercopy hardening protections.
276 */
277 data = fanotify_fid_fh(fid, fh_len);
278 if (fh_len <= FANOTIFY_INLINE_FH_LEN) {
279 memcpy(bounce, data, fh_len);
280 data = bounce;
281 }
282 if (copy_to_user(buf, data, fh_len))
283 return -EFAULT;
284
285 buf += fh_len;
286 len -= fh_len;
287
288 if (name_len) {
289 /* Copy the filename with terminating null */
290 name_len++;
291 if (WARN_ON_ONCE(len < name_len))
292 return -EFAULT;
293
294 data = name->name;
295 if (name_len <= DNAME_INLINE_LEN) {
296 memcpy(bounce, data, name_len);
297 data = bounce;
298 }
299 if (copy_to_user(buf, data, name_len))
300 return -EFAULT;
301
302 buf += name_len;
303 len -= name_len;
304 }
305
306 /* Pad with 0's */
307 WARN_ON_ONCE(len < 0 || len >= FANOTIFY_EVENT_ALIGN);
308 if (len > 0 && clear_user(buf, len))
309 return -EFAULT;
310
311 return info_len;
312 }
313
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
From: kbuild test robot <hidden> Date: 2020-02-19 10:18:24
Hi Amir,
I love your patch! Perhaps something to improve:
[auto build test WARNING on 11a48a5a18c63fd7621bb050228cebf13566e4d8]
url: https://github.com/0day-ci/linux/commits/Amir-Goldstein/Fanotify-event-with-name-info/20200219-160517
base: 11a48a5a18c63fd7621bb050228cebf13566e4d8
config: microblaze-randconfig-a001-20200219 (attached as .config)
compiler: microblaze-linux-gcc (GCC) 7.5.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.5.0 make.cross ARCH=microblaze
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <redacted>
All warnings (new ones prefixed by >>):
In file included from include/linux/kernel.h:15:0,
from include/linux/list.h:9,
from include/linux/preempt.h:11,
from include/linux/spinlock.h:51,
from include/linux/seqlock.h:36,
from include/linux/time.h:6,
from include/linux/stat.h:19,
from include/linux/fcntl.h:5,
from fs/notify/fanotify/fanotify_user.c:3:
fs/notify/fanotify/fanotify_user.c: In function 'copy_info_to_user':
quoted
include/linux/kern_levels.h:5:18: warning: format '%lu' expects argument of type 'long unsigned int', but argument 3 has type 'size_t {aka unsigned int}' [-Wformat=]
#define KERN_SOH "\001" /* ASCII Start Of Header */
^
include/linux/printk.h:137:10: note: in definition of macro 'no_printk'
printk(fmt, ##__VA_ARGS__); \
^~~
include/linux/kern_levels.h:15:20: note: in expansion of macro 'KERN_SOH'
#define KERN_DEBUG KERN_SOH "7" /* debug-level messages */
^~~~~~~~
include/linux/printk.h:341:12: note: in expansion of macro 'KERN_DEBUG'
no_printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
^~~~~~~~~~
fs/notify/fanotify/fanotify_user.c:238:2: note: in expansion of macro 'pr_debug'
pr_debug("%s: fh_len=%lu name_len=%lu, info_len=%lu, count=%lu\n",
^~~~~~~~
fs/notify/fanotify/fanotify_user.c:238:25: note: format string is defined here
pr_debug("%s: fh_len=%lu name_len=%lu, info_len=%lu, count=%lu\n",
~~^
%u
In file included from include/linux/kernel.h:15:0,
from include/linux/list.h:9,
from include/linux/preempt.h:11,
from include/linux/spinlock.h:51,
from include/linux/seqlock.h:36,
from include/linux/time.h:6,
from include/linux/stat.h:19,
from include/linux/fcntl.h:5,
from fs/notify/fanotify/fanotify_user.c:3:
include/linux/kern_levels.h:5:18: warning: format '%lu' expects argument of type 'long unsigned int', but argument 4 has type 'size_t {aka unsigned int}' [-Wformat=]
#define KERN_SOH "\001" /* ASCII Start Of Header */
^
include/linux/printk.h:137:10: note: in definition of macro 'no_printk'
printk(fmt, ##__VA_ARGS__); \
^~~
include/linux/kern_levels.h:15:20: note: in expansion of macro 'KERN_SOH'
#define KERN_DEBUG KERN_SOH "7" /* debug-level messages */
^~~~~~~~
include/linux/printk.h:341:12: note: in expansion of macro 'KERN_DEBUG'
no_printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
^~~~~~~~~~
fs/notify/fanotify/fanotify_user.c:238:2: note: in expansion of macro 'pr_debug'
pr_debug("%s: fh_len=%lu name_len=%lu, info_len=%lu, count=%lu\n",
^~~~~~~~
fs/notify/fanotify/fanotify_user.c:238:38: note: format string is defined here
pr_debug("%s: fh_len=%lu name_len=%lu, info_len=%lu, count=%lu\n",
~~^
%u
In file included from include/linux/kernel.h:15:0,
from include/linux/list.h:9,
from include/linux/preempt.h:11,
from include/linux/spinlock.h:51,
from include/linux/seqlock.h:36,
from include/linux/time.h:6,
from include/linux/stat.h:19,
from include/linux/fcntl.h:5,
from fs/notify/fanotify/fanotify_user.c:3:
include/linux/kern_levels.h:5:18: warning: format '%lu' expects argument of type 'long unsigned int', but argument 5 has type 'size_t {aka unsigned int}' [-Wformat=]
#define KERN_SOH "\001" /* ASCII Start Of Header */
^
include/linux/printk.h:137:10: note: in definition of macro 'no_printk'
printk(fmt, ##__VA_ARGS__); \
^~~
include/linux/kern_levels.h:15:20: note: in expansion of macro 'KERN_SOH'
#define KERN_DEBUG KERN_SOH "7" /* debug-level messages */
^~~~~~~~
include/linux/printk.h:341:12: note: in expansion of macro 'KERN_DEBUG'
no_printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
^~~~~~~~~~
fs/notify/fanotify/fanotify_user.c:238:2: note: in expansion of macro 'pr_debug'
pr_debug("%s: fh_len=%lu name_len=%lu, info_len=%lu, count=%lu\n",
^~~~~~~~
fs/notify/fanotify/fanotify_user.c:238:52: note: format string is defined here
pr_debug("%s: fh_len=%lu name_len=%lu, info_len=%lu, count=%lu\n",
~~^
%u
In file included from include/linux/kernel.h:15:0,
from include/linux/list.h:9,
from include/linux/preempt.h:11,
from include/linux/spinlock.h:51,
from include/linux/seqlock.h:36,
from include/linux/time.h:6,
from include/linux/stat.h:19,
from include/linux/fcntl.h:5,
from fs/notify/fanotify/fanotify_user.c:3:
include/linux/kern_levels.h:5:18: warning: format '%lu' expects argument of type 'long unsigned int', but argument 6 has type 'size_t {aka unsigned int}' [-Wformat=]
#define KERN_SOH "\001" /* ASCII Start Of Header */
^
include/linux/printk.h:137:10: note: in definition of macro 'no_printk'
printk(fmt, ##__VA_ARGS__); \
^~~
include/linux/kern_levels.h:15:20: note: in expansion of macro 'KERN_SOH'
#define KERN_DEBUG KERN_SOH "7" /* debug-level messages */
^~~~~~~~
include/linux/printk.h:341:12: note: in expansion of macro 'KERN_DEBUG'
no_printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
^~~~~~~~~~
fs/notify/fanotify/fanotify_user.c:238:2: note: in expansion of macro 'pr_debug'
pr_debug("%s: fh_len=%lu name_len=%lu, info_len=%lu, count=%lu\n",
^~~~~~~~
fs/notify/fanotify/fanotify_user.c:238:63: note: format string is defined here
pr_debug("%s: fh_len=%lu name_len=%lu, info_len=%lu, count=%lu\n",
--
In file included from include/linux/kernel.h:15:0,
from include/linux/list.h:9,
from include/linux/preempt.h:11,
from include/linux/spinlock.h:51,
from include/linux/seqlock.h:36,
from include/linux/time.h:6,
from include/linux/stat.h:19,
from include/linux/fcntl.h:5,
from fs/notify//fanotify/fanotify_user.c:3:
fs/notify//fanotify/fanotify_user.c: In function 'copy_info_to_user':
quoted
include/linux/kern_levels.h:5:18: warning: format '%lu' expects argument of type 'long unsigned int', but argument 3 has type 'size_t {aka unsigned int}' [-Wformat=]
#define KERN_SOH "\001" /* ASCII Start Of Header */
^
include/linux/printk.h:137:10: note: in definition of macro 'no_printk'
printk(fmt, ##__VA_ARGS__); \
^~~
include/linux/kern_levels.h:15:20: note: in expansion of macro 'KERN_SOH'
#define KERN_DEBUG KERN_SOH "7" /* debug-level messages */
^~~~~~~~
include/linux/printk.h:341:12: note: in expansion of macro 'KERN_DEBUG'
no_printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
^~~~~~~~~~
fs/notify//fanotify/fanotify_user.c:238:2: note: in expansion of macro 'pr_debug'
pr_debug("%s: fh_len=%lu name_len=%lu, info_len=%lu, count=%lu\n",
^~~~~~~~
fs/notify//fanotify/fanotify_user.c:238:25: note: format string is defined here
pr_debug("%s: fh_len=%lu name_len=%lu, info_len=%lu, count=%lu\n",
~~^
%u
In file included from include/linux/kernel.h:15:0,
from include/linux/list.h:9,
from include/linux/preempt.h:11,
from include/linux/spinlock.h:51,
from include/linux/seqlock.h:36,
from include/linux/time.h:6,
from include/linux/stat.h:19,
from include/linux/fcntl.h:5,
from fs/notify//fanotify/fanotify_user.c:3:
include/linux/kern_levels.h:5:18: warning: format '%lu' expects argument of type 'long unsigned int', but argument 4 has type 'size_t {aka unsigned int}' [-Wformat=]
#define KERN_SOH "\001" /* ASCII Start Of Header */
^
include/linux/printk.h:137:10: note: in definition of macro 'no_printk'
printk(fmt, ##__VA_ARGS__); \
^~~
include/linux/kern_levels.h:15:20: note: in expansion of macro 'KERN_SOH'
#define KERN_DEBUG KERN_SOH "7" /* debug-level messages */
^~~~~~~~
include/linux/printk.h:341:12: note: in expansion of macro 'KERN_DEBUG'
no_printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
^~~~~~~~~~
fs/notify//fanotify/fanotify_user.c:238:2: note: in expansion of macro 'pr_debug'
pr_debug("%s: fh_len=%lu name_len=%lu, info_len=%lu, count=%lu\n",
^~~~~~~~
fs/notify//fanotify/fanotify_user.c:238:38: note: format string is defined here
pr_debug("%s: fh_len=%lu name_len=%lu, info_len=%lu, count=%lu\n",
~~^
%u
In file included from include/linux/kernel.h:15:0,
from include/linux/list.h:9,
from include/linux/preempt.h:11,
from include/linux/spinlock.h:51,
from include/linux/seqlock.h:36,
from include/linux/time.h:6,
from include/linux/stat.h:19,
from include/linux/fcntl.h:5,
from fs/notify//fanotify/fanotify_user.c:3:
include/linux/kern_levels.h:5:18: warning: format '%lu' expects argument of type 'long unsigned int', but argument 5 has type 'size_t {aka unsigned int}' [-Wformat=]
#define KERN_SOH "\001" /* ASCII Start Of Header */
^
include/linux/printk.h:137:10: note: in definition of macro 'no_printk'
printk(fmt, ##__VA_ARGS__); \
^~~
include/linux/kern_levels.h:15:20: note: in expansion of macro 'KERN_SOH'
#define KERN_DEBUG KERN_SOH "7" /* debug-level messages */
^~~~~~~~
include/linux/printk.h:341:12: note: in expansion of macro 'KERN_DEBUG'
no_printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
^~~~~~~~~~
fs/notify//fanotify/fanotify_user.c:238:2: note: in expansion of macro 'pr_debug'
pr_debug("%s: fh_len=%lu name_len=%lu, info_len=%lu, count=%lu\n",
^~~~~~~~
fs/notify//fanotify/fanotify_user.c:238:52: note: format string is defined here
pr_debug("%s: fh_len=%lu name_len=%lu, info_len=%lu, count=%lu\n",
~~^
%u
In file included from include/linux/kernel.h:15:0,
from include/linux/list.h:9,
from include/linux/preempt.h:11,
from include/linux/spinlock.h:51,
from include/linux/seqlock.h:36,
from include/linux/time.h:6,
from include/linux/stat.h:19,
from include/linux/fcntl.h:5,
from fs/notify//fanotify/fanotify_user.c:3:
include/linux/kern_levels.h:5:18: warning: format '%lu' expects argument of type 'long unsigned int', but argument 6 has type 'size_t {aka unsigned int}' [-Wformat=]
#define KERN_SOH "\001" /* ASCII Start Of Header */
^
include/linux/printk.h:137:10: note: in definition of macro 'no_printk'
printk(fmt, ##__VA_ARGS__); \
^~~
include/linux/kern_levels.h:15:20: note: in expansion of macro 'KERN_SOH'
#define KERN_DEBUG KERN_SOH "7" /* debug-level messages */
^~~~~~~~
include/linux/printk.h:341:12: note: in expansion of macro 'KERN_DEBUG'
no_printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
^~~~~~~~~~
fs/notify//fanotify/fanotify_user.c:238:2: note: in expansion of macro 'pr_debug'
pr_debug("%s: fh_len=%lu name_len=%lu, info_len=%lu, count=%lu\n",
^~~~~~~~
fs/notify//fanotify/fanotify_user.c:238:63: note: format string is defined here
pr_debug("%s: fh_len=%lu name_len=%lu, info_len=%lu, count=%lu\n",
vim +5 include/linux/kern_levels.h
314ba3520e513a Joe Perches 2012-07-30 4
04d2c8c83d0e3a Joe Perches 2012-07-30 @5 #define KERN_SOH "\001" /* ASCII Start Of Header */
04d2c8c83d0e3a Joe Perches 2012-07-30 6 #define KERN_SOH_ASCII '\001'
04d2c8c83d0e3a Joe Perches 2012-07-30 7
:::::: The code at line 5 was first introduced by commit
:::::: 04d2c8c83d0e3ac5f78aeede51babb3236200112 printk: convert the format for KERN_<LEVEL> to a 2 byte pattern
:::::: TO: Joe Perches [off-list ref]
:::::: CC: Linus Torvalds [off-list ref]
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
From: Amir Goldstein <amir73il@gmail.com> Date: 2020-02-19 11:23:02
On Mon, Feb 17, 2020 at 3:15 PM Amir Goldstein [off-list ref] wrote:
quoted hunk
Report event FAN_DIR_MODIFY with name in a variable length record similar
to how fid's are reported. With name info reporting implemented, setting
FAN_DIR_MODIFY in mark mask is now allowed.
When events are reported with name, the reported fid identifies the
directory and the name follows the fid. The info record type for this
event info is FAN_EVENT_INFO_TYPE_DFID_NAME.
For now, all reported events have at most one info record which is
either FAN_EVENT_INFO_TYPE_FID or FAN_EVENT_INFO_TYPE_DFID_NAME (for
FAN_DIR_MODIFY). Later on, events "on child" will report both records.
There are several ways that an application can use this information:
1. When watching a single directory, the name is always relative to
the watched directory, so application need to fstatat(2) the name
relative to the watched directory.
2. When watching a set of directories, the application could keep a map
of dirfd for all watched directories and hash the map by fid obtained
with name_to_handle_at(2). When getting a name event, the fid in the
event info could be used to lookup the base dirfd in the map and then
call fstatat(2) with that dirfd.
3. When watching a filesystem (FAN_MARK_FILESYSTEM) or a large set of
directories, the application could use open_by_handle_at(2) with the fid
in event info to obtain dirfd for the directory where event happened and
call fstatat(2) with this dirfd.
The last option scales better for a large number of watched directories.
The first two options may be available in the future also for non
privileged fanotify watchers, because open_by_handle_at(2) requires
the CAP_DAC_READ_SEARCH capability.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
---
fs/notify/fanotify/fanotify.c | 2 +-
fs/notify/fanotify/fanotify_user.c | 120 ++++++++++++++++++++++-------
include/linux/fanotify.h | 3 +-
include/uapi/linux/fanotify.h | 1 +
4 files changed, 98 insertions(+), 28 deletions(-)
From: Matthew Bobrowski <hidden> Date: 2020-02-20 22:10:34
On Mon, Feb 17, 2020 at 03:14:39PM +0200, Amir Goldstein wrote:
This is v2 of the fanotify name info series.
The user requirement for the name info feature, as well as early UAPI
discussions can be found in this [1] lore thread.
Oh, wonderful. I'm keen to have this feature come to fruition.
After my wedding, which is this Saturday (tomorrow), I'll come around
to reviewing this series.
/M
From: Michael Kerrisk (man-pages) <hidden> Date: 2020-04-16 12:17:05
Hello Amir,
On Mon, 17 Feb 2020 at 15:10, Amir Goldstein [off-list ref] wrote:
Report event FAN_DIR_MODIFY with name in a variable length record similar
to how fid's are reported. With name info reporting implemented, setting
FAN_DIR_MODIFY in mark mask is now allowed.
I see this was merged for 5.7. Would you be able to send a man-pages
patch that documents this new feature please.
Cheers,
Michael
quoted hunk
When events are reported with name, the reported fid identifies the
directory and the name follows the fid. The info record type for this
event info is FAN_EVENT_INFO_TYPE_DFID_NAME.
For now, all reported events have at most one info record which is
either FAN_EVENT_INFO_TYPE_FID or FAN_EVENT_INFO_TYPE_DFID_NAME (for
FAN_DIR_MODIFY). Later on, events "on child" will report both records.
There are several ways that an application can use this information:
1. When watching a single directory, the name is always relative to
the watched directory, so application need to fstatat(2) the name
relative to the watched directory.
2. When watching a set of directories, the application could keep a map
of dirfd for all watched directories and hash the map by fid obtained
with name_to_handle_at(2). When getting a name event, the fid in the
event info could be used to lookup the base dirfd in the map and then
call fstatat(2) with that dirfd.
3. When watching a filesystem (FAN_MARK_FILESYSTEM) or a large set of
directories, the application could use open_by_handle_at(2) with the fid
in event info to obtain dirfd for the directory where event happened and
call fstatat(2) with this dirfd.
The last option scales better for a large number of watched directories.
The first two options may be available in the future also for non
privileged fanotify watchers, because open_by_handle_at(2) requires
the CAP_DAC_READ_SEARCH capability.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
---
fs/notify/fanotify/fanotify.c | 2 +-
fs/notify/fanotify/fanotify_user.c | 120 ++++++++++++++++++++++-------
include/linux/fanotify.h | 3 +-
include/uapi/linux/fanotify.h | 1 +
4 files changed, 98 insertions(+), 28 deletions(-)
@@ -253,14 +282,33 @@ static int copy_fid_to_user(__kernel_fsid_t *fsid, struct fanotify_fid_hdr *fh,if(copy_to_user(buf,data,fh_len))return-EFAULT;-/* Pad with 0's */buf+=fh_len;len-=fh_len;++if(name_len){+/* Copy the filename with terminating null */+name_len++;+if(WARN_ON_ONCE(len<name_len))+return-EFAULT;++data=name->name;+if(name_len<=DNAME_INLINE_LEN){+memcpy(bounce,data,name_len);+data=bounce;+}+if(copy_to_user(buf,data,name_len))+return-EFAULT;++buf+=name_len;+len-=name_len;+}++/* Pad with 0's */WARN_ON_ONCE(len<0||len>=FANOTIFY_EVENT_ALIGN);if(len>0&&clear_user(buf,len))return-EFAULT;-return0;+returninfo_len;}staticssize_tcopy_event_to_user(structfsnotify_group*group,
@@ -302,16 +350,36 @@ static ssize_t copy_event_to_user(struct fsnotify_group *group,if(copy_to_user(buf,&metadata,FAN_EVENT_METADATA_LEN))gotoout_close_fd;+buf+=FAN_EVENT_METADATA_LEN;+count-=FAN_EVENT_METADATA_LEN;+if(fanotify_is_perm_event(event->mask))FANOTIFY_PE(fsn_event)->fd=fd;-if(fanotify_event_has_path(event)){+if(f)fd_install(fd,f);-}elseif(fanotify_event_has_fid(event)){-ret=copy_fid_to_user(&event->fsid,&event->fh,&event->fid,-buf+FAN_EVENT_METADATA_LEN);++/* Event info records order is: dir fid + name, child fid */+if(fanotify_event_has_dfid_name(event)){+structfanotify_name_event*fne=FANOTIFY_NE(fsn_event);++ret=copy_info_to_user(&event->fsid,&event->dfh,&fne->dfid,+&fne->name,buf,count);if(ret<0)returnret;++buf+=ret;+count-=ret;+}++if(fanotify_event_has_fid(event)){+ret=copy_info_to_user(&event->fsid,&event->fh,&event->fid,+NULL,buf,count);+if(ret<0)+returnret;++buf+=ret;+count-=ret;}returnmetadata.event_len;
@@ -47,7 +47,8 @@*Directoryentrymodificationevents-reportedonlytodirectory*whereentryismodifiedandnottoawatchingparent.*/-#define FANOTIFY_DIRENT_EVENTS (FAN_MOVE | FAN_CREATE | FAN_DELETE)+#define FANOTIFY_DIRENT_EVENTS (FAN_MOVE | FAN_CREATE | FAN_DELETE | \+FAN_DIR_MODIFY)/* Events that can only be reported with data type FSNOTIFY_EVENT_INODE */#define FANOTIFY_INODE_EVENTS (FANOTIFY_DIRENT_EVENTS | \
From: Jan Kara <jack@suse.cz> Date: 2020-04-20 15:53:20
On Thu 16-04-20 14:16:40, Michael Kerrisk (man-pages) wrote:
Hello Amir,
On Mon, 17 Feb 2020 at 15:10, Amir Goldstein [off-list ref] wrote:
quoted
Report event FAN_DIR_MODIFY with name in a variable length record similar
to how fid's are reported. With name info reporting implemented, setting
FAN_DIR_MODIFY in mark mask is now allowed.
I see this was merged for 5.7. Would you be able to send a man-pages
patch that documents this new feature please.
I know that Amir has the manpage ready. I'm not sure when he plans to
submit it.
Honza
--
Jan Kara [off-list ref]
SUSE Labs, CR
From: Amir Goldstein <amir73il@gmail.com> Date: 2020-04-20 18:45:47
On Thu, Apr 16, 2020 at 3:16 PM Michael Kerrisk (man-pages)
[off-list ref] wrote:
Hello Amir,
On Mon, 17 Feb 2020 at 15:10, Amir Goldstein [off-list ref] wrote:
quoted
Report event FAN_DIR_MODIFY with name in a variable length record similar
to how fid's are reported. With name info reporting implemented, setting
FAN_DIR_MODIFY in mark mask is now allowed.
I see this was merged for 5.7. Would you be able to send a man-pages
patch that documents this new feature please.
Sorry, I missed your email.
Just posted the patches.
I never know when in development cycle you expect to get the man page patches...
Thanks,
Amir.
From: Michael Kerrisk (man-pages) <hidden> Date: 2020-04-20 18:47:44
On Mon, 20 Apr 2020 at 20:45, Amir Goldstein [off-list ref] wrote:
On Thu, Apr 16, 2020 at 3:16 PM Michael Kerrisk (man-pages)
[off-list ref] wrote:
quoted
Hello Amir,
On Mon, 17 Feb 2020 at 15:10, Amir Goldstein [off-list ref] wrote:
quoted
Report event FAN_DIR_MODIFY with name in a variable length record similar
to how fid's are reported. With name info reporting implemented, setting
FAN_DIR_MODIFY in mark mask is now allowed.
I see this was merged for 5.7. Would you be able to send a man-pages
patch that documents this new feature please.
Sorry, I missed your email.
Just posted the patches.
I never know when in development cycle you expect to get the man page patches...
Ideally,m the manual page patches are posted in parallel with the
kernel patches, with a note saying that the featur eis not yet merged.
Thanks,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/