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: <4532123f-4c03-0303-1480-a51faabca806@oracle.com>
Date:   Tue, 17 May 2022 12:30:26 +1000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
 Gecko/20100101 Thunderbird/91.9.0
Subject: Re: [PATCH 2/5] 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: <20220428055431.3826852-1-imran.f.khan@oracle.com>
 <20220428055431.3826852-3-imran.f.khan@oracle.com>
 <YnQtL7+GYHwpo4n2@slm.duckdns.org>
 <f5ff2554-580c-c817-b77f-25e2ef46411f@oracle.com>
 <Yn0/RrgMRie2YPEb@slm.duckdns.org>
 <526b46a7-7daa-9050-1276-e19836816991@oracle.com>
 <YoKna/Ty+k9O+pjt@slm.duckdns.org>
From:   Imran Khan <imran.f.khan@oracle.com>
In-Reply-To: <YoKna/Ty+k9O+pjt@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?dVE2blMraVNWVGwxWkF0SDFCSHdMVHFUcjMyYi9nalltY3EyYW9uS2UrcGs5?=
 =?utf-8?B?ZlNmRGNVRGxnWFRKcDZhLzVaOEt5emlwY1VsUXhnbTZFUUs0Yi9Pd09FUHZx?=
 =?utf-8?B?WlNqejY1Mkw1MGU4RTZHRTAwbzRsMmx0bFhaSDVUbGdOR0NCMFJHZVJjMEUy?=
 =?utf-8?B?eGRUS3RXUmJqOFJIeE56TmV4ckc3OThPS2lsbzNBa3o3WDVTb2szUGpMN3hH?=
 =?utf-8?B?S2N6cFp2eG42KytFVEJjcWYzNEphcXcxVFZ3c1ZpN3V5ZUMrQnFWY1RYdXhN?=
 =?utf-8?B?cHRzM29kTlk1VTFCV09PMytjZDlqU2IzNE9DRXk5ZEtoVWJlV00yZjBNOUJI?=
 =?utf-8?B?bFF0SG5NUyt5Zi9EQ3YxSnBPNzQ4YTVTSndWWk42R29pdUlWaTBIbWhwRzE1?=
 =?utf-8?B?Y0lqM3NQSGRNb2Vhb05zZW1RdDk0YW0xdkthckVwbXE0aVlLdlovWEQ2RE56?=
 =?utf-8?B?Y0gyYUtBWFdUTVRQQ1VoclJGRmF2VCs0dDVwTkRWdWlXWEJtS09hVm04Lzdq?=
 =?utf-8?B?OC9BUFNNeVBhSU9LTXlBR0tOalFIOWlxdzhaWWRoUkhuakd1Rk5rcDFiR2dn?=
 =?utf-8?B?cTdBc012cnIrTksxcnpkaGkwNDdDckpHNmF2T3J0M01uWEUrYTRxaExXUUZT?=
 =?utf-8?B?RzBVeGc5KzhzcUQzSW5sOUFEak95aDZxYTVEVklURTZJUEF6NUthTTNrSUd1?=
 =?utf-8?B?REZXMmJuWEh2dlRnejFoVzRuTWhjS3BRSGUvRkxTR0xGZkltb0pZTmJCU1lH?=
 =?utf-8?B?UStacUhQZGl1K3BYenRZSktINVNSUmpUTVI5eS9XS1RtaHIzckd5QkR5YXdp?=
 =?utf-8?B?VVEwTWZRaFBieU1MQzU5eVdJd0gydDVPdlNOcWRTNDFoT0JyMy9yYnBleEdM?=
 =?utf-8?B?TE5ZcFhJNFVtWElIRWhzdlgzYmhiZ28rYkQ5SzJmRjFGRnUyaS93U3NPM1JY?=
 =?utf-8?B?UllSK2FLWEZzN1V5OTY1YlZPYzA5WU54VTVxcmFxRE9tNTNoRUo5SCticTI0?=
 =?utf-8?B?WTNpdGliOGRLanhNeHJUcGE4ekExL2wya1B1ODdQV2dLQTRjR1ZVOE82bkt2?=
 =?utf-8?B?TzJTeU9yRDZTQnB1ZE16dUxJbHUvRlRUSGdwNXVTcEZFMlg3c1lzdkFabGJB?=
 =?utf-8?B?T3ZUYkNsRDJEZlBHMElabUpVUGFEalVjSUxkNVY3OG5BZXNnaDgvK29LTlZi?=
 =?utf-8?B?cklWbWVyL0xqeTFOOUVUS2tTWjlZeDhzeENJK3dmS0dzQ1EydHFsbm8xeXd0?=
 =?utf-8?B?WTBSejFqclRiM0h0RjJhdzJvVHJxYzRzclVsWGp3enJ2TTlkSlExUTB6bGVT?=
 =?utf-8?B?cWZWZ21iek02SFRtbFE1MDNzYjI3ZWg5dXcrT3p6Z2FEUGlPbFhjT3E3Tllu?=
 =?utf-8?B?VEFleTlhT2hOaHRoQ3RydTAzaFhZZ2U2N0Jqc1ZDZ0NrSzZOYXpWb3U5M3dW?=
 =?utf-8?B?OXlVQlVQTGV6T0tpSjFpaklqbWFIUTBPNzNqTFE1UGZFWFVCVFpETWxGRXU5?=
 =?utf-8?B?OTByUkFMdHlROStvbENZamZjcWtNTHd1R0tXYXQ5dTgxZXR0dXNyVk5QZ091?=
 =?utf-8?B?ZE9ET0ZMQWZtUXArT2hmeDVzb25kZWxXbSthRm1lTHBOSEdaOXN6cyswRWx1?=
 =?utf-8?B?ZzZmQi8yamxqdXI1MWpmUlU2WEI1R28zTTNKTGJ5WGRJTDlyLy9sUUg4cjlP?=
 =?utf-8?B?UjY5Q25kSnl3a0tNb01xVEVGWUM2ajZrR0x3UFZCRGN1WXZCUFYyWUJpNDE2?=
 =?utf-8?B?WWhRbHcxNmdOeWp6elZOQUJYeUVRY2Q2d3dOWW1EQVQyNlBKUG1IVmgzczRJ?=
 =?utf-8?B?dVI0bC8wSFdjTDBiMDU5ZjJpT09XR2E4c05mWk1SV3JHNXlvNWFkdFY0VWpL?=
 =?utf-8?B?SzdTQWxTT3M5NElsdTEwMk9NdzA1UzZEOFlnd0JHWWlnQU1oaDgyQ2U4cVQ5?=
 =?utf-8?B?VkpQL2VFUng5d0pleUc5TXFFUmNkMTlzMmVHcFladTIxMTF4NUV2SVY4QTdG?=
 =?utf-8?B?WStMNXlRcUZ1ZjRKUHdZcHNQNk9aNXVPcmVIak1ZSDhuZk1GTzVNaGpFZ1Nv?=
 =?utf-8?B?MWVwR0lSck5PUE9EVzJlc0RCNUgxb2VDc1lydUNKRTJ0Y0laQ2tvTmZnMjNi?=
 =?utf-8?B?M1EwbmFjRjNrRFpEdDZJMDBpTHRkU0xBd0YrSUJBTk1nNGEwQkVlZ2tGZXEz?=
 =?utf-8?B?Z2ZHVzdSZ29ZdnFOSEVEYnBDL1hNc016QS9rbHNOamRJa281VWErZ3NsMkI0?=
 =?utf-8?B?YjVTcmxZbjJQMnFJSTNHV2lNRFVQdmNZaEZvWDVLaUgwYWlPL2VMV2xyeGMr?=
 =?utf-8?B?N0FHTE1BQk9QNzdCOURXKzQyVkVFa1J6S1FxeDkvUEZxeWlhYndxV1JLL3dn?=
 =?utf-8?Q?igAETUp7hRNTUj0U=3D?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f91856b7-46c2-45b6-b0f6-08da37ad37db
