Re: Enable EVFILT_EXCEPT

2020-08-21 Thread Visa Hankala
On Fri, Aug 21, 2020 at 09:32:13AM +0200, Martin Pieuchot wrote: > The kqueue-based poll(2) backend is still a WIP due to regressions in > the kqueue layer. In the meantime should we expose EVFILT_EXCEPT to > userland? The diff below should be enough to allow userland apps to > use the new code

Re: Log mutex for msgbuf concurrency control

2020-08-20 Thread Visa Hankala
On Tue, Aug 18, 2020 at 03:06:58PM +, Visa Hankala wrote: > This diff introduces a mutex that serializes access to the kernel > message buffers. At the moment, the buffers do not have clear > concurrency control. > > The mutex controls access to all the modifiable fields o

Re: Fewer pool_get() in kqueue_register()

2020-08-19 Thread Visa Hankala
On Wed, Aug 19, 2020 at 12:10:12PM +0200, Martin Pieuchot wrote: > On 18/08/20(Tue) 15:30, Visa Hankala wrote: > > On Tue, Aug 18, 2020 at 11:04:47AM +0200, Martin Pieuchot wrote: > > > Diff below changes the order of operations in kqueue_register() to get > > > rid

Re: Fewer pool_get() in kqueue_register()

2020-08-18 Thread Visa Hankala
On Tue, Aug 18, 2020 at 11:04:47AM +0200, Martin Pieuchot wrote: > Diff below changes the order of operations in kqueue_register() to get > rid of an unnecessary pool_get(). When an event is already present on > the list try to acquire it first. Note that knote_acquire() may sleep > in which

Log mutex for msgbuf concurrency control

2020-08-18 Thread Visa Hankala
This diff introduces a mutex that serializes access to the kernel message buffers. At the moment, the buffers do not have clear concurrency control. The mutex controls access to all the modifiable fields of struct msgbuf. It also protects logsoftc.sc_state for managing thread wakeups. A tricky

Re: Fix kn_data returned by filt_logread()

2020-08-16 Thread Visa Hankala
On Sun, Aug 16, 2020 at 11:39:31AM +, Visa Hankala wrote: > The kernel message buffer is circular. This is not handled properly > by filt_logread(). When the write index wraps, and becomes smaller than > the read index, filt_logread() reports an incorrect number of available > byt

Fix kn_data returned by filt_logread()

2020-08-16 Thread Visa Hankala
The kernel message buffer is circular. This is not handled properly by filt_logread(). When the write index wraps, and becomes smaller than the read index, filt_logread() reports an incorrect number of available bytes. This has not affected the activation of the event, though, because the reported

Remove unnecessary field from struct msgbuf

2020-08-16 Thread Visa Hankala
The msg_bufl field of struct msgbuf is written but never read. The value was used by kernfs which is no longer present, so the code could be cleaned up a little by removing the field. On some systems the message buffer data are preserved across a reboot. However, the preservation is best-effort

Re: kqueue_scan_setup/finish

2020-08-15 Thread Visa Hankala
On Fri, Aug 14, 2020 at 12:31:33PM +0200, Martin Pieuchot wrote: > The previous change introducing the kqueue_scan_setup()/finish() API > required to switch poll(2) internals to use the kqueue mechanism has > been backed out. The reason for the regression is still unknown, so > let's take a baby

Reduce kqueue_scan()'s stack usage

2020-08-09 Thread Visa Hankala
sys_kevent() and kqueue_scan() consume a relatively large amount of kernel stack space, 352 and 544 bytes, respectively, on amd64. The portion of kqueue_scan() can be reduced by 256 bytes to 288 bytes by reusing sys_kevent()'s kev[] array. This diff overlaps with the non-committed kqueue_scan()

Use klist_invalidate() in knote_processexit()

