lkml.org 
[lkml]   [2000]   [Jul]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Strange chmod behavior on 2.2.16 with write_inode()


Alexander Viro wrote:
>
> On Wed, 26 Jul 2000, Jeff V. Merkey wrote:
>
> >
> > More on this problem -- here's someting weird. If I wait a few seconds
> > after typing 'chmod 444 *' on a directory of files, then I start seeing
> > write_inode() come through the vfs, however, if I do an 'ls -l' on the
> > directory immediately after I issue a chmod command, then the
> > write_inode() never seems to happen. It looks like write_inode() is
> > getting called by some sort of delayed process (who writes dirty inodes
> > back to disk). The changes don't show up changed right away after a
> > chmod call either.
> >
> > I think I'll just implement notify_change() since the vfs.txt
> > information about relying on notify_change() to default to write_inode()
> > is obviously incorrect -- there's a hole somewhere where the inode
> > permissions can get lost.
>
> Do you, by chance, do something with inodes in readdir()? I suspect that
> it should be the right place to look. Looks like you are losing the dirty
> bit on inode before it gets written...

No. I don't believe I do. Al, the codes at 207.109.151.240 -- DIR.C
has readdir() and the dentry stuff. I might be doing something else
flaky though.

>
> Eh, wait. Where does your filesystem keep inode metadata? I think I know
> one of the possible reasons, but I'ld like to hear the answer first...

The only inode meta-data I use is the inode->u.generic_ip pointer to
hold the hash head for the fat chain header/semaphore. This structure
gets assigned to the inode on read_inode() calls and zeroed when the
put_inode() gets called.

Jeff

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:1.796 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site