[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAM_iQpXKWDr4AbROO=ZbkxwQHkj4anA9FJAaohOqg1SCq0L7eg@mail.gmail.com>
Date: Sat, 20 Apr 2019 11:25:43 -0700
From: Cong Wang <xiyou.wangcong@...il.com>
To: Borislav Petkov <bp@...en8.de>
Cc: LKML <linux-kernel@...r.kernel.org>, linux-edac@...r.kernel.org,
Tony Luck <tony.luck@...el.com>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH v2 1/2] ras: fix an off-by-one error in __find_elem()
On Sat, Apr 20, 2019 at 4:34 AM Borislav Petkov <bp@...en8.de> wrote:
>
> On Tue, Apr 16, 2019 at 04:16:08PM -0700, Cong Wang wrote:
> > It is actually fairly easy:
> >
> > 1) Fill the whole page with PFN's:
> > for i in `seq 0 511`; do echo $i >> /sys/kernel/debug/ras/cec/pfn; done
> >
> > 2) Set thresh to 1 in order to trigger the deletion:
> > echo 1 > /sys/kernel/debug/ras/cec/count_threshold
> >
> > 3) Repeatedly add and remove the last element:
> > echo 512 >> /sys/kernel/debug/ras/cec/pfn
> > (until you get a crash.)
>
> Thanks, I was able to reproduce with that. Below is a conglomerate patch
> which converts __find_elem() to using Donald Knuth's binary search
> version. I don't know what I was thinking then and why I didn't use
> it from the get-go. The textbook even says that one can easily get it
> wrong...
If you want to go that far, you can choose to use lib/bsearch.c too in
case you want to reinvent the wheel.
What's your point here? You know my fix is targeted for -stable, I doubt
your 83-line change could fit for -stable.
Feel free to drop my patch to favor yours. I am really tired.
Good luck with that!
Thanks.
Powered by blists - more mailing lists