Re: copyright notice question

2020-10-21 Thread Rick Macklem
Mehmet Erol Sanliturk wrote: >On Wed, Oct 21, 2020 at 4:04 AM Rick Macklem >mailto:rmack...@uoguelph.ca>> wrote: >>Warner Losh wrote: >>>On Mon, Oct 19, 2020, 7:25 PM Rick Macklem >>>mailto:rmack...@uoguelph.ca><mailto:rmack...@uoguelph.ca<mailto:rmac

Re: copyright notice question

2020-10-20 Thread Rick Macklem
Warner Losh wrote: >On Mon, Oct 19, 2020, 7:25 PM Rick Macklem >mailto:rmack...@uoguelph.ca>> 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/sr

Re: review of new mountd option disabling use of rpcbind

2020-10-20 Thread Rick Macklem
nfsd does. I don't have a strong opinion either way. What do others think? Thanks for the comment, rick - Peter > On 20 Oct 2020, at 02:56, Rick Macklem wrote: > > Hi, > > I've put a patch up on phabricator that adds a new option to mountd > which disables use of rpcbind. Th

copyright notice question

2020-10-19 Thread Rick Macklem
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

review of new mountd option disabling use of rpcbind

2020-10-19 Thread Rick Macklem
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

RFC: gssd needs /usr mounted to start up

2020-10-10 Thread Rick Macklem
Meowthink reported a problem on freebsd-hackers@ where the gssd would not start up because /usr was not yet mounted. (I moved the discussion here, hoping to catch more comments.) He has a separately mounted /usr and, recently, gssd was failing to start since /usr was not yet mounted when

Re: RFC: should copy_file_range(2) remain Linux compatible or support special files?

2020-10-01 Thread Rick Macklem
Mateusz Guzik wrote: >On 9/27/20, Alan Somers wrote: >> On Sun, Sep 27, 2020 at 7:49 AM Wall, Stephen >> wrote: >> >>> >>> > I'll assume you are referring to the "flags" argument when you say >>> "param" above. >>> >>> Correct, I was misremembering the man page. >>> >>> > However, since the

Re: RFC: should copy_file_range(2) remain Linux compatible or support special files?

2020-09-26 Thread Rick Macklem
Wall, Stephen wrote: > Could the as yet unused options param have a bit assigned to trigger the new > behavior? Inform the linux community of the addition and let them decide if > they > would like to adopt it as well. I'll assume you are referring to the "flags" argument when you say "param"

RFC: should copy_file_range(2) remain Linux compatible or support special files?

2020-09-26 Thread Rick Macklem
I know cross-posting is frowned upon, but I wanted everyone who might like to comment to see this. Currently copy_file_range(2) only supports regular files, which is compatible with the Linux one, where EINVAL is returned when either file descriptor refers to a non-regular file. Alan Somers

review of mountd.c change

2020-09-21 Thread Rick Macklem
Hi, I just put a patch up in phabricator (D26521) which avoids always malloc()'ng a large MAX_NGROUPS sized groups list by having a small one in the structure and then only malloc()'ng when a large groups list is needed. I've listed kib@ and freqlabs@ as reviewers, but anyone else is welcome to

Re: Plans for git

2020-09-20 Thread Rick Macklem
Christian Weisgerber wrote: > On 2020-09-19, Zaphod Beeblebrox wrote: > > > Hrm. Maybe what I hear others saying, tho, and not entirely being replied > > to is just a nice concise document of the why. What I hear you saying is > > that GIT has momentum and that it's popular... (and I accept

Re: Documentation regarding NFSv4

2020-09-18 Thread Rick Macklem
Russell L. Carter wrote: >On 2020-09-18 16:28, Rick Macklem wrote: > > Oh, and I forgot to mention name<->id# mapping. > > If using AUTH_SYS (not kerberos), then you have the > > choice of running "nfsuserd" or setting these two sysctls t

Re: Documentation regarding NFSv4

2020-09-18 Thread Rick Macklem
ed, you'll see lots of files owned by "nobody" on the client mounts. rick ________ From: Rick Macklem Sent: Friday, September 18, 2020 7:21 PM To: Shawn Webb; freebsd-current@freebsd.org; freebsd-sta...@freebsd.org Subject: Re: Documentation regarding NFSv

Re: Documentation regarding NFSv4

2020-09-18 Thread Rick Macklem
Shawn Webb wrote: >Hey all, > >It appears the Handbook and the nfsv4 manpages don't really agree, >leading to some confusion as to how to properly set up an NFSv4 server >on FreeBSD. > >Any guidance would be appreciated. 1 - I never look at the Handbook, but do try and maintain the man pages.

Re: rfc: should extant TLS connections be closed when a CRL is updated?

