Message ID | 20240212094618.344921-1-sakari.ailus@linux.intel.com |
---|---|
Headers |
Return-Path: <linux-kernel+bounces-61255-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:50ea:b0:106:860b:bbdd with SMTP id r10csp2327996dyd; Mon, 12 Feb 2024 01:46:49 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCWRn9wUyJC0jxxbyBu7zNOUH2ZHe99Y+7Mnk+fD5fBHCqe4F5mDzUw2ARS6pkX5D7i0ypUpun7uLwUV8bSbhV2zocKtPw== X-Google-Smtp-Source: AGHT+IENERNKmcOb1NU7qRXpmxoU02m1TdcPwPYmyYYN3jOil/JOYeYFbhxmC3PpDcnVFjVyozGj X-Received: by 2002:a05:6808:1307:b0:3c0:3f65:dc2f with SMTP id y7-20020a056808130700b003c03f65dc2fmr120519oiv.50.1707731209519; Mon, 12 Feb 2024 01:46:49 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1707731209; cv=pass; d=google.com; s=arc-20160816; b=PwWiOmL2NyYiXCL5HMRn4aicBUHdv+1T/nDZmZuB+eCzoMwuOZtSWFEWIy3SC0texQ K4rxKprkWSGshRUO2lWQ2DmziccG+irq+Ccp4Mni133mNVQGfUi6kDE1gC5fGDIfGxuw /2s1xWqifhF/1yJ6RCPI2qEFXwEA68Ec1O9OGSJobUPkyxSXJQ2L2qlqHwbAsFX6Edib 0tml7FwrIlI8Oc+ZBIAq/3E9Rt4wKAU/k/wS1/iQ5JP5UgubF+8XfgtdsU6/1UhpHsJJ fXyXrcyh98hwRnPEltbXRqL9OjWhQXqmruNIiDXNOwYbvxxYE4M4AGV2QxKzroCCvDfZ 42CA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from:dkim-signature; bh=Jr+VmhJxbtuRvb3E57vQJJIzDznyeDLf3BDuTgMaI0Y=; fh=MqMhQSJgVd9nfaj9HUxc54vsSkCkwrWgM7dxL8tONMs=; b=rpB4Tr5BC+3I7izcnBa9DvZsvx1D8fiYoLk5AtrGnwNsiB2Xydq4eUU7TbdntZLyB3 S9NpUN+AGSIHHyhYTzcECMX7055OIQ2E0S63/S9u93GTf+EcZ2npYVnKLF/vbqvKKL9A 1c8MkiwWMeIOjHvaPl7g0x05+f8aSPTxt1++wMhTNg5KcJQ0XINUDRDhuTLsBtm9MV9C uK8GLNGx+X6bzuWYasy360+o4+HDf5Vu+i2nmHAQsGqdxiu3zHdGxQpZ7fD+g2HtUMdr Nl4cdaFuAfSrdkFO5WrWhwvyYsa22acKRZD6oIjlWCQU2uqAxQLnYlQlORjNWBg6/DOR UEiw==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=nIs3HW56; arc=pass (i=1 dkim=pass dkdomain=intel.com dmarc=pass fromdomain=linux.intel.com); spf=pass (google.com: domain of linux-kernel+bounces-61255-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-61255-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com X-Forwarded-Encrypted: i=2; AJvYcCV0Kw/KguvualR7yojOtJV29f9/sQaiAH+CAL9Wz545o1EvX1G1KqN7p/U3uP/OrJHkuBmWRTUiazclo3Ac+LKmL4olzQ== Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id n15-20020a05622a11cf00b0042c7c75dd84si4540qtk.77.2024.02.12.01.46.49 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Feb 2024 01:46:49 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-61255-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=nIs3HW56; arc=pass (i=1 dkim=pass dkdomain=intel.com dmarc=pass fromdomain=linux.intel.com); spf=pass (google.com: domain of linux-kernel+bounces-61255-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-61255-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 4E4001C2101A for <ouuuleilei@gmail.com>; Mon, 12 Feb 2024 09:46:49 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 72DB817C7B; Mon, 12 Feb 2024 09:46:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="nIs3HW56" Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E37B717BA8 for <linux-kernel@vger.kernel.org>; Mon, 12 Feb 2024 09:46:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.11 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707731186; cv=none; b=Putb+Pj0Ye1PFuIdngZ5uChG9aHd7CinKmS0nSUOYX9ILpxO7YL39mcUiO5ctV0ucn1iOfARqiqXsX8UWdQJqgRRvMaohbMsSRT71TKuVZgXd00med4IuwV/LpMlnRkx8LQU/4bj0OfReuLJFwdmDombQKJQeBhLP4/1fgf0RPc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707731186; c=relaxed/simple; bh=h5gYrH/ws8FrpMWJe8FAI2E4iZamVDZXdp6p7sFZnQY=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=aaAzUYlznATpQHYrnTI0kfVstzYN6Gbpv3x01QH4GAA3b/sZ6q2ffaAOThzgqcdgb7ItjDDwUp/sQcjZ/2Gpce8Xq1UO/Xe5aCTytD7u9pBewywYM208NxMozwswhOXSLeATDoKOh9oalZ3jvW3rRyTJRE3a6mNbpmftFuVO0HY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=nIs3HW56; arc=none smtp.client-ip=192.198.163.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1707731185; x=1739267185; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=h5gYrH/ws8FrpMWJe8FAI2E4iZamVDZXdp6p7sFZnQY=; b=nIs3HW56WbLfYWBxnpOhc2c1NWPltX8dQHm4mSWLMq/LFIVhmIzQElN/ kJ3XNdr0+FAM2rp+vb2xR/akvoeGfueuioY5IVhgE9ErPo2dam/w3jQGI +bmJNKJNo/7SOs/vWX6mnNmvpCZLrOzRiZj2EmNZjRdWM0XXXp1UtyOhd XtHbw0KpzGZfEyL+FjwxCj8mw91LqD3xIpWu1WO3Fs3ioZVaQT+xaR3FX DUjhZZCk+cnR9oa9QpYG7cY8+6jRfzxkF+PMWaXQQFcCGYAUSRFBkkfyM G6L6NbLTSioIDaurbAAgHeR/xgh7agilmepLDFUoG/E9AY5vtw3RlVKeG Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10981"; a="12335871" X-IronPort-AV: E=Sophos;i="6.05,262,1701158400"; d="scan'208";a="12335871" Received: from fmviesa007.fm.intel.com ([10.60.135.147]) by fmvoesa105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Feb 2024 01:46:24 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.05,262,1701158400"; d="scan'208";a="2502527" Received: from turnipsi.fi.intel.com (HELO kekkonen.fi.intel.com) ([10.237.72.44]) by fmviesa007-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Feb 2024 01:46:22 -0800 Received: from svinhufvud.ger.corp.intel.com (localhost [IPv6:::1]) by kekkonen.fi.intel.com (Postfix) with ESMTP id C956611F86A; Mon, 12 Feb 2024 11:46:18 +0200 (EET) From: Sakari Ailus <sakari.ailus@linux.intel.com> To: linux-kernel@vger.kernel.org Cc: Hans de Goede <hdegoede@redhat.com>, Tomas Winkler <tomas.winkler@intel.com>, Wentong Wu <wentong.wu@intel.com>, Arnd Bergmann <arnd@arndb.de>, Greg Kroah-Hartman <gregkh@linuxfoundation.org> Subject: [PATCH 0/3] MEI VSC fixes and cleanups Date: Mon, 12 Feb 2024 11:46:15 +0200 Message-Id: <20240212094618.344921-1-sakari.ailus@linux.intel.com> X-Mailer: git-send-email 2.39.2 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1790685960464076617 X-GMAIL-MSGID: 1790685960464076617 |
Series | MEI VSC fixes and cleanups | |
Message
Sakari Ailus
Feb. 12, 2024, 9:46 a.m. UTC
Hi folks, These patches address sleeping in atomic context. It wasn't obvious at first this was taking place since the callback sleeps while the caller (a different driver) called it in a threaded IRQ handler. Sakari Ailus (3): mei: vsc: Call wake_up() and event handler in a workqueue mei: vsc: Don't use sleeping condition in wait_event_timeout() mei: vsc: Assign pinfo fields in variable declaration drivers/misc/mei/vsc-tp.c | 64 ++++++++++++++++++++++++--------------- 1 file changed, 40 insertions(+), 24 deletions(-)
Comments
On Mon, Feb 12, 2024 at 11:46:18AM +0200, Sakari Ailus wrote: > Assign all possible fields of pinfo in variable declaration, instead of > just zeroing it there. > > Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> > --- > drivers/misc/mei/vsc-tp.c | 16 ++++++++-------- > 1 file changed, 8 insertions(+), 8 deletions(-) > > diff --git a/drivers/misc/mei/vsc-tp.c b/drivers/misc/mei/vsc-tp.c > index 200af14490d7..1eda2860f63b 100644 > --- a/drivers/misc/mei/vsc-tp.c > +++ b/drivers/misc/mei/vsc-tp.c > @@ -447,11 +447,16 @@ static int vsc_tp_match_any(struct acpi_device *adev, void *data) > > static int vsc_tp_probe(struct spi_device *spi) > { > - struct platform_device_info pinfo = { 0 }; > + struct vsc_tp *tp; > + struct platform_device_info pinfo = { > + .name = "intel_vsc", > + .data = &tp, > + .size_data = sizeof(tp), > + .id = PLATFORM_DEVID_NONE, > + }; But now you have potential stack data in the structure for the fields that you aren't assigning here, right? Is that acceptable, or will it leak somewhere? This is why we generally do not do this type of style. So unless you are fixing an issue here, please don't do it. thanks, greg k-h
On Mon, Feb 12, 2024, at 11:02, Greg Kroah-Hartman wrote: > On Mon, Feb 12, 2024 at 11:46:18AM +0200, Sakari Ailus wrote: >> Assign all possible fields of pinfo in variable declaration, instead of >> just zeroing it there. >> >> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> >> --- >> drivers/misc/mei/vsc-tp.c | 16 ++++++++-------- >> 1 file changed, 8 insertions(+), 8 deletions(-) >> >> diff --git a/drivers/misc/mei/vsc-tp.c b/drivers/misc/mei/vsc-tp.c >> index 200af14490d7..1eda2860f63b 100644 >> --- a/drivers/misc/mei/vsc-tp.c >> +++ b/drivers/misc/mei/vsc-tp.c >> @@ -447,11 +447,16 @@ static int vsc_tp_match_any(struct acpi_device *adev, void *data) >> >> static int vsc_tp_probe(struct spi_device *spi) >> { >> - struct platform_device_info pinfo = { 0 }; >> + struct vsc_tp *tp; >> + struct platform_device_info pinfo = { >> + .name = "intel_vsc", >> + .data = &tp, >> + .size_data = sizeof(tp), >> + .id = PLATFORM_DEVID_NONE, >> + }; > > But now you have potential stack data in the structure for the fields > that you aren't assigning here, right? Is that acceptable, or will it > leak somewhere? > > This is why we generally do not do this type of style. So unless you > are fixing an issue here, please don't do it. If you have any initializer, all named fields in the structure are zeroed. The only bits of the structure that may contain stack data are for padding between fields, but that doesn't actually change here from the previous version. The old version you have here just skips the named fields and otherwise would end up lookingn like struct platform_device_info pinfo = { .parent = 0, }; which is still a partial initializer and has the added problem of relying on a literal '0' as a NULL pointer. In modern compilers, one can write this as struct platform_device_info pinfo = {}, but Sakari's version looks best to me. Arnd
On Mon, Feb 12, 2024 at 11:14:29AM +0100, Arnd Bergmann wrote: > On Mon, Feb 12, 2024, at 11:02, Greg Kroah-Hartman wrote: > > On Mon, Feb 12, 2024 at 11:46:18AM +0200, Sakari Ailus wrote: > >> Assign all possible fields of pinfo in variable declaration, instead of > >> just zeroing it there. > >> > >> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> > >> --- > >> drivers/misc/mei/vsc-tp.c | 16 ++++++++-------- > >> 1 file changed, 8 insertions(+), 8 deletions(-) > >> > >> diff --git a/drivers/misc/mei/vsc-tp.c b/drivers/misc/mei/vsc-tp.c > >> index 200af14490d7..1eda2860f63b 100644 > >> --- a/drivers/misc/mei/vsc-tp.c > >> +++ b/drivers/misc/mei/vsc-tp.c > >> @@ -447,11 +447,16 @@ static int vsc_tp_match_any(struct acpi_device *adev, void *data) > >> > >> static int vsc_tp_probe(struct spi_device *spi) > >> { > >> - struct platform_device_info pinfo = { 0 }; > >> + struct vsc_tp *tp; > >> + struct platform_device_info pinfo = { > >> + .name = "intel_vsc", > >> + .data = &tp, > >> + .size_data = sizeof(tp), > >> + .id = PLATFORM_DEVID_NONE, > >> + }; > > > > But now you have potential stack data in the structure for the fields > > that you aren't assigning here, right? Is that acceptable, or will it > > leak somewhere? > > > > This is why we generally do not do this type of style. So unless you > > are fixing an issue here, please don't do it. > > If you have any initializer, all named fields in the structure > are zeroed. The only bits of the structure that may contain > stack data are for padding between fields, but that doesn't > actually change here from the previous version. I thought we had looked into that before and it would 0 out everything if you just had the {0} initializer, including holes? Or was it not, or did it depend on the compiler/version? Sorry, I never remember and so just recommend a memset which should be the same overall. > The old version you have here just skips the named fields > and otherwise would end up lookingn like > > struct platform_device_info pinfo = { > .parent = 0, > }; > > which is still a partial initializer and has the added > problem of relying on a literal '0' as a NULL pointer. > In modern compilers, one can write this as > struct platform_device_info pinfo = {}, but Sakari's > version looks best to me. Ok, as long as there's no stale stack data, I'm ok with it. thanks, greg k-h