2020-06-29 Thread Visa Hankala
knote_processexit() uses knote_remove() to clear any remaining knotes from >ps_klist when process `pr' exits. All EVFILT_PROC knotes are removed by the KNOTE(>ps_klist, NOTE_EXIT) call. However, ps_klist can contain EVFILT_SIGNAL knotes after the KNOTE(). To reserve knote_remove() for the kqueue

Retire

2020-06-19 Thread Visa Hankala
The header has been unhooked from / for a while, and no one has complained. Nothing seems to reference any longer, so the following files should be ready for removal: sys/arch/alpha/include/stdarg.h sys/arch/amd64/include/stdarg.h sys/arch/arm/include/stdarg.h sys/arch/arm64/include/stdarg.h

Block interrupts when changing struct process' ps_klist

2020-06-13 Thread Visa Hankala
The ps_klist member of struct process can be accessed from interrupt context as a result of signal sending. Currently, interrupts are not blocked when ps_klist is modified, which allows race conditions. The patch below guards ps_klist insertions and removals with splhigh(). The list should only

Call FRELE() without fdplock in dup*(2)

2020-06-10 Thread Visa Hankala
A while ago, finishdup() was changed to release fdplock before calling closef() to avoid potential lock order problems in the file close path. However, the dup* code can still invoke that path with fdplock held through FRELE(). That is fixed by the diff below. (In principle, the FRELE(fp, p)

Re: Kill NFS-only kqueue poller thread

2020-05-31 Thread Visa Hankala
On Sun, May 31, 2020 at 09:40:47AM +0200, Martin Pieuchot wrote: > On 30/05/20(Sat) 15:49, Visa Hankala wrote: > > [...] > > Local filesystems can observe changes at the source, which makes polling > > unnecessary. NFS clients do not have that benefit. The NFSv3 protocol

Re: Kill NFS-only kqueue poller thread

2020-05-30 Thread Visa Hankala
On Sat, May 30, 2020 at 03:34:06PM +0200, Martin Pieuchot wrote: > On 30/05/20(Sat) 09:22, Visa Hankala wrote: > > On Thu, May 28, 2020 at 12:11:20PM +0200, Martin Pieuchot wrote: > > > When it comes to kqueue filters NFS is special. A custom thread is > > > c

Outdated BUGS section in kqueue.2

2020-05-30 Thread Visa Hankala
The BUGS section in kqueue.2 is outdated. The FIFO limitation does not seem to exist anymore, AIO is not implemented at all in the kernel, and watching vnodes looks possible on all filesystem types that allow writing. OK to remove the section? Index: kqueue.2

Re: Kill NFS-only kqueue poller thread

2020-05-30 Thread Visa Hankala
On Thu, May 28, 2020 at 12:11:20PM +0200, Martin Pieuchot wrote: > When it comes to kqueue filters NFS is special. A custom thread is > created when the first event is registered. Its purpose is to poll > for changes every 2.5sec. This logic has been inherited from NetBSD > and is not present

Retire

2020-05-23 Thread Visa Hankala
The header is not used any longer. Consequently, it should be safe to remove the following files: sys/arch/alpha/include/varargs.h sys/arch/hppa/include/varargs.h sys/arch/i386/include/varargs.h sys/arch/landisk/include/varargs.h sys/arch/loongson/include/varargs.h

Update stale comment in

2020-05-20 Thread Visa Hankala
The header contains an outdated comment about headers and and should be updated. The comment is not fully consistent with the syslog(3) manual page because the manual does mention . However, the header's point still seems valid. OK? Index: sys/syslog.h

Remove sparc64 mutex.S

2020-05-18 Thread Visa Hankala
sparc64 has used the MI mutex since year 2018. However, the MD code still exists. The diff below removes it. OK? Index: arch/sparc64/sparc64/mutex.S === RCS file: arch/sparc64/sparc64/mutex.S diff -N arch/sparc64/sparc64/mutex.S ---

Convert octrtc(4) to use

2020-05-18 Thread Visa Hankala
This diff converts octrtc(4) to use the interface, to reduce use of . Some highlights for reviewing: * dt.dt_year contains the actual year, while tt->year has base 1900. * dt.dt_wday uses range 0-6, whereas tt->dow's range is 1-7. * octrtc_gettime() no longer extracts day of week because

Struct for kqueue scan state

2020-04-20 Thread Visa Hankala
This diff introduces a struct for kqueue scan state. It eases making scans piecewise by keeping track of the scan's end point. The end point prevents the scan from recollecting events that are already being reported to the userspace. Below is an overview of the goal. It is achieved by combining

stacktrace_save() sync

2020-04-15 Thread Visa Hankala
This diff: * upgrades stacktrace_save() to stacktrace_save_at() if the latter is missing on the architecture, * defines stacktrace_save() as an inline function in to replace MD definitions. OK? Index: arch/amd64/amd64/db_trace.c

Re: Simplify NET_LOCK() variations

2020-04-12 Thread Visa Hankala
On Sun, Apr 12, 2020 at 03:26:14PM +0200, Martin Pieuchot wrote: > The existing variations of the NET_LOCK() macros are confusing. We're > now all aware of this fact. So let's keep them simple to prevent future > mistakes :) > > The diff below reduces the current set of methods to the

Fix error path of VOP_IOCTL() in sr_hotspare()

2020-04-05 Thread Visa Hankala
In sr_hotspare(), the error path of VOP_IOCTL() appears to do a redundant VOP_CLOSE() and vput(). The diff below fixes that. The fail branch will close the vnode because `open' is true. OK? Index: dev/softraid.c === RCS file:

Change knote list head type

2020-04-04 Thread Visa Hankala
Below is a mostly mechanical patch that wraps the SLIST head of knotes inside another struct. The patch also introduces functions for adding and removing knotes from these lists. My intent is to extend the list struct so that the system can assert when the knote list should be locked. The idea is

Constify pledgenames[]

