I'd been looking through ->readlink() callers, and there are several areas where behaviour looks wrong. 1) atime updates, according to POSIX, should happen in case of success. For example, giving readlink(2) an unmapped buffer should _not_ touch atime. Neither should calling readlink(2) in case if ->readlink() method returns e.g. -EIO or -ENOMEM. We do atime update in those cases. Looks like a bug and unless there's a good reason to keep that behaviour, I'd rather have it do what POSIX says. The question of which ->readlink() callers should bother with atime is interesting as well: * readlink(2) and nfsd_readlink() are touching atime of the symlink in question. Fair enough. * ecryptfs_readlink_lower() calls ->readlink() on the underlying filesystem inode and does *not* do anything to atime there. Also makes sense - one of the callers (->getattr()) certainly does not want timestamps modified, the other two will have atime of ecryptfs symlink touched, which will propagate to underlying fs. * overlayfs copyup does not touch atime of the underlying object. Also fine - the whole reason we are doing the copyup is that the layer it was in is not to be modified in any way. * overlayfs ->readlink(), OTOH, *does* attempt to touch atime of the symlink we end up reading. Looks bogus, especially since symlink _traversal_ does no such thing. Am I missing something subtle here? Miklos? 2) LSM, with its usual stellar consistency, has a hook stuck into readlink(2), but not into nfsd_readlink(). Could the esteemed Linux S&M folks decide if that's right? 3) normally, readlink(2) fails for non-symlinks. Moreover, according to POSIX it should do so (with -EINVAL). There is a pathological case when it succeeds for a directory, though. Namely, one of the kinds of AFS "mountpoints". stat(2) reports those as directories, stepping into them leads to automounting a directory there (why do we have ->open() for them, BTW?) How the hell is userland supposed to guess to call readlink(2) on those suckers to get the information of what'll get automounted there if we step upon them? And could we please get rid of that kludge? David? -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
