Re: What sort of inode state does ->evict_inode() expect to see? [was Re: 9p: fscache duplicate cookie]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 5/15/21 2:46 AM, Dominique Martinet wrote:
Hi Aneesh,

I'm going to rely on your memory here... A long, long time ago (2011!),
you've authored this commit:
-------
commit ed80fcfac2565fa866d93ba14f0e75de17a8223e
Author: Aneesh Kumar K.V <aneesh.kumar@xxxxxxxxxxxxxxxxxx>
Date:   Wed Jul 6 16:32:31 2011 +0530

     fs/9p: Always ask new inode in create
This make sure we don't end up reusing the unlinked inode object.
     The ideal way is to use inode i_generation. But i_generation is
     not available in userspace always.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@xxxxxxxxxxxxxxxxxx>
     Signed-off-by: Eric Van Hensbergen <ericvh@xxxxxxxxx>
-------

Do you happen to remember or know *why* you wanted to make sure we don't
reuse the unlinked inode object?



Sorry, I don't recall all the details, hence some of these details may not be correct. I did look at the archives to see if we have email discussions around the change. I found the below related email thread.

https://lore.kernel.org/lkml/1310402460-5098-1-git-send-email-aneesh.kumar@xxxxxxxxxxxxxxxxxx/


IIRC, this was to avoid picking up wrong inode from the hash? So a create is a new object and we want to actually avoid any comparison?
Hence pass a test function that always return false?

-aneesh



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux