From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753763AbbCPNS1 (ORCPT ); Mon, 16 Mar 2015 09:18:27 -0400 Received: from mail-pd0-f181.google.com ([209.85.192.181]:32782 "EHLO mail-pd0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752579AbbCPNSY (ORCPT ); Mon, 16 Mar 2015 09:18:24 -0400 Message-ID: <5506D81C.50805@m4x.org> Date: Mon, 16 Mar 2015 21:18:20 +0800 From: Nicolas Iooss User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Jeff Mahoney , reiserfs-devel@vger.kernel.org CC: "linux-kernel@vger.kernel.org" Subject: Re: reiserfs: inconsistent format in __RASSERT References: <5506D2DB.6040907@m4x.org> <5506D504.7040800@suse.com> In-Reply-To: <5506D504.7040800@suse.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/16/2015 09:05 PM, Jeff Mahoney wrote: > On 3/16/15 8:55 AM, Nicolas Iooss wrote: >> * I missed something in my analysis and in fact the PID argument >> is processed by reiserfs_panic (don't know where), or * the PID >> argument is not used and should be removed, or > > This, please. reiserfs_panic calls BUG(), which will contain the PID. Whoo, thanks for the quick answer. I will send a patch as soon as possible. >> * the PID is useful and "[%i]" should be added somewhere in the >> format string. > >> Which one would you prefer? > >> Also, I found this when building the kernel with "allmodconfig" on >> x86_64. With "defconfig" gcc does not report this error, but I >> guess it is because without CONFIG_REISERFS_CHECK, __RASSERT is >> never used. > > Yeah. If reiserfs was more actively maintained, what is currently > protected by CONFIG_REISERFS_CHECK would be handled a bit better. > There are ton of fsfuzzer bugs that would be caught by it and should > be handled using reiserfs_error. Unfortunately, it also enables some > heavy checks that make the file system very slow. > > Thanks for looking into this. It looks like it's been broken for a > while. I suppose the only saving grace is that it would crash in a > path that crashes on purpose a few lines later. Yes, and this is also why I believe this bug is not a security issue nor something which needs an urgent fix. Thanks, Nicolas