From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C2D9EC1B0F1 for ; Wed, 20 Jun 2018 02:51:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 79A882083A for ; Wed, 20 Jun 2018 02:51:01 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="d2jqT6OZ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 79A882083A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754213AbeFTCu7 (ORCPT ); Tue, 19 Jun 2018 22:50:59 -0400 Received: from mail-pf0-f193.google.com ([209.85.192.193]:44629 "EHLO mail-pf0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753906AbeFTCuz (ORCPT ); Tue, 19 Jun 2018 22:50:55 -0400 Received: by mail-pf0-f193.google.com with SMTP id h12-v6so815854pfk.11; Tue, 19 Jun 2018 19:50:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=Gh5wpn/72YAHQNb9azvAnaSfWQhemAACqfG+y1LWwlM=; b=d2jqT6OZAt7Sk1czQxXEi6Kr3SshL5J1o5WqCangmmwgyskbWy7hgYqOLCmmuQPjum iUTg/JqPXtKJr0KgW/X5tPu2Id9mDvaFzNrxtOHDM2lxhjssvUrYp23H47gTEVtMdyyf OFpPbnj+vMrTFHW7ZJQQefDOj7g3a9pVemP1rVwnvcRnisXL0NWGX75wcmDmT1snOi+m vyNGsMlUpGWZJ3FF7F4Tk5s3J3lQHlvS5RuFm2H5MH0+a/ghEqNIWv5HO6sYjhUD8ywj GopsnG1RBBZkC+pmc/eLlIUrNzPG1Rl/qgqo2G5GsVBv71UyDvNWrXZQCaz1yA35xoaj 7nEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=Gh5wpn/72YAHQNb9azvAnaSfWQhemAACqfG+y1LWwlM=; b=cBn2xv8y9M1mh8kksN3nr3XlVZKFRBpFwPdoGx9NbqusiDIZRqQhCY1NZP5XEj8KyG /jTvNFYCFPuTq1TTJ7PkaEgHnGEzYmQ0R9kpqQ1o3kyEZZPin4x7c2CIY81Aejh/67yu TAb1wW+lt+Ij2xVwF3awvyu7D+lAXzi6nnETUbybI018/3f3oPuIAo47rIcNO2IcXDn5 8N0kwVD6Q6EGyBNHoMFPSzobBaSk4LZqXPhVJC6mfFdEroDYrzUmU751QsFJmtLdFirc 9OkBcHTYJ2Mxr1LJKZaEZLafKKCAQ+4OEiJ0eYS4nTsFQgJJqTKueLCswuJJ2beZkHWx 99mw== X-Gm-Message-State: APt69E30HqgjnKLw1R/wHfQ91RzD+ynmpUKBxyrolzOVKNbYSycuYxHh fTn91nV391wwZlg0xSCSf7w= X-Google-Smtp-Source: ADUXVKL4b9F7qiwrto8Wo0Qk0Oz05fHX94gI5j8ObNfg7Ptj2Tf9HebRhws3csgGwiZtZtv44A0lXw== X-Received: by 2002:a65:51c9:: with SMTP id i9-v6mr17254820pgq.202.1529463055203; Tue, 19 Jun 2018 19:50:55 -0700 (PDT) Received: from localhost ([110.70.59.159]) by smtp.gmail.com with ESMTPSA id x72-v6sm1431102pff.176.2018.06.19.19.50.53 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 19 Jun 2018 19:50:53 -0700 (PDT) Date: Wed, 20 Jun 2018 11:50:50 +0900 From: Sergey Senozhatsky To: Linus Torvalds Cc: Petr Mladek , Sergey Senozhatsky , One Thousand Gnomes , Steven Rostedt , Greg Kroah-Hartman , Jiri Slaby , Peter Zijlstra , Andrew Morton , Dmitry Vyukov , Linux Kernel Mailing List , linux-serial , SergeySenozhatsky Subject: Re: [RFC][PATCH 0/6] Use printk_safe context for TTY and UART port locks Message-ID: <20180620025050.GE650@jagdpanzerIV> References: <20180615093919.559-1-sergey.senozhatsky@gmail.com> <20180618143818.50b2f2f9@alans-desktop> <20180619005308.GA405@jagdpanzerIV> <20180619083021.4avsgvcqjrpkat6s@pathway.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.0 (2018-05-17) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On (06/20/18 11:01), Linus Torvalds wrote: > On Tue, Jun 19, 2018 at 5:30 PM Petr Mladek wrote: > > > > To make it clear. This patch set adds yet another spin_lock API. > > It behaves exactly as spin_lock_irqsafe()/spin_unlock_irqrestore() > > but in addition it sets printk_context. > > > > This patchset forces safe context around TTY and UART locks. > > In fact, the deferred context would be enough to prevent > > all the mentioned deadlocks. > > Please stop this garbage. I'm guessing the message was addressed to me, not to Petr. Let me explain myself. > The rule is simple: DO NOT DO THAT THEN. > > Don't make recursive locks. Don't make random complexity. Just stop > doing the thing that hurts. We didn't add any of those recursive printk()-s. Those are the things like kmalloc()/scheduler/etc which tty/etc invoke that hurt. > There is no valid reason why an UART driver should do a printk() of > any sort inside the critical region where the console is locked. It's not UART on its own that immediately calls into printk(), that would be trivial to fix, it's all those subsystems that serial console driver can call into. For instance, kernel/workqueue.c - it may WARN_ON/printk in various cases. And those WARNs/printks are OK. Except for one thing: workqueue can be called from a serial console driver, which suddenly will turn those WARNs/printks into illegal ones, due to possible deadlocks. And serial consoles can call into WQ. Not directly, but via tty code. A random example: s3c24xx_serial_rx_chars_dma() spin_lock_irqsave(&port->lock, flags); tty_flip_buffer_push() __queue_work() spin_unlock_irqrestore(&port->lock, flags); Should for some reason WQ warn/printk, we are done, because we will end up taking the same port->lock: __queue_work() printk() call_console_drivers() spin_lock_irqsave(&port->lock, flags); IOW, there is this tricky "we were called from a serial driver" context, which is hard to track, but printk_safe can help us in those cases. There are other examples. WQ is not the only thing serial drivers can call into. So that's why I sent the patch set. -ss