lkml.org 
[lkml]   [2020]   [Dec]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v2 0/6] kernfs: proposed locking and concurrency improvement
    Hello,

    On Thu, Dec 17, 2020 at 07:48:49PM +0800, Ian Kent wrote:
    > > What could be done is to make the kernfs node attr_mutex
    > > a pointer and dynamically allocate it but even that is too
    > > costly a size addition to the kernfs node structure as
    > > Tejun has said.
    >
    > I guess the question to ask is, is there really a need to
    > call kernfs_refresh_inode() from functions that are usually
    > reading/checking functions.
    >
    > Would it be sufficient to refresh the inode in the write/set
    > operations in (if there's any) places where things like
    > setattr_copy() is not already called?
    >
    > Perhaps GKH or Tejun could comment on this?

    My memory is a bit hazy but invalidations on reads is how sysfs namespace is
    implemented, so I don't think there's an easy around that. The only thing I
    can think of is embedding the lock into attrs and doing xchg dance when
    attaching it.

    Thanks.

    --
    tejun

    \
     
     \ /
      Last update: 2020-12-17 16:17    [W:3.469 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site