lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sat, 07 Sep 2013 18:14:56 +0200 From: Marco Stornelli <marco.stornelli@...il.com> To: Al Viro <viro@...IV.linux.org.uk> CC: Linux FS Devel <linux-fsdevel@...r.kernel.org>, linux-kernel@...r.kernel.org, Vladimir Davydov <vdavydov@...allels.com> Subject: Re: [PATCH 08/19] pramfs: file operations for dirs Il 07/09/2013 17:01, Al Viro ha scritto: > On Sat, Sep 07, 2013 at 10:22:36AM +0200, Marco Stornelli wrote: >> +int pram_add_link(struct dentry *dentry, struct inode *inode) >> +{ >> + struct inode *dir = dentry->d_parent->d_inode; >> + struct pram_inode *pidir, *pi, *pitail = NULL; >> + u64 tail_ino, prev_ino; >> + >> + const char *name = dentry->d_name.name; >> + >> + int namelen = min_t(unsigned int, dentry->d_name.len, PRAM_NAME_LEN); > > Whatever the hell for? Your ->lookup() rejects dentries with names longer > than PRAM_NAME_LEN with an error, so they won't reach this function at all. > Ok. I'll remove it. >> +int pram_remove_link(struct inode *inode) > > Umm... That's called on rename (for old one) *and* inode eviction when link > count goes to zero. What's the point of keeping unlinked ones (unlink/rmdir/ > rename victims) on those lists? Sure, you skip them on lookups, but why > delay link removal until eviction? You pay for that with extra locking, > BTW - if not for that, you wouldn't need your i_link_mutex at all. > Good question. The only answer I've got now is for "historical" reason, I can't see at the moment why we can remove the link information in case of opened-but-unlinked, instead of delay the operation until evict. >> + pi = pram_get_inode(sb, inode->i_ino); >> + >> + switch ((u32)file->f_pos) { >> + case 0: >> + ret = dir_emit_dot(file, ctx); >> + ctx->pos = 1; >> + return ret; > > Really? So on the first call of ->iterate() you just generate one > entry and don't even try to produce more? And it looks like the > rest is no nicer... > I'll try to improve the behavior here. Marco -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists