Re: fanotify bug on gdb -- hard crash

[Eric Paris]

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.welch@xxxxxxxxx)
> 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 <eparis@xxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/