public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Paris <eparis@redhat.com>
To: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: ivo.welch@gmail.com, linux-kernel@vger.kernel.org
Subject: Re: fanotify bug on gdb -- hard crash
Date: Sun, 28 Dec 2014 18:13:32 -0500	[thread overview]
Message-ID: <1419808412.5162.73.camel@localhost> (raw)
In-Reply-To: <549DAB95.3090003@gmx.de>

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



  reply	other threads:[~2014-12-28 23:13 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-26 14:45 fanotify bug on gdb -- hard crash ivo welch
2014-12-26 18:40 ` Heinrich Schuchardt
2014-12-28 23:13   ` Eric Paris [this message]
     [not found]     ` <CAPr7RtWQ6bt4M8f-2-w0nbLvgpupb0kckE=VQDYbC8EXwiPDJg@mail.gmail.com>
2014-12-29  4:29       ` Eric Paris
2014-12-29  5:06         ` ivo welch
2014-12-31  0:21           ` Eric Paris
2014-12-26 22:14 ` Pavel Machek
2014-12-26 23:48   ` ivo welch

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1419808412.5162.73.camel@localhost \
    --to=eparis@redhat.com \
    --cc=ivo.welch@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=xypron.glpk@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox