Change FAN_OPEN_PERM to FAN_OPEN If you have any more deadlocks, please let us know. Once you understand the difference between the two let us know if there are any more problems...
-Eric On Mon, 2014-12-29 at 08:13 +0800, ivo welch wrote: > > > I really don't know what I am doing. however, the code is really not > mine, but verbatim from the man-page example, > http://man7.org/linux/man-pages/man7/fanotify.7.html . I had more > code below my code, but had whittled down the example to illustrate > where my system locks up. > > > I wonder if there could be safeguards in the call to avoid crashing > the system. I know fanotify is playing with fire, but should it > incapacitate the system in this way? > > > in the end, all I want to do is log each and every file-open operation > asap. I want to do read-only probing. could someone please point me > to a correct example or facility if the manpage is wrong. > > > /iaw > > > > ---- > Ivo Welch (ivo.we...@gmail.com) > http://www.ivo-welch.info/ > J. Fred Weston Professor of Finance > Anderson School at UCLA, C519 > Director, UCLA Anderson Fink Center for Finance and Investments > Free Finance Textbook, http://book.ivo-welch.info/ > Editor, Critical Finance Review, > http://www.critical-finance-review.org/ > > > On Mon, Dec 29, 2014 at 7:13 AM, Eric Paris <epa...@redhat.com> wrote: > Why are you setting FAN_OPEN_PERM and then not responding to > perm > requests? Of course the system is going to appear locked, > until you > start responding to open events, remove that mark, or close > the fanotify > fd... > > -Eric > > On Fri, 2014-12-26 at 19:40 +0100, Heinrich Schuchardt wrote: > > Hello Ivo, > > > > On 26.12.2014 15:45, ivo welch wrote: > > > I am not a kernel developer, so forgive the intrusion. > > > > > > I suspect I have found either a bug in gdb (less likely) > or a bug in > > > fanotify (more likely). it is replicable, and the code is > almost > > > unchanged from the example in the fanotify man page. to > trigger it, > > > all an su needs to do is to step through the program below > with gdb > > > 7.8.1 'n' command, and linux locks up the system pretty > hard (reboot > > > required). I have confirmed the replicability of this > issue on a > > > clean arch 2014.12.01 3.17.6-1 system and on a clean > ubuntu 14.10 > > > system, both VMs created just to check it. /iaw > > > > > > > > > #define _GNU_SOURCE /* Needed to get O_LARGEFILE > definition */ > > > #include <stdio.h> > > > #include <stdlib.h> > > > #include <errno.h> > > > #include <fcntl.h> > > > #include <poll.h> > > > #include <sys/fanotify.h> > > > > > > int main(int argc, char *argv[]) { > > > int fd; > > > fd = fanotify_init(FAN_CLOEXEC | FAN_CLASS_CONTENT | > FAN_NONBLOCK, > > > O_RDONLY | O_LARGEFILE); > > > if (fd == -1) exit(1); > > > fprintf(stderr, "calling fanotify_mark: fd=%d\n", fd); > > > if (fanotify_mark(fd, FAN_MARK_ADD | FAN_MARK_MOUNT, > FAN_OPEN_PERM | > > > FAN_CLOSE_WRITE, -1, "/") == -1) exit(2); > > > fprintf(stderr, "in gdb step through with 'n' for > repeat.\n"); > > > fprintf(stderr, " (and sometimes otherwise), a ^C > works, but a ^Z > > > and then ^C does not.\n"); > > > } > > > > I was not able to reproduce your problem according to your > description > > with Ubuntu 14.10. > > > > I ran a Ubuntu 14.04 amd64 LiveImage in a VM and compiled > your example with > > gcc -g -o test test.c > > > > The gdb version in Ubuntu 14.10 is 7.4 and not 7.8.1. The > kernel version > > is 3.13. > > > > root@ubuntu:/home/ubuntu/temp# gdb ./test > > GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04 > > Copyright (C) 2012 Free Software Foundation, Inc. > > License GPLv3+: GNU GPL version 3 or later > > <http://gnu.org/licenses/gpl.html> > > This is free software: you are free to change and > redistribute it. > > There is NO WARRANTY, to the extent permitted by law. Type > "show copying" > > and "show warranty" for details. > > This GDB was configured as "x86_64-linux-gnu". > > For bug reporting instructions, please see: > > <http://bugs.launchpad.net/gdb-linaro/>... > > Reading symbols from /home/ubuntu/temp/test...done. > > (gdb) break main > > Breakpoint 1 at 0x400693: file test.c, line 10. > > (gdb) run > > Starting program: /home/ubuntu/temp/test > > warning: no loadable sections found in added symbol-file > system-supplied > > DSO at 0x7ffff7ffa000 > > > > Breakpoint 1, main (argc=1, argv=0x7fffffffe638) at > test.c:10 > > 10 fd = fanotify_init(FAN_CLOEXEC | FAN_CLASS_CONTENT > | FAN_NONBLOCK, > > (gdb) n > > 12 if (fd == -1) exit(1); > > (gdb) n > > 13 fprintf(stderr, "calling fanotify_mark: fd=%d\n", > fd); > > (gdb) n > > calling fanotify_mark: fd=7 > > 14 if (fanotify_mark(fd, FAN_MARK_ADD | > FAN_MARK_MOUNT, > > FAN_OPEN_PERM | > > (gdb) n > > 16 fprintf(stderr, "in gdb step through with 'n' for > repeat.\n"); > > (gdb) n > > in gdb step through with 'n' for repeat. > > 17 fprintf(stderr, " (and sometimes otherwise), a ^C > works, but > > a ^Z and then ^C does not.\n"); > > (gdb) n > > (and sometimes otherwise), a ^C works, but a ^Z and then > ^C does not. > > 18 } > > (gdb) n > > 0x00007ffff7a3b78d in __libc_start_main () from > > /lib/x86_64-linux-gnu/libc.so.6 > > (gdb) n > > Single stepping until exit from function __libc_start_main, > > which has no line number information. > > [Inferior 1 (process 4423) exited with code 0110] > > (gdb) n > > The program is not being run. > > (gdb) q > > root@ubuntu:/home/ubuntu/temp# > > > > > > > > I don't know who else to tell this. I hope this report is > useful, if > > > someone competent can confirm it. /iaw > > > > Bug reports for the Linux kernel should be adressed to the > maintainer. > > You can find him in the MAINTAINERS file of the linux > source. > > > > See > > > https://www.kernel.org/pub/linux/docs/lkml/reporting-bugs.html > > https://bugzilla.kernel.org/ > > > > Before reporting a bug it is worthwhile to check if the > problem also > > occurs with the current kernel version (as of today 3.18.1 > or 3.19-rc1). > > > > > PS: Is there an alternative to fanotify to avoid this? I > want to > > > learn of all file-open requests on a ro device. > > > ---- > > > > The fanotify API is the right choice. Inotify is an > alternative but > > requires marking all directories. > > > > For your task you can use the code provided at > > https://launchpad.net/fatrace > > > > Best regards > > > > Heinrich Schuchardt > > > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
