From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752864AbcBVJuE (ORCPT ); Mon, 22 Feb 2016 04:50:04 -0500 Received: from out03.mta.xmission.com ([166.70.13.233]:42360 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751364AbcBVJuC convert rfc822-to-8bit (ORCPT ); Mon, 22 Feb 2016 04:50:02 -0500 From: ebiederm@xmission.com (Eric W. Biederman) To: Xianpeng Zhao Cc: "linux-kernel\@vger.kernel.org" , References: Date: Mon, 22 Feb 2016 03:39:53 -0600 In-Reply-To: (Xianpeng Zhao's message of "Tue, 16 Feb 2016 10:31:53 +0000") Message-ID: <87y4adnkwm.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-XM-AID: U2FsdGVkX1+hpzJspS3BGdndQPOVt5/uLReKNgSI324= X-SA-Exim-Connect-IP: 67.3.245.179 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 * [sa06 1397; Body=1 Fuz1=1 Fuz2=1] * 0.0 T_TooManySym_01 4+ unique symbols in subject * 0.2 T_XMDrugObfuBody_14 obfuscated drug references X-Spam-DCC: XMission; sa06 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;Xianpeng Zhao X-Spam-Relay-Country: X-Spam-Timing: total 357 ms - load_scoreonly_sql: 0.04 (0.0%), signal_user_changed: 4.3 (1.2%), b_tie_ro: 3.1 (0.9%), parse: 1.11 (0.3%), extract_message_metadata: 16 (4.4%), get_uri_detail_list: 2.8 (0.8%), tests_pri_-1000: 4.9 (1.4%), tests_pri_-950: 1.24 (0.3%), tests_pri_-900: 1.03 (0.3%), tests_pri_-400: 21 (5.9%), check_bayes: 20 (5.6%), b_tokenize: 6 (1.7%), b_tok_get_all: 6 (1.8%), b_comp_prob: 2.2 (0.6%), b_tok_touch_all: 2.7 (0.7%), b_finish: 0.74 (0.2%), tests_pri_0: 271 (76.0%), check_dkim_signature: 0.55 (0.2%), check_dkim_adsp: 22 (6.1%), tests_pri_500: 33 (9.1%), poll_dns_idle: 27 (7.5%), rewrite_mail: 0.00 (0.0%) Subject: Re: [linux-kernel] dead loop for rtnl_trylock X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Wed, 24 Sep 2014 11:00:52 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Copied netdev as that is the more appropriate mailling list for questions like this. Xianpeng Zhao writes: > Hi Group, > >          I have find a problem in my system, I found there have a chance that cause the system enter dead loop when try to get the rtnl lock in the sysctl function in net/ipv6/addrconf.c > >          The situation should like this, there are 2 processes may need get the rtnl lock, we call them process A and process B, A have high priority than B. > B need get the rtnl lock to do something, when B schedule out without release the lock; At this time, the A start to run "echo 1 > /proc/sys/net/ipv6/conf//disable_ipv6", the echo process will run to this code: > >     if (!rtnl_trylock()) > >         return restart_syscall(); > > Because the rtnl lock was hold by process B, so here the try will be failure, and run the restart_syscall to let the sys_write do again, even try many times, because the B have very lower priority, the lock was hard to be released, so the echo process created by A will enter a loop of restart system call. > > In my case it is the wireless_nlevent_process in process kworker taken the rtnl lock, and another higher priority process need use echo to disable IPv6 met this problem. > > I am not very sure, but I think it is better to let the process A sleep a while instead of try it again and again without any delay. > > Expects, what's your opinions? That the entire situation is a mess. From what little I have seen it is a very rare condition. Does this reproduce easily in your environment? If we are going the delay route we probably want to put the delay in restart_syscall or in a wrapper around restart_syscall that we use for the rtnl_trylock failure case. On first blush I would suggest the logic for sleeping should be: if (need_reschedule()) schedule(); That will limit the spinning to a single time slice which is definitely preferrable. Ugh. But we already cross the kernel/userspace boundary that already does that. If you are encountering a deadlock it is very much because you have been playing very ugly priority games. At which point my sympathies but this feels like a case of "Docter it hurts when I do this. Then don't do that." > @@ -5304,8 +5308,10 @@ static int addrconf_disable_ipv6(struct ctl_table *table, int *p, int newf) > > struct net *net; > > int old; > > > > - if (!rtnl_trylock()) > > + if (!rtnl_trylock()){ > > + schedule_timeout_uninterruptible(HZ/4); > > return restart_syscall(); > > + } > > > > net = (struct net *)table->extra2; > > old = *p; Eric