Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp1900246imj; Fri, 8 Feb 2019 09:08:33 -0800 (PST) X-Google-Smtp-Source: AHgI3IaFJuNuE+Z3mou68Gkc4TDt9pCvrYyCLeWI3DhupsMshommrlbg90L+26/izew4RMYTS3LN X-Received: by 2002:a62:ea09:: with SMTP id t9mr24158703pfh.228.1549645713139; Fri, 08 Feb 2019 09:08:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1549645713; cv=none; d=google.com; s=arc-20160816; b=lORuGJSuomJrPQWSo19LpuZz+txU1tTCjd8d8JopnRLSMJlftjBhe3rdo9QmIgH8Kd +ujGHsZ2hzzWoft1suw4kDSO/IL5SEqavhKoVn5EtSs+EoOvpGe1K8rdtS7oDUNaApKa IW1LOqXbMYoX/JNVLUrC5I6B9YRoY9RWmysALpyfKk+2VGDRlsLt0PQDsqnOKl36B3ot VpmRavP8zVo7nhDoFv+XcoKyjsMJznhT6MJwIiV65Mt9/vgwqrnawz+q9JjngakaKcAh ecAb7CjDTEh7BcQxhBt5+/JKd/2xJiop7yH5z0ztFnPqkSIvyCqZCci5UONYsLvVpn28 nqGQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=5ooj+zw+YBLytS2PSdNmBfDnd/v+4zq3W3AATSUlfrQ=; b=XmkMVYrtXIFrPcOno449+37SQhdF4N8htNU+I+AynIimGKsOce6/judsMIl7d3pgRN B9dGEsCwGBXL7WXPm/OasjOwA1MFlWA1oeo2Se6BrCMAJ4vTS66gq12AIqljHMEpGMX+ 6N8pNo+r7ARUxfmDShcVHzspjSH2onrOWH3SM5YPu/2i9hbPu9LVK0S2HpJZd2KXp2HH dTaPUQeEFab2fjpvSZ3aPLbOUKbiMi0TORttcVZ/u+fFlCAClYbKXbRv2d7877fVmaGh J6vwXrnQ4D0Qw6h/MiADopZYoiwUewgdHs5tUtjbvFm5Fp358nsWaCC/u4nJkBwL5wo5 KN8Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b="OyNXpB/w"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l67si2695845pfc.147.2019.02.08.09.08.16; Fri, 08 Feb 2019 09:08:33 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b="OyNXpB/w"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727797AbfBHRHA (ORCPT + 99 others); Fri, 8 Feb 2019 12:07:00 -0500 Received: from mail-yb1-f196.google.com ([209.85.219.196]:39495 "EHLO mail-yb1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726522AbfBHRHA (ORCPT ); Fri, 8 Feb 2019 12:07:00 -0500 Received: by mail-yb1-f196.google.com with SMTP id s17so1685601ybp.6 for ; Fri, 08 Feb 2019 09:06:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=5ooj+zw+YBLytS2PSdNmBfDnd/v+4zq3W3AATSUlfrQ=; b=OyNXpB/wjXhZXdoTZWUAbiDGAyzKi5GXExY8NE4m+D+/yFj1ABi010xUgC7/Kf5239 drh5+xihn6LGweE1pFf1cCG13xSSRoT/zexKcd98ER4qfanUoGaY29Bw28isfwm65rC3 UsS+IjYBZFLqW3+gVXvJKKdiGpT2+9gRW4IKCA2Uf5pRYhh7gegQDsza9en2ho4zzXfd AsQddL6r55iAm9dyD7AQCvtfJmB7V5kp/GB/c6F2Rmu4frk8seUTLDItGt9fp4/aMHnC zkV5bJG/teFnj2r8sRoHocvp5f1m5lfgZn4lINPKCSN9Db8CYzbrT847HAqnhipAxOQV At+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=5ooj+zw+YBLytS2PSdNmBfDnd/v+4zq3W3AATSUlfrQ=; b=QhnYB4pQWhHQJmiG+/5DO2qA6RJWXnxDNAd2nyRShij1EmwXavqeCIu+6OUb8xfbSO 4WTwmYBbajz5sX+RwtdjO6kWEGodq3uOrfiJ6i4Hl4owwDdfkeXSt61iVpsxY33P7BBT jCraCtYBKMrgPxilNSp8+axicV+BNtcY9EuDWLldKoUy/LvKsFRTFTxZjUp8srl+4i4q 8KxCb7mjRykniaoJdblOb03HFUTH7+Z/mmYXCPBHMxB5dd2fIJPS0dP9EsuTEwAUQVPM oggedEk1HFNEUeI+YuxNEtmCmQvI5j2OL1gwWkaGMm9My49MRp68rabTzUOf4Paup/+b TPIQ== X-Gm-Message-State: AHQUAuZx7lWUy0Ai2TWjnbYvOzlwh6P6LeyhW9aNBbftalcY2JvRDDo7 cZonP6lKIYFeDwwkvMCV8S8= X-Received: by 2002:a25:abf0:: with SMTP id v103mr18932844ybi.429.1549645619244; Fri, 08 Feb 2019 09:06:59 -0800 (PST) Received: from localhost ([2620:10d:c091:180::1:1597]) by smtp.gmail.com with ESMTPSA id s185sm1161081yws.69.2019.02.08.09.06.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Feb 2019 09:06:58 -0800 (PST) Date: Fri, 8 Feb 2019 09:06:56 -0800 From: Tejun Heo To: Sven Van Asbroeck Cc: Lai Jiangshan , linux-kernel@vger.kernel.org, Sebastian Reichel , Dmitry Torokhov , Kees Cook Subject: Re: [RFC v1 1/3] workqueue: Add resource-managed version of INIT_[DELAYED_]WORK() Message-ID: <20190208170656.GL50184@devbig004.ftw2.facebook.com> References: <20190204220952.30761-1-TheSven73@googlemail.com> <20190204220952.30761-2-TheSven73@googlemail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190204220952.30761-2-TheSven73@googlemail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 04, 2019 at 05:09:50PM -0500, Sven Van Asbroeck wrote: > In modules which extensively use devm_ resource management, it is often > easy to overlook (delayed) work that is left pending or running after the > module is unloaded. This could introduce user-after-free issues. > > Nudge kernel developers into 'doing the right thing' by introducing a > resource-managed version of INIT_[DELAYED_]WORK(). This can be used as > an elegant way to ensure that work is not left pending or running after > its dependencies are released. > > Functions introduced in workqueue.h : > - devm_init_work() > - devm_init_delayed_work() I don't object to the basic idea but cancel_[delayed_]work_sync() works iff queueing is disabled already, so there can be situations where this can lead to surprising / subtle failures. Given that, it *might* not be a bad idea to keep this explicit unless there is a way to reliably block future queueing. Thanks. -- tejun