From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752458AbcAFIfr (ORCPT ); Wed, 6 Jan 2016 03:35:47 -0500 Received: from mail-pa0-f49.google.com ([209.85.220.49]:33328 "EHLO mail-pa0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752366AbcAFIfp (ORCPT ); Wed, 6 Jan 2016 03:35:45 -0500 Date: Wed, 6 Jan 2016 17:36:53 +0900 From: Sergey Senozhatsky To: Jan Kara Cc: Andrew Morton , Petr Mladek , KY Sri nivasan , Steven Rostedt , linux-kernel@vger.kernel.org, Sergey Senozhatsky , Sergey Senozhatsky Subject: Re: [PATCH 1/7] printk: Hand over printing to console if printing too long Message-ID: <20160106083653.GA10678@swordfish> References: <20151210145251.GA540@swordfish> <20151222134730.GD7266@quack.suse.cz> <20151231024459.GA479@swordfish> <20151231031337.GB479@swordfish> <20151231045859.GC479@swordfish> <20160105144818.GD14464@quack.suse.cz> <20160106033830.GB781@swordfish> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160106033830.GB781@swordfish> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On (01/06/16 12:38), Sergey Senozhatsky wrote: > On (01/05/16 15:48), Jan Kara wrote: > > > [..] > > > > cond_resched() does its job there, of course. well, a user process still can > > > > do a lot of call_console_drivers() calls. may be we can check who is calling > > > > console_unlock() and if we have "!printk_sync && !oops_in_progress" (or just printk_sync > > > > test) AND a user process then return from console_unlock() doing irq_work_queue() > > > > and set PRINTK_PENDING_OUTPUT pending bit, the way vprintk_emit() does it. > > > > > > attached two patches, I ended up having on top of yours. just in case. > > > > > > printk: factor out can_printk_async() > > > > > > console_unlock() can be called directly or indirectly by a user > > > space process, so it can end up doing call_console_drivers() loop, > > > which will hold it from returning back to user-space from a syscall > > > for unpredictable amount of time. > > > > > > Factor out can_printk_async() function, which queues an irq work and > > > sets a PRINTK_PENDING_OUTPUT pending bit (if we can do async printk). > > > vprintk_emit() already does it, add can_printk_async() call to > > > console_unlock() for !PF_KTHREAD processes. > > > > I'd be cautious about changing this userspace visible behavior. Someone may > > be relying on it... I agree that sometimes we can block userspace process > > in kernel for a long time (e.g. in my testing I often see syslog process > > doing the printing) but so far I didn't see / was notified about some real > > problem with this. So unless I see some real user issues with user > > processes doing printing for too long I would not touch this. > > and w/o a lot of effort (no heavy printk message traffic) or like this on another setup ([k|u]_ts updated to u64) # cat /proc/1/time_in_console_unlock kern:[12.755920] user:[38.367332] -ss