On Thu, May 18, 2023 at 01:56:13AM +0300, Vitaliy Makkoveev wrote: > > On 18 May 2023, at 01:14, Alexander Bluhm <alexander.bl...@gmx.net> wrote: > > > > On Wed, May 17, 2023 at 12:46:02PM +0300, Vitaliy Makkoveev wrote: > >> Introduce `ip6_soiikey_lock' rwlock(9) to protect `ip6_soiikey'. It > >> accessed only by ip6_sysctl_soiikey() and ip6_sysctl() is the only > >> ip6_sysctl_soiikey() caller so context switch is allowed here. Also > >> remove unused `oldkey' from ip6_sysctl_soiikey(). > > > > rwlock or mutex? As sysctl mlocks userland memory, copyin/copyout > > cannot sleep here. So it should be safe to use a mutex. > > It is locked because context switch is strictly unwanted when you > do copyin/copyout within foreach loops of kernel lock protected > lists like ps_list. Really this lock is the kind of a hack. But > since rwlocks already introduced context switch to sysctl() paths, > we use sysctl_lock rwlock to prevent many processes to > simultaneously lock large amount of memory. This is another hack > in this layer. Guess, both of them will gone in the future, so > copyin/copyout will sleep. So rwlock is better. > > > > > And why is this ip6_soiikey in the kernel anyway? I guess it is > > from a time when address configuration was done in the kernel. > > Could slaacd(8) just read /etc/soii.key? > > It could, but this should be implemented in slaacd first. And this > work is not related to (*pr_sysctl)() unlocking. >
Please stop changing the locking inside sysctl. It seems that the last change introduced a regression with the result that systems lock up. Until that is solved nothing else should be changed in this code. -- :wq Claudio
