Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3253299imu; Fri, 18 Jan 2019 07:21:30 -0800 (PST) X-Google-Smtp-Source: ALg8bN7h4EuG1nHLcrqMVdVFrvUCHk8TIulDm276NaiA+sjTKE+n0c3AJzKMaNPpi0LQjqpftfdG X-Received: by 2002:a63:db02:: with SMTP id e2mr18347352pgg.419.1547824890100; Fri, 18 Jan 2019 07:21:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547824890; cv=none; d=google.com; s=arc-20160816; b=TxGjWeBsG/pLphXZsR/GnhTzCpb93E4c60uu2xHnJnq5BeGr1TIat0MSs/o7Km0ift fhn1aAGidMYU2/8KvyHeO2MJ4aURtzCT9ePfQafs8s8k87sVeCurTTBWKJd3IbUx3q2W AsnffYvPljcGham8jMdzbFz8tkRzfOtnE7OgKbIkgz6qdRJMQ7HW17GLTzMe/m2VF1Io QDJDcWJLmg+4fkympmITbjAjpAssJ9rdySQznoJ/mBkEnWkFT8xhV8AVxGw8DHxwvdvq OYp7uync+hP+cOQK9pE5wS9Mr9kCVqx+v9X5Zzx2C6k5q0BWhO7eVMl/Ezfr4RMxrM39 2WvA== 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=98FiCnrw9JYgf+A9kHZFlw177h7QnYfW6Bgdqo25DKk=; b=oCcEKXpNtRRrKssCUjeExZLLq7I63CuTyO3yhsLWl3ll5CR7sSDGbEUZpz82j6lPWs AShxlw0tA6LKfmyIc+0sNIW+ZkYOrpgGvrw2GILuQ2W1zlPWBbmRKK69HVFI06t+2TyS DQOqMcGw1aPfGO9KgvvwqxTtyWX3RQf7Ab72v2LttzLKCMptd0azh9dRtBwmg4+ruUa3 sKFZ3/deCQNzbOt5VkXhnmqt9OgTtIRjAbOWB9q/eiwL/eX32OY7PfzNsZjP/jXJurJN MhO/lJxAlmZNQTNL4ABCQKa+rq/TvDyaCIOyBhpO69iiXBKMyq7H+V8u6s7A5anX8ItL /SGQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@joelfernandes.org header.s=google header.b=o4mo5ipB; 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 e4si4869559plk.260.2019.01.18.07.21.14; Fri, 18 Jan 2019 07:21:30 -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=pass header.i=@joelfernandes.org header.s=google header.b=o4mo5ipB; 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 S1727779AbfARPTp (ORCPT + 99 others); Fri, 18 Jan 2019 10:19:45 -0500 Received: from mail-qt1-f196.google.com ([209.85.160.196]:39518 "EHLO mail-qt1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727448AbfARPTp (ORCPT ); Fri, 18 Jan 2019 10:19:45 -0500 Received: by mail-qt1-f196.google.com with SMTP id u47so15542090qtj.6 for ; Fri, 18 Jan 2019 07:19:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelfernandes.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=98FiCnrw9JYgf+A9kHZFlw177h7QnYfW6Bgdqo25DKk=; b=o4mo5ipBUk9/xXbZPBEGvBRxyd/7L8tovfv5XeLAX8wHtUXaUJ/7HumfdP7lY4Fiyy kofMpIEOnPfHiiDBKEAln2q3rDCs8BzWmWIJFCVDHYigGlvBcPmdfvs6K+A+FOUnovv0 lX0rEihiwRxKSqWT5NqjKkOq8ryf6FVZpZMxg= 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=98FiCnrw9JYgf+A9kHZFlw177h7QnYfW6Bgdqo25DKk=; b=PtuSY6vVn0CM87FgOs7jPaLDaWYw58UzIAyaXnUKqq1qbvsiulSl9AqjJFYNo3Tq7H pDzKJeijgUvpLskQRWXM8jAH/DE/7wYuRN1e8jCsxZdF1WEoSA3FIJy7oTlbzwOZTu2P Io+hd7INTDfOKgXPsmW8NE+5CCUGpNEHRgOLrSrMwhwyx7RLjYuaepNTrUu+RhAupK5s iCUDvFCaAi1Z1MpDHBQWwnbt2RlEyZtUd67OpI1kmiorp9DrIMAf2nxZaMGXarWVdSNz qBBksXvzBp0BHzzhQpTE+arKP/6N7AAjq/X4weMH95uXQ+9gXZnS43cBeyH1KCm4fKFl 5+Wg== X-Gm-Message-State: AJcUukfo2YlooiFZMMkh1hTNCx3bJ/iqILCr5C7wox1TsO0Lu9IoQZ+l b1kevcvpgCQbSheL+G641aQ++Q== X-Received: by 2002:aed:3aa7:: with SMTP id o36mr16268389qte.240.1547824783575; Fri, 18 Jan 2019 07:19:43 -0800 (PST) Received: from localhost ([2620:0:1004:1100:cca9:fccc:8667:9bdc]) by smtp.gmail.com with ESMTPSA id g23sm66585862qta.24.2019.01.18.07.19.41 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 18 Jan 2019 07:19:42 -0800 (PST) Date: Fri, 18 Jan 2019 10:19:41 -0500 From: Joel Fernandes To: Hugo Lefeuvre Cc: Greg Kroah-Hartman , Greg Hartman , Alistair Strachan , Arve =?iso-8859-1?B?SGr4bm5lduVn?= , Todd Kjos , Martijn Coenen , Christian Brauner , Ingo Molnar , Peter Zijlstra , devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] sched/wait: introduce wait_event_freezable_hrtimeout Message-ID: <20190118151941.GB187589@google.com> References: <20190117224135.GC8100@hle-laptop.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190117224135.GC8100@hle-laptop.local> 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 Hi Hugo, On Thu, Jan 17, 2019 at 11:41:35PM +0100, Hugo Lefeuvre wrote: > introduce wait_event_freezable_hrtimeout, an interruptible and freezable > version of wait_event_hrtimeout. > > simplify handle_vsoc_cond_wait (drivers/staging/android/vsoc.c) using this > newly added helper and remove useless includes. I believe these should be 2 patches. In the first patch you introduce the new API, in the second one you would simplify the VSOC driver. In fact, in one part of the patch you are using wait_event_freezable which already exists so that's unrelated to the new API you are adding. More comments below: > Signed-off-by: Hugo Lefeuvre > --- > drivers/staging/android/vsoc.c | 69 +++++----------------------------- > include/linux/wait.h | 25 ++++++++++-- > 2 files changed, 31 insertions(+), 63 deletions(-) > > diff --git a/drivers/staging/android/vsoc.c b/drivers/staging/android/vsoc.c > index 22571abcaa4e..7e620e69f39d 100644 > --- a/drivers/staging/android/vsoc.c > +++ b/drivers/staging/android/vsoc.c > @@ -17,7 +17,6 @@ > */ > > #include > -#include > #include > #include > #include > @@ -29,7 +28,6 @@ > #include > #include > #include > -#include > #include > #include > #include "uapi/vsoc_shm.h" > @@ -401,7 +399,6 @@ static int handle_vsoc_cond_wait(struct file *filp, struct vsoc_cond_wait *arg) > DEFINE_WAIT(wait); > u32 region_number = iminor(file_inode(filp)); > struct vsoc_region_data *data = vsoc_dev.regions_data + region_number; > - struct hrtimer_sleeper timeout, *to = NULL; > int ret = 0; > struct vsoc_device_region *region_p = vsoc_region_from_filep(filp); > atomic_t *address = NULL; > @@ -420,69 +417,23 @@ static int handle_vsoc_cond_wait(struct file *filp, struct vsoc_cond_wait *arg) > /* Ensure that the type of wait is valid */ > switch (arg->wait_type) { > case VSOC_WAIT_IF_EQUAL: > + ret = wait_event_freezable(data->futex_wait_queue, > + arg->wakes++ && > + atomic_read(address) != arg->value); > break; > case VSOC_WAIT_IF_EQUAL_TIMEOUT: > - to = &timeout; > - break; > - default: > - return -EINVAL; > - } > - > - if (to) { > - /* Copy the user-supplied timesec into the kernel structure. > - * We do things this way to flatten differences between 32 bit > - * and 64 bit timespecs. > - */ > if (arg->wake_time_nsec >= NSEC_PER_SEC) > return -EINVAL; > wake_time = ktime_set(arg->wake_time_sec, arg->wake_time_nsec); > - > - hrtimer_init_on_stack(&to->timer, CLOCK_MONOTONIC, > - HRTIMER_MODE_ABS); > - hrtimer_set_expires_range_ns(&to->timer, wake_time, > - current->timer_slack_ns); > - > - hrtimer_init_sleeper(to, current); > + ret = wait_event_freezable_hrtimeout(data->futex_wait_queue, > + arg->wakes++ && > + atomic_read(address) != arg->value, > + wake_time); > + break; > + default: > + return -EINVAL; > } > > - while (1) { > - prepare_to_wait(&data->futex_wait_queue, &wait, > - TASK_INTERRUPTIBLE); > - /* > - * Check the sentinel value after prepare_to_wait. If the value > - * changes after this check the writer will call signal, > - * changing the task state from INTERRUPTIBLE to RUNNING. That > - * will ensure that schedule() will eventually schedule this > - * task. > - */ > - if (atomic_read(address) != arg->value) { > - ret = 0; > - break; > - } > - if (to) { > - hrtimer_start_expires(&to->timer, HRTIMER_MODE_ABS); > - if (likely(to->task)) > - freezable_schedule(); > - hrtimer_cancel(&to->timer); > - if (!to->task) { > - ret = -ETIMEDOUT; > - break; > - } > - } else { > - freezable_schedule(); > - } > - /* Count the number of times that we woke up. This is useful > - * for unit testing. > - */ > - ++arg->wakes; > - if (signal_pending(current)) { > - ret = -EINTR; > - break; > - } > - } > - finish_wait(&data->futex_wait_queue, &wait); > - if (to) > - destroy_hrtimer_on_stack(&to->timer); > return ret; > } > > diff --git a/include/linux/wait.h b/include/linux/wait.h > index ed7c122cb31f..13a454884f8b 100644 > --- a/include/linux/wait.h > +++ b/include/linux/wait.h > @@ -483,7 +483,7 @@ do { \ > __ret; \ > }) > > -#define __wait_event_hrtimeout(wq_head, condition, timeout, state) \ > +#define __wait_event_hrtimeout(wq_head, condition, timeout, state, cmd) \ > ({ \ > int __ret = 0; \ > struct hrtimer_sleeper __t; \ > @@ -500,7 +500,7 @@ do { \ > __ret = -ETIME; \ > break; \ > } \ > - schedule()); \ > + cmd); \ > \ > hrtimer_cancel(&__t.timer); \ > destroy_hrtimer_on_stack(&__t.timer); \ > @@ -529,7 +529,23 @@ do { \ > might_sleep(); \ > if (!(condition)) \ > __ret = __wait_event_hrtimeout(wq_head, condition, timeout, \ > - TASK_UNINTERRUPTIBLE); \ > + TASK_UNINTERRUPTIBLE, \ > + schedule()); \ > + __ret; \ > +}) > + > +/* > + * like wait_event_hrtimeout() -- except it uses TASK_INTERRUPTIBLE to avoid > + * increasing load and is freezable. > + */ > +#define wait_event_freezable_hrtimeout(wq_head, condition, timeout) \ You should document the variable names in the header comments. Also, this new API appears to conflict with definition of 'freezable' in wait_event_freezable I think, wait_event_freezable - sleep or freeze until condition is true. wait_event_freezable_hrtimeout - sleep but make sure freezer is not blocked. (your API) It seems to me these are 2 different definitions of 'freezing' (or I could be completely confused). But in the first case it calls try_to_freeze after schedule(). In the second case (your new API), it calls freezable_schedule(). So I am wondering why is there this difference in the 'meaning of freezable'. In the very least, any such subtle differences should be documented in the header comments IMO. thanks! - Joel