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;
Date:   Mon, 22 Aug 2022 17:05:32 +0300
From:   Dan Carpenter <dan.carpenter@oracle.com>
To:     Khalid Masum <khalid.masum.92@gmail.com>
Cc:     Hawkins Jiawei <yin31149@gmail.com>,
        David Howells <dhowells@redhat.com>,
        Marc Dionne <marc.dionne@auristor.com>,
        "David S. Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>,
        Jakub Kicinski <kuba@kernel.org>,
        Paolo Abeni <pabeni@redhat.com>,
        "open list:NETWORKING [GENERAL]" <netdev@vger.kernel.org>,
        syzkaller-bugs <syzkaller-bugs@googlegroups.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        syzbot+7f0483225d0c94cb3441@syzkaller.appspotmail.com,
        Pavel Skripkin <paskripkin@gmail.com>,
        linux-kernel-mentees 
        <linux-kernel-mentees@lists.linuxfoundation.org>,
        linux-afs@lists.infradead.org
Subject: Re: [PATCH] rxrpc: fix bad unlock balance in rxrpc_do_sendmsg
Message-ID: <20220822140532.GF2695@kadam>
References: <20220822112952.2961-1-yin31149@gmail.com>
 <20220822130414.28489-1-yin31149@gmail.com>
 <CAABMjtE-XKa-_kW-aREvHDiyGwcs-GZWjtSjZEeF577FKcUTAA@mail.gmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAABMjtE-XKa-_kW-aREvHDiyGwcs-GZWjtSjZEeF577FKcUTAA@mail.gmail.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?/fDPlDPm+CdS0WXgGNQI9og7HO8M494aLTuZTKB4RNVsMTQko4utVD5v7v5t?=
 =?us-ascii?Q?3FcUX+eVPYsvmHp08PPk3UZZ8kTOX9x3/mD4M/bKgGFls+Vztp/TmFAieyJr?=
 =?us-ascii?Q?mQOKQA/+jPFbYWEU24KXU+PcLSgutXhKUBcLL9SUw5ZdRz8E+H2AXISeiToZ?=
 =?us-ascii?Q?MrMQHgFyXN4n1lmNL5Di5HitmzzTw6zQ0x8PRcg4C36gwWf0lTHNu87cj/YP?=
 =?us-ascii?Q?/DXLz/EcjJplF9x2Gtz1sTmNj/mwrzfRkepREbw9CL1DBvQJgAigGHvGcpDx?=
 =?us-ascii?Q?95T+OkBq/x2VdwD/fe8HkGLfW5AfU22hV7oF/JPwiqdZDZJG33F/T2pKgk9+?=
 =?us-ascii?Q?luzaDaXFVQDDtINdVKmJOlfAlsQrHMtqYHCdYRtq6ZcOf4NvYSWmw8+21xYX?=
 =?us-ascii?Q?t0AK0drmCndPsbANlCnRoXH1txryM1j480xTuK0ohJzZAKU+QBxO7uT//62I?=
 =?us-ascii?Q?DJ6M9vXCQaxSqXI3CLLdmT/1j/JhTczWwumVb3Jdnvf2M1LDf1Ec3Rz1+qZp?=
 =?us-ascii?Q?fBRjyMD6/tzXTNGgcmQ2VQeteKUYpyBz1a/8APmoMIXbTAf1g7+8n8ezpAmo?=
 =?us-ascii?Q?zMy9wCrXDrxAUUJ1H9mPevL6qszQlqzXJ8dgb0vKKg2EyHG42cdFBy6QvvOf?=
 =?us-ascii?Q?eIM4LYizEIvkJ1jCWSZPJyqlZQ00gW9Ad2Z4efMi+JDcVMcOnDBDcqWhsWud?=
 =?us-ascii?Q?nEDQSNzRsoRRy1BJCqDhG5GUJyyrriyE496ttm98+3naiFeNjhISvXu4EL8L?=
 =?us-ascii?Q?+BrnG2yGzgn5tV4fIRUzQrA4LScuMSYVUIQg++Yo8zpB5Dqmv7LleQM0zaJn?=
 =?us-ascii?Q?EMTnDFfMB67d8x58Ndp+q7ZcEInqdV50w9R9uyC0f96AOEfmc/vPOFKd1zs2?=
 =?us-ascii?Q?NRPrsX+C7PNchsBvTby/J6+f1nJa7NsZyjpgeLPSMJs1gzW7bAKTOoPLoiK5?=
 =?us-ascii?Q?ECMoPLXzxgr0wQADpxbaKbwzJG/uDwPaZUtPBSWeqtgxJyoSmNczJuoq9eco?=
 =?us-ascii?Q?CuBLJUR2AOQCDvkpt14rQotBDysQIo2U0sBygnlH/wr/bQQjKyaYHZ0CChW1?=
 =?us-ascii?Q?ImBEE+8hfApYHZ8wZxsoCgGVk0FuUptg71Q8YpuRcAoxOorqVPnHfmrDREWn?=
 =?us-ascii?Q?IwKWQyfIH07cmTX5l4Jpv+FwC7DGLVqZ3tDyYhPOQzjf/Y4MzBFq3jG4IhJV?=
 =?us-ascii?Q?4+5Rz2MzSIHFlZNaCtdjyDsipJeM/0hge27F1tPSKqr7PR+xlUsQhstMx6zi?=
 =?us-ascii?Q?Tdokk8ijMg9mEa184C8BoyIdNoxvdb5MMoIsxmStlvHskHaPTWEH/KJT3NBd?=
 =?us-ascii?Q?KBgV/PkgiY5Irdg/pGzHSm45hGQkR0CLOrh1pAxS26WN1qxURMQY8JfR9nGv?=
 =?us-ascii?Q?0LWd6xTgwDcEbSsJQYhiCBmuFYU0zmllqoS4JCtbuzNeiIIzgWCrh0TyO7/8?=
 =?us-ascii?Q?jpbJCFXM8hgFtB6ZHvH3iXQl4cUZ2HsVupTG9oUwdHmXNHPhnj7R5a75h5OL?=
 =?us-ascii?Q?VKy+KrbON9iRfNXa6OXJH5t7eXnrSbKp1gqfwQsjdKF+LzNzm2iwGcmTJsDK?=
 =?us-ascii?Q?uJ0AVyVuvqZHNEKi46Fluz0O+fbz5Zzo52+Qn+xtaxmkfXF3ndnBIOKgadAy?=
 =?us-ascii?Q?Rw=3D=3D?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 157238b0-4e83-47a5-d64f-08da84476f2c
