Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <61868aa1-6c88-ecd2-beb2-67b87673b805@oracle.com>
Date:   Mon, 13 Jun 2022 13:56:43 +1000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
 Gecko/20100101 Thunderbird/91.10.0
Subject: Re: [PATCH RESEND v4 1/4] kernfs: make ->attr.open RCU protected.
Content-Language: en-US
To:     Tejun Heo <tj@kernel.org>
Cc:     viro@zeniv.linux.org.uk, gregkh@linuxfoundation.org,
        linux-kernel@vger.kernel.org
References: <20220602063907.136569-1-imran.f.khan@oracle.com>
 <20220602063907.136569-2-imran.f.khan@oracle.com>
 <YqYpTShTDLvAp4vx@slm.duckdns.org>
 <6d1c5a49-fc16-5fc7-e527-8cb91ec0d25c@oracle.com>
 <YqalHuEB6OjjUosV@slm.duckdns.org>
 <c8a8a616-da4c-f2ce-0bb2-e0cba69db24d@oracle.com>
 <Yqaqbas1JaWz25jB@slm.duckdns.org>
From:   Imran Khan <imran.f.khan@oracle.com>
In-Reply-To: <Yqaqbas1JaWz25jB@slm.duckdns.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?R1Q3R2k2WURKN3lzS2toNjRjSXg3NE1yajNWN0wyeGZHZERsT1hyaExyMUsx?=
 =?utf-8?B?aDRrVGNjckRLcTBncWhWQWF6cHNzc05TRTIyVytuS0t5TWxkOFg4NGt3TE9M?=
 =?utf-8?B?LytKZnhPL3ExMEZ2KzBPZ0NFNGFBMlVCbzB5dHFEM092dXFqMzJQbHE3VWFU?=
 =?utf-8?B?WXlFYlpmQ2p0TjZuUE90VVcwckVRVUcwaVZ5em1aazNnL2Vhb09NaDVlQmg1?=
 =?utf-8?B?N3ZhZFdBYzVTS0U2Q3VHSTJrZXkyNHJ3Y3VVNmRWMlpsQWJ5UmowdmgzK2hw?=
 =?utf-8?B?LzZoWWI2cm44Q1BJK3owOEVHOURmc0I4TzkxM3dQZjYzYnhOTUJvZWtxaVlR?=
 =?utf-8?B?R1ByZEhyODBZc2RjOTZic2xWS3UrQzBGb2lzbWxnUW4rZ2RtOEJ5dDVJVFpF?=
 =?utf-8?B?T2JybW0zWEZwV1IwNEw0Sis1czJYMVhGWkFXT09pcDZ6aXROSTNsSm1DazIv?=
 =?utf-8?B?UmJEMHppSnlqczVlUFdRU1d0WU8vWmNqMk4rSk54VEZTbnFNSi9IZ1RBQWp1?=
 =?utf-8?B?d1IzelgxOVdFWGJRRnZNWVB4enUwZ1FjN1hFWTR4ZnB0cXZVd3hjUHk2UXVp?=
 =?utf-8?B?M2FTU2F6TTEzRVhici9YdldoU3d6ZDhMMFJRVDA0c0h0NkpRWUVMeGt3Ym5T?=
 =?utf-8?B?dlZkQVorQXFoYXVNM0xxN1RSZmlFNkpuc2N4Y0RvMWJ5dHFhdWNtLzhIVUgy?=
 =?utf-8?B?cmRRcEZQYWNBdmpWN1QwTlczQ0Y0cjdHQkQrY3V0SEZJTWtGLzQ4Yy9MQUZi?=
 =?utf-8?B?MUpuQ1hDY0pDTXFxbUZsODNUdWU2dzVZQW1lT1pyd3l5MXg4NVR0ZXhQdzF5?=
 =?utf-8?B?SzJJbkxxNUpCTFVjeDh5YUsrUmdDNHJ1ZTJlY3dGLzllQlhPOGJ6OWdFWmhT?=
 =?utf-8?B?SzNaTjN3VE9mNEdNK0NDY3VtZ2JORVpwNmI0ejFTTnh4U0d3UlYxZWViVk1r?=
 =?utf-8?B?V3ZVUlNVNWN2S3NoRUNDYzF0Mk5PY2U0bGNCQ2tiQXdZVk9hS2ozWGx2NHZL?=
 =?utf-8?B?em8ySm9SaUxvVnFRa2lMUkZpZThTalFmQ1FidmJtQllEL3BlZ2QzOHJyellS?=
 =?utf-8?B?TTlFZThNd1c3bEJYSTNlRlFvWm90UTZiT09HYnhlM3NudUtLNXRRZXVCVWJn?=
 =?utf-8?B?cjJXU05qUGdQenVnaFhUU3l2R2RLRHZ0VVZSWndqTjBTSnhxUkFBSXZSM1M4?=
 =?utf-8?B?ZUN2QUIzR01CYXpJQUVWaEZ0QW56NkxCVFVhdVU2MmlHR1JROHptcDg1S0Vu?=
 =?utf-8?B?Y2hXYnRGdElMRVdKNGN6QXc5anJBVXNRcjJ6dHg5TUh2eVI0aVpkU3dNN0s4?=
 =?utf-8?B?SUNmY0dJb0UvbVo3c0JzdmtZU1BNbzlhZWxJeHZwcHBKVFVTc24rMnVZbm1J?=
 =?utf-8?B?emZKWUZZejhVbUUxMUo0bVIxaFlTUnJzUlJLUkRzMy84Nlp3bExrU29BUUV5?=
 =?utf-8?B?WFBHZEJ1QzZDV1M5T2M3MzhlYWVwcFNXenZ0RHQrR05lWGg1MnpSOUVsSito?=
 =?utf-8?B?UGswNEl2bi9JaytXdkdTNG15QjhTUkovOWVQalhCVTlUUnNwclhNWGplUWlo?=
 =?utf-8?B?cDBhbFpoVGk4eEFmQmI5ZDZnWTBYZVliV09kWEh1Tk1RczhaZDhJTGRzQTQv?=
 =?utf-8?B?Q0NvaTNSMGIvZHhaRkkrTWhPb3dvS1FhMGI1dVRjYW9jMTZ2cFZSdk9jbk5G?=
 =?utf-8?B?U1VhcjNUSEJhcVFyTVpZQmdycGs1OEduZERBMUVsOUxsUTkvcmdPb1VqdXFX?=
 =?utf-8?B?MWIzNFRWMk5RWW1ETXFKeEtGaUtJenRDTHJ2bUgrZEJDR2p3UDBld0pTcEtn?=
 =?utf-8?B?OGdvTjJDRmxOMzlZOFhqSUVlWVFwbXNGSXhXUmkxNGQrclZ3NXprN2xERUt0?=
 =?utf-8?B?ME5yZGFvdWY0aE9ZWm9YM0wyaEFDQiswOHRtWnBNUHVlamUrMmRxUHJ1anV5?=
 =?utf-8?B?b3lhbW8xUWRQNHNiNElhZnhnbXBZdlJFNmZvS0ErT2ZsN2o4UXMzQ2ZENDZh?=
 =?utf-8?B?a09pRGswZVRSOXFqTWgzb1RMa3pxN0x6ZnJzRE5uVWgzL2p6bnpYUThHaDd0?=
 =?utf-8?B?T1ozK0dDTlg2dEpMUWhoMkxxWWhuSnQ4OWtrQ21vZ1QrZ2x4bGZ6V05xOG5v?=
 =?utf-8?B?dGVrSExEaUNYV1ovMUxJZzIzQ3BsZGJzMDkzeGYzWktmUW5WRGVkcXJsWGxE?=
 =?utf-8?B?T2Jwb3hyY2JQRTNDdHhhMUcyWE04aVk0SXY5aUEzMDlUU2FxWWZWM201ZmNW?=
 =?utf-8?B?UTdIVFlZRFo0T0NDY2JxU1VKNjR5Y1l3Y2dCMklybTN3aUhLbjFQZisyanBO?=
 =?utf-8?B?Nm9kZVFiR1Z5OTBCN1NrVHMrUy9DOUpiVWNyRXhKTXlDcDVjRUZWa2R2d2VY?=
 =?utf-8?Q?m2ANOJKM0Xbw24y0=3D?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d8d54d11-111e-4cd8-11e6-08da4cf0bf99
