From: alex chen <alex.chen@huawei.com>
To: Ben Hutchings <ben.hutchings@codethink.co.uk>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
piaojun <piaojun@huawei.com>, Joseph Qi <jiangqi903@gmail.com>,
"stable@vger.kernel.org" <stable@vger.kernel.org>,
Changwei Ge <ge.changwei@h3c.com>,
Mark Fasheh <mfasheh@versity.com>,
Joel Becker <jlbec@evilplan.org>,
Junxiao Bi <junxiao.bi@oracle.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 4.4 13/16] ocfs2: should wait dio before inode lock in ocfs2_setattr()
Date: Fri, 8 Dec 2017 12:03:29 +0800 [thread overview]
Message-ID: <5A2A0F11.2090908@huawei.com> (raw)
In-Reply-To: <1512699985.18523.219.camel@codethink.co.uk>
On 2017/12/8 10:26, Ben Hutchings wrote:
> On Fri, 2017-12-08 at 08:39 +0800, alex chen wrote:
>>
>> On 2017/12/8 2:25, Ben Hutchings wrote:
>>> On Wed, 2017-12-06 at 09:02 +0800, alex chen wrote:
>>>> Hi Ben,
>>>>
>>>> Thanks for your reply.
>>>>
>>>> On 2017/12/5 23:49, Ben Hutchings wrote:
>>>>> On Wed, 2017-11-22 at 11:12 +0100, Greg Kroah-Hartman wrote:
>>>>>> 4.4-stable review patch. If anyone has any objections,
>>>>>> please let me know.
>>>>>>
>>>>>> ------------------
>>>>>>
>>>>>> From: alex chen <alex.chen@huawei.com>
>>>>>>
>>>>>> commit 28f5a8a7c033cbf3e32277f4cc9c6afd74f05300 upstream.
>>>>>>
>>>>>> we should wait dio requests to finish before inode lock in
>>>>>> ocfs2_setattr(), otherwise the following deadlock will
>>>>>> happen:
>>>>>
>>>>> [...]
>>>>>
>>>>> I looked at the kernel-doc for inode_dio_wait():
>>>>>
>>>>> /**
>>>>> * inode_dio_wait - wait for outstanding DIO requests to finish
>>>>> * @inode: inode to wait for
>>>>> *
>>>>> * Waits for all pending direct I/O requests to finish so that we can
>>>>> * proceed with a truncate or equivalent operation.
>>>>> *
>>>>> * Must be called under a lock that serializes taking new references
>>>>> * to i_dio_count, usually by inode->i_mutex.
>>>>> */
>>>>>
>>>>> Now that ocfs2_setattr() calls this outside of the inode locked region,
>>>>> what prevents another task adding a new dio request immediately
>>>>> afterward?
>>>>>
>>>>
>>>> In the kernel 4.6, firstly, we use the inode_lock() in do_truncate() to
>>>> prevent another bio to be issued from this node.
>>>
>>> [...]
>>>
>>> Yes but there seems to be a race condition - after the call to
>>> inode_dio_wait() and before the call to inode_lock(), another dio
>>> request can be added.
>
> Sorry, I've been mixing up inode_lock() and ocfs2_inode_lock().
> However:
>
>> In the truncating file situation, the lock order is as follow:
>> do_truncate()
>> inode_lock()
>> notify_change()
>> ocfs2_setattr()
>> inode_dio_wait()
>> --here it is under the protect of inode_lock(), so another dio requests
>> from another process will not be added.
>
> only DIO reads seem to take the inode lock.
>
I do not clearly understand what you mean.
The inode_lock() will be called in ocfs2_file_write_iter().
You mean only DIO writes seem to take the inode_lock()?
BTW, in this patch, I just adjusted the inode_dio_wait() to the front of the ocfs2_rw_lock()
and didn't adjust the order of inode_lock() and inode_dio_wait().
Thanks,
Alex
> Ben.
>
>> ocfs2_rw_lock()
>> ocfs2_inode_lock_tracker()
>> this function is used to prevent the inode from being modified by another
>> nodes in the cluster
>> inode_unlock()
>>
>>>
>>> Ben.
>>>
>>
>>
next prev parent reply other threads:[~2017-12-08 4:04 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-22 10:11 [PATCH 4.4 00/16] 4.4.101-stable review Greg Kroah-Hartman
2017-11-22 10:11 ` [PATCH 4.4 01/16] tcp: do not mangle skb->cb[] in tcp_make_synack() Greg Kroah-Hartman
2017-11-22 10:11 ` [PATCH 4.4 02/16] netfilter/ipvs: clear ipvs_property flag when SKB net namespace changed Greg Kroah-Hartman
2017-11-22 10:11 ` [PATCH 4.4 03/16] bonding: discard lowest hash bit for 802.3ad layer3+4 Greg Kroah-Hartman
2017-11-22 10:11 ` [PATCH 4.4 04/16] vlan: fix a use-after-free in vlan_device_event() Greg Kroah-Hartman
2017-11-22 10:11 ` [PATCH 4.4 05/16] af_netlink: ensure that NLMSG_DONE never fails in dumps Greg Kroah-Hartman
2017-11-22 10:11 ` [PATCH 4.4 06/16] sctp: do not peel off an assoc from one netns to another one Greg Kroah-Hartman
2017-11-22 10:12 ` [PATCH 4.4 07/16] fealnx: Fix building error on MIPS Greg Kroah-Hartman
2017-11-22 10:12 ` [PATCH 4.4 08/16] net/sctp: Always set scope_id in sctp_inet6_skb_msgname Greg Kroah-Hartman
2017-11-22 10:12 ` [PATCH 4.4 09/16] ima: do not update security.ima if appraisal status is not INTEGRITY_PASS Greg Kroah-Hartman
2017-11-22 10:12 ` [PATCH 4.4 10/16] serial: omap: Fix EFR write on RTS deassertion Greg Kroah-Hartman
2017-11-22 10:12 ` [PATCH 4.4 11/16] arm64: fix dump_instr when PAN and UAO are in use Greg Kroah-Hartman
2017-11-22 10:12 ` [PATCH 4.4 12/16] [PATCH-stable] nvme: Fix memory order on async queue deletion Greg Kroah-Hartman
2017-11-22 10:12 ` [PATCH 4.4 13/16] ocfs2: should wait dio before inode lock in ocfs2_setattr() Greg Kroah-Hartman
2017-12-05 15:49 ` Ben Hutchings
2017-12-06 1:02 ` alex chen
2017-12-06 16:36 ` Greg Kroah-Hartman
2017-12-07 18:25 ` Ben Hutchings
2017-12-08 0:39 ` alex chen
2017-12-08 2:26 ` Ben Hutchings
2017-12-08 4:03 ` alex chen [this message]
2017-12-08 5:36 ` Ben Hutchings
2017-12-08 6:16 ` alex chen
2017-12-08 10:04 ` Changwei Ge
2017-12-12 1:34 ` alex chen
2017-11-22 10:12 ` [PATCH 4.4 14/16] ipmi: fix unsigned long underflow Greg Kroah-Hartman
2017-11-22 10:12 ` [PATCH 4.4 15/16] mm/page_alloc.c: broken deferred calculation Greg Kroah-Hartman
2017-11-22 10:12 ` [PATCH 4.4 16/16] coda: fix kernel memory exposure attempt in fsync Greg Kroah-Hartman
2017-11-22 15:29 ` [PATCH 4.4 00/16] 4.4.101-stable review Nathan Chancellor
2017-11-22 17:05 ` Greg Kroah-Hartman
2017-11-22 17:38 ` Nathan Chancellor
2017-11-22 21:32 ` Guenter Roeck
2017-11-23 14:28 ` Naresh Kamboju
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=5A2A0F11.2090908@huawei.com \
--to=alex.chen@huawei.com \
--cc=akpm@linux-foundation.org \
--cc=ben.hutchings@codethink.co.uk \
--cc=ge.changwei@h3c.com \
--cc=gregkh@linuxfoundation.org \
--cc=jiangqi903@gmail.com \
--cc=jlbec@evilplan.org \
--cc=junxiao.bi@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mfasheh@versity.com \
--cc=piaojun@huawei.com \
--cc=stable@vger.kernel.org \
--cc=torvalds@linux-foundation.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;
as well as URLs for NNTP newsgroup(s).