From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sergey Senozhatsky Date: Fri, 13 Jan 2017 02:52:55 +0000 Subject: Re: [PATCH] mm/page_alloc: Wait for oom_lock before retrying. Message-Id: <20170113025212.GB9360@jagdpanzerIV.localdomain> List-Id: References: <20161220153948.GA575@tigerII.localdomain> <201612221927.BGE30207.OSFJMFLFOHQtOV@I-love.SAKURA.ne.jp> <20161222134250.GE413@tigerII.localdomain> <201612222301.AFG57832.QOFMSVFOJHLOtF@I-love.SAKURA.ne.jp> <20161222140930.GF413@tigerII.localdomain> <201612261954.FJE69201.OFLVtFJSQFOHMO@I-love.SAKURA.ne.jp> <20161226113407.GA515@tigerII.localdomain> <20170112131017.GF14894@pathway.suse.cz> In-Reply-To: <20170112131017.GF14894@pathway.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Petr Mladek Cc: Sergey Senozhatsky , Tetsuo Handa , mhocko@suse.com, linux-mm@kvack.org, Greg Kroah-Hartman , Jiri Slaby , linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org, sergey.senozhatsky.work@gmail.com On (01/12/17 14:10), Petr Mladek wrote: [..] > > /** > > * console_lock - lock the console system for exclusive use. > > * > > @@ -2316,7 +2321,7 @@ EXPORT_SYMBOL(console_unlock); > > */ > > void __sched console_conditional_schedule(void) > > { > > - if (console_may_schedule) > > + if (get_console_may_schedule()) > > Note that console_may_schedule should be zero when > the console drivers are called. See the following lines in > console_unlock(): > > /* > * Console drivers are called under logbuf_lock, so > * @console_may_schedule should be cleared before; however, we may > * end up dumping a lot of lines, for example, if called from > * console registration path, and should invoke cond_resched() > * between lines if allowable. Not doing so can cause a very long > * scheduling stall on a slow console leading to RCU stall and > * softlockup warnings which exacerbate the issue with more > * messages practically incapacitating the system. > */ > do_cond_resched = console_may_schedule; > console_may_schedule = 0; console drivers are never-ever-ever getting called under logbuf lock. never. with disabled local IRQs - yes. under logbuf lock - no. that would soft lockup systems in really bad ways, otherwise. the reason why we set console_may_schedule to zero in console_unlock() is.... VT. and lf() function in particular. commit 78944e549d36673eb6265a2411574e79c28e23dc Author: Antonino A. Daplas XXXX Date: Sat Aug 5 12:14:16 2006 -0700 [PATCH] vt: printk: Fix framebuffer console triggering might_sleep assertion Reported by: Dave Jones Whilst printk'ing to both console and serial console, I got this... (2.6.18rc1) BUG: sleeping function called from invalid context at kernel/sched.c:4438 in_atomic():0, irqs_disabled():1 Call Trace: [] show_trace+0xaa/0x23d [] dump_stack+0x15/0x17 [] __might_sleep+0xb2/0xb4 [] __cond_resched+0x15/0x55 [] cond_resched+0x3b/0x42 [] console_conditional_schedule+0x12/0x14 [] fbcon_redraw+0xf6/0x160 [] fbcon_scroll+0x5d9/0xb52 [] scrup+0x6b/0xd6 [] lf+0x24/0x44 [] vt_console_print+0x166/0x23d [] __call_console_drivers+0x65/0x76 [] _call_console_drivers+0x5e/0x62 [] release_console_sem+0x14b/0x232 [] fb_flashcursor+0x279/0x2a6 [] run_workqueue+0xa8/0xfb [] worker_thread+0xef/0x122 [] kthread+0x100/0x136 [] child_rip+0x8/0x12 and we really don't want to cond_resched() when we are in panic. that's why console_flush_on_panic() sets it to zero explicitly. console_trylock() checks oops_in_progress, so re-taking the semaphore when we are in panic() console_flush_on_panic() console_unlock() console_trylock() should be OK. as well as doing get_console_conditional_schedule() somewhere in console driver code. I still don't understand why do you guys think we can't simply do get_console_conditional_schedule() and get the actual value. [..] > Sergey, if you agree with the above paragraph. Do you want to prepare > the patch or should I do so? I'm on it. -ss