From: Bart Van Assche <bvanassche@acm.org>
To: Weiping Zhang <zwp10758@gmail.com>
Cc: Weiping Zhang <zhangweiping@didiglobal.com>,
Jens Axboe <axboe@kernel.dk>,
hch@infradead.org, linux-block@vger.kernel.org
Subject: Re: [PATCH v2] block: don't show io_timeout if driver has no timeout handler
Date: Wed, 03 Apr 2019 09:49:57 -0700 [thread overview]
Message-ID: <1554310197.118779.225.camel@acm.org> (raw)
In-Reply-To: <CAA70yB65t+yCcysDUvYCdcpto1BUio0a1woXkzVL7=efJ5FtJw@mail.gmail.com>
On Wed, 2019-04-03 at 18:48 +0800, Weiping Zhang wrote:
> Could you point out the race case for udev?
Hi Weiping,
A quote from Documentation/kobject.txt:
"Use the KOBJ_ADD action for when the kobject is first added to the kernel.
This should be done only after any attributes or children of the kobject
have been initialized properly, as userspace will instantly start to look
for them when this call happens."
You may want to have a look at commit 33b14f67a4e1 ("nvme: register ns_id
attributes as default sysfs groups") as an example of a patch that fixes a
race condition between sysfs attribute creation and udev.
Regarding the block layer timeout attribute: I just noticed that for the
request queue kobj attribute KOBJ_ADD is triggered explicitly from
blk_register_queue():
kobject_uevent(&q->kobj, KOBJ_ADD);
Your patch adds sysfs attributes before that code is encountered so it should
be fine.
Bart.
next prev parent reply other threads:[~2019-04-03 16:50 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-02 13:14 [PATCH v2] block: don't show io_timeout if driver has no timeout handler Weiping Zhang
2019-04-02 15:05 ` Bart Van Assche
2019-04-03 10:48 ` Weiping Zhang
2019-04-03 16:49 ` Bart Van Assche [this message]
2019-04-03 16:54 ` Bart Van Assche
2019-04-22 14:35 ` Weiping Zhang
2019-04-22 14:37 ` Jens Axboe
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=1554310197.118779.225.camel@acm.org \
--to=bvanassche@acm.org \
--cc=axboe@kernel.dk \
--cc=hch@infradead.org \
--cc=linux-block@vger.kernel.org \
--cc=zhangweiping@didiglobal.com \
--cc=zwp10758@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.