Re: [Drbd-dev] drbd 8.4.3: refcounter overflow on re-sync

[Lars Ellenberg <lars.ellenberg@linbit.com>]

On Wed, Sep 24, 2014 at 05:57:42PM +0200, PaX Team wrote:
> On 24 Sep 2014 at 14:50, Lars Ellenberg wrote:
> 
> > So what PAX really is doing is redefine "atomic_add" and similar to
> > basically become a no-op, if it would overflow.
> 
> correct.

> > Might help with debugging.  Not with much else. 
> 
> not correct ;)

> so in short: this is not for debugging, this doesn't replace one bug
> with another, but it does prevent real life exploitation of refcount
> overflow bugs.

It won't make things "work".  It probably makes things crash in less
obscure ways, though, I give you that.

> > Anyways, now that I know PAX is really just keeping that counter
> > at a fixed value of INT_MAX in this case, and nothing else,
> > what would have caused DRBD to disconnect/reconnect?
> 
> perhaps it's a consequence of the reaction from the kernel on the overflow
> which is equivalent to a SIGKILL with all that it implies (files and network
> connections get closed, etc).

That would be the result of the _ASM_EXTABLE()?
or what causes that "reaction"?

As the process in question in *this* case is a drbd kernel thread, it
does not much care about that KILL. It notices, clears it, and lives on.

But how would KILL'ing an innocent userland process improve the overall
situation?  Being a user land process, it cannot possibly be blamed for
an in-kernel counter overflow, so why even kill it?

	Lars