[lvm-devel] [BISECT] Regression: SEGV: 9156c5d dmeventd rework locking code

[Eric Wheeler]

On Wed, 5 Apr 2017, Zdenek Kabelac wrote:

> Dne 5.4.2017 v 01:22 Eric Wheeler napsal(a):
> > On Sat, 1 Apr 2017, Zdenek Kabelac wrote:
> >
> > > Dne 1.4.2017 v 00:19 Eric Wheeler napsal(a):
> 
> > > > (gdb) bt
> > > > #0  _touch_memory (size=<optimized out>, mem=<optimized out>) at
> > > > mm/memlock.c:141
> > > > #1  _allocate_memory () at mm/memlock.c:163
> > >
> > >
> > > Hi
> > >
> > > Hmm few theories -  from your gdb backtrace it suggests it has failed on
> > > libc
> > > syscall  (getpagesize()) ??
> > > So have you upgraded all related packages ?  (device-mapper*,  kernel*)
> > > or it's some 'mixture' in use ?
> > >
> > > Also don't you have some large/changed values of 'reserved_stack'   or
> > > 'reserved_memory' in your lvm.conf ?
> >
> > Yes! Actually, reserved_stack was the problem. By trial and error we found
> > that when reserved_stack is 290 or more, dmeventd will segfault. We tried
> > on servers with far fewer logical volumes and did not have a problem, so
> > while I am not going to try and figure out how many logical volumes hit
> > this stack limit, this is the problem!
> >
> > Is there some kind of hard limit to reserved_stack that should be
> > enforced?
> >
> > I seem to recall increasing these values because lvcreate (or lvchange or
> > something) suggested that the values were too small.
> >
> > Do you still want a bugzilla report?
> 
> 
> Hi
> 
> Yep - so this explains it. Not clear we need BZ yet.
> I'll explain the reason of limitation.
> 
> Dmeventd is using threads - and to minimize the RAM usage by memlocked process
> with number of threads - we picked 'relatively' low value for pthread_stack
> with assumption noone will ever need bigger value than this :)
> 
> Now lvm.conf does defined 'reserved_stack' amount - and this stack is then
> 'mapped' in dmeventd lvm plugin thread.  However this is after 'dmeventd' has
> created thread with 128K stack limit (dmeventd itself doesn't 'see/use'
> lvm.conf so can't create threads with different settings)
> 
> So clearly a logical problem we can't really solve in any easy way.
> We limited amount of stack used by lvm2 code - so current defaults should be
> rather good enough for almost every possible use-case.
> 
> So before we start to fix this  'catch 42' case - could you check and
> eventually describe which use-case was not working well we 'default'
> reserved_stack  so you had to raise the value to 290 to make it work ?
> 
> Otherwise I think the best solution would be to simply internally limit
> the 'accepted' value and ignore any higher setting and just document it.

I don't recall the reason that we needed to increase the defaults, that 
was a long time ago probably in 7.0 . Now it seems to work fine with 
default values, so internally limiting the value is probably a good idea 
to prevent others from having such an issue.

It might be a good idea to gracefully accept and warn about any higher 
limit but cap it to the internal maximum instead of giving an error in 
case users have lvm.conf inside of initrds---we definitely don't want to 
break peoples' bootup processes.

--
Eric Wheeler
 
 
> Regards
> 
> Zdenek
> 
> --
> lvm-devel mailing list
> lvm-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/lvm-devel
> 
>