In commit 177f8fc491e230c2e7a3ac7d5626dd6f3d94e9f2 (orangefs: sanitize ->llseek()), Al Viro removed a call to make_bad_inode in llseek. I had put that in on the theory that if our getattr returns ESTALE, the inode is bad and shouldn't be relied upon (and will be caught on the next revalidate). But I wasn't sure make_bad_inode was right then, and I'm really doubting it now. And orangefs_inode_getattr would call make_bad_inode anyway, so it could still be called from lseek. So how should we handle this case? Other callers will detect the stale inode in the same way, so is what we have now sufficient minus calling make_bad_inode in orangefs_inode_getattr? -- Martin -- 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
