Project

General

Profile

Actions

Bug #2084

closed

nfs3_map() should call lm_safemap()

Added by Dan Kruchinin over 9 years ago. Updated over 9 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
nfs - NFS server and client
Start date:
2012-02-06
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage
Gerrit CR:

Description

I think that mmap() function of NFSv3 client contains a logical error closely related to nfs3_frlock() function.

According to the nfs3_frlock() code, it doesn't allowed to add a new lock on a file when the file is memory mapped.
The only exception is so-called "safe" locks. Safe lock is a lock that occupies the whole file from 0 to the very last byte (in contrast,
"unsafe" lock is a lock that occupies only some "chunk" of the file).
nfs3_frlock() explicitly checks whether it's "safe" to add new lock by calling lm_safelock(): http://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/fs/nfs/nfs3_vnops.c#5407

lm_safelock() returns FALSE if memory mappings are present and lock is not safe. So it's impossible to add new lock if a file is memory mapped. To close this issue, nfs3_map() should call lm_safemap() before adding an actual mapping.

On the other hand, nfs3_map() function misses such check: http://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/fs/nfs/nfs3_vnops.c#5205

So that it becomes possible to have a memory mapping and a bunch of "unsafe" locks at the same time if you add several "unsafe" locks to the file and then create a memory mapping using that file.

Actions #1

Updated by Dan Kruchinin over 9 years ago

  • Status changed from New to Closed

Sorry, the bug is irrelevant when closed source lock manager is used.

Actions

Also available in: Atom PDF