public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Anand Jain <anand.jain@oracle.com>
To: dsterba@suse.cz, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 4/4] btrfs: sysfs, add devid/dev_state kobject and attribute
Date: Thu, 5 Dec 2019 22:38:15 +0800	[thread overview]
Message-ID: <78560abd-7d85-c95d-ed76-7810b1d03789@oracle.com> (raw)
In-Reply-To: <20191205142148.GQ2734@twin.jikos.cz>



On 12/5/19 10:21 PM, David Sterba wrote:
> On Thu, Dec 05, 2019 at 07:27:06PM +0800, Anand Jain wrote:
>> A new sysfs RW attribute
> 
> Why RW? Most attributes/files in sysfs are supposed to be read-only, but
> you actually define the attribute as read-only with the macro
> BTRFS_ATTR.
> 

  Oh. Change log has to be fixed here.

  But I am also working on a new patch to make this RW, to set the
  new read_preferred state on the device.

>>    UUID/devinfo/<devid>/dev_state
>> is added here. The dev_state here reflects the state of the device from
>> the kernel parameter btrfs_device::dev_state and this attribute is born
>> after the device is mounted and goes along with the dynamic nature of the
>> device add and delete. This attribute gets deleted at unmount.
>>
>> For example:
>> pwd
>>   /sys/fs/btrfs/6e1961f1-5918-4ecc-a22f-948897b409f7/devinfo
>> cat 1/dev_state
>>   IN_FS_METADATA MISSING
>> cat 2/dev_state
>>   WRITABLE IN_FS_METADATA
> 
> So the values copy the device state macros, that's probably ok.
> 
  Yep.

>> +static ssize_t btrfs_sysfs_dev_state_show(struct kobject *kobj,
>> +					  struct kobj_attribute *a, char *buf)
>> +{
>> +	struct btrfs_device *device = container_of(kobj, struct btrfs_device,
>> +						   devid_kobj);
>> +
>> +	btrfs_dev_state_to_str(device, buf, PAGE_SIZE);
> 
> The device access is unprotected, you need at least RCU but that still
> does not prevent from the device being freed by deletion.

  We need RCU let me fix. Device being deleted is fine, there
  is nothing to lose, another directory lookup will show that
  UUID/devinfo/<devid> is gone is the device is deleted.

> The
> device_list_mutex is quite heavy and allowing a DoS by repeatedly
> reading the file contents is not something we want to allow.
> 

   Yes we don't have to use device_list_mutex here, as its read,
   a refresh/re-read will refresh the dev_state.

Thanks, Anand



  reply	other threads:[~2019-12-05 14:39 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-05 11:27 [PATCH 0/4] btrfs, sysfs cleanup and add dev_state Anand Jain
2019-12-05 11:27 ` [PATCH 1/4] btrfs: sysfs, use btrfs_sysfs_remove_fsid in fail return in add_fsid Anand Jain
2019-12-05 11:27 ` [PATCH 2/4] btrfs: sysfs, add UUID/devinfo kobject Anand Jain
2020-01-14 18:32   ` David Sterba
2020-02-03 10:40     ` Anand Jain
2019-12-05 11:27 ` [PATCH v2 3/4] btrfs: sysfs, rename device_link add,remove functions Anand Jain
2019-12-05 11:27 ` [PATCH 4/4] btrfs: sysfs, add devid/dev_state kobject and attribute Anand Jain
2019-12-05 14:10   ` David Sterba
2019-12-05 14:38     ` Anand Jain
2019-12-05 14:21   ` David Sterba
2019-12-05 14:38     ` Anand Jain [this message]
2019-12-05 15:14       ` David Sterba
2019-12-06 13:49         ` Anand Jain
2019-12-09 14:05           ` Anand Jain
2019-12-09 18:31             ` David Sterba
2019-12-13 16:43             ` David Sterba
2019-12-13 17:02               ` David Sterba
2019-12-14  0:26                 ` Anand Jain
2020-01-06 16:00                   ` David Sterba
2019-12-09 14:06   ` [PATCH v2 " Anand Jain
2019-12-19 10:41     ` [PATCH v3 " Anand Jain
2020-01-06 11:38   ` [PATCH v4] " Anand Jain
2020-01-09 15:20     ` [PATCH v4 4/4] " David Sterba
2020-01-10  1:03       ` Anand Jain
2019-12-05 15:00 ` [PATCH 0/4] btrfs, sysfs cleanup and add dev_state David Sterba
2019-12-06 13:46   ` Anand Jain
2019-12-09 14:09     ` Anand Jain
2019-12-09 22:48 ` Anand Jain
2019-12-10 16:41   ` David Sterba
2020-01-14 18:39 ` David Sterba
2020-01-15  8:22   ` [PATCH] btrfs: update devid after replace Anand Jain
2020-01-15 16:17     ` David Sterba
2020-01-20 19:10     ` David Sterba

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=78560abd-7d85-c95d-ed76-7810b1d03789@oracle.com \
    --to=anand.jain@oracle.com \
    --cc=dsterba@suse.cz \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox