linux-kernel - Re: [RFC PATCH 8/9] debugfs: defer debugfs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <1493790238.2602.3.camel@sipsolutions.net>
Date:   Wed, 03 May 2017 07:43:58 +0200
From:   Johannes Berg <johannes@...solutions.net>
To:     Nicolai Stange <nicstange@...il.com>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Paul E.McKenney" <paulmck@...ux.vnet.ibm.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 8/9] debugfs: defer debugfs_fsdata allocation to
 first usage

On Tue, 2017-05-02 at 22:05 +0200, Nicolai Stange wrote:

> > So either you could return some valid ops (perhaps
> > debugfs_noop_file_operations although those don't have .name or
> > .poll, so it doesn't cover everything), or you can just BUG_ON()
> > here directly, saving the incomprehensible crash later.
> 
> The purpose of that WARN_ON() there was to turn a potentially
> incomprehensible crash into a comprehensible one ;)
> 
> In order to avoid a new BUG_ON(), what about keeping the WARN_ON() as
> is and returning NULL instead of the garbage? That would crash
> current on first access and the earlier warning would hopefully give
> some clue?

Yeah, I guess that might work. Probably less harmful to the system than
a BUG_ON(), but I still operate under the assumption that there might
actually be something mapped at NULL - not sure if that's still true.

johannes