From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752031AbdFORC5 (ORCPT ); Thu, 15 Jun 2017 13:02:57 -0400 Received: from out03.mta.xmission.com ([166.70.13.233]:42031 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750830AbdFORCz (ORCPT ); Thu, 15 Jun 2017 13:02:55 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: "Luis R. Rodriguez" Cc: "Paul E. McKenney" , Josh Triplett , Steven Rostedt , mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com, Paul Gortmaker , Dmitry Torokhov , "linux-kernel\@vger.kernel.org" , Oleg Nesterov , Peter Zijlstra References: <20170614230639.15079-1-mcgrof@kernel.org> <20170614234345.GX3721@linux.vnet.ibm.com> <20170615155039.GP27288@wotan.suse.de> <20170615162201.GB3721@linux.vnet.ibm.com> Date: Thu, 15 Jun 2017 11:55:57 -0500 In-Reply-To: (Luis R. Rodriguez's message of "Thu, 15 Jun 2017 09:35:45 -0700") Message-ID: <87zid92ns2.fsf@xmission.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1dLYAW-0007as-LN;;;mid=<87zid92ns2.fsf@xmission.com>;;;hst=in02.mta.xmission.com;;;ip=67.3.213.87;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX19qvcEaRNc3YK2220bn6Vbsc5f1m0csTY4= X-SA-Exim-Connect-IP: 67.3.213.87 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.0 TVD_RCVD_IP Message was received from an IP address * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5000] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa08 1397; Body=1 Fuz1=1 Fuz2=1] X-Spam-DCC: XMission; sa08 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;"Luis R. Rodriguez" X-Spam-Relay-Country: X-Spam-Timing: total 240 ms - load_scoreonly_sql: 0.03 (0.0%), signal_user_changed: 2.8 (1.2%), b_tie_ro: 2.0 (0.8%), parse: 0.63 (0.3%), extract_message_metadata: 2.2 (0.9%), get_uri_detail_list: 1.00 (0.4%), tests_pri_-1000: 2.9 (1.2%), tests_pri_-950: 0.86 (0.4%), tests_pri_-900: 0.77 (0.3%), tests_pri_-400: 21 (8.8%), check_bayes: 20 (8.5%), b_tokenize: 5 (2.1%), b_tok_get_all: 8 (3.4%), b_comp_prob: 1.57 (0.7%), b_tok_touch_all: 3.6 (1.5%), b_finish: 0.58 (0.2%), tests_pri_0: 200 (83.3%), check_dkim_signature: 0.36 (0.1%), check_dkim_adsp: 3.3 (1.4%), tests_pri_500: 2.9 (1.2%), rewrite_mail: 0.00 (0.0%) Subject: Re: [RFC] rcu: use killable versions of swait X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org "Luis R. Rodriguez" writes: > On Thu, Jun 15, 2017 at 9:22 AM, Paul E. McKenney > wrote: >> On Thu, Jun 15, 2017 at 05:50:39PM +0200, Luis R. Rodriguez wrote: >>> On Wed, Jun 14, 2017 at 04:43:45PM -0700, Paul E. McKenney wrote: >>> > On Wed, Jun 14, 2017 at 04:06:39PM -0700, Luis R. Rodriguez wrote: >>> > > Signed-off-by: Luis R. Rodriguez >>> > > --- >>> > > >>> > > The killable swaits were just posted [1] as part of a series where SIGCHLD >>> > > was detected as interrupting and killing kernel calls waiting using >>> > > non-killable swaits [1]. The fragility here made curious about other callers >>> > > and seeing if they really meant to use such broad wait which captures a lot >>> > > of signals. >>> > > >>> > > I can't see why we'd want to have these killed by other signals, specialy >>> > > since it seems we don't even check for the return value... Granted to abort >>> > > properly we'd have to check for the return value for -ERESTARTSYS, but yeah, >>> > > none of this is done, so it would seem we don't want fragile signals >>> > > interrupting these ? >>> > >>> > The later WARN_ON(signal_pending(current)) complains if a signal somehow >>> > makes it to this task. Assuming that the signal is nonfatal, anyway. >>> >>> I see, how about just using swait_event_timeout() and removing the WARN_ON()? >>> Is there a reason for having the interruptible ? >> >> If sleeping-uninterruptible kthreads are now excluded from the load average, >> no reason. But if sleeping-uninterruptible kthreads are still included in >> the load average, it must stay interruptible. > > Got it! There is now TASK_IDLE that is uninterruptible and does not contribute to load avearage. see: task_contributes_to_load. So a swait_event_idle() could be written for this case. Eric