snv_28 contains a fix for bug 6341645: "global variable ('b') name clashes with
hex
digit on x86 mdb -k".
The source file usr/src/common/fs/ufsops.c was changed to move
two global variables (variables |b| and |blknos|) into the function
sbmap(). Complete diff for the change is this:
http://cvs.opensolaris.org/source/diff/on/usr/src/common/fs/ufsops.c?r2=1.3&r1=1.2
Note that the global variable |b|, defined as "union { ... } b", had a static
attribute,
while global |blknos| had *no* static attribute. The static / non-static
attributes
for |b| and |blknos| are still in use, now that both variables have been moved
into the sbmap() function.
Looking at the code in sbmap(), isn't there now an access to an uninitialized
local array element, at line 270? That doesn't look correct.
213 static daddr32_t
214 sbmap(fileid_t *filep, daddr32_t bn)
215 {
...
222 /* These are the pools of buffers, etc. */
223 /* Compilers like to play with alignment, so force the issue
here */
224 static union {
225 char *blk[NIADDR + 1];
226 daddr32_t *dummy;
227 } b;
228 daddr32_t blknos[NIADDR + 1];
...
266 /*
267 * fetch through the indirect blocks
268 */
269 for (; j <= NIADDR; j++) {
270 if (blknos[j] != nb) {
To get back the original behaviour (that existed before fix 6341645
was applied), the local variable |blknos| should/must be declared with
attribute static.
I'm not sure what breaks due to this bug; I assume there could be
- kernel panics when reading from big files using ufs indirect blocks
(uninitialized b.blk[] pointers are referenced)
- maybe performance problems when reading huge ufs files, because
the indirect block cache in sbmap does not work as expected.
Btw.: what happens when there are
- two ufs filesystems (ufs1, ufs2)
- both ufs filesystem contain an inode with indirect block (ino1 in ufs1,
ino2 in ufs2)
- the block number for an indirect block for ufs1/ino1 and ufs2/ino2 happens
to be the same for the two inodes (bn1 == bn2 == bn)
(but since they are located in different ufs filesystem, the indirect block
data
could point to different block numbers)
and we're reading first from ino1: blknos[x] is set to bn1, b.blk[x] points to
ino1's indirect block data;
and now we're trying to read from ino2. blknos[x] would already contain the
correct
block number bn2 for ino2's indirect data block, and we would end up using
ino1's cached indirect block map data when reading ino2 data!
Did I miss something? Shouldn't the key for the indirect block cache in sbmap()
include a reference to the ufs filesystem, in addition to the block number?
This message posted from opensolaris.org
_______________________________________________
ufs-discuss mailing list
[email protected]
