Project

General

Profile

Bug #6015

vnode: v_path reading should be protected by v_lock

Added by Marcel Telka about 4 years ago. Updated about 2 years ago.

Status:
In Progress
Priority:
Normal
Assignee:
Category:
kernel
Start date:
2015-06-19
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage

Description

The vnode's v_path is stable only in a case the v_lock is held. The nice example of that is in the vn_copypath() function implementation. Unfortunately, some v_path readers does not hold the v_lock when they work with v_path, so they are in danger that the v_path might get freed and/or replaced under their hands.

Examples

From nfs4_srv_ns.c

181    vpathlen = vp->v_path ? strlen(vp->v_path) : 0;
182    kex->ex_pathlen = vpathlen + strlen(PSEUDOFS_SUFFIX);
183    kex->ex_path = kmem_alloc(kex->ex_pathlen + 1, KM_SLEEP);
184
185    if (vpathlen)
186        (void) strcpy(kex->ex_path, vp->v_path);

From tmp_vnops.c:

236
237                    zcmn_err(GLOBAL_ZONEID,
238                        CE_WARN, "%s: File system full, " 
239                        "swap space limit exceeded",
240                        vfs->vfs_vnodecovered->v_path);

Related issues

Related to illumos gate - Bug #8376: cached v_path should be kept freshClosed2017-06-12

Actions

History

#1

Updated by Marcel Telka over 2 years ago

  • Status changed from New to In Progress
  • Assignee set to Marcel Telka
#2

Updated by Marcel Telka over 2 years ago

  • Related to Bug #8376: cached v_path should be kept fresh added
#4

Updated by Andrew Stormont about 2 years ago

What testing has been done?

#5

Updated by Marcel Telka about 2 years ago

Andrew Stormont wrote:

What testing has been done?

Please see the reviewboard.

Also available in: Atom PDF