• T
    ext4: Avoid races caused by on-line resizing and SMP memory reordering · 8df9675f
    Theodore Ts'o 提交于
    Ext4's on-line resizing adds a new block group and then, only at the
    last step adjusts s_groups_count.  However, it's possible on SMP
    systems that another CPU could see the updated the s_group_count and
    not see the newly initialized data structures for the just-added block
    group.  For this reason, it's important to insert a SMP read barrier
    after reading s_groups_count and before reading any (for example) the
    new block group descriptors allowed by the increased value of
    s_groups_count.
    
    Unfortunately, we rather blatently violate this locking protocol
    documented in fs/ext4/resize.c.  Fortunately, (1) on-line resizes
    happen relatively rarely, and (2) it seems rare that the filesystem
    code will immediately try to use just-added block group before any
    memory ordering issues resolve themselves.  So apparently problems
    here are relatively hard to hit, since ext3 has been vulnerable to the
    same issue for years with no one apparently complaining.
    Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
    8df9675f
ext4.h 48.2 KB