Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <2d394dbd-484b-ad9b-b432-51b342ac6fb5@oracle.com>
Date:   Thu, 10 Feb 2022 11:56:24 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
 Gecko/20100101 Thunderbird/91.5.1
Subject: Re: [PATCH RFC v12 1/3] fs/lock: add new callback, lm_lock_conflict,
 to lock_manager_operations
Content-Language: en-US
To:     Chuck Lever III <chuck.lever@oracle.com>
Cc:     Jeff Layton <jlayton@redhat.com>,
        Bruce Fields <bfields@fieldses.org>,
        Al Viro <viro@zeniv.linux.org.uk>,
        Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
        "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
References: <1644468729-30383-1-git-send-email-dai.ngo@oracle.com>
 <1644468729-30383-2-git-send-email-dai.ngo@oracle.com>
 <20220210142143.GC21434@fieldses.org>
 <c069bb1b0ec50358fc4d093ebd7482c7484d77b4.camel@redhat.com>
 <47535edd-9761-f729-1d6b-f474a31eeafc@oracle.com>
 <E7CBF516-9DE5-4AC6-AFB1-148188C74699@oracle.com>
From:   dai.ngo@oracle.com
In-Reply-To: <E7CBF516-9DE5-4AC6-AFB1-148188C74699@oracle.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?elFzZkM5SU9nUUplbzFNYldTYVBuNTJwWitiR1BkR2lWNTNNK21lVmpKM1hw?=
 =?utf-8?B?ZVhPRWhRbU9EcjZvWjliKzI0ejRqbGwvMVUxNnhsTTFOTWlPRU9NZ1FGbVdQ?=
 =?utf-8?B?Um1lY3RFY1BKN0pQSk1aaDNYam05TmRITmJNVkUwQ1R2akVIM0NjQWxSNlph?=
 =?utf-8?B?RkRVc0RodlVncy9CRWx1a3I4T2FmSnozWFpCaEkzL0huREppS0dHcFZ0VW1l?=
 =?utf-8?B?SjNaVkJxY2FOa09OUWpsTzF0RmpxZ3ZZMC8rdjJDMm1jUitnQ29nUnNoS3V3?=
 =?utf-8?B?VVVGM0ZkMkV1MUZUWXdQMDVVZ2hYYkh0VlQ0OVJjVXMvc1RLMVJURmVGOGpq?=
 =?utf-8?B?OGRlbXNCUlJQV2ZBUElQMkRXd214RE5vNXZuY2ZMU2pPRTJ3OWhzSWxGbFlN?=
 =?utf-8?B?dDZNNjJaNE5LUVRkSVFzVzlPVnowNnZ6Nys5SWlLdlhVdGhVZFJaSGhJMjQ2?=
 =?utf-8?B?OGhGclZqb0k5MkRuSWx1UU1rU1BDWlR4OUZzN1FySHNsMGUrZ3FDSGh2elYr?=
 =?utf-8?B?UzM0Q2E5Z28wWCthVXR1WThPbzBPTEYzaEk0NWYyQyt2VGVjTlhPYk9maW1i?=
 =?utf-8?B?SmYzQmF3QVYyL2F6dWxGWGl5RlN4bUd4Ni9xb2YvNDY0VFBzY3cweWJJUm1F?=
 =?utf-8?B?QnpDb0dFcWR4bXlaWDgwNGo3OTNlaHFwZUVqQ0tyajBqZ1d6d0RnVmM3Uzg4?=
 =?utf-8?B?MlVQTmVxS0JyUXFTT0RKSVQ0RGJaWnBFMGZ0N1djNWNtUlErNi9qY0V1a3dV?=
 =?utf-8?B?YzdtYzllT08wUUpVUlJaM0t5em01Z2VHaC92eWJVSjNCamM1R0ZTeGN1ZXR0?=
 =?utf-8?B?WDU1eXhIUit0Ymk2WFhGMnJiUjdxZEQ0WDExd2dHVHF5RGsvRk1SRlJJL3BD?=
 =?utf-8?B?cXkzYk5jVkl4NjEvRHJDMHpBY1Bob0x4OVZ2R25hWFBqVFNibFdobXFLR0cw?=
 =?utf-8?B?V01xaldWUTVIRlpVM015ckc0OUhoSjZvYmZyU1RvMG03NlBxQ2daV29RdldM?=
 =?utf-8?B?V0JoRXVRVjZmeG1Hd3ArdG5ZSzRSK3dpSDdMUUZSc3lQM09RL1Q3NDZhaU9h?=
 =?utf-8?B?Nmp3NEozYU45emJNTjFRNkM5YWs0ZG4yK2l3bTNjaTZGeXFUSW1LUTR2N3JV?=
 =?utf-8?B?VEVBK05FYklmd2ZISzU0eWpXSXFvMzZsM1VxUmcwVThweTFrRkRiWEprRkw2?=
 =?utf-8?B?NHlsQ3JiTlZLU1ovWnpLQzBtSkplTWJSaFg5bE5PTGhDeVZvL29JaXdyeFhY?=
 =?utf-8?B?RTgwancwN2xmWFQraUNmbGx0M0Vpb3VOK3ZRdXpJOS8wRE1qNjE3Nnl3UUdD?=
 =?utf-8?B?aGQwRVBJbUcwcmpacUpkT2szTXJvNFVUNklncSttYzkwelYwQzBsT0xUVDVi?=
 =?utf-8?B?YjB4UXRkZWZsV0V3SE1nbG9uRVZ4QWx0cHhIbE0ya2oxbm9GcGViZ2pXZDNn?=
 =?utf-8?B?YjBqRFhldHF5L1ZmN0xqeFF0WUJ0Tjd5ZXlNS0g3U2JlSVEyM0xzWTQxOVdt?=
 =?utf-8?B?dmwrbmw1WW5mYlVNMnZEU3huNmwvT2dwWWVaaG1sZURXcit2STd5eFRaVjRw?=
 =?utf-8?B?Q012aXNGc1doa2paMW4ySms1cDkxcDFBdW9xM2pBUUVNTnM2VlhCVER3Rm1Y?=
 =?utf-8?B?VVdmemhweFdPeTlMQjhvWjh2aUhKcmIvWkcyZmR1QURCUk1BbWUzY2VUV09P?=
 =?utf-8?B?UGsranVNQVdhVXVRSEJPaStjRVhRM05NTm54MTZwelRhTDBIMTJqZjMwODNQ?=
 =?utf-8?B?MjZtODBROUZmM3QyY2U1MkVYbldhaFZGZWxvbjNXdTVtdHNCQ1c3eGEyMGJW?=
 =?utf-8?B?UnBHSFprelZGdDNtWmh5VVVMd0FxamNSa1o1RTdPcUNLSFJIOEVPNXFwL09j?=
 =?utf-8?B?YU56aXZyZEtneDNDSER3TkJiTFBKc2Zkby95NUx1K1BTMVJwbGVBaE5kZk5U?=
 =?utf-8?B?ZmNhRW5FbVRkRGxBdEgxNGhLemtIVnlCN1Y3UFFlWmpDaGRjMjVUOGtXN2Fw?=
 =?utf-8?B?OGRJM0RxWEs1YmdLMEFCdm1UUW9mZEJieTd4cW9mWW9nSldPdkNLUTQvZ1FK?=
 =?utf-8?B?SlFVRzRMZHVPL2Qrdnk5Q1phVjVHNk1GUE9BYW5yL3VseldXUmg5TXgzZjBz?=
 =?utf-8?B?aCtEUy94L1RQMnlubHZyTUFha1VhZ1IybCtlSDNJSzlmanhsUmREQlRJUy9I?=
 =?utf-8?Q?L/JODXib39sIfgHsM7GDqJ4=3D?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 771641fa-25f2-42a3-b959-08d9eccf6be9
