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 don't know who else to tell this. I hope this report is useful, if
someone competent can confirm it. /iaw
PS: Is there an alternative to fanotify to avoid this? I want to
learn of all file-open requests on a ro device.
----
Ivo Welch ([email protected])
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
On Fri 2014-12-26 22:45:38, ivo welch wrote:
> I am not a kernel developer, so forgive the intrusion.
Good bug reports are always welcome.
> 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
Hard lockup -> this can't be gdb problem.
> 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
Does it need root priviledges to trigger?
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
hi pavel---I do a complete fresh install on ubuntu 64-bit 14.10 in a
vmware virtual machine. the gcc version is 4.9.1. this way I cannot
have made a mistake. ;-)
the compile is gcc -g -o testfa testfa.c .
the gdb and program must run with root privilege. without it, it will
just abort on the fd test.
then gdb, do "b main", "run", and step through with 'n's. you should
see "calling fanotify_mark: fd=3" and then, on the next 'n', it should
never return from the fanotify_mark. you should not be able to
interrupt. at this point, you have to pull the plug.
(I think I also trigger this sometimes without gdb, but then it is not
intermittent but replicable. I started debugging because of this
issue.)
/iaw
----
Ivo Welch ([email protected])
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 Sat, Dec 27, 2014 at 6:14 AM, Pavel Machek <[email protected]> wrote:
> On Fri 2014-12-26 22:45:38, ivo welch wrote:
>> I am not a kernel developer, so forgive the intrusion.
>
> Good bug reports are always welcome.
>
>> 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
>
> Hard lockup -> this can't be gdb problem.
>
>> 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
>
> Does it need root priviledges to trigger?
>
> Best regards,
> Pavel
>
>
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
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
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 ([email protected])
> 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 <[email protected]> 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
>
>
>
>
>
thank you, eric. will do. I read up on it above and now understand it better.
the example in the man page seems somewhat misfortunate. I would use
an example that does not, by default, lock up the user system.
(perhaps add a second example with the _PERM feature that shows how it
responds.)
regards,
/iaw
----
Ivo Welch ([email protected])
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 12:29 PM, Eric Paris <[email protected]> wrote:
> 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 ([email protected])
>> 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 <[email protected]> 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
>>
>>
>>
>>
>>
>
>
On Mon, 2014-12-29 at 13:06 +0800, ivo welch wrote:
> thank you, eric. will do. I read up on it above and now understand it better.
Great let us know if it keeps giving you trouble!
> the example in the man page seems somewhat misfortunate. I would use
> an example that does not, by default, lock up the user system.
> (perhaps add a second example with the _PERM feature that shows how it
> responds.)
The link you gave does respond and allow permissions:
if (metadata->fd >= 0) {
/* Handle open permission event */
if (metadata->mask & FAN_OPEN_PERM) {
printf("FAN_OPEN_PERM: ");
/* Allow file to be opened */
response.fd = metadata->fd;
response.response = FAN_ALLOW;
write(fd, &response,
sizeof(struct fanotify_response));
}
That's the key bit of the example... If you use gdb and never get to
there, you are in a bit of trouble, I agree!