Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8145981

(fs) LinuxWatchService can reports events against wrong directory

    Details

    • Subcomponent:
    • Resolved In Build:
      b100
    • CPU:
      x86
    • OS:
      linux
    • Verification:
      Verified

      Backports

        Description

        FULL PRODUCT VERSION :
        java version "1.8.0_20"
        Java(TM) SE Runtime Environment (build 1.8.0_20-b26)
        Java HotSpot(TM) 64-Bit Server VM (build 25.20-b23, mixed mode)


        ADDITIONAL OS VERSION INFORMATION :
        Linux 2.6.32-358.23.2.el6.x86_64 #1 SMP Sat Sep 14 05:32:37 EDT 2013 x86_64 x86_64 x86_64 GNU/Linux

        A DESCRIPTION OF THE PROBLEM :
        In LinuxWatchService$Poller.run(), you read from the inotify file descriptor into an unmanaged buffer called "address". If there is data available on socketpair[0] you then read from that file descriptor *into the same buffer*.

        This means that in the case where both the inotify FD and the socketpair[0] FD have data available, you end up corrupting at least 1 byte of the inotify event stream with data from socketpair[0] (which is basically just junk data).

        In the most common case, this corruption just corrupts 1 byte of data, so the LSB of the first watch descriptor in the event stream will be changed. This causes the WatchService to report inotify events against the wrong Path -- e.g. if you have subscribed to directories A and B, and then touch file A/C, you'll actually see a WatchEvent for the path B/C.

        As far as I can tell this bug has been present since at least 2011.


        REPRODUCIBILITY :
        This bug can be reproduced occasionally.

        CUSTOMER SUBMITTED WORKAROUND :
        Reimplement the WatchService using JNA :-)

        1. Repro.java
          2 kB
          Pallavi Sonal
        2. wakeup.patch
          2 kB
          Alan Bateman

          Activity

          Hide
          shade Aleksey Shipilev added a comment - - edited
          I think the author posted this as the follow up: http://blog.omega-prime.co.uk/?p=161
          Which makes me wonder if there is a communication breakdown somewhere?
          Show
          shade Aleksey Shipilev added a comment - - edited I think the author posted this as the follow up: http://blog.omega-prime.co.uk/?p=161 Which makes me wonder if there is a communication breakdown somewhere?
          Hide
          alanb Alan Bateman added a comment - - edited
          I have attached an initial patch for this, it is an oversight in the original implementation. Basically the checking for wakeup events is moved to after the processing of events. An alternative would be a small buffer to read wakeup events but it's not really needed.
          Show
          alanb Alan Bateman added a comment - - edited I have attached an initial patch for this, it is an oversight in the original implementation. Basically the checking for wakeup events is moved to after the processing of events. An alternative would be a small buffer to read wakeup events but it's not really needed.
          Hide
          hgupdate HG Updates added a comment -
          URL: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f9919c0e0a18
          User: alanb
          Date: 2015-12-31 07:45:10 +0000
          Show
          hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f9919c0e0a18 User: alanb Date: 2015-12-31 07:45:10 +0000
          Hide
          hgupdate HG Updates added a comment -
          URL: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f9919c0e0a18
          User: lana
          Date: 2016-01-06 20:14:31 +0000
          Show
          hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f9919c0e0a18 User: lana Date: 2016-01-06 20:14:31 +0000

            People

            • Assignee:
              sebastian Sebastian Sickelmann
              Reporter:
              webbuggrp Webbug Group
            • Votes:
              0 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: