Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp3060483ybp; Sun, 6 Oct 2019 04:01:13 -0700 (PDT) X-Google-Smtp-Source: APXvYqz4MVmJnQw+qJrYxqF9TCDSlAS8UbANngDyRll1l0eYIZR+3vflwYVPkXj8iwM460V5/b+n X-Received: by 2002:a17:906:1248:: with SMTP id u8mr18955050eja.172.1570359672975; Sun, 06 Oct 2019 04:01:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570359672; cv=none; d=google.com; s=arc-20160816; b=uWOZi6zQdmnhbIKc7PSHvHbAlCgMakIMdemJDn3abnlOR/3b5ZbmsHIGP0a4F/z/tl +Vz2JRjICuK58E43H136+pjydV8r0Cs7fTyKE9ddInEm+GXqxbfK2Cdn9eAjVCKbPD/E DgGiRkra/nwuODtscfaK0aBF54dZzchEWTSaJpV20EWe+Z6sJFZ1+C6e3zQPyXyFce6I 6p6oPclkwATgE+qAYDg/6r+mM/6YKWXSIXtF4RnUNkCSpOALo/Z1hxhdsksxM6i3nfSS 9vWseODNDJ+wIMbs05aP+ArSW/EddeftrVDNy0UJEwBzqveMC25DJwwfiwLrHiu2sYKl cung== 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; bh=mWMVOLEhHnN0fhtVcchTo8wqPHTBv4mWSzdfdTwt/zQ=; b=duBvRyKM5C0CcQV1FtPLdH5klkiv5/dT2QSZ0sZfVUBP23u+4HDmRxyDRU0C0SuMHt ZyNFnCFIYJSkwjtZpx1uXZfSdx+TX/yUh1r/io3kSEFJceEzlHeeNbHnVtb/uix2C9gC r/roz3gbmAX1TFcsAOZICCYsJ3TEEuXOzTGvZiDu5nzpKu+Lx0Jp5SyY4FQTRjlpt7VL zyeBrp4T6iC/+hPGFvZH5UyV8N+clQ40sljyt/H5duuOLZy9wc13lbOBj1kdJ10uju4I 97oMNp3d+oCmG+b0UEZZw+MBuDKQYZjZUW4utDpJLG4+PI/tXhMW3898p3pT7wfM6KvT syFg== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f2si5379076ejw.335.2019.10.06.04.00.48; Sun, 06 Oct 2019 04:01:12 -0700 (PDT) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726591AbfJFK7h (ORCPT + 99 others); Sun, 6 Oct 2019 06:59:37 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:53464 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726250AbfJFK7g (ORCPT ); Sun, 6 Oct 2019 06:59:36 -0400 Received: from [213.220.153.21] (helo=wittgenstein) by youngberry.canonical.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1iH4GB-0007pU-N7; Sun, 06 Oct 2019 10:59:31 +0000 Date: Sun, 6 Oct 2019 12:59:31 +0200 From: Christian Brauner To: Dmitry Vyukov Cc: syzbot , bsingharora@gmail.com, Marco Elver , LKML , syzkaller-bugs Subject: Re: [PATCH] taskstats: fix data-race Message-ID: <20191006105930.5a5jxislaqpzmo22@wittgenstein> References: <0000000000009b403005942237bf@google.com> <20191005112806.13960-1-christian.brauner@ubuntu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Oct 06, 2019 at 12:00:32PM +0200, Dmitry Vyukov wrote: > On Sat, Oct 5, 2019 at 1:28 PM Christian Brauner > wrote: > > > > When assiging and testing taskstats in taskstats > > taskstats_exit() there's a race around writing and reading sig->stats. > > > > cpu0: > > task calls exit() > > do_exit() > > -> taskstats_exit() > > -> taskstats_tgid_alloc() > > The task takes sighand lock and assigns new stats to sig->stats. > > > > cpu1: > > task catches signal > > do_exit() > > -> taskstats_tgid_alloc() > > -> taskstats_exit() > > The tasks reads sig->stats __without__ holding sighand lock seeing > > garbage. > > > > Fix this by taking sighand lock when reading sig->stats. > > > > Reported-by: syzbot+c5d03165a1bd1dead0c1@syzkaller.appspotmail.com > > Signed-off-by: Christian Brauner > > --- > > kernel/taskstats.c | 28 +++++++++++++++++----------- > > 1 file changed, 17 insertions(+), 11 deletions(-) > > > > diff --git a/kernel/taskstats.c b/kernel/taskstats.c > > index 13a0f2e6ebc2..58b145234c4a 100644 > > --- a/kernel/taskstats.c > > +++ b/kernel/taskstats.c > > @@ -553,26 +553,32 @@ static int taskstats_user_cmd(struct sk_buff *skb, struct genl_info *info) > > > > static struct taskstats *taskstats_tgid_alloc(struct task_struct *tsk) > > { > > + int empty; > > + struct taskstats *stats_new, *stats = NULL; > > struct signal_struct *sig = tsk->signal; > > - struct taskstats *stats; > > - > > - if (sig->stats || thread_group_empty(tsk)) > > - goto ret; > > > > /* No problem if kmem_cache_zalloc() fails */ > > - stats = kmem_cache_zalloc(taskstats_cache, GFP_KERNEL); > > + stats_new = kmem_cache_zalloc(taskstats_cache, GFP_KERNEL); > > This seems to be over-pessimistic wrt performance b/c: > 1. We always allocate the object and free it on every call, even if > the stats are already allocated, whereas currently we don't. > 2. We always allocate the object and free it if thread_group_empty, > whereas currently we don't. > 3. We do lock/unlock on every call. > > I would suggest to fix the double-checked locking properly. As I said in my reply to Marco: I'm integrating this. I just haven't had time to update the patch. Christian