Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2758670imu; Mon, 19 Nov 2018 05:44:50 -0800 (PST) X-Google-Smtp-Source: AJdET5cjiUzPoHlyjQ8YZRQxr0ZsUj87OLbHolArGJYdbmUVxnrZqJYHSz01Fb8vtTSAWBEQ+NNJ X-Received: by 2002:a63:ef47:: with SMTP id c7mr20409373pgk.386.1542635090244; Mon, 19 Nov 2018 05:44:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542635090; cv=none; d=google.com; s=arc-20160816; b=ut83EQN1CB2qaKstjzUqLqLXn1xBBf9qa/hGWqRBNP9UnHpehZdbBdzGOds9MgdY9H w06TMDveyLhcqlPnPhYKfZqlhwLCB8wnrSlXfT39r0H6POObgi7QP+C/rDQuAP1RFr6O 5BmtMgpO3/jVyQITmxzRBXujXxNV7XtVxsPjZT8wW6jQyGQhg3A+yzibKgVSdfY2Ih82 DXHoWRd7thVhQKH9Q1MMeIbLTQ8ZmByiG6htSG1q+3FLqQtIl8x6Axu6OS5JbeYw0g+/ 1Xkh2hyB6tcKHDmuOY0s8BUFqX3o7/sZ7/X/Pc5tz37mo8G5+MSuuQwo00orffVYtMFp ct6w== 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=UNdh24OgljeNzNAVQrGrAEsZQ5CXN58xq5RU/xcXQZ0=; b=CZSGoTOPAcUgsQCUV0PjBiZO0W6AEqlripUKDNNSpwvA5GVpAdMLmqGcSHwX5WvApa mrhrp9qFjhqD2hOJMx5HoixuVvrwWuF6Jdnq+QCAa+Ffpv3s339F5hZsITkY4DMjtHA7 mS7CVZvRa1kOYTsNKaB1WyDxB/saFnz1IADzJYEYSm+VFvLZw7oFHZEx0dnfparN7z3E aSL2J2ekHgP+n2iNiBm97hIC89mZDCeneIuo1TwEF6HfDtzQI3kgDciLL/12R0L3ZFPc 7rC50gFslT5gMZ5Yq0ssgqyCtiHW2ARDR4dfIuRdYRVRQIhBKLPTukrDle82pStIQuyt OfIw== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c19si24086439pls.242.2018.11.19.05.44.35; Mon, 19 Nov 2018 05:44:50 -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; 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=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728735AbeKTAHf (ORCPT + 99 others); Mon, 19 Nov 2018 19:07:35 -0500 Received: from mail-wr1-f67.google.com ([209.85.221.67]:45944 "EHLO mail-wr1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727059AbeKTAHe (ORCPT ); Mon, 19 Nov 2018 19:07:34 -0500 Received: by mail-wr1-f67.google.com with SMTP id v6so10257149wrr.12 for ; Mon, 19 Nov 2018 05:43:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=UNdh24OgljeNzNAVQrGrAEsZQ5CXN58xq5RU/xcXQZ0=; b=DbsFiC3iWmbCFV7M+EyWQXwgpDQFTA4opGLbBIdUG2iNk7O7tGNNPEpWiPuBlYGHTt c6ZOP94hIdP4D1tL5h9RbK9kuFy510YGOPnAk0cvvybNORyAqeHe3K2hDvfKmAQFOr9r 4uCg7xZZ4cqdz9a3u268eHIMYjzUXiLt9weJ+ur0MWxFPT+cY6VHc+gRZsNbdjO0AZ0x h2MAaKjtwXe5tKXK6qgpNVUq10zn8XaJsoLXdGq2+AJcn+lp30ZqDYYiYTAlBPThAvC/ CbpBfwiJ3OekQvMFEJJGAtvafnr75zCFCDGudSnZiSKNIF2okqNbspXhTTup2LJ+Dqge +V5A== X-Gm-Message-State: AA+aEWZqj+N5Hzm8CbPXyY6+IHXc1pq2leKUxA8hI11ZubFh1hmMjm/w 3d/Dxqx5X+N0gXUZXhMnwunmtw== X-Received: by 2002:a05:6000:120a:: with SMTP id e10mr16504827wrx.85.1542635033224; Mon, 19 Nov 2018 05:43:53 -0800 (PST) Received: from localhost.localdomain ([151.15.226.84]) by smtp.gmail.com with ESMTPSA id e16sm15060982wrn.72.2018.11.19.05.43.51 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 19 Nov 2018 05:43:52 -0800 (PST) Date: Mon, 19 Nov 2018 14:43:49 +0100 From: Juri Lelli To: Peter Zijlstra Cc: luca abeni , Thomas Gleixner , syzbot , Borislav Petkov , "H. Peter Anvin" , LKML , Andy Lutomirski , mingo@redhat.com, syzkaller-bugs@googlegroups.com, x86@kernel.org, Daniel Bristot de Oliveira Subject: Re: WARNING in enqueue_task_dl Message-ID: <20181119134349.GA2119@localhost.localdomain> References: <000000000000b5e346057af4da06@google.com> <20181119130718.69eddf46@luca64> <20181119125241.GC9761@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181119125241.GC9761@hirez.programming.kicks-ass.net> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 19/11/18 13:52, Peter Zijlstra wrote: > On Mon, Nov 19, 2018 at 01:07:18PM +0100, luca abeni wrote: > > > > On Sun, 18 Nov 2018, syzbot wrote: > > > > > WARNING: CPU: 1 PID: 6351 at kernel/sched/deadline.c:628 > > > > enqueue_task_dl+0x22da/0x38a0 kernel/sched/deadline.c:1504 > > > > Here, it looks like a task is invoking sched_setattr() to become > > SCHED_DEADLINE when dl_boosted is set... > > > > Is this possible / correct? > > Possible, clearly. Correct, only in so far as that it is not a malformed > program, but it is very poor design to actually trigger this (of course > the fuzzer doesn't care about that). > > > If this (sched_setattr() with dl_boosted set) should not be possible, > > then we have a bug that we need to investigate... > > > > Otherwise, I suspect we can just remove the WARN_ON at line 628 of > > deadline.c > > I wonder why we put that WARN in there to begin with... git-blame gives > us: > > 98b0a8578050 ("sched/deadline: Remove useless parameter from setup_new_dl_entity()") > > So the problem seems to be that if we're boosted, we should maybe not be > using our own (newly set) parameters, but those of the donor task. > > Specifically, our 'suboptimal' deadline inheritance scheme 'requires' us > to use the inherited deadline, not our own. So in that respect I think > the WARN is valid, although I'm not sure what, apart from actually > finishing that PE patch-set we can do about it just now. Mmm, but, as it was written in the comment that was removed by 295d6d5 ("sched/deadline: Fix switching to -deadline"), I was still expecting that for a boosted task setup_new_dl_entity() shouldn't be called. Wonder if this is another manifestation of the problems we have with clocks. Need to think more about it.