2020-09-16 Thread Rick Macklem
John-Mark Gurney wrote: >Rick Macklem wrote this message on Fri, Sep 04, 2020 at 01:20 +: >> The server side NFS over TLS daemon (rpc.tlsservd) can reload an updated >> CRL (Certificate Revocation List) when a SIGHUP is posted to it. >> However, it does not SSL_shutdown

Re: rfc: should extant TLS connections be closed when a CRL is updated?

2020-09-04 Thread Rick Macklem
John-Mark Gurney wrote: >Rick Macklem wrote this message on Fri, Sep 04, 2020 at 01:20 +: >> The server side NFS over TLS daemon (rpc.tlsservd) can reload an updated >> CRL (Certificate Revocation List) when a SIGHUP is posted to it. >> However, it does not SSL_shutdown

rfc: should extant TLS connections be closed when a CRL is updated?

2020-09-03 Thread Rick Macklem
Hi, The server side NFS over TLS daemon (rpc.tlsservd) can reload an updated CRL (Certificate Revocation List) when a SIGHUP is posted to it. However, it does not SSL_shutdown()/close() extant TCP connections using TLS. (Those would only be closed if the daemon is restarted.) I am now thinking

Re: /sys/modules/ nfscl & nfsd

2020-09-01 Thread Rick Macklem
Julian H. Stacey wrote: >Hi curr...@freebsd.org, > >/sys/modules/ nfscl & nfsd >With .ctm_status src-cur 14656 .svn_revision 364986 > >/usr/src/sys/fs/nfsclient/nfs_clkrpc.c:40:10: fatal error: 'opt_kern_tls.h' >file not found ># #include "opt_kern_tls.h" > ># /usr/src/sys/modules/nfsd >#

Re: should rpctlssd be called rpc.tlssd?

2020-09-01 Thread Rick Macklem
Gary Jennejohn wrote:On Tue, 1 Sep 2020 13:00:33 +0200 (CEST) >Ronald Klop wrote: >> Van: Rick Macklem >> Datum: dinsdag, 1 september 2020 04:37 >> Aan: "freebsd-current@FreeBSD.org" >> Onderwerp: should rpctlssd be called rpc.tlssd? >> > &

should rpctlssd be called rpc.tlssd?

2020-08-31 Thread Rick Macklem
This sounds trivial, but I thought I'd ask, in case anyone has a preference? The NFS over TLS code includes two daemons, one for the client and one for the server. I have called them rpctlscd and rpctlssd. There was/is a tradition in Sun RPC of putting a "." in the names. So, should I be calling

Re: Does FreeBSD have an assigned Internet OID?

2020-08-30 Thread Rick Macklem
Poul-Henning Kamp wrote: >Rick Macklem writes: >> Poul-Henning Kamp wrote: > >> Is https://reviews.freebsd.org/D26225 >> sufficient to allow me to use 1.3.6.1.4.1.2238.1.1.1 for a user@domain >> name in this otherName component of subjAltName in the X.509 cert?

Re: Does FreeBSD have an assigned Internet OID?

2020-08-28 Thread Rick Macklem
Poul-Henning Kamp wrote: >Rick Macklem writes: >> For the NFS over TLS work, I have a need for an Internet OID. >> (I understand that IETF assigns ones for things like SNMP under >> 1.3.6.1.4.1...) > >See: > >/usr/share/snmp/mibs/FREEBSD-MIB.txt Is h

Does FreeBSD have an assigned Internet OID?

2020-08-27 Thread Rick Macklem
For the NFS over TLS work, I have a need for an Internet OID. (I understand that IETF assigns ones for things like SNMP under 1.3.6.1.4.1...) I'm referring to the long strings of numbers separated by "."s, where each number is a subtree administered by someone. If either the project or

review of a change to sosend_generic()

2020-08-16 Thread Rick Macklem
Hi, I put D25923 up on phabricator a little while ago. I clicked on a couple of people that I thought might like to review it. However, if anyone else would like to review it, please do so. The review is as much about the concept as the actual implementation. Thanks, rick Here is the

Re: can buffer cache pages be used in ext_pgs mbufs?

2020-08-13 Thread Rick Macklem
Konstantin Belousov wrote: >On Tue, Aug 11, 2020 at 03:10:39AM +0000, Rick Macklem wrote: >> Konstantin Belousov wrote: >> >On Mon, Aug 10, 2020 at 12:46:00AM +, Rick Macklem wrote: >> >> Konstantin Belousov wrote: >> >> >On Fri, Aug 07,

Re: can buffer cache pages be used in ext_pgs mbufs?

2020-08-10 Thread Rick Macklem
Konstantin Belousov wrote: >On Mon, Aug 10, 2020 at 12:46:00AM +0000, Rick Macklem wrote: >> Konstantin Belousov wrote: >> >On Fri, Aug 07, 2020 at 09:43:14PM -0700, Kirk McKusick wrote: >> >> I do not have the answer to your question, but I am copying Kostik >&

can buffer cache pages be used in ext_pgs mbufs?