2020-04-03 Thread Visa Hankala
This diff makes pledgenames[] const. OK? Index: sys/kern/kern_pledge.c === RCS file: src/sys/kern/kern_pledge.c,v retrieving revision 1.261 diff -u -p -r1.261 kern_pledge.c --- sys/kern/kern_pledge.c 15 Feb 2020 09:35:48 -

Avoid selwakeup() in kqueue_wakeup()

2020-04-02 Thread Visa Hankala
selwakeup(sip) calls KNOTE(>si_note, 0), which implies that kqueue_wakeup() should not call selwakeup() directly. Otherwise, a contrived program can trigger deep recursion. The diff below moves selwakeup() from kqueue_wakeup() to kqueue_task(). In addition to preventing the recursion, this change

Check ktrstart() error in doktrace()

2020-03-21 Thread Visa Hankala
This diff makes doktrace() check the outcome of ktrstart() and skip tracing if the trace file header cannot be written. OK? Index: kern/kern_ktrace.c === RCS file: src/sys/kern/kern_ktrace.c,v retrieving revision 1.101 diff -u -p

Fix tsleep(9) during execve(2)

2020-03-21 Thread Visa Hankala
The recent change of initializing sls_sig = 0 in sleep_setup() (r1.164 of kern_synch.c) has introduced a regression with execve(2). execve(2) sets the current process in single thread mode for replacing the program image. In this mode, sleep_setup_signal() cancels a sleep, making tsleep(9) with

Fix a panic with unlocked soclose()

2020-03-11 Thread Visa Hankala
jcs@ has reported the following panic which started appearing as a consequence of the recent file close unlocking: panic: kernel diagnostic assertion "timo || _kernel_lock_held()" failed: file "/usr/src/sys/kern/kern_synch.c", line 123 panic __assert tsleep usbd_transfer usbd_do_request_flags

Fix use of WITNESS_UNLOCK() in rw_exit_{read,write}()

2020-02-29 Thread Visa Hankala
There is a bug in how rw_exit_read() and rw_exit_write() use WITNESS_UNLOCK(). The fast paths call WITNESS_UNLOCK() after releasing the actual lock. This leads to a use-after-free in the checker if the lock is dynamically allocated and another thread happens to free it too early. The following

Generic flags field in struct filterops

2020-02-19 Thread Visa Hankala
Eventually, it will become necessary to add new properties to struct filterops. One such property is whether the filter is safe to use without the kernel lock. The diff below replaces the f_isfd field with a generic flags field in struct filterops, to allow adding new properties without

Release fdplock before closef() in finishdup()

2020-02-18 Thread Visa Hankala
The following diff makes finishdup() release the file descriptor table lock before calling closef(). This makes the order of operations similar to that of fdrelease(). The dup* code still has an issue with file closing that this diff does not address. If fdalloc() fails in dodup3(), sys_dup() or

Set UF_EXCLOSE inside finishdup()

2020-02-16 Thread Visa Hankala
The closing of a file can be a complex operation, and hence it would be good to hold as few locks as possible when calling closef(). In particular, the code behind close(2) already releases the file descriptor table lock before closef(). This might not be strictly necessary when the type of the

Re: Raise spl for updating kn_status

2020-02-16 Thread Visa Hankala
On Sat, Feb 15, 2020 at 09:42:53PM +0100, Martin Pieuchot wrote: > On 15/02/20(Sat) 16:56, Visa Hankala wrote: > > When I added the knote_acquire() call in kqueue_register(), I overlooked > > the fact that the knote could be modified by a (soft) interrupt. > > Interrupts ha

Raise spl for updating kn_status

2020-02-15 Thread Visa Hankala
When I added the knote_acquire() call in kqueue_register(), I overlooked the fact that the knote could be modified by a (soft) interrupt. Interrupts have to be blocked when changing kn_status. Otherwise the state could become confused. The diff below adds splhigh() where kn_status is modified.

Re: const*ify cfattach

2020-02-15 Thread Visa Hankala
On Fri, Feb 14, 2020 at 06:08:31PM +0100, Martin Pieuchot wrote: > On 13/02/20(Thu) 17:23, Visa Hankala wrote: > > On Thu, Feb 13, 2020 at 06:07:01PM +0100, Martin Pieuchot wrote: > > > On 13/02/20(Thu) 16:53, Visa Hankala wrote: > > > [...] > > > > I wo

Re: const*ify cfattach

2020-02-13 Thread Visa Hankala
On Thu, Feb 13, 2020 at 06:07:01PM +0100, Martin Pieuchot wrote: > On 13/02/20(Thu) 16:53, Visa Hankala wrote: > > On Thu, Feb 13, 2020 at 12:00:35PM +0100, Martin Pieuchot wrote: > > > These structures are only used by autoconf(9) and don't need to be > > > modifie

Re: const*ify cfattach