X-MS-Exchange-CrossTenant-AuthSource: BY5PR10MB4257.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Feb 2022 19:56:26.4062
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: Sa6XzECFugBKNlVDnAFregNOtnj1NbWv3bvSl1+ctHA+1SRZ6D7lwjc74+eCnr5tVN1h4Hgg8bcmyz/Ib6/+Ow==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR10MB1875
X-Proofpoint-Virus-Version: vendor=nai engine=6300 definitions=10254 signatures=673431
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 phishscore=0
 suspectscore=0 adultscore=0 malwarescore=0 bulkscore=0 spamscore=0
 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2201110000 definitions=main-2202100104
X-Proofpoint-GUID: CqoopeOpS-sSoH_kk5sp75RbtZkl5gmq
X-Proofpoint-ORIG-GUID: CqoopeOpS-sSoH_kk5sp75RbtZkl5gmq
X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_LOW,
        RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,
        T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-nfs.vger.kernel.org>
X-Mailing-List: linux-nfs@vger.kernel.org


On 2/10/22 11:44 AM, Chuck Lever III wrote:
>
>> On Feb 10, 2022, at 2:41 PM, Dai Ngo <dai.ngo@oracle.com> wrote:
>>
>>
>> On 2/10/22 6:29 AM, Jeff Layton wrote:
>>> On Thu, 2022-02-10 at 09:21 -0500, J. Bruce Fields wrote:
>>>> Jeff, this table of locking rules seems out of date since 6109c85037e5
>>>> "locks: add a dedicated spinlock to protect i_flctx lists".  Are any of
>>>> those callbacks still called with the i_lock?  Should that column be
>>>> labeled "flc_lock" instead?  Or is that even still useful information?
>>>>
>>>> --b.
>>> Yeah, that should probably be the flc_lock. I don't think we protect
>>> anything in the file locking code with the i_lock anymore.
>> Will replace inode->i_lock with flc_lock in v13.
> To be clear, if you're fixing the documentation, that would need
> to be a clean-up patch before your 1/3. Thanks!

Got it Chuck,

Thanks,
-Dai

>
>
>> -Dai
>>
>>>> On Wed, Feb 09, 2022 at 08:52:07PM -0800, Dai Ngo wrote:
>>>>> diff --git a/Documentation/filesystems/locking.rst b/Documentation/filesystems/locking.rst
>>>>> index d36fe79167b3..57ce0fbc8ab1 100644
>>>>> --- a/Documentation/filesystems/locking.rst
>>>>> +++ b/Documentation/filesystems/locking.rst
>>>>> @@ -439,6 +439,7 @@ prototypes::
>>>>>   	void (*lm_break)(struct file_lock *); /* break_lease callback */
>>>>>   	int (*lm_change)(struct file_lock **, int);
>>>>>   	bool (*lm_breaker_owns_lease)(struct file_lock *);
>>>>> +	bool (*lm_lock_conflict)(struct file_lock *);
>>>>>     locking rules:
>>>>>   @@ -450,6 +451,7 @@ lm_grant:		no		no			no
>>>>>   lm_break:		yes		no			no
>>>>>   lm_change		yes		no			no
>>>>>   lm_breaker_owns_lease:	no		no			no
>>>>> +lm_lock_conflict:       no		no			no
>>>>>   ======================	=============	=================	=========
> --
> Chuck Lever
>
>
>