2020-08-06 Thread Rick Macklem
Hi, I've been at this game for a while and one of the axioms is... "Everything is harder than it at first looks." Currently, when the FreeBSD NFS client does a write, it does: - VOP_WRITE() copies the data into buffer cache block(s). --> An nfsiod thread (or sometimes the thread that called

Re: RFC: ktls and krpc using M_EXTPG mbufs

2020-07-27 Thread Rick Macklem
Andrew Gallatin wrote: >On 2020-07-19 19:34, Rick Macklem wrote: >> I spent a little time chasing a problem in the nfs-over-tls code, where it >> would sometimes end up with corrupted data in the file(s) of a mirrored >> pNFS configuration. >> >> I think the

RFC: ktls and krpc using M_EXTPG mbufs

2020-07-19 Thread Rick Macklem
I spent a little time chasing a problem in the nfs-over-tls code, where it would sometimes end up with corrupted data in the file(s) of a mirrored pNFS configuration. I think the problem was that the code filled the data to be written into anonymous page M_EXTPG mbufs, then did a m_copym() { copy

Re: r358252 causes intermittent hangs where processes are stuck sleeping on btalloc

2020-07-03 Thread Rick Macklem
Ryan Libby wrote: >On Sun, Jun 28, 2020 at 9:57 PM Rick Macklem wrote: >> >> Just in case you were waiting for another email, I have now run several >> cycles of the kernel build over NFS on a recent head kernel with the >> one line change and it has n

Re: r358252 causes intermittent hangs where processes are stuck sleeping on btalloc

2020-06-28 Thread Rick Macklem
anything in the next few days, I'll put it in a PR so it doesn't get forgotten. rick From: owner-freebsd-curr...@freebsd.org on behalf of Rick Macklem Sent: Thursday, June 18, 2020 11:42 PM To: Ryan Libby Cc: Konstantin Belousov; Jeff Roberson; freebsd

Re: openzfs-kmod build error

2020-06-23 Thread Rick Macklem
Kostya Berger wrote: >CURRENT r362292 >sysutils/openzfs-kmod build aborts with error:... >/usr/ports/sysutils/openzfs-kmod/work/zfs->c0eb5c35e/module/os/freebsd/zfs/zfs_vfsops.c:128:19: > error: > incompatible pointer types initializing 'vfs_checkexp_t *' (aka 'int > (*)(struct >

Re: r358252 causes intermittent hangs where processes are stuck sleeping on btalloc

2020-06-18 Thread Rick Macklem
Ryan Libby wrote: >On Mon, Jun 15, 2020 at 5:06 PM Rick Macklem wrote: >> >> Rick Macklem wrote: >> >r358098 will hang fairly easily, in 1-3 cycles of the kernel build over = NFS. >> >I thought this was the culprit, since I did 6 cycles of r358097 without = a han

does a ZFS change in head require additional work?

2020-06-16 Thread Rick Macklem
Hi, r362158 changed the arguments for zfs_checkexp() in head. There were no other changes, since the arguments are simply passed on to vfs_stdcheckexp(). Is there something else that needs to be done, such as sending this patch upstream? rick ___

Re: r358252 causes intermittent hangs where processes are stuck sleeping on btalloc

2020-06-15 Thread Rick Macklem
Rick Macklem wrote: >r358098 will hang fairly easily, in 1-3 cycles of the kernel build over NFS. >I thought this was the culprit, since I did 6 cycles of r358097 without a hang. >However, I just got a hang with r358097, but it looks rather different. >The r358097 hang did not have a

Re: r358252 causes intermittent hangs where processes are stuck sleeping on btalloc

2020-06-09 Thread Rick Macklem
ote: >On Fri, May 22, 2020 at 11:46:26PM +, Rick Macklem wrote: >> Konstantin Belousov wrote: >> >On Wed, May 20, 2020 at 11:58:50PM -0700, Ryan Libby wrote: >> >> On Wed, May 20, 2020 at 6:04 PM Rick Macklem wrote: >> >> > >> >> > Hi,

new mbuf functions to allocate and copy into ext_pgs mbufs with anonymous pages

2020-06-07 Thread Rick Macklem
Hi, I just put a patch that has a couple of new mbuf handling functions here: https://reviews.freebsd.org/D25182 I listed glebius@, gallatin@ and jhb@ as possible reviewers, but if anyone else wants to review or comment on these, please feel free to do so. rick

getgrouplist duplication of cr_groups[0] as cr_groups[1]

2020-06-03 Thread Rick Macklem
Hi, During testing of a mountd.c patch I have, I found an "old bug" where the mountd.c code assumed that getgrouplist() would always duplicate cr_groups[0] in cr_groups[1]. If I read the commit logs correctly, this was always the case until r174547 (only 12years ago), which switched

Re: vfs_mouse.c breakage?

2020-06-01 Thread Rick Macklem
now, rick From: Pete Wright Sent: Monday, June 1, 2020 8:05 PM To: Rick Macklem; FreeBSD Current Subject: Re: vfs_mouse.c breakage? CAUTION: This email originated from outside of the University of Guelph. Do not click links or open attachments unless you recognize the sende

Re: vfs_mouse.c breakage?

2020-06-01 Thread Rick Macklem
Pete Wright wrote: >Subject: vfs_mouse.c breakage? Not sure if the vfs mouse is broken (sorry, I couldn't resist), but... I think it needs a: #include but it will take a little while for me to test this. Thanks for reporting it, rick >hello - i am having issues building CURRENT after this was

review of an update to "struct export_args"

2020-05-31 Thread Rick Macklem
Hi, I have put a patch up on phabricator https://reviews.freebsd.org/D25088 I have listed kib@ and freqlabs@ as reviewers, but if anyone else wishes to review it, be my guest. It updates "struct export_args" to make the ex_flags field 64bits and the mapped user (is called ex_anon in the current

Re: r358252 causes intermittent hangs where processes are stuck sleeping on btalloc

2020-05-26 Thread Rick Macklem
Konstantin Belousov wrote: >On Fri, May 22, 2020 at 11:46:26PM +0000, Rick Macklem wrote: >> Konstantin Belousov wrote: >> >On Wed, May 20, 2020 at 11:58:50PM -0700, Ryan Libby wrote: >> >> On Wed, May 20, 2020 at 6:04 PM Rick Macklem wrote: >> >> &g

Re: r358252 causes intermittent hangs where processes are stuck sleeping on btalloc

2020-05-22 Thread Rick Macklem
Konstantin Belousov wrote: >On Wed, May 20, 2020 at 11:58:50PM -0700, Ryan Libby wrote: >> On Wed, May 20, 2020 at 6:04 PM Rick Macklem wrote: >> > >> > Hi, >> > >> > Since I hadn't upgraded a kernel through the winter, it took me a while >> &g

Re: RFC: merging nfs-over-tls changes into head/sys

2020-05-22 Thread Rick Macklem
John Baldwin wrote: >On 5/21/20 2:01 PM, Rick Macklem wrote: >> Hi, >> >> I have now completed changes to the code in projects/nfs-over-tls, which >> implements TLS encryption of NFS RPC messages. (This roughly conforms >> to the internet draft "Towards Remot

RFC: merging nfs-over-tls changes into head/sys

2020-05-21 Thread Rick Macklem
Hi, I have now completed changes to the code in projects/nfs-over-tls, which implements TLS encryption of NFS RPC messages. (This roughly conforms to the internet draft "Towards Remote Procedure Call Encryption By Default", which should soon become an RFC. For now, TLS1.2 is used instead of

r358252 causes intermittent hangs where processes are stuck sleeping on btalloc

2020-05-20 Thread Rick Macklem
Hi, Since I hadn't upgraded a kernel through the winter, it took me a while to bisect this, but r358252 seems to be the culprit. If I do a kernel build over NFS using my not so big Pentium 4 (single core, 1.25Gbytes RAM, i386), about every second attempt will hang. When I do a "ps" in the

Re: TLS certificates for NFS-over-TLS floating client

2020-03-28 Thread Rick Macklem
John-Mark Gurney wrote: >Rick Macklem wrote this message on Thu, Mar 26, 2020 at 14:33 +: >> John-Mark Gurney wrote: >> [lots of stuff snipped] >> >Rick Macklem wrote: >> >> I had originally planned on some "secret" in the certificate (like a CN

Re: TLS certificates for NFS-over-TLS floating client

2020-03-26 Thread Rick Macklem
of Rick Macklem Sent: Thursday, March 26, 2020 10:33 AM To: John-Mark Gurney Cc: Alexander Leidinger; freebsd-current@FreeBSD.org Subject: Re: TLS certificates for NFS-over-TLS floating client John-Mark Gurney wrote: [lots of stuff snipped] >Rick Macklem wrote: >> I had originally planne

Re: TLS certificates for NFS-over-TLS floating client

2020-03-26 Thread Rick Macklem
John-Mark Gurney wrote: [lots of stuff snipped] >Rick Macklem wrote: >> I had originally planned on some "secret" in the certificate (like a CN name >> that satisfies some regular expression or ???) but others convinced me that >> that wouldn't provide anything beyo

Re: TLS certificates for NFS-over-TLS floating client

2020-03-25 Thread Rick Macklem
John-Mark Gurney wrote: >Rick Macklem wrote this message on Mon, Mar 23, 2020 at 23:53 +: >> Alexander Leidinger wrote: >> John-Mark Gurney wrote: >> >>Rick Macklem wrote: >> >>> to be the best solution. The server can verify that the certificat

Re: TLS certificates for NFS-over-TLS floating client

2020-03-23 Thread Rick Macklem
Alexander Leidinger wrote: John-Mark Gurney wrote: >>Rick Macklem wrote: >>> to be the best solution. The server can verify that the certificate  >>> was issued by >>> the local CA. Unfortunately, if the client is compromised and the  >>> certificate is

Re: TLS certificates for NFS-over-TLS floating client

2020-03-20 Thread Rick Macklem
Miroslav Lachman wrote: >Rick Macklem wrote on 2020/03/19 03:09: >> Miroslav Lachman wrote: >>> >> [...] > >>> NFS (or any other server) should check list of revoked certificates too. >>> Otherwise you will not be able to deny access to user which you

Re: TLS certificates for NFS-over-TLS floating client

2020-03-20 Thread Rick Macklem
Jan Bramkamp wrote: >On 20.03.20 02:44, Russell L. Carter wrote: >> Here I commit heresy, by A) top posting, and B) by just saying, why >> not make it easy, first, to tunnel NFSv4 sessions through >> e.g. net/wireguard or sysutils/spiped? NFS is point to point. >> Security infrastructure that

Re: TLS certificates for NFS-over-TLS floating client

2020-03-19 Thread Rick Macklem
John-Mark Gurney wrote: >Rick Macklem wrote this message on Wed, Mar 04, 2020 at 03:15 +: >> I am slowly trying to understand TLS certificates and am trying to figure >> out how to do the following: >> -> For an /etc/exports file with... >> /home -tls -network 1

Re: TLS certificates for NFS-over-TLS floating client

2020-03-18 Thread Rick Macklem
Miroslav Lachman wrote: >Hiroki Sato wrote on 2020/03/04 05:35: > [...] > >> I do not think it is a good idea to use a certificate with an >> embedded secret for authentication and/or authorization. >> >> In the case that the client offers a certificate upon establishing a >> TLS

Re: when does a server need to use SSL_CTX_set_client_CA_list()?

2020-03-16 Thread Rick Macklem
Alexander Leidinger wrote: >Quoting Rick Macklem (from Sun, 15 Mar 2020  >23:27:58 +): > >> As such, it stills seems to be a bit of a mystery to me, but it  >> seems that putting >> all the certificates in a CAfile and not using a CApath directory is  >> th

Re: when does a server need to use SSL_CTX_set_client_CA_list()?

2020-03-15 Thread Rick Macklem
Ronald Klop wrote: >On Sat, 14 Mar 2020 02:28:22 +0100, Rick Macklem >wrote: > >> Hi, >> >> Since it is done in sample code, I have an option in the RPC-over-TLS >> server daemon that does the SSL_CTX_set_client_CA_list() call. >> When I test, I have

Re: when does a server need to use SSL_CTX_set_client_CA_list()?

2020-03-14 Thread Rick Macklem
Garrett Wollman wrote: >Rick Macklem writes: >>Since it is done in sample code, I have an option in the RPC-over-TLS >>server daemon that does the SSL_CTX_set_client_CA_list() call. >>When I test, I have not used this option and the code seems to work. >>Maybe this is

when does a server need to use SSL_CTX_set_client_CA_list()?

2020-03-13 Thread Rick Macklem
Hi, Since it is done in sample code, I have an option in the RPC-over-TLS server daemon that does the SSL_CTX_set_client_CA_list() call. When I test, I have not used this option and the code seems to work. Maybe this is because the client only has a single certificate? Here's the lame

Re: TLS certificates for NFS-over-TLS floating client

2020-03-05 Thread Rick Macklem
Rick Macklem wrote: >Benjamin Kaduk wrote: >>Rick Macklem wrote: [stuff snipped] >>> A typical client mounting from outside of the subnet might be my laptop, >>> which is using wifi and has no fixed IP/DNS name. >>> --> How do you create a certificate

Re: TLS certificates for NFS-over-TLS floating client

2020-03-05 Thread Rick Macklem
Benjamin Kaduk wrote: >On Wed, Mar 04, 2020 at 03:15:48AM +0000, Rick Macklem wrote: >> Hi, >> >> I am slowly trying to understand TLS certificates and am trying to figure >> out how to do the following: >> -> For an /etc/exports file with... >> /home -tl

TLS certificates for NFS-over-TLS floating client

2020-03-03 Thread Rick Macklem
Hi, I am slowly trying to understand TLS certificates and am trying to figure out how to do the following: -> For an /etc/exports file with... /home -tls -network 192.168.1.0 -mask 255.255.255.0 /home -tlscert This syntax isn't implemented yet, but the thinking is that clients on the 192.168.1

Re: how to use the ktls

2020-02-03 Thread Rick Macklem
Benjamin Kaduk wrote: >On Tue, Jan 28, 2020 at 11:01:31PM +0000, Rick Macklem wrote: >> John Baldwin wrote: >> [stuff snipped] >> >I don't know yet. :-/ With the TOE-based TLS I had been testing with, this >> >doesn't >> >happen because the NIC blocks th

Re: easy way to work around a lack of a direct map on i386

2020-01-31 Thread Rick Macklem
-freebsd-curr...@freebsd.org on behalf of Konstantin Belousov Sent: Friday, January 31, 2020 7:31 AM To: Hans Petter Selasky Cc: Rick Macklem; freebsd-current@FreeBSD.org Subject: Re: easy way to work around a lack of a direct map on i386 On Fri, Jan 31, 2020 at 10:13:58AM +0100, Hans Petter Selasky

easy way to work around a lack of a direct map on i386

2020-01-30 Thread Rick Macklem
Hi, The current code for KERN_TLS uses PHYS_TO_DMAP() to access unmapped external pages on m_ext.ext_pgs mbufs. I also need to do this to implement RPC-over-TLS. The problem is that some arches, like i386, don't support PHYS_TO_DMAP(). Since it appears that there will be at most 4 pages on one

Re: how to use the ktls

2020-01-28 Thread Rick Macklem
John Baldwin wrote: [stuff snipped] >I don't know yet. :-/ With the TOE-based TLS I had been testing with, this >doesn't >happen because the NIC blocks the data until it gets the key and then it's >always >available via KTLS. With software-based KTLS for RX (which I'm going to start >working

Re: how to use the ktls

2020-01-27 Thread Rick Macklem
John Baldwin wrote: >On 1/26/20 8:08 PM, Rick Macklem wrote: >> John Baldwin wrote: >> [stuff snipped] >>> Hmmm, this might be a fair bit of work indeed. >>> >>> Right now KTLS only works for transmit (though I have some WIP for receive). >>&g

Re: how to use the ktls

2020-01-26 Thread Rick Macklem
John Baldwin wrote: [stuff snipped] >Hmmm, this might be a fair bit of work indeed. > >Right now KTLS only works for transmit (though I have some WIP for receive). > >KTLS does assumes that the initial handshake and key negotiation is handled by >OpenSSL. OpenSSL uses custom setockopt() calls to

Re: how to use the ktls

2020-01-13 Thread Rick Macklem
John Baldwin wrote: >On 1/12/20 8:23 PM, Benjamin Kaduk wrote: >> On Thu, Jan 09, 2020 at 10:53:38PM +0000, Rick Macklem wrote: >>> John Baldwin wrote: >>>> On 1/7/20 3:02 PM, Rick Macklem wrote: >>>>> Hi, >>>>> >>>

Re: how to use the ktls

2020-01-09 Thread Rick Macklem
John Baldwin wrote: >On 1/7/20 3:02 PM, Rick Macklem wrote: >> Hi, >> >> Now that I've completed NFSv4.2 I'm on to the next project, which is making >> NFS >> work over TLS. >> Of course, I know absolutely nothing about TLS, which will make this an >

how to use the ktls

2020-01-07 Thread Rick Macklem
Hi, Now that I've completed NFSv4.2 I'm on to the next project, which is making NFS work over TLS. Of course, I know absolutely nothing about TLS, which will make this an interesting exercise for me. I did find simple server code in the OpenSSL doc. which at least gives me a starting point for

Re: getting rid of sys/nfs/nfs_lock.c

2019-12-29 Thread Rick Macklem
Dennis Clarke wrote: >On 12/28/19 7:30 PM, Rick Macklem wrote: >> Hi, >> >> sys/nfs/nfs_lock.c uses Giant. Since it has not been used by default since >> March 2008, I suspect it can be removed from head without any impact. >> Post March 2008, the only way this

Re: getting rid of sys/nfs/nfs_lock.c

2019-12-28 Thread Rick Macklem
Oh, I forgot to mention that, post March 2008, this code was replaced by the in kernel nlm found in sys/nlm, which is why it has been in use. From: owner-freebsd-curr...@freebsd.org on behalf of Rick Macklem Sent: Saturday, December 28, 2019 7:30 PM

getting rid of sys/nfs/nfs_lock.c

2019-12-28 Thread Rick Macklem
Hi, sys/nfs/nfs_lock.c uses Giant. Since it has not been used by default since March 2008, I suspect it can be removed from head without any impact. Post March 2008, the only way this code could be executed is by both building a kernel without "options NFSLOCKD" and deleting nfslockd.ko from the

Heads up: Large patch that adds NFSv4.2 has been committed to head/current

2019-12-12 Thread Rick Macklem
Hi, r355677 is a large patch that adds NFSv4.2 support to the NFS client/server. It has survived a "make universe" for all arches that would build (some mips and sparc64 failed for reasons unrelated to this patch). However, I have not been able to do a build with a recent GCC. If there are build

merge of NFSv4.2 support into head/current

2019-11-25 Thread Rick Macklem
Hi, I have completed development and a testing cycle for the NFSv4.2 (RFC-7862) code in base/projects/nfsv42 on subversion. NFSv4.2 is a minor revision to NFSv4.1 and adds support for the following optional features: - lseek(SEEK_DATA/SEEK_HOLE) - posix_fallocate() -

re: Reproducable deadlock in NFS client

2019-10-03 Thread Rick Macklem
Hi Peter, You could try a couple of things: 1 - kib@ just put a patch up on phabricator that reorganizes the handling of vnode_pager_setsize(). D21883 (If you could test this patch, that might be the best approach.) or 2 - The only differences between the post r352392 code and

Re: RFC: should lseek(SEEK_DATA/SEEK_HOLE) return ENOTTY?

2019-08-16 Thread Rick Macklem
Ian Lepore wrote: >On Sun, 2019-08-11 at 09:12 -0600, Alan Somers wrote: >> On Sun, Aug 11, 2019 at 8:57 AM Ian Lepore wrote: >> > >> > On Sun, 2019-08-11 at 09:04 +0200, Gary Jennejohn wrote: >> > > On Sun, 11 Aug 2019 02:03:10 + >>

Re: RFC: should lseek(SEEK_DATA/SEEK_HOLE) return ENOTTY?

2019-08-11 Thread Rick Macklem
Ian Lepore wrote: >On Sun, 2019-08-11 at 09:12 -0600, Alan Somers wrote: >> On Sun, Aug 11, 2019 at 8:57 AM Ian Lepore wrote: >> > >> > On Sun, 2019-08-11 at 09:04 +0200, Gary Jennejohn wrote: >> > > On Sun, 11 Aug 2019 02:03:10 + >>

RFC: should lseek(SEEK_DATA/SEEK_HOLE) return ENOTTY?

2019-08-10 Thread Rick Macklem
Hi, I've noticed that, if you do a lseek(SEEK_DATA/SEEK_HOLE) on a file that resides in a file system that does not support holes, ENOTTY is returned. This error isn't listed for lseek() and seems a liitle weird. I can see a couple of alternatives to this: 1 - Return a different error. Maybe

Re: should a copy_file_range(2) syscall be interrupted via a signal

2019-07-07 Thread Rick Macklem
Konstantin Belousov wrote: >On Fri, Jul 05, 2019 at 08:59:23PM +0000, Rick Macklem wrote: >> Konstantin Belousov wrote: >> >On Fri, Jul 05, 2019 at 07:30:54PM +0200, Jilles Tjoelker wrote: >> >> On Fri, Jul 05, 2019 at 12:28:51AM +, Rick Macklem wrote: >>

Re: test program for copy_file_range(2)

2019-07-05 Thread Rick Macklem
Alan Somers wrote: >On Fri, Jul 5, 2019 at 9:11 AM Rick Macklem wrote: >> >> Alan Somers wrote: >> >On Thu, Jul 4, 2019 at 6:38 PM Rick Macklem wrote: >> >> >> >> I have a little program for testing the copy_file_range(2) syscall I've &

Re: should a copy_file_range(2) syscall be interrupted via a signal

2019-07-05 Thread Rick Macklem
Konstantin Belousov wrote: >On Fri, Jul 05, 2019 at 07:30:54PM +0200, Jilles Tjoelker wrote: >> On Fri, Jul 05, 2019 at 12:28:51AM +0000, Rick Macklem wrote: >> > I have been working on a Linux compatible copy_file_range(2) syscall >> > (the current code can be found at

Re: should a copy_file_range(2) syscall be interrupted via a signal

2019-07-05 Thread Rick Macklem
Hans Petter Selasky wrote: >On 2019-07-05 02:28, Rick Macklem wrote: >> I am thinking that copy_file_range(2) should do this also. >> However, if it returns an error, it is impossible for the caller to know how >> much >> of the data range got copied. > >

Re: should a copy_file_range(2) syscall be interrupted via a signal

2019-07-05 Thread Rick Macklem
Mark Johnston wrote: >On Fri, Jul 05, 2019 at 12:28:51AM +0000, Rick Macklem wrote: >> Hi, >> >> I have been working on a Linux compatible copy_file_range(2) syscall >> (the current code can be found at https://reviews.freebsd.org/D20584). >> >> One

Re: [Differential] D20584: add a linux compatible copy_file_range(2) syscall

2019-07-05 Thread Rick Macklem
jilles wrote in copy_file_range.2:99 > The Linux man page (from > http://man7.org/linux/man->pages/man2/copy_file_range.2.html ) says that a > non-zero flags argument will cause >the call to return an [EINVAL] error. I > think that is better than ignoring the argument >completely since it

Re: test program for copy_file_range(2)

2019-07-05 Thread Rick Macklem
Alan Somers wrote: >On Thu, Jul 4, 2019 at 6:38 PM Rick Macklem wrote: >> >> I have a little program for testing the copy_file_range(2) syscall I've been >> working on. (The current version is attached, in case anyone is interested.) >> >> It take a few minutes

test program for copy_file_range(2)

2019-07-04 Thread Rick Macklem
I have a little program for testing the copy_file_range(2) syscall I've been working on. (The current version is attached, in case anyone is interested.) It take a few minutes to run on a slow system and uses about 6Gbytes of disk space for the file system the output file is on. (It creates 2

should a copy_file_range(2) syscall be interrupted via a signal

2019-07-04 Thread Rick Macklem
Hi, I have been working on a Linux compatible copy_file_range(2) syscall (the current code can be found at https://reviews.freebsd.org/D20584). One outstanding issue is how it should deal with signals. Right now, I have vn_start_write() without PCATCH, so that it won't be interrupted by a

patch to add a Linux compatible copy_file_range(2) syscall

2019-06-09 Thread Rick Macklem
Hi, I just put a patch in phabricator that is intended to add a Linux compatible copy_file_range(2) syscall. My main interest in having this is that NFSv4.2 will know how to do file copying locally on the NFS server, saving all the reads/writes across the wire. It copies the file byte range in

Re: adding a syscall to libc?

2019-06-09 Thread Rick Macklem
Konstantin Belousov wrote: >On Sat, Jun 08, 2019 at 02:57:27AM +0000, Rick Macklem wrote: >> Hi, >> First off, thanks Kostik for the fine explanation. I agree with Oliver that it should be captured somewhere like the wiki. I'm no wiki guy, so hopefully someone else will do this?

adding a syscall to libc?

2019-06-07 Thread Rick Macklem
Hi, I've started working of a copy_file_range() syscall for FreeBSD. I think I have the kernel patched and ready for some testing. However, I'm confused about what I need to do in src/lib/libc/sys? - Some syscalls have little .c files, but other ones do not. When is one of these little .c

Re: RFC w.r.t. toggling debugging on/off for mountd via a signal

2019-05-19 Thread Rick Macklem
Cy Schubert wrote: [lots of stuff snipped] >Instead of syslog() calls, DTrace probes are designed for this type of >instrumentation. DTrace us way too obscure for me. Never used it, probably never will. (Remember I'm the guy who still uses "ed" to edit

Re: RFC w.r.t. toggling debugging on/off for mountd via a signal

2019-05-18 Thread Rick Macklem
Alan Somers wrote: >On Sat, May 18, 2019 at 7:59 PM Rick Macklem wrote: >> >> Hi, >> >> I've been working with Peter Errikson on a patch for mountd that adds a new >> option >> for incremental updating of exports. This seems to be helping a lot w.r

RFC w.r.t. toggling debugging on/off for mountd via a signal

2019-05-18 Thread Rick Macklem
Hi, I've been working with Peter Errikson on a patch for mountd that adds a new option for incremental updating of exports. This seems to be helping a lot w.r.t. performance on an NFS server with lots (1+) of exported file systems. I have debug syslog() calls in the code, which I/Peter

patch that replaces a single linked list with a hash table of lists (mountd.c) for review

2019-05-15 Thread Rick Macklem
Hi, I just put a patch for mountd.c in phabricator as D20270, which replaces the single linked list of structures for exported file systems with a hash table of lists. This is part of what I hope will fix the performance of mountd when reloading the exports file(s) for a server with a lot of

Re: Do the pidhashtbl_locks added by r340742 need to be sx locks?

2019-04-10 Thread Rick Macklem
Mateusz Guzik wrote: >On 4/11/19, Rick Macklem wrote: >> Hi, >> >> I finally got around to looking at what effect replacing pfind_locked() >> with >> pfind() has for the NFSv4 client and it is broken. >> >> The problem is that the NFS code nee

Do the pidhashtbl_locks added by r340742 need to be sx locks?

2019-04-10 Thread Rick Macklem
Hi, I finally got around to looking at what effect replacing pfind_locked() with pfind() has for the NFSv4 client and it is broken. The problem is that the NFS code needs to call some variant of "pfind()" while holding a mutex lock. The current _pfind() code uses the pidhashtbl_locks, which are

Re: what do jails map 127.0.0.1 to?

2019-02-16 Thread Rick Macklem
Rodney W. Grimes wrote: [stuff snipped] > ipv4 127.0.0.1 == ipv6 ::1, see /etc/hosts Thanks. I've created D19218 with the patch for nfsuserd.c to both check the mapping of localhost and adding support for IPv6. I've listed bz@ as a reviewer, but if anyone else would like to review it, feel to do

Re: what do jails map 127.0.0.1 to?

2019-02-12 Thread Rick Macklem
Bjoern A. Zeeb wrote: [good stuff snipped] >Yes, could do easily but wouldn’t work for my above case, would it? I >can help you with the code for v4 and jails if you help me with the code >for IPv6? Well, not quite what you volunteered to do, but can you fill in the INET6 code for this code

  1   2   3   4   5   6   >