Hi Shakeel,
On Tue, Jun 19, 2018 at 9:21 PM Shakeel Butt wrote:
> Jason, can you try the following patch?
Your patch also fixed the problem, which was also fixed by enabling
CONFIG_SLUB_DEBUG, per the other email. I haven't checked to see if
your patch is simply a subset of what SLUB_DEBUG is
Hi Shakeel,
On Tue, Jun 19, 2018 at 9:21 PM Shakeel Butt wrote:
> Jason, can you try the following patch?
Your patch also fixed the problem, which was also fixed by enabling
CONFIG_SLUB_DEBUG, per the other email. I haven't checked to see if
your patch is simply a subset of what SLUB_DEBUG is
Hi Andrey,
On Tue, Jun 19, 2018 at 7:33 PM Andrey Ryabinin wrote:
> What's the status of CONFIG_SLUB_DEBUG in your config?
>
> AFAICS __kmem_cache_empty() is broken for CONFIG_SLUB_DEBUG=n. We use
> slabs_node() there
> which is always 0 for CONFIG_SLUB_DEBUG=n.
>
> The problem seems not
Hi Andrey,
On Tue, Jun 19, 2018 at 7:33 PM Andrey Ryabinin wrote:
> What's the status of CONFIG_SLUB_DEBUG in your config?
>
> AFAICS __kmem_cache_empty() is broken for CONFIG_SLUB_DEBUG=n. We use
> slabs_node() there
> which is always 0 for CONFIG_SLUB_DEBUG=n.
>
> The problem seems not
On Tue, Jun 19, 2018 at 8:19 AM Jason A. Donenfeld wrote:
>
> On Tue, Jun 19, 2018 at 5:08 PM Shakeel Butt wrote:
> > > > Are you using SLAB or SLUB? We stress kernel pretty heavily, but with
> > > > SLAB, and I suspect Shakeel may also be using SLAB. So if you are
> > > > using SLUB, there is
On Tue, Jun 19, 2018 at 8:19 AM Jason A. Donenfeld wrote:
>
> On Tue, Jun 19, 2018 at 5:08 PM Shakeel Butt wrote:
> > > > Are you using SLAB or SLUB? We stress kernel pretty heavily, but with
> > > > SLAB, and I suspect Shakeel may also be using SLAB. So if you are
> > > > using SLUB, there is
On 06/19/2018 05:51 AM, Jason A. Donenfeld wrote:
> Hello Shakeel,
>
> It may be the case that f9e13c0a5a33d1eaec374d6d4dab53a4f72756a0 has
> introduced a regression. I've bisected a failing test to this commit,
> and after staring at the my code for a long time, I'm unable to find a
> bug
On 06/19/2018 05:51 AM, Jason A. Donenfeld wrote:
> Hello Shakeel,
>
> It may be the case that f9e13c0a5a33d1eaec374d6d4dab53a4f72756a0 has
> introduced a regression. I've bisected a failing test to this commit,
> and after staring at the my code for a long time, I'm unable to find a
> bug
On Tue, Jun 19, 2018 at 5:08 PM Shakeel Butt wrote:
> > > Are you using SLAB or SLUB? We stress kernel pretty heavily, but with
> > > SLAB, and I suspect Shakeel may also be using SLAB. So if you are
> > > using SLUB, there is significant chance that it's a bug in the SLUB
> > > part of the
On Tue, Jun 19, 2018 at 5:08 PM Shakeel Butt wrote:
> > > Are you using SLAB or SLUB? We stress kernel pretty heavily, but with
> > > SLAB, and I suspect Shakeel may also be using SLAB. So if you are
> > > using SLUB, there is significant chance that it's a bug in the SLUB
> > > part of the
On Tue, Jun 19, 2018 at 6:05 AM Jason A. Donenfeld wrote:
>
> HI Dimitry,
>
> On Tue, Jun 19, 2018 at 6:55 AM Dmitry Vyukov wrote:
> > Your code frees all entries before freeing the cache, right? If you
> > add total_entries check before freeing the cache, it does not fire,
> > right?
>
> Yes,
On Tue, Jun 19, 2018 at 6:05 AM Jason A. Donenfeld wrote:
>
> HI Dimitry,
>
> On Tue, Jun 19, 2018 at 6:55 AM Dmitry Vyukov wrote:
> > Your code frees all entries before freeing the cache, right? If you
> > add total_entries check before freeing the cache, it does not fire,
> > right?
>
> Yes,
On Tue, Jun 19, 2018 at 3:31 PM Dmitry Vyukov wrote:
> Since I already looked at the code, if init and uninit can be called
> concurrently, I think there is a prominent race condition between init
> and uninit: a concurrent uninit can run concurrnetly with the next
> init and this will totally
On Tue, Jun 19, 2018 at 3:31 PM Dmitry Vyukov wrote:
> Since I already looked at the code, if init and uninit can be called
> concurrently, I think there is a prominent race condition between init
> and uninit: a concurrent uninit can run concurrnetly with the next
> init and this will totally
On Tue, Jun 19, 2018 at 3:25 PM, Jason A. Donenfeld wrote:
> On Tue, Jun 19, 2018 at 7:06 AM Shakeel Butt wrote:
>> Currently refcnt in your
>> code can underflow, through it does not seem like the selftest will
>> cause the underflow but still you should fix it.
>
> Indeed, and if this happened
On Tue, Jun 19, 2018 at 3:25 PM, Jason A. Donenfeld wrote:
> On Tue, Jun 19, 2018 at 7:06 AM Shakeel Butt wrote:
>> Currently refcnt in your
>> code can underflow, through it does not seem like the selftest will
>> cause the underflow but still you should fix it.
>
> Indeed, and if this happened
On Tue, Jun 19, 2018 at 7:06 AM Shakeel Butt wrote:
> Currently refcnt in your
> code can underflow, through it does not seem like the selftest will
> cause the underflow but still you should fix it.
Indeed, and if this happened this would be a bug in the caller, not
the ratelimiter itself, kind
On Tue, Jun 19, 2018 at 7:06 AM Shakeel Butt wrote:
> Currently refcnt in your
> code can underflow, through it does not seem like the selftest will
> cause the underflow but still you should fix it.
Indeed, and if this happened this would be a bug in the caller, not
the ratelimiter itself, kind
On Tue, Jun 19, 2018 at 3:04 PM, Jason A. Donenfeld wrote:
> HI Dimitry,
>
> On Tue, Jun 19, 2018 at 6:55 AM Dmitry Vyukov wrote:
>> Your code frees all entries before freeing the cache, right? If you
>> add total_entries check before freeing the cache, it does not fire,
>> right?
>
> Yes,
On Tue, Jun 19, 2018 at 3:04 PM, Jason A. Donenfeld wrote:
> HI Dimitry,
>
> On Tue, Jun 19, 2018 at 6:55 AM Dmitry Vyukov wrote:
>> Your code frees all entries before freeing the cache, right? If you
>> add total_entries check before freeing the cache, it does not fire,
>> right?
>
> Yes,
HI Dimitry,
On Tue, Jun 19, 2018 at 6:55 AM Dmitry Vyukov wrote:
> Your code frees all entries before freeing the cache, right? If you
> add total_entries check before freeing the cache, it does not fire,
> right?
Yes, certainly.
> Are you using SLAB or SLUB? We stress kernel pretty heavily,
HI Dimitry,
On Tue, Jun 19, 2018 at 6:55 AM Dmitry Vyukov wrote:
> Your code frees all entries before freeing the cache, right? If you
> add total_entries check before freeing the cache, it does not fire,
> right?
Yes, certainly.
> Are you using SLAB or SLUB? We stress kernel pretty heavily,
On Mon, Jun 18, 2018 at 9:08 PM Jason A. Donenfeld wrote:
>
> On Tue, Jun 19, 2018 at 5:59 AM Shakeel Butt wrote:
> > Hi Jason, yes please do send me the test suite with the kernel config.
>
> $ git clone https://git.zx2c4.com/WireGuard
> $ cd WireGuard/src
> $ [[ $(gcc -v 2>&1) =~ gcc\ version\
On Mon, Jun 18, 2018 at 9:08 PM Jason A. Donenfeld wrote:
>
> On Tue, Jun 19, 2018 at 5:59 AM Shakeel Butt wrote:
> > Hi Jason, yes please do send me the test suite with the kernel config.
>
> $ git clone https://git.zx2c4.com/WireGuard
> $ cd WireGuard/src
> $ [[ $(gcc -v 2>&1) =~ gcc\ version\
On Tue, Jun 19, 2018 at 6:08 AM, Jason A. Donenfeld wrote:
> On Tue, Jun 19, 2018 at 5:59 AM Shakeel Butt wrote:
>> Hi Jason, yes please do send me the test suite with the kernel config.
>
> $ git clone https://git.zx2c4.com/WireGuard
> $ cd WireGuard/src
> $ [[ $(gcc -v 2>&1) =~ gcc\ version\
On Tue, Jun 19, 2018 at 6:08 AM, Jason A. Donenfeld wrote:
> On Tue, Jun 19, 2018 at 5:59 AM Shakeel Butt wrote:
>> Hi Jason, yes please do send me the test suite with the kernel config.
>
> $ git clone https://git.zx2c4.com/WireGuard
> $ cd WireGuard/src
> $ [[ $(gcc -v 2>&1) =~ gcc\ version\
On Tue, Jun 19, 2018 at 5:59 AM Shakeel Butt wrote:
> Hi Jason, yes please do send me the test suite with the kernel config.
$ git clone https://git.zx2c4.com/WireGuard
$ cd WireGuard/src
$ [[ $(gcc -v 2>&1) =~ gcc\ version\ 8\.1\.0 ]] || echo crash needs 8.1
$ export DEBUG_KERNEL=yes
$ export
On Tue, Jun 19, 2018 at 5:59 AM Shakeel Butt wrote:
> Hi Jason, yes please do send me the test suite with the kernel config.
$ git clone https://git.zx2c4.com/WireGuard
$ cd WireGuard/src
$ [[ $(gcc -v 2>&1) =~ gcc\ version\ 8\.1\.0 ]] || echo crash needs 8.1
$ export DEBUG_KERNEL=yes
$ export
On Mon, Jun 18, 2018 at 7:51 PM Jason A. Donenfeld wrote:
>
> Hello Shakeel,
>
> It may be the case that f9e13c0a5a33d1eaec374d6d4dab53a4f72756a0 has
> introduced a regression. I've bisected a failing test to this commit,
> and after staring at the my code for a long time, I'm unable to find a
>
On Mon, Jun 18, 2018 at 7:51 PM Jason A. Donenfeld wrote:
>
> Hello Shakeel,
>
> It may be the case that f9e13c0a5a33d1eaec374d6d4dab53a4f72756a0 has
> introduced a regression. I've bisected a failing test to this commit,
> and after staring at the my code for a long time, I'm unable to find a
>
Hello Shakeel,
It may be the case that f9e13c0a5a33d1eaec374d6d4dab53a4f72756a0 has
introduced a regression. I've bisected a failing test to this commit,
and after staring at the my code for a long time, I'm unable to find a
bug that this commit might have unearthed. Rather, it looks like this
Hello Shakeel,
It may be the case that f9e13c0a5a33d1eaec374d6d4dab53a4f72756a0 has
introduced a regression. I've bisected a failing test to this commit,
and after staring at the my code for a long time, I'm unable to find a
bug that this commit might have unearthed. Rather, it looks like this
32 matches
Mail list logo
