On 12/5/16 3:33 PM, Brian Foster wrote:
> On Mon, Dec 05, 2016 at 02:31:32PM -0600, Eric Sandeen wrote:
>> On 12/1/16 6:15 AM, Brian Foster wrote:
>>> On Wed, Nov 30, 2016 at 04:33:15PM -0600, Eric Sandeen wrote:
>>>> When we create a new attribute, we first create a shortform
>>>> attribute, and try to fit the new attribute into it.
>>>> If that fails, we copy the (empty) attribute into a leaf attribute,
>>>> and do the copy again. Thus there can be a transient state where
>>>> we have an empty leaf attribute.
>>>>
>>>> If we encounter this during log replay, the verifier will fail.
>>>> So add a test to ignore this part of the leaf attr verification
>>>> during log replay.
>>>>
>>>> Thanks as usual to dchinner for spotting the problem.
>>>>
>>>> Signed-off-by: Eric Sandeen <sandeen@xxxxxxxxxx>
>>>> ---
>>>>
>>>> diff --git a/fs/xfs/libxfs/xfs_attr_leaf.c b/fs/xfs/libxfs/xfs_attr_leaf.c
>>>> index 8ea91f3..2852521 100644
>>>> --- a/fs/xfs/libxfs/xfs_attr_leaf.c
>>>> +++ b/fs/xfs/libxfs/xfs_attr_leaf.c
>>>> @@ -253,6 +253,7 @@ STATIC void xfs_attr3_leaf_moveents(struct xfs_da_args *args,
>>>> {
>>>> struct xfs_mount *mp = bp->b_target->bt_mount;
>>>> struct xfs_attr_leafblock *leaf = bp->b_addr;
>>>> + struct xfs_perag *pag = bp->b_pag;
>>>> struct xfs_attr3_icleaf_hdr ichdr;
>>>>
>>>> xfs_attr3_leaf_hdr_from_disk(mp->m_attr_geo, &ichdr, leaf);
>>>> @@ -273,7 +274,12 @@ STATIC void xfs_attr3_leaf_moveents(struct xfs_da_args *args,
>>>> if (ichdr.magic != XFS_ATTR_LEAF_MAGIC)
>>>> return false;
>>>> }
>>>> - if (ichdr.count == 0)
>>>> + /*
>>>> + * In recovery there is a transient state where count == 0 is valid
>>>> + * because we may have transitioned an empty shortform attr to a leaf
>>>> + * if the attr didn't fit in shortform.
>>>> + */
>>>> + if (pag && pag->pagf_init && ichdr.count == 0)
>>>> return false;
>>>
>>> Seems fine, but if the idea is to filter out failures during log
>>> recovery, can we detect that state explicitly? E.g., check for some
>>> combination of XLOG_ACTIVE_RECOVERY and/or XLOG_RECOVERY_NEEDED (or just
>>> define and use a new flag/helper if necessary)?
>>
>> Yeah, this is done in several other places; see xfs_allocbt_verify,
>> xfs_refcountbt_verify, xfs_rmapbt_verify and the comments in those.
>>
>
> Ok, but that doesn't necessarily look like the same thing. Those places
> check for perag initialization because they check against values in the
> perag data structure. Here we are just using the state to imply that log
> recovery hasn't occurred yet.
Yep :D
> What happens if for some unknown future reason we need an initialized
> perag during/before log recovery and so decide to initialize it earlier
> and invalidate it post-recovery (for e.g.) to deal with potential
> inconsistencies? AFAICT the existing verifier logic should generally
> work as expected, but this can become a landmine.
>
> Granted, that isn't the case right now, it may never be, and you have an
> r-b. So I guess it just depends on whether you reach my level of
> paranoia. :)
Oh, yeah, I raised an eyebrow for me too. But there was a precedent, and
I followed it. ;)
-Eric
> Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