2020-02-13 Thread Visa Hankala
On Thu, Feb 13, 2020 at 12:00:35PM +0100, Martin Pieuchot wrote: > These structures are only used by autoconf(9) and don't need to be > modified. Some subsystems already define most of them as 'const'. > Diff below turn all the remaining one as such. > > Only a single driver, de(4), needed a

Re: Push KERNEL_LOCK() down in pgsigio() and selwakeup()

2020-02-09 Thread Visa Hankala
On Tue, Feb 04, 2020 at 02:21:02PM +0100, Martin Pieuchot wrote: > void > selwakeup(struct selinfo *sip) > { > + KERNEL_LOCK(); > + KNOTE(>si_note, NOTE_SUBMIT); > + doselwakeup(sip); > + KERNEL_UNLOCK(); > +} There is a problem with audio code. Audio interrupt handlers

Remove non-__STDC__ asserts from

2020-02-08 Thread Visa Hankala
The header defines two sets of assert macros, one for standard C and another for the traditional cpp. As the header requires the use of a C compiler (that is, no inclusion from an assembly file), it looks that the non-__STDC__ parts could be removed. OK? Index: lib/libkern/libkern.h

Zero knotes on allocation

2020-02-08 Thread Visa Hankala
Zero knotes on allocation. Parts of struct knote, such as kn_tqe, can retain their old value quite long, which is not good in this complex piece of code. OK? Index: kern/kern_event.c === RCS file: src/sys/kern/kern_event.c,v

Re: Push KERNEL_LOCK() down in pgsigio() and selwakeup()

2020-02-08 Thread Visa Hankala
On Tue, Feb 04, 2020 at 02:21:02PM +0100, Martin Pieuchot wrote: > As recently profiled, the softnet thread which runs mostly without > KERNEL_LOCK() is still somehow serialized with the rest of the kernel. > This is because the various subsystems to notify userland, either via >

Re: Replace ttkqflush() with klist_invalidate()

2020-02-04 Thread Visa Hankala
On Tue, Feb 04, 2020 at 01:04:24PM +0100, Martin Pieuchot wrote: > On 02/02/20(Sun) 09:58, Visa Hankala wrote: > > tty(4) uses custom code for revoking knotes. It should be changed to use > > klist_invalidate() to handle the revocation in one place. The following > > diff

Replace ttkqflush() with klist_invalidate()

2020-02-02 Thread Visa Hankala
tty(4) uses custom code for revoking knotes. It should be changed to use klist_invalidate() to handle the revocation in one place. The following diff does that. In addition, the patch makes the code store the tty context pointer in kn_hook directly. This simplifies the code. Unlike ttkqflush(),

Re: Null pointer crash in filt_uhidrdetach

2020-01-06 Thread Visa Hankala
On Fri, Jan 03, 2020 at 11:37:22PM -0800, Greg Steuck wrote: > While playing with chromium u2f support[1] I managed to induce kernel > crashes in filt_uhidrdetach. It takes a few attempts of plugging/unplugging > the fido key while trying to authenticate at demo.yubico.com/playground. > Eventually

Re: SMR question

2019-12-29 Thread Visa Hankala
On Sun, Dec 29, 2019 at 05:23:43PM -0600, Amit Kulkarni wrote: > I was preparing a diff and wanted to know if it is safe to disable the > SMR kthread by commenting it out for testing purposes on amd64. Just a > simple yes/no would do! no

Re: grep -R with no path

2019-12-02 Thread Visa Hankala
On Mon, Dec 02, 2019 at 06:08:35PM +0100, Jeremie Courreges-Anglas wrote: > On Mon, Dec 02 2019, Marc Espie wrote: > > On Mon, Dec 02, 2019 at 08:31:02AM +, Miod Vallat wrote: > >> grep(1), when invoked with the -R option but no path, displays a > >> "recursive search of stdin" warning and

Re: Fix regress/sys/rtable for octeon

2019-06-24 Thread Visa Hankala
On Sun, Jun 23, 2019 at 02:48:24PM +0200, Moritz Buhl wrote: > Hi, > while running regression tests on an octeon ERL, I noticed that > no-macro-redefined flag was not known to the compiler. > I added some #undefs and some hours ago a change to art_walk made > the tests fail too. > > The

Re: mtx_enter_try(9) & recursion

2019-06-02 Thread Visa Hankala
On Sun, Jun 02, 2019 at 10:29:01AM -0300, Martin Pieuchot wrote: > On 02/06/19(Sun) 04:30, Visa Hankala wrote: > > On Sat, Jun 01, 2019 at 07:04:23PM -0300, Martin Pieuchot wrote: > > > On 01/06/19(Sat) 23:22, Mark Kettenis wrote: > > > > > Date: Sat, 1 Jun 2

Re: mtx_enter_try(9) & recursion

