Re: CVS commit: src/sbin/cgdconfig

2018-12-27 Thread Alexander Nasonov
Christoph Badura wrote:
> Using /etc/cgd/ROOT. has the advantage that the cgd will configure
> if the root device changes name, thus upholding POLA.
> 
> E.g. moving disks from a controller that attaches sd(4)s to one that
> attaches ld(4)s.  I believe you can see that when dd'ing an image from
> SDcard to MMC on Pinebook.
> 
> It seems to me that similar behaviour for NAME=label would be more useful
> too. dk(4) attachments move around in practice.

Yeah, I discovered it the hard way ;-)

Perhaps the simplest change would be to pass an unresolved (original)
name when composing a paramsfile. E.g.

/etc/cgd/NAME=mylabel
/etc/cgd/ROOT.e

-- 
Alex


Removal of M_COPY_PKTHDR etc.

2018-12-27 Thread Christoph Badura
Doesn't that trigger a kernel version bump?
And shouldn't changes like this be documented in src/CHANGES?

--chris

On Thu, Dec 27, 2018 at 02:03:55PM +, Maxime Villard wrote:
> Module Name:  src
> Committed By: maxv
> Date: Thu Dec 27 14:03:55 UTC 2018
> 
> Modified Files:
>   src/sys/dev/pci: hifn7751.c
>   src/sys/kern: uipc_mbuf.c
>   src/sys/netmpls: mpls_ttl.c
>   src/sys/sys: mbuf.h
> 
> Log Message:
> Remove M_COPY_PKTHDR, M_MOVE_PKTHDR, M_ALIGN and MH_ALIGN.


Re: CVS commit: src/sbin/cgdconfig

2018-12-27 Thread Christoph Badura
On Thu, Dec 27, 2018 at 09:53:44PM +, Alexander Nasonov wrote:
> Alexander Nasonov wrote:
> > XXX Default paramsfile for NAME=label is /etc/cgd/dkNN (resolved wedge
> > partition) and /etc/cgd/ROOT. for ROOT.. This isn't yet
> > documented. IMO, it should be the other way around: /etc/cgd/label
> > for the former and /et/cgd/[root-device] for the latter.
> 
> This is true for NetBSD-8 which doesn't support ROOT. prefix.
> Both prefixes are resolved to real device names before composing
> a default paramsfile in NetBSD-current.

Using /etc/cgd/ROOT. has the advantage that the cgd will configure
if the root device changes name, thus upholding POLA.

E.g. moving disks from a controller that attaches sd(4)s to one that
attaches ld(4)s.  I believe you can see that when dd'ing an image from
SDcard to MMC on Pinebook.

It seems to me that similar behaviour for NAME=label would be more useful
too. dk(4) attachments move around in practice.

--chris


Re: CVS commit: src

2018-12-27 Thread Jason Thorpe



> On Dec 27, 2018, at 6:04 AM, Jason Thorpe  wrote:
> 
> -- job_hold remains lockless, but job_rele can only be called **without** the 
> job_lock held, because it needs to acquire the lock in the unlikely case it 
> performs a cv_broadcast (see below).  Also need a job_rele_locked.

Correction -- all cases of job_rele can be called with the job_lock held.  (I 
mis-read the block of the code in the overseer where the job_lock is dropped 
immediately before calling job_rele.)

