linux-kernel - Re: [PATCH] devcoredump: increase the device delete timeout to 10 mins

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 for Android: free password hash cracker in your pocket

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

Message-ID: <564672530e489da8872bdf1d8cdee7ce071d6a19.camel@sipsolutions.net>
Date:   Fri, 11 Mar 2022 12:53:57 +0100
From:   Johannes Berg <johannes@...solutions.net>
To:     Rob Clark <robdclark@...il.com>,
        David Laight <David.Laight@...lab.com>
Cc:     Abhinav Kumar <quic_abhinavk@...cinc.com>,
        Greg KH <gregkh@...uxfoundation.org>,
        "rafael@...nel.org" <rafael@...nel.org>,
        "linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
        "swboyd@...omium.org" <swboyd@...omium.org>,
        "khsieh@...eaurora.org" <khsieh@...eaurora.org>,
        "nganji@...eaurora.org" <nganji@...eaurora.org>,
        "seanpaul@...omium.org" <seanpaul@...omium.org>,
        "dmitry.baryshkov@...aro.org" <dmitry.baryshkov@...aro.org>,
        "aravindh@...eaurora.org" <aravindh@...eaurora.org>,
        "freedreno@...ts.freedesktop.org" <freedreno@...ts.freedesktop.org>
Subject: Re: [PATCH] devcoredump: increase the device delete timeout to 10
 mins

On Tue, 2022-03-01 at 09:45 -0800, Rob Clark wrote:
> On Mon, Feb 28, 2022 at 10:49 PM David Laight <David.Laight@...lab.com> wrote:
> > 
> > From: Abhinav Kumar
> > > Sent: 28 February 2022 21:38
> > ...
> > > We also did some profiling around how much increasing the block size
> > > helps and here is the data:
> > > 
> > > Block size    cost
> > > 
> > > 4KB           229s
> > > 8KB            86s
> > 
> > You must have an O(n^2) operation in there - find it.
> 
> The problem is how the devcoredump/sysfs interface works, which
> results in "re-rendering" the output for each block.. it's fine for
> moderate size sysfs files, but scales quite badly once you get into
> couple MB size sysfs files.
> 
> It could be fixed by having some way to keep state across successive
> read callbacks.

I'm not sure that's true? Perhaps for dev_coredumpm(), but only if you
implemented read() badly.

If you have e.g. dev_coredumpsg() or dev_coredumpv() that's just a
simple read from the existing buffer.

johannes