On Thu, Mar 19, 2015 at 04:25:30PM -0700, Darrick J. Wong wrote: > On Fri, Mar 20, 2015 at 09:59:17AM +1100, Dave Chinner wrote: > > On Thu, Mar 19, 2015 at 02:02:50PM -0700, Darrick J. Wong wrote: > > > This seems possible if we read in the block, detach it from > > > whatever points to it, and then we want to allocate it to a > > > directory. The buffer's still in memory and it's still the > > > right size, so we don't free b_addr; the init function doesn't > > > overwrite the whole buffer, and now we've just leaked old disk > > > contents. Adding a memset to getbuf would fix this, but again > > > at a cost of unnecessary zeroing. > > > > Leaked the contents to whom? > > > > In the kernel we don't care about stale contents in metadata > > buffers as the contents cannot be directly read from userspace. > > i.e. there is no vector for information leakage (other than > > through the root user reading the bdev directly), so we don't > > need to zero buffers to prevent information leakage either in > > userspace or the kernel... > > Ok. It was a mostly theoretical worry -- a corrupt FS thinks a > data block contains metadata; repair frees the block but then > reallocates it to a dir or something, and then a second file gets > pointed to the dir block. Now the second file can read the old > file's contents, even after we supposedly reallocated it to > something else. We don't rebuild directories until we've already resolved all the used/free block references in the filesystem (phase 3/4) and then rebuilt the free space trees (phase 5). Hence by the end of phase 5 we do not have any doubly referenced blocks, nor do we have any dangling references in inodes to free space, and we have a fully correct free space index written to disk. We then rebuild directories (phase 6) using the corrected free space btrees if we need to allocate new blocks and hence we can't get doubly linked blocks in the manner you suggest unless we've broken repair rather badly... > OTOH it's probably hard to make that happen. *nod* Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
