Eric Sandeen wrote: > This is w.r.t. https://bugzilla.redhat.com/show_bug.cgi?id=452333 > > Dave had a few stale entries in blkid.tab; label from a usb key showed > up under several non-existent, stale device names. fstab had LABEL=, > mounting by label failed because blkid returned a stale, nonexistent device. Ted, ping (when you're done kernel-wrangling anyway)? Any thoughts on this? Returning cached data for a device when stat says ENOENT seems very weird (and wrong). Thanks, -Eric > It seems there's a problem in blkid_verify(): > > if (((probe.fd = open(dev->bid_name, O_RDONLY)) < 0) || > (fstat(probe.fd, &st) < 0)) { > if (probe.fd >= 0) close(probe.fd); > if ((errno != EPERM) && (errno != EACCES) && > (errno != ENOENT)) { > DBG(DEBUG_PROBE, > printf("blkid_verify: error %s (%d) while " > "opening %s\n", strerror(errno), errno, > dev->bid_name)); > blkid_free_dev(dev); > return NULL; > } > /* We don't have read permission, just return cache data. */ > DBG(DEBUG_PROBE, > printf("returning unverified data for %s\n", > dev->bid_name)); > return dev; > > We find the bad/stale device in the cache, and stat it - if the device > doesn't exist, we get ENOENT. But we return the stale data for the > nonexistent device anyway. Eh? > > http://git.kernel.org/?p=fs/ext2/e2fsprogs.git;a=commitdiff;h=8bcaaabb1a023af4852dbf0dba76249982c62e40 > > did this: > > When a nonprivileged user uses the blkid command, we want to keep the > cached filesystem information, and opening a device file could result > in an EACCESS or ENOENT (if an intervening directory is mode 700). We > were previously testing for EPERM, which was really the wrong error > code to be testing against. > > But do we really want to do this in the case of ENOENT? It seems like > this is going to grow a crop of missing devices in the cache, no? > > Thanks, > > -Eric > -- > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
