Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp2272912ybe; Tue, 3 Sep 2019 10:19:27 -0700 (PDT) X-Google-Smtp-Source: APXvYqwvd2ErJjkDxvBkMt/mgm1eYHaVHg+CvS6wqrWQAwxBamA2NO8/ghyXWN5SMqEDf6jL+TdC X-Received: by 2002:a17:902:d907:: with SMTP id c7mr26951203plz.126.1567531167702; Tue, 03 Sep 2019 10:19:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567531167; cv=none; d=google.com; s=arc-20160816; b=TnjcSpRu9XJQSoUVDwRx9V+Be2ipHeAA0j6nSDtiRVZoziiXGAcsjFVvSsouS6+pLs MhnyftAe24/GLDLzxIk66y4LmviYTenONRdVAT7MSjwt12x897W5v8D7oSKujwMjDxlZ lzJ+dlyBAMR6wdANgdrYl1wNyuw36bqQHw3uaPvxofJpc8AS9FlT9VgiGbzi62/HV7Yi cBkDkSdLNyVjjSoiCh4w5ivKWmf7pjuy/YyWGG9wvlFnV4k0bBQcrBNKwDbIAhZpSEO8 f7DDQmXQYe2J26s0pXjRwVHaJkOwLHNr14LgQHYQo8TUBYZfF8kylmUud7/Zb8cbCdLv iEAw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=cLOm2Eg72s6UA/ZXe4AECd7A1BxdB3xoIDp/exZAX60=; b=RLeOoiVEYQigMUOW15VgQMwcNEZdqpB1EBuuqyFL99CJOpdyw0/922CK5KMqEsLOFg h8NzNjpPd8kbEvklnItHH+M+KOS1Q5cLRcDXkneHptKNZseVoKT8WVN/tj6evZnNjpXo zqj5AZmzYjdlA5mtEoo4jcK6y3xx8WNj6gArvpK5h2K73E9fSwBnlwkdAt1uy2h5RTQ+ IY68miRJG/ZGRsNKy7s3e0/IZxXUIKybhuAg27liMP5wAJlskLaPIJkrUD9O4Do1ZjpO p/rsm/L7ZqGl9iEuL+3ovopS4YnIB2L9cn3wd288sEOqzkZ6qcw+5zsDiFYzx0giupKj 1ZyA== 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=canonical.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u20si14883877pgg.565.2019.09.03.10.19.12; Tue, 03 Sep 2019 10:19:27 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730175AbfICRRF (ORCPT + 99 others); Tue, 3 Sep 2019 13:17:05 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:54298 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729499AbfICRRE (ORCPT ); Tue, 3 Sep 2019 13:17:04 -0400 Received: from 1.general.cascardo.us.vpn ([10.172.70.58] helo=localhost.localdomain) by youngberry.canonical.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1i5CQQ-0006gX-1l; Tue, 03 Sep 2019 17:17:02 +0000 From: Thadeu Lima de Souza Cascardo To: linux-kernel@vger.kernel.org Cc: Peter Zijlstra , Ingo Molnar , Thadeu Lima de Souza Cascardo , Patrick Bellasi Subject: [PATCH 2/2] sched: allow sched_getattr with old size Date: Tue, 3 Sep 2019 14:16:45 -0300 Message-Id: <20190903171645.28090-2-cascardo@canonical.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190903171645.28090-1-cascardo@canonical.com> References: <20190903171645.28090-1-cascardo@canonical.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org After commit a509a7cd7974 (sched/uclamp: Extend sched_setattr() to support utilization clamping), using sched_getattr with size 48 will return E2BIG. This breaks, for example, chrt. $ chrt -p $$ chrt: failed to get pid 26306's policy: Argument list too long $ With this fix, when using the old size, the utilization clamping values will be absent from sched_attr. When using the new size or some larger size, they will be present. After the fix, chrt works again. $ chrt -p $$ pid 4649's current scheduling policy: SCHED_OTHER pid 4649's current scheduling priority: 0 $ The drawback with this solution is that userspace will ignore there are non-default utilization clamps, but it's arguable whether returning E2BIG in this case makes sense when that same userspace doesn't know about those values anyway. Signed-off-by: Thadeu Lima de Souza Cascardo Fixes: a509a7cd7974 (sched/uclamp: Extend sched_setattr() to support utilization clamping) Cc: Patrick Bellasi --- kernel/sched/core.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 0fd67281e656..0ccc7fa80da6 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -5183,8 +5183,10 @@ SYSCALL_DEFINE4(sched_getattr, pid_t, pid, struct sched_attr __user *, uattr, attr.sched_nice = task_nice(p); #ifdef CONFIG_UCLAMP_TASK - attr.sched_util_min = p->uclamp_req[UCLAMP_MIN].value; - attr.sched_util_max = p->uclamp_req[UCLAMP_MAX].value; + if (size >= SCHED_ATTR_SIZE_VER1) { + attr.sched_util_min = p->uclamp_req[UCLAMP_MIN].value; + attr.sched_util_max = p->uclamp_req[UCLAMP_MAX].value; + } #endif rcu_read_unlock(); -- 2.20.1