Message ID | 1699355026-6788-1-git-send-email-quic_mojha@quicinc.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:aa0b:0:b0:403:3b70:6f57 with SMTP id k11csp155201vqo; Tue, 7 Nov 2023 03:04:35 -0800 (PST) X-Google-Smtp-Source: AGHT+IFSWsyyo0JcazrBMuOTymKcvvmm8blMpw8+1GUhWF7o5vJFC+W2AEikpSgmktOvITXqpkZf X-Received: by 2002:aca:110f:0:b0:3b2:f576:3f97 with SMTP id 15-20020aca110f000000b003b2f5763f97mr33923755oir.12.1699355074944; Tue, 07 Nov 2023 03:04:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1699355074; cv=none; d=google.com; s=arc-20160816; b=cMnVzltel9smSO3HJgBoxp5xBQToAb2U2CDV4k63dqXjZEuGuW9/iQJkCCXE6/bbn+ xJGIO18VCpuqcJWNDphpFVIOER61cOdJ8AUxLzH8X7ejDBP3vGSuoNBuWbuBRgcQ2Lkh wKpbV5Mc0sNDvcXvsXwVLlOmwmikogPI7P5nC/xFpjCvp/AkriCydl29ecJEITrK7xa6 vbEatcpd0lPk2dzZxkp9xIVQMvVA06HsmCV6vkQ7PDMangGuDRMMlvxvbQwUX+K6Avo6 tnavWkHQlX8K5rRqlk6myNhWNNZNAm57JFYhDtBirD6DaICa3qJy6BAxskGPBfOfg2Hk NjMA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:subject:cc:to:from :dkim-signature; bh=S7luXczpHBfLgaLO2EzI+DICZGtdES7p38UsKdlENT8=; fh=hm161jP+98iCRLrn3ON2q1VVo2bbNNnzJxvnXyMyMOk=; b=tmeiH4e6BmSolW2LcZY+r5fgeNhUB+mgWkzpS8wBD+XOfIdlGd2QANdngXOmwJzXE2 65Ja2jGfOaQ92+arzKfXP3UBsWObu4AGlODiqQqCvHRRMh3SPJHi/vZpf+4+VzP7fzET yKYeUpYKlUOj0ukByn2GaBm1dmeaiWekD14dMm+rP3YkmOTqd32QIhCJ8rEyHansAald gceqyZtZ0t80GzyhqM354LLOxwK8XJ5KlMvCp+uPVrOHDCmlfHKwk60dpR8QFGSfW3tJ gMu34L2kZqbRbmVC6kqEK/HC7PfvBbIV4vYR8N4oUk3QTym8roA3KRM3wWtfRZZ1U+mX ZNaA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=hkfvC8Gk; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Received: from fry.vger.email (fry.vger.email. [23.128.96.38]) by mx.google.com with ESMTPS id t189-20020a6381c6000000b005649f560ebesi1757398pgd.525.2023.11.07.03.04.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Nov 2023 03:04:34 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) client-ip=23.128.96.38; Authentication-Results: mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=hkfvC8Gk; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by fry.vger.email (Postfix) with ESMTP id 8B17E80D79BD; Tue, 7 Nov 2023 03:04:32 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at fry.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234244AbjKGLEW (ORCPT <rfc822;lhua1029@gmail.com> + 32 others); Tue, 7 Nov 2023 06:04:22 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41932 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234272AbjKGLET (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 7 Nov 2023 06:04:19 -0500 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1274B12B for <linux-kernel@vger.kernel.org>; Tue, 7 Nov 2023 03:04:15 -0800 (PST) Received: from pps.filterd (m0279871.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 3A77Ke0r006680; Tue, 7 Nov 2023 11:04:08 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h=from : to : cc : subject : date : message-id : mime-version : content-type; s=qcppdkim1; bh=S7luXczpHBfLgaLO2EzI+DICZGtdES7p38UsKdlENT8=; b=hkfvC8GkUdK+uW/cltXGKmRbtKIxXz+Qi1OK0ap/cQzVq7RJ2X1TiY6aFMjfFQY5UVIR krfkKvsWVWihRO3pMhYfS9zIaQ6xerLoymNh7jVzgkygV+uQf0L83Dp2/8cN/Urr52p7 TKpLBUOl/HM3Q9cEc2wbKM2UrNOI2f2lH3eT31mw5NpRtSP6MP2blxyQovT6+XAyGNDn nI5s15xXRbmPCnkmgeK0hIMkPCu3Ivy2QNBrwFDZGyB7S0qmgdq5uqve/iZZdA+zh0b5 OMzZzv8AaejddSXuy1+Tex6Ei9SAPeWR8znrAUWgQq792Et89ZeQvNJfMKPZH0tJZLzh JA== Received: from nasanppmta04.qualcomm.com (i-global254.qualcomm.com [199.106.103.254]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3u72r2a81t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 07 Nov 2023 11:04:07 +0000 Received: from nasanex01c.na.qualcomm.com (nasanex01c.na.qualcomm.com [10.45.79.139]) by NASANPPMTA04.qualcomm.com (8.17.1.5/8.17.1.5) with ESMTPS id 3A7B461c001592 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 7 Nov 2023 11:04:06 GMT Received: from hu-mojha-hyd.qualcomm.com (10.80.80.8) by nasanex01c.na.qualcomm.com (10.45.79.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.39; Tue, 7 Nov 2023 03:04:04 -0800 From: Mukesh Ojha <quic_mojha@quicinc.com> To: <johannes@sipsolutions.net>, <gregkh@linuxfoundation.org>, <rafael@kernel.org> CC: <linux-kernel@vger.kernel.org>, Mukesh Ojha <quic_mojha@quicinc.com> Subject: [PATCH v2] devcoredump: Send uevent once devcd is ready Date: Tue, 7 Nov 2023 16:33:46 +0530 Message-ID: <1699355026-6788-1-git-send-email-quic_mojha@quicinc.com> X-Mailer: git-send-email 2.7.4 MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01b.na.qualcomm.com (10.46.141.250) To nasanex01c.na.qualcomm.com (10.45.79.139) X-QCInternal: smtphost X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085 X-Proofpoint-GUID: x658QG48bhbGlIJoD40J9zZ4rJLEzw_u X-Proofpoint-ORIG-GUID: x658QG48bhbGlIJoD40J9zZ4rJLEzw_u X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.987,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2023-11-07_01,2023-11-07_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 bulkscore=0 adultscore=0 lowpriorityscore=0 suspectscore=0 malwarescore=0 clxscore=1015 phishscore=0 priorityscore=1501 mlxscore=0 spamscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2310240000 definitions=main-2311070091 X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on fry.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (fry.vger.email [0.0.0.0]); Tue, 07 Nov 2023 03:04:32 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1781825054277460746 X-GMAIL-MSGID: 1781902947022729738 |
Series |
[v2] devcoredump: Send uevent once devcd is ready
|
|
Commit Message
Mukesh Ojha
Nov. 7, 2023, 11:03 a.m. UTC
dev_coredumpm() creates a devcoredump device and adds it
to the core kernel framework which eventually end up
sending uevent to the user space and later creates a
symbolic link to the failed device. An application
running in userspace may be interested in this symbolic
link to get the name of the failed device.
In a issue scenario, once uevent sent to the user space
it start reading '/sys/class/devcoredump/devcdX/failing_device'
to get the actual name of the device which might not been
created and it is in its path of creation.
To fix this, suppress sending uevent till the failing device
symbolic link gets created and send uevent once symbolic
link is created successfully.
Fixes: 833c95456a70 ("device coredump: add new device coredump class")
Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com>
---
Change in v2:
- Added Fixes tag as per suggestion from [Johannes]
drivers/base/devcoredump.c | 3 +++
1 file changed, 3 insertions(+)
Comments
On Tue, Nov 07, 2023 at 04:33:46PM +0530, Mukesh Ojha wrote: > dev_coredumpm() creates a devcoredump device and adds it > to the core kernel framework which eventually end up > sending uevent to the user space and later creates a > symbolic link to the failed device. An application > running in userspace may be interested in this symbolic > link to get the name of the failed device. > > In a issue scenario, once uevent sent to the user space > it start reading '/sys/class/devcoredump/devcdX/failing_device' > to get the actual name of the device which might not been > created and it is in its path of creation. > > To fix this, suppress sending uevent till the failing device > symbolic link gets created and send uevent once symbolic > link is created successfully. > > Fixes: 833c95456a70 ("device coredump: add new device coredump class") > Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com> > --- > Change in v2: > - Added Fixes tag as per suggestion from [Johannes] > > drivers/base/devcoredump.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/base/devcoredump.c b/drivers/base/devcoredump.c > index 91536ee05f14..7e2d1f0d903a 100644 > --- a/drivers/base/devcoredump.c > +++ b/drivers/base/devcoredump.c > @@ -362,6 +362,7 @@ void dev_coredumpm(struct device *dev, struct module *owner, > devcd->devcd_dev.class = &devcd_class; > > mutex_lock(&devcd->mutex); > + dev_set_uevent_suppress(&devcd->devcd_dev, true); > if (device_add(&devcd->devcd_dev)) > goto put_device; > > @@ -376,6 +377,8 @@ void dev_coredumpm(struct device *dev, struct module *owner, > "devcoredump")) > dev_warn(dev, "devcoredump create_link failed\n"); > > + dev_set_uevent_suppress(&devcd->devcd_dev, false); > + kobject_uevent(&devcd->devcd_dev.kobj, KOBJ_ADD); > INIT_DELAYED_WORK(&devcd->del_wk, devcd_del); > schedule_delayed_work(&devcd->del_wk, DEVCD_TIMEOUT); > mutex_unlock(&devcd->mutex); > -- > 2.7.4 > Hi, This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him a patch that has triggered this response. He used to manually respond to these common problems, but in order to save his sanity (he kept writing the same thing over and over, yet to different people), I was created. Hopefully you will not take offence and will fix the problem in your patch and resubmit it so that it can be accepted into the Linux kernel tree. You are receiving this message because of the following common error(s) as indicated below: - You have marked a patch with a "Fixes:" tag for a commit that is in an older released kernel, yet you do not have a cc: stable line in the signed-off-by area at all, which means that the patch will not be applied to any older kernel releases. To properly fix this, please follow the documented rules in the Documentation/process/stable-kernel-rules.rst file for how to resolve this. If you wish to discuss this problem further, or you have questions about how to resolve this issue, please feel free to respond to this email and Greg will reply once he has dug out from the pending patches received from other developers. thanks, greg k-h's patch email bot
diff --git a/drivers/base/devcoredump.c b/drivers/base/devcoredump.c index 91536ee05f14..7e2d1f0d903a 100644 --- a/drivers/base/devcoredump.c +++ b/drivers/base/devcoredump.c @@ -362,6 +362,7 @@ void dev_coredumpm(struct device *dev, struct module *owner, devcd->devcd_dev.class = &devcd_class; mutex_lock(&devcd->mutex); + dev_set_uevent_suppress(&devcd->devcd_dev, true); if (device_add(&devcd->devcd_dev)) goto put_device; @@ -376,6 +377,8 @@ void dev_coredumpm(struct device *dev, struct module *owner, "devcoredump")) dev_warn(dev, "devcoredump create_link failed\n"); + dev_set_uevent_suppress(&devcd->devcd_dev, false); + kobject_uevent(&devcd->devcd_dev.kobj, KOBJ_ADD); INIT_DELAYED_WORK(&devcd->del_wk, devcd_del); schedule_delayed_work(&devcd->del_wk, DEVCD_TIMEOUT); mutex_unlock(&devcd->mutex);