[lustre-devel] [PATCH 05/18] lustre: llite: fast read implementation

[Patrick Farrell]

They do.  It’s probably gone unnoticed because those updates are mostly directly triggered by users or one time only during initialization, so there’s little risk of colliding.

________________________________
From: lustre-devel <lustre-devel-bounces at lists.lustre.org> on behalf of NeilBrown <neilb at suse.com>
Sent: Monday, July 2, 2018 11:10:54 PM
To: James Simmons; Andreas Dilger; Oleg Drokin
Cc: Lustre Development List
Subject: Re: [lustre-devel] [PATCH 05/18] lustre: llite: fast read implementation

On Mon, Jul 02 2018, James Simmons wrote:

> +static ssize_t fast_read_store(struct kobject *kobj,
> +                            struct attribute *attr,
> +                            const char *buffer,
> +                            size_t count)
> +{
> +     struct ll_sb_info *sbi = container_of(kobj, struct ll_sb_info,
> +                                           ll_kobj);
> +     bool val;
> +     int rc;
> +
> +     rc = kstrtobool(buffer, &val);
> +     if (rc)
> +             return rc;
> +
> +     spin_lock(&sbi->ll_lock);
> +     if (val)
> +             sbi->ll_flags |= LL_SBI_FAST_READ;
> +     else
> +             sbi->ll_flags &= ~LL_SBI_FAST_READ;
> +     spin_unlock(&sbi->ll_lock);

This is a little odd... no other code uses ll_lock to protect updates to
ll_flags.  Various other places (e.g. checksum_pages_store()) updates it
unprotected.

Maybe there all need to use ll_lock for protection.


Thanks,
NeilBrown
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-devel-lustre.org/attachments/20180703/4a1bdce9/attachment.html>