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=-5.6 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 8D5A5C4727E for ; Wed, 30 Sep 2020 11:28:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4779A20709 for ; Wed, 30 Sep 2020 11:28:40 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=suse.com header.i=@suse.com header.b="THtL5oLx" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729104AbgI3L2i (ORCPT ); Wed, 30 Sep 2020 07:28:38 -0400 Received: from mx2.suse.de ([195.135.220.15]:47802 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725779AbgI3L2i (ORCPT ); Wed, 30 Sep 2020 07:28:38 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1601465317; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=BJDgWAYhRp6it/2DpEbAViTJ8/e5BFTejOFXfq86KFU=; b=THtL5oLxX+5tAvr5GMG47Or7AqFGxz5Ug9Lu943eInO8oBaSfeU1cgV1ke8CmmORaVScXf NkpPrFYfzxA8jRp2BMMj5RfRLMHV7JWOKfqPDYFMuswtRolYJtSYYqeWRQvXc9LhmqDTxX +HMYofEotjjnFXG8Ds1jTsvLnXffsZQ= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 0245DABC1; Wed, 30 Sep 2020 11:28:37 +0000 (UTC) Date: Wed, 30 Sep 2020 13:28:36 +0200 From: Petr Mladek To: John Ogness Cc: Sergey Senozhatsky , Sergey Senozhatsky , Steven Rostedt , Linus Torvalds , Greg Kroah-Hartman , Thomas Gleixner , Marek Szyprowski , linux-kernel@vger.kernel.org Subject: Re: [PATCH next v2 1/2] printk: avoid and/or handle record truncation Message-ID: <20200930112836.GC29288@alley> References: <20200930090134.8723-1-john.ogness@linutronix.de> <20200930090134.8723-2-john.ogness@linutronix.de> <20200930094316.GB987@jagdpanzerIV.localdomain> <87imbv1s0d.fsf@jogness.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87imbv1s0d.fsf@jogness.linutronix.de> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed 2020-09-30 12:30:50, John Ogness wrote: > On 2020-09-30, Sergey Senozhatsky wrote: > > On (20/09/30 11:07), John Ogness wrote: > >> bool prb_reserve_in_last(struct prb_reserved_entry *e, struct printk_ringbuffer *rb, > >> - struct printk_record *r, u32 caller_id); > >> + struct printk_record *r, u32 caller_id, unsigned int max_size); > > > > Isn't `max_size' always LOG_LINE_MAX? > > Yes. But I still think it makes sense that it is an argument of the > function. It is quite an important setting and hard-coding it within the > ringbuffer code might lead to hidden problems later. I personally prefer the argument as well. It is true that printk_ringbuffer is not a fully generic ringbuffer. It has very special behavior so that it can be hardly be used anywhere else. Sometimes it is not clear what printk() requirements should be passed via the API or hardcoded into the ring buffer code. IMHO, it depends on the code complexity. Anyway, I see hardcoded limit more like a hack. It limits something somewhere so that some other code somewhere else is safe to use. And printk.c is really bad from this point. It sometimes does not check for overflow because it "knows" that the buffers are big enough. But it is error prone code, especially when there are more limits defined (pure text, prefix, extended prefix). And it will be worse if we allow to add more optional information into the prefix. Best Regards, Petr