Re: userret: assert td_lk_slocks == 0
On Mon, Aug 12, 2019 at 12:14:25PM +0300, Andriy Gapon wrote: > > I am trying to debug a leak of a shared vnode lock and I noticed that > there is no check for td_lk_slocks in userret. There are checks for > td_rw_rlocks and td_sx_slocks. I wonder if there is any valid scenario > where a thread is allowed to retain a shared lock manager lock across > system calls. There is a situation where thread returns while keeping the lockmgr lock busied. This is used by buffer cache to keep everybody hands away of async buffers until io is finished. But the ownership of the lock is erased, and the thread's slocks count is decremented. I think it should be correct to add the assert you proposed. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: rc script: manual stop vs system shutdown
On Mon, Aug 12, 2019 at 10:46:29AM +0300, Andriy Gapon wrote: > On 01/08/2019 22:51, Ian Lepore wrote: > > On Thu, 2019-08-01 at 21:14 +0300, Andriy Gapon wrote: > >> On 01/08/2019 19:12, Warner Losh wrote: > >>> > >>> > >>> On Thu, Aug 1, 2019, 10:53 AM Rodney W. Grimes > >>> mailto:freebsd-...@gndrsh.dnsmgr.net>> > >>> wrote: > >>> > >>> > > >>> > Is it possible in an rc script to distinguish between a manual stop > >>> > (e.g., service foo stop) and a stop during a system shutdown (via > >>> > rc.shutdown) ? > >>> > Are there any marker variables for that? > >>> > Or something in the global system state? > >>> > >>> Not that I can think of, but I like this idea, > >>> I am sure that use cases exist. > >>> > >>> > >>> What is the use case that needs to disambiguate the two cases... > >> > >> I have one use case in mind and it's a truly special case. > >> I want rc.d/watchdogd to gracefully stop watchdogd and to disable the > >> watchdog timer when the stop action is requested manually. And I want > >> it to stop watchdogd and set the watchdog timer to a special shutdown > >> timeout during the shutdown. If the special timeout is configured, of > >> course. > >> > > > > The shutdown timeout is already supported: you just set '-x ' > > in watchdogd_flags in rc.conf; no changes to the rc.d script needed. > > > > I think probably you don't even need the first part of what you want. > > The -x arg covers you in the reboot case; most people probably won't > > use it. But if you are using it, and you want to truly kill the dog, > > you would just do "watchdog -t 0" after "service watchdogd stop". If > > you really felt the need to cover that with a single service command, > > then how about using "service watchdogd cancel" where the cancel verb > > does the -t 0 after killing the daemon? > > I guess that there is more than one way to achieve what I want or > something similar to that. > Rather than "expend words" on a theoretical discussion, I decided to do > this: https://reviews.freebsd.org/D21221 > However, I am still open to the discussion and suggestions. > One thing that I would prefer, though, is to make the watchdogd service > as smart as possible -- but not smarter :-) -- that is, I would prefer > to do without adding any new command verbs to it. Did you considered exporting kern_shutdown.c:rebooting as a sysctl ? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: userret: assert td_lk_slocks == 0
On 12/08/2019 13:49, Mateusz Guzik wrote: > On 8/12/19, Andriy Gapon wrote: >> >> I am trying to debug a leak of a shared vnode lock and I noticed that >> there is no check for td_lk_slocks in userret. There are checks for >> td_rw_rlocks and td_sx_slocks. I wonder if there is any valid scenario >> where a thread is allowed to retain a shared lock manager lock across >> system calls. >> > > These counters are not for debugging purposes. They are part of poor > man's starvation prevention for writers. Yes, I realize that. > If the target lock is taken for reading and someone wants to take it for > writing, a bit will be set to denote this fact and prevent more readers > from showing up. However, this can lead to deadlocks so if someone > already has a read lock on something, they can bypass the bit and > grab the extra read lock anyway. > > No locks are allowed to leak back to userspace and witness should > already handles checking this for readers as well. Yes. But since we have those asserts for td_rw_rlocks and td_sx_slocks, wouldn't it make sense to add one for td_lk_slocks? If it's considered superfluous for FreeBSD, then at least I'll add it in the work's fork. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: rc script: manual stop vs system shutdown
On 12/08/2019 13:57, Andriy Gapon wrote: > On 12/08/2019 13:45, Konstantin Belousov wrote: >> On Mon, Aug 12, 2019 at 10:46:29AM +0300, Andriy Gapon wrote: >>> I guess that there is more than one way to achieve what I want or >>> something similar to that. >>> Rather than "expend words" on a theoretical discussion, I decided to do >>> this: https://reviews.freebsd.org/D21221 >>> However, I am still open to the discussion and suggestions. >>> One thing that I would prefer, though, is to make the watchdogd service >>> as smart as possible -- but not smarter :-) -- that is, I would prefer >>> to do without adding any new command verbs to it. >> >> Did you considered exporting kern_shutdown.c:rebooting as a sysctl ? > > No, I didn't it. Thank you for the suggestion. > Let me investigate it. 'rebooting' seems to be too late, it's set when the actual reboot system call is made. rc.shutdown is run before that. I think that the kernel is generally[*] not aware of an imminent shutdown between the time init(8) is signaled and the time init(8) calls reboot(2). [*] -- except for cases where the kernel is an initiator of the shutdown. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: userret: assert td_lk_slocks == 0
On 8/12/19, Andriy Gapon wrote: > > I am trying to debug a leak of a shared vnode lock and I noticed that > there is no check for td_lk_slocks in userret. There are checks for > td_rw_rlocks and td_sx_slocks. I wonder if there is any valid scenario > where a thread is allowed to retain a shared lock manager lock across > system calls. > These counters are not for debugging purposes. They are part of poor man's starvation prevention for writers. If the target lock is taken for reading and someone wants to take it for writing, a bit will be set to denote this fact and prevent more readers from showing up. However, this can lead to deadlocks so if someone already has a read lock on something, they can bypass the bit and grab the extra read lock anyway. No locks are allowed to leak back to userspace and witness should already handles checking this for readers as well. -- Mateusz Guzik ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: rc script: manual stop vs system shutdown
On 12/08/2019 13:45, Konstantin Belousov wrote: > On Mon, Aug 12, 2019 at 10:46:29AM +0300, Andriy Gapon wrote: >> I guess that there is more than one way to achieve what I want or >> something similar to that. >> Rather than "expend words" on a theoretical discussion, I decided to do >> this: https://reviews.freebsd.org/D21221 >> However, I am still open to the discussion and suggestions. >> One thing that I would prefer, though, is to make the watchdogd service >> as smart as possible -- but not smarter :-) -- that is, I would prefer >> to do without adding any new command verbs to it. > > Did you considered exporting kern_shutdown.c:rebooting as a sysctl ? No, I didn't it. Thank you for the suggestion. Let me investigate it. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: rc script: manual stop vs system shutdown
On 01/08/2019 22:51, Ian Lepore wrote: > On Thu, 2019-08-01 at 21:14 +0300, Andriy Gapon wrote: >> On 01/08/2019 19:12, Warner Losh wrote: >>> >>> >>> On Thu, Aug 1, 2019, 10:53 AM Rodney W. Grimes >>> mailto:freebsd-...@gndrsh.dnsmgr.net>> >>> wrote: >>> >>> > >>> > Is it possible in an rc script to distinguish between a manual stop >>> > (e.g., service foo stop) and a stop during a system shutdown (via >>> > rc.shutdown) ? >>> > Are there any marker variables for that? >>> > Or something in the global system state? >>> >>> Not that I can think of, but I like this idea, >>> I am sure that use cases exist. >>> >>> >>> What is the use case that needs to disambiguate the two cases... >> >> I have one use case in mind and it's a truly special case. >> I want rc.d/watchdogd to gracefully stop watchdogd and to disable the >> watchdog timer when the stop action is requested manually. And I want >> it to stop watchdogd and set the watchdog timer to a special shutdown >> timeout during the shutdown. If the special timeout is configured, of >> course. >> > > The shutdown timeout is already supported: you just set '-x ' > in watchdogd_flags in rc.conf; no changes to the rc.d script needed. > > I think probably you don't even need the first part of what you want. > The -x arg covers you in the reboot case; most people probably won't > use it. But if you are using it, and you want to truly kill the dog, > you would just do "watchdog -t 0" after "service watchdogd stop". If > you really felt the need to cover that with a single service command, > then how about using "service watchdogd cancel" where the cancel verb > does the -t 0 after killing the daemon? I guess that there is more than one way to achieve what I want or something similar to that. Rather than "expend words" on a theoretical discussion, I decided to do this: https://reviews.freebsd.org/D21221 However, I am still open to the discussion and suggestions. One thing that I would prefer, though, is to make the watchdogd service as smart as possible -- but not smarter :-) -- that is, I would prefer to do without adding any new command verbs to it. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
userret: assert td_lk_slocks == 0
I am trying to debug a leak of a shared vnode lock and I noticed that there is no check for td_lk_slocks in userret. There are checks for td_rw_rlocks and td_sx_slocks. I wonder if there is any valid scenario where a thread is allowed to retain a shared lock manager lock across system calls. Thanks! -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 13.0 Current - r350702 exposed a Xorg failure
On 8/9/19 8:56 PM, Clay Daniels Jr. wrote: I was eager to load the new 13.0 Current snapshot yesterday as I wanted to play with the new FUSE tools. I was running 13.0 Current r350491 from last week and everything was going great. So last night, a little late I guess, I wiped the older install and loaded r250702. Then I loaded Xorg, all 172 packages, and loaded the drm-kmod video driver kernel modules, and then ran startx (as user of course). I got errors & it was late so today I looked closer. It said: "xauth: file .serverauth.1039 does not exist" Well, this file is apparently something created automatically. I played with the half-running install for a long time. It ran fine in console mode. Then I the wiped it and reloaded the same newer r350702. No Go. Wiped the new r350702 and reloaded the older r350491 that was working just fine last night. Same Problemserverauth.xxx Now, I do know that the drm-kmod was the same (g20190710) that had worked for me at least two times already. I do not know if the Xorg pkg is the same. I couldn't find a date other than "latest". I'm writing this email from my Linux partition. first thing that comes to mind, did you make sure to add your user to the "video" group? this doesn't sound related though...this does sound like a local configuration issue. iirc when i ran into this problem in the past it was due to permissions, either a .serverauth file owned by root or a UID that no longer exists. -p -- Pete Wright p...@nomadlogic.org @nomadlogicLA ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
