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: <2a150836-d459-86fd-a9f4-b8d3383710af@oracle.com>
Date:   Thu, 10 Feb 2022 11:47:11 -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:     "J. Bruce Fields" <bfields@fieldses.org>
Cc:     chuck.lever@oracle.com, jlayton@redhat.com,
        viro@zeniv.linux.org.uk, linux-nfs@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>
 <20220210142826.GD21434@fieldses.org>
From:   dai.ngo@oracle.com
In-Reply-To: <20220210142826.GD21434@fieldses.org>
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?ZnRNNTlqWWdCS0NQWGpkOXVMVkhyR0QzM3NtYm10bTZYVDlLajkwdDBUR1Q3?=
 =?utf-8?B?US9oMFVjOVNVT1poMjZodmxjZGlqZTNtODdTdmRkQ0psbHBtQi9laXVKN213?=
 =?utf-8?B?N3d6R1N5Y3ArVjMzeWUvcDR6QzduQmlvUHFUWHAxT2JsOWpuNk42bjAxbW5I?=
 =?utf-8?B?b3FjZGIrdDB0UXhrUFRXTW9Jb3BuSG5aMWdZaFJiVm81MWkycTNyV1oyNE9y?=
 =?utf-8?B?VVYxS2Z4N3JDNXBsaWZBemdGTnoxZDgyaWpWTEtTYjdVeWlma0V5NU5oa0Vr?=
 =?utf-8?B?UWxPbTErYW9oaXVPK3JOU3lScmdzQ2taZm9WbDZqUHl6aHVobElIanFRVWE5?=
 =?utf-8?B?cS9JUlRMQUR0SEhJTjFKbFJRdVVWS3JldDlJSEN4SmpCR1BCTjBXUm5jaHpu?=
 =?utf-8?B?ajNzTVJwMU0wWUZHL1ducmVrb2VJNFBVVVFiYi9uSDYxTS9UZkNnQnBsbS9Z?=
 =?utf-8?B?dlJ3MnlhYmNBa3ZvUzZzOVhTK3F5Q0lsdlFoVTE1ZHBRRERFMkZpVXNjcHRs?=
 =?utf-8?B?UkpLY09NZzlmQ2lHUW1YMy9ta0w1UTVHMkZJNURPc2NRL0k0d2FNMndYZWVV?=
 =?utf-8?B?dmxPZlliZEJLOEpVVTE3MmZadG9zUTVqQ1ArbkNia2NtQVh6R2FyQmgzLzVn?=
 =?utf-8?B?d3FiVDNQRTJwWUhVUGsvQ0VYS3dodlFNeTB6cWRKTVJBdjYxVTRGOUp2cXZx?=
 =?utf-8?B?cW1IMjg3RmxUUS9KZjFkS0lwS2oyalkveDhqcGRvdytzM2c4eHYyUFFPUURL?=
 =?utf-8?B?T3RTaFNqYXhYODBGUzlNWEZHVWM5Ny9Gbmw5dVQ2Y1hyQzNrd0NWMmdLeHRq?=
 =?utf-8?B?bnRUcTlqU2ZEd01jaHE0MThYcEhxK0ROdGI4WkFvSUMybk8rSWt2Z3NtNVlo?=
 =?utf-8?B?Y2tlTUlVemVtZ2Zpc2pzSE5BcVVGTWxZamZnK3N6QnNPOXNCcUxod1k4NTcw?=
 =?utf-8?B?Vk9IN3VVV2V6UGxuVkdjUzV2MFlUT09sWWNBck5Dak5ScTZ6WDhFTTE4d3Jh?=
 =?utf-8?B?Z2JUUGJLTmZBTDlhd2dua0tMZ1V1V0hjTzlNVGlobUI3eURhMVNJR0p6Wk1H?=
 =?utf-8?B?RldVMHFKaXY3MTRFLzIxWk1CN2NERkQ3clRrUys3bmIyREJIK1NONnNlUmNs?=
 =?utf-8?B?ZkU2cXRxblF0ZFFvOEJaTXpJRnEyT2YvSWhHY005WVVKTll2ME10RXp2eVJN?=
 =?utf-8?B?UytaR1RUM1MrdFJ6NDRZSVRIVFJUeWk3UklHMjdGVTZlWE90NkZseDRVeGc4?=
 =?utf-8?B?NmxCMVNtbDBvV1FTeGRDVGJsWWFJREdQTDlNM1R1K096cVRBU1ljcDhtbHl5?=
 =?utf-8?B?YmtuakFFcVBMdk95bE5pdUM2VkVwbExENHd6aUZ1MmhsNEFReW1yUWJ6WGFH?=
 =?utf-8?B?YjlCQzN4cEd0SU9aSWV6dm5PWmtjamhnM3N5Mjh4Tk9LUjViM0pXbFJEOS90?=
 =?utf-8?B?TkJxbmRkRXo5T1VPb0VwaVBlTGVsemhTN2ppeHJBT1k4b3lUZ2t4aGEwK3dK?=
 =?utf-8?B?bDVZMlFJV09PbEJWem83cGYwUkprYVBwL0lpbDBlM2RhV0VJTGk1WlpuUEFj?=
 =?utf-8?B?c2w0M2ZFcnhPZ1huelJRbjJlcE1IVjMxTXVaQVl6K0xkQ1hBb3JBOEE0N25m?=
 =?utf-8?B?eVZ1OHloU0lWSjJLWmwrY21QZzA3SGttREQzTitKcjFxeWl1UngwSEdTM1Mv?=
 =?utf-8?B?NnZYNU9sekwxS05DbTFZWHgyZGlyYjJmRTJpUjNtemdQTmpuYTBrT2NxeG1E?=
 =?utf-8?B?VGdEV1M3SFFlVWFubXRrTjh5NDE1cFNHNFNMNWxpcmRnZFVTZEVQcmZaQlVh?=
 =?utf-8?B?dWpwUk1zWWdZR1RYbVlMSHo3R01FWVZxeVRDd0VISDdEK2U0cEExQXNCQkda?=
 =?utf-8?B?T09LOFA3cjlpanFsTkYzQmwzYUxuS0dGZzZDT0l0TVIrMkJncE5tWHU3YWhh?=
 =?utf-8?B?ZE1xYTV3VlN3TmpKMWhyeGZNKzRsb3lWTlh5aG1rd2hkV3UzS1pndEYwK3J3?=
 =?utf-8?B?RzMrcGZ4YWQwVC9IYVVqbFFHb2RnVWVBMENqZ01YYmpNR0RINVplbHBtcC84?=
 =?utf-8?B?ZUtzWWh4Sm9HOXFlck1makd1MzZVMDhzQlJUZzVWTHQ5OXRoNVkrRlAxOVov?=
 =?utf-8?B?TG0wenVYa3ZtU0d2NkgxRVpoeWQ5QlVZTy85QmpDY3lJS2xNQzYyK2RJZVVu?=
 =?utf-8?Q?FqVl8rslxjZwQrFp/GiFS/M=3D?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c400679d-5bf4-4ec5-56be-08d9ecce2316
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:47:14.7282
 (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: wzEW9jfU8f9t1Uzi3gPpOyP0DTqTWyR3cRmIZ5KdlbsQyy0lUPRMz2r6PTKNrgJFoISZ91GOPxzjJltZDumbzw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR10MB1639
X-Proofpoint-Virus-Version: vendor=nai engine=6300 definitions=10254 signatures=673431
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 bulkscore=0 suspectscore=0
 mlxlogscore=999 mlxscore=0 adultscore=0 malwarescore=0 spamscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2201110000
 definitions=main-2202100104
X-Proofpoint-ORIG-GUID: Y4VBMTVelBQKi0izqS2Mfm1nfKUhKrY1
X-Proofpoint-GUID: Y4VBMTVelBQKi0izqS2Mfm1nfKUhKrY1
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 6:28 AM, J. Bruce Fields wrote:
> On Wed, Feb 09, 2022 at 08:52:07PM -0800, Dai Ngo wrote:
>> diff --git a/include/linux/fs.h b/include/linux/fs.h
>> index bbf812ce89a8..726d0005e32f 100644
>> --- a/include/linux/fs.h
>> +++ b/include/linux/fs.h
>> @@ -1068,6 +1068,14 @@ struct lock_manager_operations {
>>   	int (*lm_change)(struct file_lock *, int, struct list_head *);
>>   	void (*lm_setup)(struct file_lock *, void **);
>>   	bool (*lm_breaker_owns_lease)(struct file_lock *);
>> +	/*
>> +	 * This callback function is called after a lock conflict is
>> +	 * detected. This allows the lock manager of the lock that
>> +	 * causes the conflict to see if the conflict can be resolved
>> +	 * somehow. If it can then this callback returns false; the
>> +	 * conflict was resolved, else returns true.
>> +	 */
>> +	bool (*lm_lock_conflict)(struct file_lock *cfl);
>>   };
> I don't love that name.  The function isn't checking for a lock
> conflict--it'd have to know *what* the lock is conflicting with.  It's
> being told whether the lock is still valid.
>
> I'd prefer lm_lock_expired(), with the opposite return values.

Will replace lm_lock_conflict with lm_lock_expired with the opposite
return values: return true if lock was expired (conflict resolved)
else return false.

>
> (Apologies if this has already been woodshedded to death, I haven't been
> following.)

Yes, the name has been changed couples of times :-) hopefully
lm_lock_expired will stick this time.


-Dai

>
> --b.