X-MS-Exchange-CrossTenant-AuthSource: CO1PR10MB4468.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jun 2022 03:56:51.7638
 (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: xbU9LRRiIuXJLKKLTcC49XoD+v6XfSGvGPz9KcdIIQVNOtufDdnYX27rhs/KSYWmKVA68O2ta5RDQ+B3fEvrtg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR10MB5514
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.517,18.0.874
 definitions=2022-06-13_01:2022-06-09,2022-06-13 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=625 mlxscore=0 spamscore=0
 bulkscore=0 malwarescore=0 phishscore=0 adultscore=0 suspectscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2204290000
 definitions=main-2206130016
X-Proofpoint-GUID: g3geutz3wgzg7U_h6gN0FBOgeCMx1t7N
X-Proofpoint-ORIG-GUID: g3geutz3wgzg7U_h6gN0FBOgeCMx1t7N
X-Spam-Status: No, score=-4.0 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_H2,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-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hello Tejun,

On 13/6/22 1:09 pm, Tejun Heo wrote:
> On Mon, Jun 13, 2022 at 12:55:14PM +1000, Imran Khan wrote:
>> I took below phrases as reference:
>>
>> If the access might be within an RCU read-side critical section on the one hand,
>> or protected by (say) my_lock on the other, use rcu_dereference_check(), for
>> example:
>>
>> p1 = rcu_dereference_check(p->rcu_protected_pointer,
>>                            lockdep_is_held(&my_lock));
>>
>>
>> and
>>
>>
>> If the access might be within an RCU read-side critical section on the one hand,
>> or protected by either my_lock or your_lock on the other, again use
>> rcu_dereference_check(), for example:
>>
>> p1 = rcu_dereference_check(p->rcu_protected_pointer,
>>                            lockdep_is_held(&my_lock) ||
>>                            lockdep_is_held(&your_lock));
> 
> So, both are saying that if a given reference can be under both read
> critical section or a lock which blocks updates, you can use deref_check to
> cover both cases - we're just using the stronger form of derefing even
> though that's not necessary while update side is locked out, which is fine.
> 
> The protected one is different in that it doesn't enforce the load ordering
> which is required for accesses with only RCU read lock. Given that all
> that's required is dependency ordering, I doubt it makes any actual
> difference and it likely is more useful in marking a specific dereference as
> always being with the update side locked.> tl;dr is that you're way over-thinking the rcu deref code. Just make one
> deref accessor which encompasses all three use cases.
> 
> 

Agree. I did over think this and went for the safest interface that I could
think of in each of the use cases. I will remove
kernfs_check_open_node_protected and use kernfs_deref_open_node_protected in its
place as well. This will cover all accesses under kernfs_open_file_mutex.

But we will still need kernfs_deref_open_node for cases where
!list_empty(&of->list) ensures safe access of ->attr.open and where we can't
ensure holding of kernfs_open_file_mutex. So we will need 2 deref accessors.
Right? Just asking this because you mentioned above to come up with one deref
accessor that can be used in all three use cases

Please let me if this sounds okay. I can send updated patch-set with these
changes in place.

Thanks,
-- Imran