Patchwork [Raring] pull-request: fsnotify: simplify locking

login
register
mail settings
Submitter Chris J Arges
Date Dec. 3, 2012, 10:04 p.m.
Message ID <50BD21D6.2030106@canonical.com>
Download mbox
Permalink /patch/203447/
State New
Headers show

Pull-request

git://kernel.ubuntu.com/arges/ubuntu-raring.git lp922906

Comments

Chris J Arges - Dec. 3, 2012, 10:04 p.m.
Hi,

I have taken a set of patches that have fixed bug 922906 [1]  and
applied them to raring. The original patches were found here [2]. I
re-tested with this code, and the test-case does not seem to fail for an
extended run.

A few notes:
* fanotify: add an extra flag to mark_remove_from_mask
* fsnotify: pass group to fsnotify_destroy_mark()
  These patches required minor modifications because line numbers
changed from the time these original patches were produced.

[1] http://bugs.launchpad.net/bugs/922906
[2] https://lkml.org/lkml/2011/1/19/213

--chris j arges

--

The following changes since commit ef2b90a5c8f24f3c9a0d3d0e46a6df7909c1160a:

  UBUNTU: Ubuntu-3.7.0-4.12 (2012-11-27 12:37:59 -0800)

are available in the git repository at:

  git://kernel.ubuntu.com/arges/ubuntu-raring.git lp922906

for you to fetch changes up to a86bafb9a8239392ac6d7ebf4028982834987cc0:

  UBUNTU: SAUCE: fsnotify: change locking order (2012-12-03 15:05:18 -0600)

----------------------------------------------------------------
Lino Sanfilippo (10):
      UBUNTU: SAUCE: inotify, fanotify: replace fsnotify_put_group()
with fsnotify_destroy_group()
      UBUNTU: SAUCE: fsnotify: introduce fsnotify_get_group()
      UBUNTU: SAUCE: fsnotify: use reference counting for groups
      UBUNTU: SAUCE: fsnotify: take groups mark_lock before mark lock
      UBUNTU: SAUCE: fanotify: add an extra flag to
mark_remove_from_mask that indicates wheather a mark should be destroyed
      UBUNTU: SAUCE: fsnotify: use a mutex instead of a spinlock to
protect a groups mark list
      UBUNTU: SAUCE: fsnotify: pass group to fsnotify_destroy_mark()
      UBUNTU: SAUCE: fsnotify: introduce locked versions of
fsnotify_add_mark() and fsnotify_remove_mark()
      UBUNTU: SAUCE: fsnotify: dont put marks on temporary list when
clearing marks by group
      UBUNTU: SAUCE: fsnotify: change locking order

 fs/notify/dnotify/dnotify.c          |    4 +-
 fs/notify/fanotify/fanotify_user.c   |   33 +++++++-----
 fs/notify/group.c                    |   40 +++++++--------
 fs/notify/inode_mark.c               |   14 ++++--
 fs/notify/inotify/inotify_fsnotify.c |    4 +-
 fs/notify/inotify/inotify_user.c     |   11 ++--
 fs/notify/mark.c                     |   91
+++++++++++++++++++---------------
 fs/notify/vfsmount_mark.c            |   14 ++++--
 include/linux/fsnotify_backend.h     |   26 ++++++----
 kernel/audit_tree.c                  |   10 ++--
 kernel/audit_watch.c                 |    4 +-
 11 files changed, 147 insertions(+), 104 deletions(-)
Tim Gardner - Dec. 4, 2012, 3:34 p.m.
Applied for now pending the results of some FS testing.

Do you plan to continue to push for upstream inclusion ? I doubt there 
is any way that these will make the 3.8 merge, but I'd sure like them 
upstream in time for 13.10.

rtg
Chris J Arges - Dec. 4, 2012, 11:16 p.m.
On 12/04/2012 09:34 AM, Tim Gardner wrote:
> Applied for now pending the results of some FS testing.
> 
Results of testing:

- Passes initial inotify_loop + mountscript tests that caused the
initial issue for a few hour run. (Running overnight now)

- Passes LTP inotify01,02,03 tests. I had to use backportpackage to
build them for raring.

- I did some basic performance tests running inotify01+inotify02 in a
loop for 1000 times and measuring the time with bash. Then running this
test 50 times and taking the average and standard deviation.
The result was it took 2.6055s on average with 0.1314 std deviation for
the patched kernel and 2.6794s on average with 0.1881 std deviation for
the non-patched kernel. I would think more testing would be necessary to
see how many iterations are necessary to get a lower standard deviation,
but overall it seems that this patchset does not introduce issues at
least testing with inotify01 and inotify02.

> Do you plan to continue to push for upstream inclusion ? I doubt there
> is any way that these will make the 3.8 merge, but I'd sure like them
> upstream in time for 13.10.
>

Yes I'll continue to push on this.
Thanks,
--chris j arges


> rtg