2019-06-01 Thread Visa Hankala
On Sat, Jun 01, 2019 at 07:04:23PM -0300, Martin Pieuchot wrote: > On 01/06/19(Sat) 23:22, Mark Kettenis wrote: > > > Date: Sat, 1 Jun 2019 17:32:52 -0300 > > > From: Martin Pieuchot > > > > > > Currently it isn't safe to call mtx_enter_try(9) if you're already > > > holding the mutex. That

Re: Patch to enable building of Octeon kernel with clang

2019-01-03 Thread Visa Hankala
On Thu, Jan 03, 2019 at 04:06:25PM +0100, Janne Johansson wrote: > Den tors 3 jan. 2019 kl 15:25 skrev Visa Hankala : > > > > On Thu, Jan 03, 2019 at 01:16:05PM +0300, Mikhael Skvortsov wrote: > > > Tested by running GENERIC.MP built by > > > make CC=clang COMPILE

Re: Patch to enable building of Octeon kernel with clang

2019-01-03 Thread Visa Hankala
On Thu, Jan 03, 2019 at 01:16:05PM +0300, Mikhael Skvortsov wrote: > Tested by running GENERIC.MP built by > make CC=clang COMPILER_VERSION=clang > on a CN6120 device. Thank you. I have something similar pending and will commit soonish. Certain things have to be done in concert with loongson and

Re: Patch for install64.octeon : EdgeRouter 6 info

2018-12-21 Thread Visa Hankala
On Thu, Dec 20, 2018 at 07:39:44PM -0500, Chris McGee wrote: > That looks much better to me, though it does get machine-specific > > I feel like it would be more clear if the examples uniformly used your > new variable > convention, as some do and some do not. This allows us to eliminate one >

Re: Patch for install64.octeon : EdgeRouter 6 info

2018-12-18 Thread Visa Hankala
On Mon, Dec 17, 2018 at 11:22:40PM -0500, Chris McGee wrote: > Hi: > > I would like to add some info for Edgerouter 6 > (and presumably ER4, and maybe also ER12?) to install64.octeon. > The document is great but it won't get a new user booting on the new > 4-core machines with MMC drives. > >

Re: SGI O2 mec(4) cold boot issue (and workaround)

2018-12-09 Thread Visa Hankala
On Sat, Dec 08, 2018 at 05:32:41PM +, Miod Vallat wrote: > I have noticed, for a while, that my O2 systems were horribly slow > during installs or upgrades, when fetching sets from the network (28 > *minutes* to fetch base64.tgz). > > At first, I thought this was a bsd.rd specific bug, but

Re: Unlock sendit-based syscalls

2018-06-27 Thread Visa Hankala
Here is a new version of the f_count atomic update diff. Now all updating of the `f_count' field should use atomic operations, and the `fhdlk' is only used for serializing access to the list of open files. In addition, the role of the `fd_fplock' should be clearer now: its only purpose is to let

Re: Unlock sendit-based syscalls

2018-06-21 Thread Visa Hankala
On Thu, Jun 21, 2018 at 04:49:48PM +, Visa Hankala wrote: > Here is an updated diff that has been adjusted for the current tree. Hmm, the diff is not right yet. Please ignore.

Re: Unlock sendit-based syscalls

2018-06-21 Thread Visa Hankala
On Tue, Jun 19, 2018 at 03:36:57PM +, Visa Hankala wrote: > On Tue, Jun 19, 2018 at 03:58:51PM +0200, Mark Kettenis wrote: > > > Date: Tue, 19 Jun 2018 15:38:01 +0200 > > > From: Martin Pieuchot > > > > > > On 19/06/18(Tue) 14:55, Mark Kettenis wrote

Re: Unlock sendit-based syscalls

