Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932180Ab2ECUKK (ORCPT ); Thu, 3 May 2012 16:10:10 -0400 Received: from mail-we0-f174.google.com ([74.125.82.174]:38119 "EHLO mail-we0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754586Ab2ECUKI (ORCPT ); Thu, 3 May 2012 16:10:08 -0400 MIME-Version: 1.0 In-Reply-To: <1336075373.6509.9.camel@twins> References: <1336004953.4240.9.camel@mop> <1336074483.6509.3.camel@twins> <1336075373.6509.9.camel@twins> From: Linus Torvalds Date: Thu, 3 May 2012 13:09:47 -0700 X-Google-Sender-Auth: u5oK5UHNLmlxbhxeu6UgUA-2xcc Message-ID: Subject: Re: [PATCH RESEND 1/3] printk: convert byte-buffer to variable-length record buffer To: Peter Zijlstra Cc: Kay Sievers , Greg Kroah-Hartmann , Ingo Molnar , linux-kernel@vger.kernel.org Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 825 Lines: 19 On Thu, May 3, 2012 at 1:02 PM, Peter Zijlstra wrote: > > Thing is, with bonkers stuff like usb-console and kms/drm that's a _lot_ > of code running under the logbuf/console locks. The top-level console lock shouldn't be a problem - we use trylock and delay if it is held. It's the lower-level driver-specific locks that screw us up. And quite frankly, I am *not* willing to say that that is a printk() problem. That is purely a "USB serial console is damn well broken" issue, and should not be considered a limitation of printk. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/