Index: kern_threadpool.c
===
RCS file: /cvsroot/src/sys/kern/kern_threadpool.c,v
retrieving revision 1.12
diff -u -p -r1.12 kern_threadpool.c
--- kern_threadpool.c   27 Dec 2018 04:45:29 -  1.12
+++ kern_threadpool.c   27 Dec 2018 14:37:46 -
@@ -134,7 +134,7 @@ static void threadpool_percpu_destroy(st
 
 static threadpool_job_fn_t threadpool_job_dead;
 
-static int threadpool_job_hold(struct threadpool_job *);
+static voidthreadpool_job_hold(struct threadpool_job *);
 static voidthreadpool_job_rele(struct threadpool_job *);
 
 static voidthreadpool_overseer_thread(void *) __dead;
@@ -650,19 +650,16 @@ threadpool_job_destroy(struct threadpool
(void)strlcpy(job->job_name, "deadjob", sizeof(job->job_name));
 }
 
-static int
+static void
 threadpool_job_hold(struct threadpool_job *job)
 {
unsigned int refcnt;
 
do {
refcnt = job->job_refcnt;
-   if (refcnt == UINT_MAX)
-   return EBUSY;
+   KASSERT(refcnt != UINT_MAX);
} while (atomic_cas_uint(>job_refcnt, refcnt, (refcnt + 1))
!= refcnt);
-
-   return 0;
 }
 
 static void
@@ -670,16 +667,16 @@ threadpool_job_rele(struct threadpool_jo
 {
unsigned int refcnt;
 
+   KASSERT(mutex_owned(job->job_lock));
+
do {
refcnt = job->job_refcnt;
KASSERT(0 < refcnt);
if (refcnt == 1) {
-   mutex_enter(job->job_lock);
refcnt = atomic_dec_uint_nv(>job_refcnt);
KASSERT(refcnt != UINT_MAX);
if (refcnt == 0)
cv_broadcast(>job_cv);
-   mutex_exit(job->job_lock);
return;
}
} while (atomic_cas_uint(>job_refcnt, refcnt, (refcnt - 1))
@@ -703,6 +700,16 @@ threadpool_job_done(struct threadpool_jo
curlwp->l_name = job->job_thread->tpt_lwp_savedname;
lwp_unlock(curlwp);
 
+   /*
+* Inline the work of threadpool_job_rele(); the job is already
+* locked, the most likely scenario (XXXJRT only scenario?) is
+* that we're dropping the last reference (the one taken in
+* threadpool_schedule_job()), and we always do the cv_broadcast()
+* anyway.
+*/
+   KASSERT(0 < job->job_refcnt);
+   unsigned int refcnt __diagused = atomic_dec_uint_nv(>job_refcnt);
+   KASSERT(refcnt != UINT_MAX);
cv_broadcast(>job_cv);
job->job_thread = NULL;
 }
@@ -725,6 +732,8 @@ threadpool_schedule_job(struct threadpoo
return;
}
 
+   threadpool_job_hold(job);
+
/* Otherwise, try to assign a thread to the job.  */
mutex_spin_enter(>tp_lock);
if (__predict_false(TAILQ_EMPTY(>tp_idle_threads))) {
@@ -740,7 +749,6 @@ threadpool_schedule_job(struct threadpoo
__func__, job->job_name, job->job_thread));
TAILQ_REMOVE(>tp_idle_threads, job->job_thread,
tpt_entry);
-   threadpool_job_hold(job);
job->job_thread->tpt_job = job;
}
 
@@ -786,6 +794,7 @@ threadpool_cancel_job_async(struct threa
mutex_spin_enter(>tp_lock);
TAILQ_REMOVE(>tp_jobs, job, job_entry);
mutex_spin_exit(>tp_lock);
+   threadpool_job_rele(job);
return true;
} else {
/* Too late -- already running.  */
@@ -889,15 +898,13 @@ threadpool_overseer_thread(void *arg)
}
 
/* There are idle threads, so try giving one a job.  */
-   bool rele_job = true;
struct threadpool_job *const job = TAILQ_FIRST(>tp_jobs);
TAILQ_REMOVE(>tp_jobs, job, job_entry);
-   error = threadpool_job_hold(job);
-   if (error) {
-   TAILQ_INSERT_HEAD(>tp_jobs, job, job_entry);
-   (void)kpause("pooljob", false, hz, >tp_lock);
-   continue;
-   }
+   /*
+* Take an extra reference on the job temporarily so that
+* it won't disappear on us while we have both locks dropped.
+*/
+   threadpool_job_hold(job);
mutex_spin_exit(>tp_lock);
 
mutex_enter(job->job_lock);
@@ 

Re: CVS commit: src

2018-12-27 Thread Maxime Villard

Le 27/12/2018 à 08:41, matthew green a écrit :

"Maxime Villard" writes:

Module Name:src
Committed By:   maxv
Date:   Thu Dec 27 07:22:31 UTC 2018

Modified Files:
src/lib/libnvmm: libnvmm.3 libnvmm.c libnvmm_x86.c nvmm.h
src/tests/lib/libnvmm: h_mem_assist.c h_mem_assist_asm.S

Log Message:
Several improvements and fixes:

  * Change the Assist API. Rather than passing callbacks in each call, the
callbacks are now registered beforehand. Then change the I/O Assist to
fetch MMIO data via the Mem callback. This allows a guest to perform an
I/O string operation on a memory that is itself an MMIO.


this should have included a shlib bump i guess - there was
at least one function signature change.

thanks.


Well, I think I've done that several times already. Basically, given that
I keep changing the design, I don't want to bump the versions each time.
They will be bumped starting from NetBSD 9.