2018-06-19 Thread Visa Hankala
On Tue, Jun 19, 2018 at 03:58:51PM +0200, Mark Kettenis wrote: > > Date: Tue, 19 Jun 2018 15:38:01 +0200 > > From: Martin Pieuchot > > > > On 19/06/18(Tue) 14:55, Mark Kettenis wrote: > > > > To avoid races with another thread that might be clearing our pointer > > > > in `fd_ofiles', we need

Re: Make witness(4) ready for UP systems

2018-06-14 Thread Visa Hankala
On Wed, Jun 13, 2018 at 10:45:08PM +0200, Christian Ludwig wrote: > It makes sense to have witness(4) on uniprocessor systems, too. Lock-order > violations are not an MP-only thing. Since UP kernels do not have the kernel > lock, wrap the code in appropriate ifdefs. Committed. Thank you.

Re: make octeon kernels compile with DEBUG.

2018-06-13 Thread Visa Hankala
On Wed, Jun 13, 2018 at 08:34:46AM +0200, Janne Johansson wrote: > The unconditional #define DEBUG in octeon/machdep.c is somewhat weird. > > Should we just keep the whole block and remove the #ifdefs, move it to > #if 1 for later easy removal? Dunno, but it won't compile with DEBUG > unless

Locking problem with open(2)

2018-06-02 Thread Visa Hankala
The open(2) system call uses a problematic locking pattern that can cause problems when the process has more than one thread. The system call keeps the file descriptor table locked when calling vn_open(9). If vn_open(9) blocks, the other threads get blocked too if they try to modify the descriptor

Re: Remove unused C3 values (VIA)

2018-06-02 Thread Visa Hankala
On Sat, Jun 02, 2018 at 01:00:05PM +0200, Frederic Cambus wrote: > Hi tech@, > > Here is a diff to remove unused C3 values. > > Comments? OK? I would keep the definitions because they can at least serve as a weak form of documentation about the hardware. For example, C3_CRYPT_CWLO_ALG_M

Re: Move FREF() inside fd_getfile()

2018-04-26 Thread Visa Hankala
On Thu, Apr 26, 2018 at 08:34:08AM +0200, Martin Pieuchot wrote: > On 25/04/18(Wed) 17:07, Visa Hankala wrote: > > On Wed, Apr 25, 2018 at 12:12:29PM +0200, Martin Pieuchot wrote: > > > The goal is to avoid races between fd_getfile() and FREF(). So we want > > > a prope

Re: Move FREF() inside fd_getfile()

2018-04-25 Thread Visa Hankala
On Wed, Apr 25, 2018 at 12:12:29PM +0200, Martin Pieuchot wrote: > The goal is to avoid races between fd_getfile() and FREF(). So we want > a properly refcounted 'struct file *' as soon as possible. Boot hangs with this patch. The last line on the console is "setting tty flags". Two issues

Re: vput(9) for NFS

2018-04-11 Thread Visa Hankala
On Wed, Apr 11, 2018 at 12:34:03PM +0200, Martin Pieuchot wrote: > On 09/04/18(Mon) 16:10, Martin Pieuchot wrote: > > Diff below implements most of the missing locking goo for NFS without > > enabling it. It does the following: > > > > - Add a missing PDIRUNLOCK in nfs_lookup() > > > > - Change

Re: NFS vs NET_LOCK()

2018-03-29 Thread Visa Hankala
On Thu, Mar 29, 2018 at 11:57:42AM +0200, Martin Pieuchot wrote: > On 28/03/18(Wed) 16:09, Visa Hankala wrote: > > On Wed, Mar 28, 2018 at 11:59:46AM +0200, Martin Pieuchot wrote: > > > Index: uvm/uvm_vnode.c > > > ===

Re: NFS vs NET_LOCK()

2018-03-28 Thread Visa Hankala
On Wed, Mar 28, 2018 at 11:59:46AM +0200, Martin Pieuchot wrote: > Index: uvm/uvm_vnode.c > === > RCS file: /cvs/src/sys/uvm/uvm_vnode.c,v > retrieving revision 1.99 > diff -u -p -r1.99 uvm_vnode.c > --- uvm/uvm_vnode.c 8 Mar 2018

Re: NFS vs NET_LOCK()

2018-03-27 Thread Visa Hankala
On Tue, Mar 27, 2018 at 11:00:20AM +0200, Martin Pieuchot wrote: > Diff below prevents a future lock ordering problem between NFSnode > locks (similar to Inode locks) and the NET_LOCK(). > > It ensures the NET_LOCK() is always locked *after* any NFSnode lock > by fixing the UVM fault case. So we

Re: sdhc(4) base clock

2018-03-18 Thread Visa Hankala
On Sun, Mar 18, 2018 at 06:33:59PM +0100, Mark Kettenis wrote: > > Date: Sun, 18 Mar 2018 12:17:09 + > > From: Visa Hankala <v...@openbsd.org> > > > > On Sat, Mar 17, 2018 at 07:41:39PM +0100, Mark Kettenis wrote:

Re: sdhc(4) base clock

2018-03-18 Thread Visa Hankala
On Sat, Mar 17, 2018 at 07:41:39PM +0100, Mark Kettenis wrote: > Index: dev/sdmmc/sdhc.c > === > RCS file: /cvs/src/sys/dev/sdmmc/sdhc.c,v > retrieving revision 1.56 > diff -u -p -r1.56 sdhc.c > --- dev/sdmmc/sdhc.c 10 Feb 2018

Re: MI mutex

2018-01-23 Thread Visa Hankala
On Tue, Jan 23, 2018 at 03:23:24PM +0100, Martin Pieuchot wrote: > On 23/01/18(Tue) 14:06, Visa Hankala wrote: > > In addition, you should put the common mutex code into kern_mutex.c. > > Lets keep kern_lock.c for the mplock only. > > I'm more in favor of putting everyt

Re: MI mutex

2018-01-23 Thread Visa Hankala
On Mon, Jan 22, 2018 at 11:12:13AM +0100, Martin Pieuchot wrote: > Diff below moves the common mutex implementation to kern/ and enable it for > alpha, amd64, arm64, i386, mips64, powerpc. Your diff seems to miss the necessary bits in . In addition, you should put the common mutex code into

Re: ddb(4) userland trace and SMAP

2017-12-07 Thread Visa Hankala
On Thu, Dec 07, 2017 at 11:43:09AM +0100, Martin Pieuchot wrote: > On 05/12/17(Tue) 14:52, Visa Hankala wrote: > > On Tue, Dec 05, 2017 at 11:32:53AM +0100, Martin Pieuchot wrote: > > > On 04/12/17(Mon) 12:24, Martin Pieuchot wrote: > > > > Since SMAP is enabled ddb

Re: ddb(4) userland trace and SMAP

2017-12-05 Thread Visa Hankala
On Tue, Dec 05, 2017 at 11:32:53AM +0100, Martin Pieuchot wrote: > On 04/12/17(Mon) 12:24, Martin Pieuchot wrote: > > Since SMAP is enabled ddb(4)'s 'trace /u' and 'trace /p' for a userland > > processes result, as expected, in page faults. > > > > Diff below disable SMAP for the duration of the

Re: Fix a typo in INSTALL.octeon

2017-11-30 Thread Visa Hankala
On Thu, Nov 30, 2017 at 01:05:58AM +0100, Rafael Neves wrote: > Hi, > > The patch below replace one "$loadaddr" to "${loadaddr}" in U-Boot > instructions of INSTALL.octeon. > > Regards, > Rafael Neves Committed, thanks. > Index: install >

Re: un-KERNEL_LOCK() TCP/UDP input & co

2017-11-14 Thread Visa Hankala
On Tue, Nov 14, 2017 at 10:37:16AM +0100, Martin Pieuchot wrote: > Note that the diff below still includes a false positive. If the > current thread doesn't have the read-lock but another one has it, > then RW_READ will still be returned. That's true if witness(4) has not been enabled.

Re: un-KERNEL_LOCK() TCP/UDP input & co

2017-11-13 Thread Visa Hankala
On Mon, Nov 13, 2017 at 01:25:42PM +0100, Martin Pieuchot wrote: > I'd love is somebody could do the changes in the rwlock API to let us > check if we're holding a lock. Maybe this is already present in > witness(4), visa? witness(4) does maintain data about lock ownership. The patch below might

Re: pow() returns a negative result on loongson

2017-10-10 Thread Visa Hankala
On Mon, Oct 09, 2017 at 10:39:47PM +0200, Juan Francisco Cantero Hurtado wrote: > Marc Feeley (Gambit Scheme) has been helping me with a bug on Gambit on > Loongson. Apparently the bug is on our side. > > I've created this little test based on his code: > > #include > #include > > int main()

Reduce pool cache items when there is no contention

2017-07-05 Thread Visa Hankala
The current pool cache code increases the number of items that can be cached locally in response to lock contention. This patch adds a tweak that lowers the number when contention does not occur. The idea is to let resources be returned to the common pool when pressure on the cache has decreased.

Re: Properly serialize pflow's sc_outputqueue

2017-05-30 Thread Visa Hankala
On Wed, May 31, 2017 at 01:52:31AM +1000, Jonathan Matthew wrote: > On Tue, May 30, 2017 at 01:04:07PM +0000, Visa Hankala wrote: > > Index: net/if_pflow.c > > === > > RCS file: src/sys/net/if_pflow.c,v > &g

Re: Properly serialize pflow's sc_outputqueue

2017-05-30 Thread Visa Hankala
On Mon, May 29, 2017 at 03:33:35PM +, Visa Hankala wrote: > Currently, access to pflow's sc_outputqueue is not serialized properly. > The producer has the NET_LOCK(), while the consumer does not. > mpi@ suggested using mbuf_queue to solve the issue. mpi@ commented that the pflow ou

Properly serialize pflow's sc_outputqueue

2017-05-29 Thread Visa Hankala
Currently, access to pflow's sc_outputqueue is not serialized properly. The producer has the NET_LOCK(), while the consumer does not. mpi@ suggested using mbuf_queue to solve the issue. OK? Index: net/if_pflow.c === RCS file:

mips64 copyin32(9)

2017-05-18 Thread Visa Hankala
Here is a copyin32(9) for mips64. With futex(2) using it, the regress tests pass on loongson, octeon and sgi. Source addresses with wrong alignment are handled by the on-fault logic in itsa() trap handler. OK? Index: arch/mips64/mips64/lcore_access.S

Re: Atomic copyin(9)/copyout(9) for amd64

2017-05-15 Thread Visa Hankala
On Sun, May 14, 2017 at 10:05:28PM +0200, Mark Kettenis wrote: > I tried to convert a few more architectures, and things get a bit > messier than I envisioned on architectures that have an optimized copy > function and care about alignment. Especially when copyin(9) is > implemented in assembly.

Re: Atomic copyin(9)/copyout(9) for amd64

2017-05-12 Thread Visa Hankala
On Mon, May 01, 2017 at 06:02:24PM +0200, Mark Kettenis wrote: > The futex(2) syscall needs to be able to atomically copy the futex in > and out of userland. The current implementation uses copyin(9) and > copyout(9) for that. The futex is a 32-bit integer, and currently our > copyin(9) and

Re: Atomic copyin(9)/copyout(9) for amd64

2017-05-02 Thread Visa Hankala
On Mon, May 01, 2017 at 06:02:24PM +0200, Mark Kettenis wrote: > The futex(2) syscall needs to be able to atomically copy the futex in > and out of userland. The current implementation uses copyin(9) and > copyout(9) for that. The futex is a 32-bit integer, and currently our > copyin(9) and

Re: Break pluart(4)

2017-04-11 Thread Visa Hankala
On Tue, Apr 11, 2017 at 04:55:45PM +0200, Mark Kettenis wrote: > Se here is an updated diff; thanks for catching this. > > ok? OK visa@ > Index: arch/arm64/dev/pluart.c > === > RCS file: /cvs/src/sys/arch/arm64/dev/pluart.c,v >

Re: Break pluart(4)

2017-04-11 Thread Visa Hankala
On Tue, Apr 11, 2017 at 03:51:51PM +0200, Mark Kettenis wrote: > + if (ISSET(sc->sc_hwflags, COM_HW_CONSOLE)) { > + if (db_console) > + Debugger(); > + continue; > +

Refactor SIMPLEQ out of sk(4)

2017-01-15 Thread Visa Hankala
sk(4) uses a queue for managing Tx DMA maps. Because the queue would require synchronization if the driver was unlocked, it might be best to refactor the code a bit. This patch removes the queue by making Tx and Rx DMA maps part of struct sk_chain. OK? Index: dev/pci/if_sk.c

Re: {ah,esp}_input_cb() & NET_LOCK()

2017-01-09 Thread Visa Hankala
On Mon, Jan 09, 2017 at 04:10:48PM +0100, Martin Pieuchot wrote: > As reported by Hrvoje Popovski, these two callbacks also need the > NET_LOCK(): > > splassert: ip_output: want 1 have 0 > Starting stack trace... > ip_output() at ip_output+0x7d > pfsync_sendout() at

Re: rasops(9): Use proper RGB values for the ANSI color palette

2017-01-07 Thread Visa Hankala
On Sat, Jan 07, 2017 at 12:23:31AM +0100, Frederic Cambus wrote: > Hi tech@, > > Here is a diff to use proper RGB values for the ANSI color palette in > rasops(9). > > Comments? OK? I prefer the old palette because its contrast is higher. > Index: sys/dev/rasops/rasops.c >

Interrupt race in NET_LOCK/NET_UNLOCK

2016-12-22 Thread Visa Hankala
NET_LOCK() should raise IPL before acquiring the lock, and NET_UNLOCK() should restore the level after releasing the lock. Otherwise, lock recursion can occur, most likely right after the splx(). An example: nd6_slowtimo <- NET_LOCK() timeout_run softclock softintr_dispatch dosoftint interrupt

NET_LOCK() recursion during netboot

2016-12-21 Thread Visa Hankala
Network boot triggers a netlock recursion: panic rw_enter sosend <- NET_LOCK() nfs_send nfs_request nfs_lookup VOP_LOOKUP vfs_lookup namei unp_connect uipc_usrreq soconnect <- NET_LOCK() sys_connect An XXXSMP workaround seems appropriate here. OK? Index: kern/uipc_usrreq.c

Outdated remarks about partitioning on sgi

2016-10-05 Thread Visa Hankala
With the disklabel read logic in the sgi bootblocks, the 'a' partition no longer has to be the first partition on a disk, so the positioning remarks in the install notes and the installer seem outdated. The patch below removes them. OK? Index: distrib/notes/sgi/install

Re: Smarter OpenBSD/sgi boot blocks

2016-10-05 Thread Visa Hankala
On Tue, Oct 04, 2016 at 08:08:32PM +, Miod Vallat wrote: > The sgi boot blocks use the PROM (ARCBios or ARCS) for its I/O routines. > When using a disk-based path, these routines are using the partition > table found in the ``volume header''. > > In order to be able to use 16 partitions per

Re: Manpage for uctuctl(4)

2016-09-18 Thread Visa Hankala
On Sun, Sep 18, 2016 at 03:33:00PM +0200, Ingo Schwarze wrote: > So, here is a cleaned-up version: > > - Move the new page to the proper directory. > - Mention it in the Makefile. > - Put the correct manual page author into the Copyright notice. > - Add the architecture to the .Dt line. > -

  1   2   >