X-MS-Exchange-CrossTenant-AuthSource: MWHPR1001MB2365.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Aug 2022 14:05:57.0662
 (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: F/ixHirNYlNaXnmmcn6jhgHWW5Ry8/3ANZrGrnAYZVPjcx5E8jLSzx0QO6tWLovS77m9yYZUjLFr3IdfQeedebY5kfz/sa1cbZuRx8B5doE=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1001MB2317
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.517,FMLib:17.11.122.1
 definitions=2022-08-22_08,2022-08-22_02,2022-06-22_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 mlxlogscore=999
 phishscore=0 mlxscore=0 adultscore=0 spamscore=0 suspectscore=0
 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2207270000 definitions=main-2208220059
X-Proofpoint-ORIG-GUID: JrvNn4A7g9dYcCSJL0b2qG4DWvR3EKOu
X-Proofpoint-GUID: JrvNn4A7g9dYcCSJL0b2qG4DWvR3EKOu
X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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

On Mon, Aug 22, 2022 at 07:55:27PM +0600, Khalid Masum wrote:
> >
> > /*
> > + * @holding_mutex: An indication whether caller can still holds
> > + * the call->user_mutex when returned to caller.
> 
> Maybe we can use mutex_is_locked instead of using the holding_mutex
> parameter to get whether call->user_mutex is still held.

That doesn't work.  What if there is contention for the lock and someone
else took it.  Locks under contention are sort of the whole point of
locking so it's highly likely.

I do kind of feel the code has a layering violation.  I'd prefer instead
of "I am setting this variable to true to reflect the caller blah blah",
the variable could just be set in the caller.  I'd probably flip it
around and call it "dropped_lock" instead of "holding_lock".

	bool dropped_lock = false;

	...

	if (!dropped_lock)
		mutex_unlock();

That way only the callers and the function which drops the lock need to
be involved with setting the variable.

regards,
dan carpenter