Re: copyright notice question
On Mon, Oct 19, 2020, 7:25 PM Rick Macklem wrote: > I'll admit I've hesitated to ask this for a long time, but I guess I have > to;-) > I've created two daemons for NFS-over-TLS, using the code in > /usr/src/usr.sbin/gssd/gssd.c as a starting point. > --> As such, I left the copyright notice from this file on the two files. > (As you can see, it is a 2 clause FreeBSD one, so the terms aren't >an issue.) > > What I am wondering is if I should be adding my name to it as an > additional author or something like that? > (I don't care, but it does seem a little weird that the copyright is held > by Isilon Inc, since I have no connection to them.) > Likely. If you changed a substantial amount, then yes. The rule of thumb is >50% is no brainer yes. Smaller percentages require more nuanced judgement as to whether the changes are substantial enough to create a new work. Chances are quite good you fall into one of those categories. Also, if you have replaced more than ~90% chances are good no original work remains. Again, a judgement call. There are more technical legal guidelines, but that would require a lawyer. My hunch is that unless this is something far more trivial than I then I'd add the notice, but retaining the old. Warnet Here's what it currently says: > /*- > * SPDX-License-Identifier: BSD-2-Clause-FreeBSD > * > * Copyright (c) 2008 Isilon Inc http://www.isilon.com/ > * Authors: Doug Rabson > * Developed with Red Inc: Alfred Perlstein > * > * Redistribution and use in source and binary forms, with or without > * modification, are permitted provided that the following conditions > * are met: > * 1. Redistributions of source code must retain the above copyright > *notice, this list of conditions and the following disclaimer. > * 2. Redistributions in binary form must reproduce the above copyright > *notice, this list of conditions and the following disclaimer in the > *documentation and/or other materials provided with the distribution. > * > * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND > * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE > * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR > PURPOSE > * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE > * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR > CONSEQUENTIAL > * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS > * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) > * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, > STRICT > * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY > WAY > * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF > * SUCH DAMAGE. > */ > > Thanks for any comments, rick > ___ > 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" > ___ 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"
copyright notice question
I'll admit I've hesitated to ask this for a long time, but I guess I have to;-) I've created two daemons for NFS-over-TLS, using the code in /usr/src/usr.sbin/gssd/gssd.c as a starting point. --> As such, I left the copyright notice from this file on the two files. (As you can see, it is a 2 clause FreeBSD one, so the terms aren't an issue.) What I am wondering is if I should be adding my name to it as an additional author or something like that? (I don't care, but it does seem a little weird that the copyright is held by Isilon Inc, since I have no connection to them.) Here's what it currently says: /*- * SPDX-License-Identifier: BSD-2-Clause-FreeBSD * * Copyright (c) 2008 Isilon Inc http://www.isilon.com/ * Authors: Doug Rabson * Developed with Red Inc: Alfred Perlstein * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright *notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright *notice, this list of conditions and the following disclaimer in the *documentation and/or other materials provided with the distribution. * * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. */ Thanks for any comments, rick ___ 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"
review of new mountd option disabling use of rpcbind
Hi, I've put a patch up on phabricator that adds a new option to mountd which disables use of rpcbind. This can be done for NFSv4 only servers. It appears that rpcbind is now considered a security risk by some. I listed freqlabs@ as a reviewer, but if anyone else would like to review it, please do so. (Someone has reviewed the man page update already. Thanks bcr@.) It's D26746. rick ___ 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: panic: non-current pmap 0xffffa00020eab8f0 on Rpi3
On Mon, Oct 19, 2020 at 04:39:54PM -0400, Mark Johnston wrote: > > I think vmspace_exit() should issue a release fence with the cmpset and > an acquire fence when handling the refcnt == 1 case, but I don't see why > that would make a difference here. So, if you can test a debug patch, > this one will yield a bit more debug info. If you can provide access to > a vmcore and kernel debug symbols, that'd be even better. > I haven't seen an invalid pmap panic since the report of October 5th. Your patch applied cleanly on the Pi3 running HEAD at r366780M, the M being due to patches supplied by Kyle Evans applied to M sys/arm/broadcom/bcm2835/bcm2835_mbox.c M sys/arm/broadcom/bcm2835/bcm2835_sdhci.c M sys/arm/broadcom/bcm2835/bcm2835_vcbus.c M sys/arm/broadcom/bcm2835/bcm2835_vcbus.h AIUI, they're something to do with DMA for peripherals. They've caused no obvious trouble, if you anticipate conflicts let me know and I'll remove them I've never seen either a vmcore file or debug symbols on this machine. A sequence of instructions to generate the data needed would be helpful. Thanks for reading! bob prohaska ___ 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: panic: non-current pmap 0xffffa00020eab8f0 on Rpi3
On Fri, Oct 16, 2020 at 11:53:56AM +0200, Michal Meloun wrote:
>
>
> On 06.10.2020 15:37, Mark Johnston wrote:
> > On Mon, Oct 05, 2020 at 07:10:29PM -0700, bob prohaska wrote:
> >> Still seeing non-current pmap panics on the Pi3, this time a B+ running
> >> 13.0-CURRENT (GENERIC-MMCCAM) #0 71e02448ffb-c271826(master)
> >> during a -j4 buildworld. The backtrace reports
> >>
> >> panic: non-current pmap 0xa00020eab8f0
> >
> > Could you show the output of "show procvm" from the debugger?
>
> I see same panic too, in my case its very rare - typical scenario is
> rebuild of kf5 ports (~250, 2 days of full load). Any idea how to debug
> this?
> Michal
I suspect that there is some race involving the pmap switching in
vmspace_exit(), but I can't see it. In the example below, presumably
process 22604 on CPU 0 is also exiting? Could you show the backtrace?
It would also be useful to see the value of PCPU_GET(curpmap) at the
time of the panic. I'm not sure if there's a way to get that from DDB,
but I suspect it should be equal to >vm_pmap.
I think vmspace_exit() should issue a release fence with the cmpset and
an acquire fence when handling the refcnt == 1 case, but I don't see why
that would make a difference here. So, if you can test a debug patch,
this one will yield a bit more debug info. If you can provide access to
a vmcore and kernel debug symbols, that'd be even better.
diff --git a/sys/arm64/arm64/pmap.c b/sys/arm64/arm64/pmap.c
index 284f00b3cc0d..3c53ae3b4c1e 100644
--- a/sys/arm64/arm64/pmap.c
+++ b/sys/arm64/arm64/pmap.c
@@ -4838,7 +4838,8 @@ pmap_remove_pages(pmap_t pmap)
int allfree, field, freed, idx, lvl;
vm_paddr_t pa;
- KASSERT(pmap == PCPU_GET(curpmap), ("non-current pmap %p", pmap));
+ KASSERT(pmap == PCPU_GET(curpmap),
+ ("non-current pmap %p %p", pmap, PCPU_GET(curpmap)));
lock = NULL;
diff --git a/sys/vm/vm_map.c b/sys/vm/vm_map.c
index c20005ae64cf..0ad415e3b88c 100644
--- a/sys/vm/vm_map.c
+++ b/sys/vm/vm_map.c
@@ -358,7 +358,10 @@ vmspace_exit(struct thread *td)
p = td->td_proc;
vm = p->p_vmspace;
atomic_add_int(_refcnt, 1);
- refcnt = vm->vm_refcnt;
+ refcnt = atomic_load_int(>vm_refcnt);
+
+ KASSERT(vmspace_pmap(vm) == PCPU_GET(curpmap),
+ ("non-current pmap %p %p", pmap, PCPU_GET(curpmap)));
do {
if (refcnt > 1 && p->p_vmspace != ) {
/* Switch now since other proc might free vmspace */
___
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: top ARC stats are wrong
On 2020-10-18 09:22, Eric van Gyzen wrote: > I would love to have 2 TB of RAM, but alas, I have a paltry 32 GB, and > only 200 GB of disk used by ZFS: > > ARC: 1860M Total, 612G MFU, K MRU, 1921G Anon, 12M Header, 157M Other > > NAME SIZE ALLOC FREE > .. 230G 178G 51.7G > .. 298G 12.6G 285G > > This is on r366500+84ccaf49083c-c272054. > > I'll look into it when I have time, but that won't be soon. > > Eric > ___ > 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" I had seen this as well, I noticed the kstat sysctls seemed to be correct, so I am wondering if the size changes or something, and so top is misreading it. I also have not had a chance to dig into it. -- Allan Jude signature.asc Description: OpenPGP digital signature