X-MS-Exchange-CrossTenant-AuthSource: SJ0PR10MB4479.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 May 2022 02:30:33.8466
 (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: I9Fw1kTAPMmMAVXrurXJqSfq1+1/XNwu2L0CG/p8oC6uZ9Quy/wwqcod5TRb+ZN3oU9w66QJ7GCyXQlb6PzQfg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR10MB3819
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.486,18.0.858
 definitions=2022-05-16_16:2022-05-16,2022-05-16 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 spamscore=0 mlxscore=0
 phishscore=0 suspectscore=0 mlxlogscore=864 adultscore=0 bulkscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000
 definitions=main-2205170012
X-Proofpoint-ORIG-GUID: yraQsRrZ3pTEzUhYeFvMQoDLjIVmyrkD
X-Proofpoint-GUID: yraQsRrZ3pTEzUhYeFvMQoDLjIVmyrkD
X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_LOW,
        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,
Thanks for your reply.

On 17/5/22 5:35 am, Tejun Heo wrote:
> Hello,
[...]
> Why does it need to return NULL on empty on->files? We wanna trigger lockdep
> warning cuz that's a bug but it's not like the caller can recover from it
> (short of causing unexpected user visible error), so I don't see what the
> point is.
> 

Yeah. Returning NULL for this is wrong. I overdid the checking part because
current users are using on->event or on->poll. Also I have modified the
interface to accommodate for different condition checks (Please see below) and
this would mean that users of the interface can/should specify the condition
under which dereferenced pointer will be treated as valid.

>> If this looks okay then I can replace usage of kernfs_deref_on_raw with
>> kernfs_deref_on_check.
> 
> So, this is the main deref function without holding the mutex, right? Then
> name it kernfs_deref_open_node() (or on but it seem a bit confusing to me).
> 

kernfs_deref_open_node() looks better to me. But I am thinking that for
dereferencing ->attr.open outside explicit read-side critical section we need
only 2 interfaces. One for the updaters and one for the readers. These updaters
and readers should be able to deref ->attr.open under specific conditions which
guarantee the validity of dereferenced pointer. For example can we have just
have these 2 interfaces:

+/**
+ *     kernfs_deref_open_node - Get kernfs_open_node corresponding to @kn.
+ *
+ *     @kn: target kernfs_node.
+ *     @val: RCU dereference will take place only if val is true.
+ *
+ *     Fetch and return ->attr.open of @kn when current updater of ->attr.open
+ *     ensures that as long as @val is true, other updater(s) of ->attr.open
+ *     can not change it. The caller needs to pass value of the condition
+ *     (@val) that prevents value of ->attr.open from changing.
+ *
+ *     This should ONLY be used by updaters of ->attr.open.
+ */
+static struct kernfs_open_node *
+kernfs_deref_open_node(struct kernfs_node *kn, bool val)
+{
+       return rcu_dereference_protected(kn->attr.open, val);
+}
+
+/**
+ *     kernfs_check_open_node - Get kernfs_open_node corresponding to @kn.
+ *
+ *     @kn: target kernfs_node.
+ *     @val: RCU dereference will take place only if val is true.
+ *
+ *     rcu_dereference and return ->attr.open of @kn. This is used in cases
+ *     where we can access ->attr.open outside RCU read-side critical section
+ *     as long as specified conditions are correct i.e @val is true.
+ *
+ *     This should ONLY be used by readers of ->attr.open.
+ */
+static struct kernfs_open_node *
+kernfs_check_open_node(struct kernfs_node *kn, bool val)
+{
+       return rcu_dereference_check(kn->attr.open, val);
+}
+

This will avoid need of different interfaces for different conditions
(holding kernfs_open_file_mutex, @of->list non-empty etc.) Current updaters like
kernfs_get_open_node, kernfs_unlink_open_file can specify
lockdep_is_held(&kernfs_open_file_mutex) as valid condition. Amongst current
readers kernfs_drain_files can specify the same condition as valid and
kernfs_seq_show, kernfs_file_read_iter etc. can specify !list_empty(&of->list)
as valid condition. This will also help us if dereferencing is needed under
certain other conditions in future.
For just checking pointer value we are using rcu_access_pointer anyways and that
should not need any wrapper.

Could you please let me know if this sounds reasonable? It is not changing
anything that we have discussed so far in this regard, it is just reducing the
number of interfaces .

Thanks
-- Imran