Re: massage tcpdump ip and encapsulation output
On Fri, Dec 06, 2019 at 03:14:42PM +1000, David Gwynne wrote: > > > > On 5 Dec 2019, at 21:14, Sebastian Benoit wrote: > > > > Claudio Jeker(cje...@diehard.n-r-g.com) on 2019.12.05 09:53:49 +0100: > >> I would suggest to just pack most of the headers into one group of (). > >> > >> IPv4 ttl 1 [tos 0x20] 10.0.127.15 > 10.0.127.1 > >> would become > >> IPv4 (ttl 1 tos 0x20) 10.0.127.15 > 10.0.127.1 > >> and > >> IPv4 ttl 1 [tos 0x20] (id 39958, len 84) 10.0.127.15 > 10.0.127.1 > >> would become > >> IPv4 (ttl 1 tos 0x20 id 39958 len 84) 10.0.127.15 > 10.0.127.1 > >> > >> Maybe add the commas if that is easy to do. > > > > its more readable with commas, i think > > do you want me to come up with something in this space as part of the large > diff, or is the large change generally ok and we can tinker with this stuff > afterward? > > there's some concern that what i'm proposing is too radical and will break > peoples muscle memory. fyi, here's what stock (or apple tweaked) tcpdump looks like for a similar set of packets: dlg@fatmac Temp$ tcpdump -V tcpdump: option requires an argument -- V tcpdump version tcpdump version 4.9.2 -- Apple version 83.200.2 libpcap version 1.8.1 -- Apple version 79.250.1 LibreSSL 2.2.7 Usage: tcpdump [-aAbdDefhHIJKlLnNOpqStuUvxX#] [ -B size ] [ -c count ] [ -C file_size ] [ -E algo:secret ] [ -F file ] [ -G seconds ] [ -i interface ] [ -j tstamptype ] [ -M secret ] [ --number ] [ -Q in|out|inout ] [ -r file ] [ -s snaplen ] [ --time-stamp-precision precision ] [ --immediate-mode ] [ -T type ] [ --version ] [ -V file ] [ -w file ] [ -W filecount ] [ -y datalinktype ] [ -z postrotate-command ] [ -g ] [ -k ] [ -o ] [ -P ] [ -Q met[ --time-zone-offset offset ] [ -Z user ] [ expression ] dlg@fatmac Temp$ tcpdump -nr ping.pcap reading from file ping.pcap, link-type EN10MB (Ethernet) 16:31:18.836620 IP 10.0.127.15 > 10.0.127.1: ICMP echo request, id 46495, seq 0, length 64 16:31:18.837074 IP 10.0.127.1 > 10.0.127.15: ICMP echo reply, id 46495, seq 0, length 64 dlg@fatmac Temp$ tcpdump -nr ping.pcap -v reading from file ping.pcap, link-type EN10MB (Ethernet) 16:31:18.836620 IP (tos 0x20, ttl 1, id 39958, offset 0, flags [none], proto ICMP (1), length 84) 10.0.127.15 > 10.0.127.1: ICMP echo request, id 46495, seq 0, length 64 16:31:18.837074 IP (tos 0x20, ttl 255, id 36919, offset 0, flags [none], proto ICMP (1), length 84) 10.0.127.1 > 10.0.127.15: ICMP echo reply, id 46495, seq 0, length 64 dlg@fatmac Temp$ tcpdump -nr ipv6-udp-fragmented.pcap reading from file ipv6-udp-fragmented.pcap, link-type EN10MB (Ethernet) 05:35:13.312348 IP6 2607:f010:3f9::11:0.6363 > 2607:f010:3f9::1001.6363: UDP, length 118 05:35:13.549553 IP6 2607:f010:3f9::11:0.6363 > 2607:f010:3f9::1001.6363: UDP, length 31 05:35:13.569339 IP6 2607:f010:3f9::1001 > 2607:f010:3f9::11:0: frag (0|1448) 6363 > 6363: UDP, bad length 5379 > 1440 05:35:13.569345 IP6 2607:f010:3f9::1001 > 2607:f010:3f9::11:0: frag (1448|1448) 05:35:13.569346 IP6 2607:f010:3f9::1001 > 2607:f010:3f9::11:0: frag (2896|1448) 05:35:13.569349 IP6 2607:f010:3f9::1001 > 2607:f010:3f9::11:0: frag (4344|1043) dlg@fatmac Temp$ tcpdump -nr ipv6-udp-fragmented.pcap -v reading from file ipv6-udp-fragmented.pcap, link-type EN10MB (Ethernet) 05:35:13.312348 IP6 (hlim 64, next-header UDP (17) payload length: 126) 2607:f010:3f9::11:0.6363 > 2607:f010:3f9::1001.6363: [udp sum ok] UDP, length 118 05:35:13.549553 IP6 (hlim 64, next-header UDP (17) payload length: 39) 2607:f010:3f9::11:0.6363 > 2607:f010:3f9::1001.6363: [udp sum ok] UDP, length 31 05:35:13.569339 IP6 (flowlabel 0x21289, hlim 64, next-header Fragment (44) payload length: 1456) 2607:f010:3f9::1001 > 2607:f010:3f9::11:0: frag (0xf88eb466:0|1448) 6363 > 6363: UDP, bad length 5379 > 1440 05:35:13.569345 IP6 (flowlabel 0x21289, hlim 64, next-header Fragment (44) payload length: 1456) 2607:f010:3f9::1001 > 2607:f010:3f9::11:0: frag (0xf88eb466:1448|1448) 05:35:13.569346 IP6 (flowlabel 0x21289, hlim 64, next-header Fragment (44) payload length: 1456) 2607:f010:3f9::1001 > 2607:f010:3f9::11:0: frag (0xf88eb466:2896|1448) 05:35:13.569349 IP6 (flowlabel 0x21289, hlim 64, next-header Fragment (44) payload length: 1051) 2607:f010:3f9::1001 > 2607:f010:3f9::11:0: frag (0xf88eb466:4344|1043) dlg@fatmac Temp$ tcpdump -nr udp-frag.pcap reading from file udp-frag.pcap, link-type EN10MB (Ethernet) 20:34:42.184788 IP 10.0.127.15.20550 > 10.0.127.1.6363: UDP, bad length 6000 > 1472 20:34:42.184789 IP 10.0.127.15 > 10.0.127.1: ip-proto-17 20:34:42.184790 IP 10.0.127.15 > 10.0.127.1: ip-proto-17 20:34:42.184791 IP 10.0.127.15 > 10.0.127.1: ip-proto-17 20:34:42.184791 IP 10.0.127.15 > 10.0.127.1: ip-proto-17 dlg@fatmac Temp$ tcpdump -nr udp-frag.pcap -v reading from file udp-frag.pcap, link-type EN10MB (Ethernet) 20:34:42.184788 IP (tos 0x0, ttl 64, id 44745, offset 0, fla
Re: Sync KVE_ET_* with UVM_ET_*
On Thu, Dec 5, 2019 at 9:15 AM Martin Pieuchot wrote: > Sync with reality, will help KERN_PROC_VMMAP consumers. Ok? > ok guenther@
Re: massage tcpdump ip and encapsulation output
> On 5 Dec 2019, at 21:14, Sebastian Benoit wrote: > > Claudio Jeker(cje...@diehard.n-r-g.com) on 2019.12.05 09:53:49 +0100: >> I would suggest to just pack most of the headers into one group of (). >> >> IPv4 ttl 1 [tos 0x20] 10.0.127.15 > 10.0.127.1 >> would become >> IPv4 (ttl 1 tos 0x20) 10.0.127.15 > 10.0.127.1 >> and >> IPv4 ttl 1 [tos 0x20] (id 39958, len 84) 10.0.127.15 > 10.0.127.1 >> would become >> IPv4 (ttl 1 tos 0x20 id 39958 len 84) 10.0.127.15 > 10.0.127.1 >> >> Maybe add the commas if that is easy to do. > > its more readable with commas, i think do you want me to come up with something in this space as part of the large diff, or is the large change generally ok and we can tinker with this stuff afterward? there's some concern that what i'm proposing is too radical and will break peoples muscle memory.
OpenSSH Feature Request
Hello, After reviewing the source code available at the below URL I believe the '-N' flag does not have an ssh_config counterpart. Can this be added? Is it something I can add? https://github.com/openssh/openssh-portable/blob/a70d92f236576c032a45c39e68ca0d71e958d19d/ssh.c Tareq Saif *Computer Systems Engineer* IT User Support Lawrence Berkeley National Laboratory p: m: 510-486-4973 510-859-4748 a: 1 Cyclotron Rd. 46-125F Berkeley, CA 94720 e: tas...@lbl.gov
Re: [PATCH] correcting in-sane ntpd.conf
I guess you don't understand what is going on there. List wrote: > Hello, > > here a diff replacing www.google.com as a default time constraint by > www.openbsd.org. > It is claimed that OpenBSD would have sane and secure defaults. While > www.google.com might be secure it ain't sane from a privacy concerned > perspective. Therefore the diff. > > Regards, > Stephan > > Index: etc/ntpd.conf > === > RCS file: /cvs/src/etc/ntpd.conf,v > retrieving revision 1.16 > diff -u -p -r1.16 ntpd.conf > --- etc/ntpd.conf 6 Nov 2019 19:04:12 - 1.16 > +++ etc/ntpd.conf 5 Dec 2019 21:36:57 - > @@ -8,4 +8,4 @@ sensor * > > constraint from "9.9.9.9" # quad9 v4 without DNS >constraint from "2620:fe::fe" # quad9 v6 without DNS >-constraints from "www.google.com" # intentionally not 8.8.8.8 >+constraints from "www.openbsd.org" # intentionally not Google >
Re: Fix cross references in {MD5,SHA1,RMD160}Init.3
On Thu, Dec 05, 2019 at 10:18:14PM +0100, Martin wrote:
> Hey!
>
> Some cross references in the {MD5,SHA1,RMD160}Init(3) pages are
> misspelled.
>
> Best,
>
> Martin
>
fixed, thanks.
jmc
> Index: MD5Init.3
> ===
> RCS file: /cvs/src/lib/libc/hash/MD5Init.3,v
> retrieving revision 1.1
> diff -u -p -r1.1 MD5Init.3
> --- MD5Init.3 30 Aug 2019 22:20:43 - 1.1
> +++ MD5Init.3 5 Dec 2019 21:04:03 -
> @@ -163,8 +163,8 @@ characters of buffer space.
> .Xr cksum 1 ,
> .Xr md5 1 ,
> .Xr RMD160Init 3 ,
> -.Xr SHA1INIT 3 ,
> -.Xr SHA256INIT 3
> +.Xr SHA1Init 3 ,
> +.Xr SHA256Init 3
> .Rs
> .%A H. Dobbertin
> .%D 1995
> Index: RMD160Init.3
> ===
> RCS file: /cvs/src/lib/libc/hash/RMD160Init.3,v
> retrieving revision 1.1
> diff -u -p -r1.1 RMD160Init.3
> --- RMD160Init.3 30 Aug 2019 22:20:43 - 1.1
> +++ RMD160Init.3 5 Dec 2019 21:04:03 -
> @@ -200,8 +200,8 @@ printf("0x%s\en", RMD160Data(buf, strlen
> .Sh SEE ALSO
> .Xr cksum 1 ,
> .Xr MD5Init 3 ,
> -.Xr SHA1INIT 3 ,
> -.Xr SHA256INIT 3
> +.Xr SHA1Init 3 ,
> +.Xr SHA256Init 3
> .Rs
> .%A H. Dobbertin, A. Bosselaers, B. Preneel
> .%T RIPEMD-160, a strengthened version of RIPEMD
> Index: SHA1Init.3
> ===
> RCS file: /cvs/src/lib/libc/hash/SHA1Init.3,v
> retrieving revision 1.1
> diff -u -p -r1.1 SHA1Init.3
> --- SHA1Init.330 Aug 2019 22:20:43 - 1.1
> +++ SHA1Init.35 Dec 2019 21:04:03 -
> @@ -207,7 +207,7 @@ printf("0x%s\en", SHA1Data(buf, strlen(b
> .Xr sha1 1 ,
> .Xr MD5Init 3 ,
> .Xr RMD160Init 3 ,
> -.Xr SHA256INIT 3
> +.Xr SHA256Init 3
> .Sh STANDARDS
> .Rs
> .%A J. Burrows
>
[PATCH] correcting in-sane ntpd.conf
Hello, here a diff replacing www.google.com as a default time constraint by www.openbsd.org. It is claimed that OpenBSD would have sane and secure defaults. While www.google.com might be secure it ain't sane from a privacy concerned perspective. Therefore the diff. Regards, Stephan Index: etc/ntpd.conf === RCS file: /cvs/src/etc/ntpd.conf,v retrieving revision 1.16 diff -u -p -r1.16 ntpd.conf --- etc/ntpd.conf 6 Nov 2019 19:04:12 - 1.16 +++ etc/ntpd.conf 5 Dec 2019 21:36:57 - @@ -8,4 +8,4 @@ sensor * constraint from "9.9.9.9" # quad9 v4 without DNS constraint from "2620:fe::fe" # quad9 v6 without DNS -constraints from "www.google.com" # intentionally not 8.8.8.8 +constraints from "www.openbsd.org" # intentionally not Google
Fix cross references in {MD5,SHA1,RMD160}Init.3
Hey!
Some cross references in the {MD5,SHA1,RMD160}Init(3) pages are
misspelled.
Best,
Martin
Index: MD5Init.3
===
RCS file: /cvs/src/lib/libc/hash/MD5Init.3,v
retrieving revision 1.1
diff -u -p -r1.1 MD5Init.3
--- MD5Init.3 30 Aug 2019 22:20:43 - 1.1
+++ MD5Init.3 5 Dec 2019 21:04:03 -
@@ -163,8 +163,8 @@ characters of buffer space.
.Xr cksum 1 ,
.Xr md5 1 ,
.Xr RMD160Init 3 ,
-.Xr SHA1INIT 3 ,
-.Xr SHA256INIT 3
+.Xr SHA1Init 3 ,
+.Xr SHA256Init 3
.Rs
.%A H. Dobbertin
.%D 1995
Index: RMD160Init.3
===
RCS file: /cvs/src/lib/libc/hash/RMD160Init.3,v
retrieving revision 1.1
diff -u -p -r1.1 RMD160Init.3
--- RMD160Init.330 Aug 2019 22:20:43 - 1.1
+++ RMD160Init.35 Dec 2019 21:04:03 -
@@ -200,8 +200,8 @@ printf("0x%s\en", RMD160Data(buf, strlen
.Sh SEE ALSO
.Xr cksum 1 ,
.Xr MD5Init 3 ,
-.Xr SHA1INIT 3 ,
-.Xr SHA256INIT 3
+.Xr SHA1Init 3 ,
+.Xr SHA256Init 3
.Rs
.%A H. Dobbertin, A. Bosselaers, B. Preneel
.%T RIPEMD-160, a strengthened version of RIPEMD
Index: SHA1Init.3
===
RCS file: /cvs/src/lib/libc/hash/SHA1Init.3,v
retrieving revision 1.1
diff -u -p -r1.1 SHA1Init.3
--- SHA1Init.3 30 Aug 2019 22:20:43 - 1.1
+++ SHA1Init.3 5 Dec 2019 21:04:03 -
@@ -207,7 +207,7 @@ printf("0x%s\en", SHA1Data(buf, strlen(b
.Xr sha1 1 ,
.Xr MD5Init 3 ,
.Xr RMD160Init 3 ,
-.Xr SHA256INIT 3
+.Xr SHA256Init 3
.Sh STANDARDS
.Rs
.%A J. Burrows
vm.conf: owner: do not default to root
vm.conf(5) states it must be `owner user[:group]' or `owner group', not
specifying a value is undocumented and ought to be invalid syntax, yet
`owner' is treated as `owner root' which is the same as simply omitting
the owner line.
Diff below causes the following behaviour change:
$ cat socket-owner.conf
socket owner
$ vmd -nf socket-owner.conf
configuration OK
$ ./obj/vmd -nf socket-owner.conf
socket-owner.conf:1: syntax error
$ cat vm-owner.conf
vm v {
disk /dev/null
owner
}
$ vmd -nf vm-owner.conf
configuration OK
$ ./obj/vmd -nf vm-owner.conf
vm-owner.conf:3: syntax error
Feedback? OK?
Index: parse.y
===
RCS file: /cvs/src/usr.sbin/vmd/parse.y,v
retrieving revision 1.52
diff -u -p -r1.52 parse.y
--- parse.y 14 May 2019 06:05:45 - 1.52
+++ parse.y 5 Dec 2019 19:30:10 -
@@ -545,11 +545,7 @@ instance_flags : BOOT { vmc.vmc_insflag
}
;
-owner_id : /* none */{
- $$.uid = 0;
- $$.gid = -1;
- }
- | NUMBER{
+owner_id : NUMBER{
$$.uid = $1;
$$.gid = -1;
}
uvm/uvm_map.h cleanup
Following cleanup diff:
- reduces gratuitous differences with NetBSD,
- merges multiple '#ifdef _KERNEL' blocks,
- kills unused 'struct vm_map_intrsafe'
- turns 'union vm_map_object' into a anonymous union (following to NetBSD)
- move questionable vm_map_modflags() into uvm/uvm_map.c
- remove guards around MAX_KMAPENT, it is defined&used only once
- document lock differences
- fix tab vs space
Ok?
Index: uvm/uvm_extern.h
===
RCS file: /cvs/src/sys/uvm/uvm_extern.h,v
retrieving revision 1.151
diff -u -p -r1.151 uvm_extern.h
--- uvm/uvm_extern.h29 Nov 2019 06:34:45 - 1.151
+++ uvm/uvm_extern.h5 Dec 2019 16:06:33 -
@@ -65,9 +65,6 @@ typedef int vm_fault_t;
typedef int vm_inherit_t; /* XXX: inheritance codes */
typedef off_t voff_t; /* XXX: offset within a uvm_object */
-union vm_map_object;
-typedef union vm_map_object vm_map_object_t;
-
struct vm_map_entry;
typedef struct vm_map_entry *vm_map_entry_t;
Index: uvm/uvm_map.c
===
RCS file: /cvs/src/sys/uvm/uvm_map.c,v
retrieving revision 1.256
diff -u -p -r1.256 uvm_map.c
--- uvm/uvm_map.c 4 Dec 2019 08:28:29 - 1.256
+++ uvm/uvm_map.c 5 Dec 2019 16:27:22 -
@@ -230,7 +230,6 @@ void vmspace_validate(struct
vm_map*)
#define PMAP_PREFER(addr, off) (addr)
#endif
-
/*
* The kernel map will initially be VM_MAP_KSIZE_INIT bytes.
* Every time that gets cramped, we grow by at least VM_MAP_KSIZE_DELTA bytes.
@@ -334,6 +333,14 @@ vaddr_t uvm_maxkaddr;
MUTEX_ASSERT_LOCKED(&(_map)->mtx); \
} \
} while (0)
+
+#definevm_map_modflags(map, set, clear)
\
+ do {\
+ mtx_enter(&(map)->flags_lock); \
+ (map)->flags = ((map)->flags | (set)) & ~(clear); \
+ mtx_leave(&(map)->flags_lock); \
+ } while (0)
+
/*
* Tree describing entries by address.
Index: uvm/uvm_map.h
===
RCS file: /cvs/src/sys/uvm/uvm_map.h,v
retrieving revision 1.65
diff -u -p -r1.65 uvm_map.h
--- uvm/uvm_map.h 29 Nov 2019 06:34:46 - 1.65
+++ uvm/uvm_map.h 5 Dec 2019 16:26:09 -
@@ -86,16 +86,6 @@
#ifdef _KERNEL
/*
- * Internal functions.
- *
- * Required by clipping macros.
- */
-voiduvm_map_clip_end(struct vm_map*, struct vm_map_entry*,
- vaddr_t);
-voiduvm_map_clip_start(struct vm_map*,
- struct vm_map_entry*, vaddr_t);
-
-/*
* UVM_MAP_CLIP_START: ensure that the entry begins at or after
* the starting address, if it doesn't we split the entry.
*
@@ -133,26 +123,6 @@ voiduvm_map_clip_start(struct
vm_map
#include
/*
- * types defined:
- *
- * vm_map_tthe high-level address map data structure.
- * vm_map_entry_t an entry in an address map.
- * vm_map_version_ta timestamp of a map, for use with vm_map_lookup
- */
-
-/*
- * Objects which live in maps may be either VM objects, or another map
- * (called a "sharing map") which denotes read-write sharing with other maps.
- *
- * XXXCDC: private pager data goes here now
- */
-
-union vm_map_object {
- struct uvm_object *uvm_obj; /* UVM OBJECT */
- struct vm_map *sub_map; /* belongs to another map */
-};
-
-/*
* Address map entries consist of start and end addresses,
* a VM object (or sharing map) and offset into that object,
* and user-exported inheritance and protection information.
@@ -177,23 +147,23 @@ struct vm_map_entry {
vsize_t guard; /* bytes in guard */
vsize_t fspace; /* free space */
- union vm_map_object object; /* object I point to */
+ union {
+ struct uvm_object *uvm_obj; /* uvm object */
+ struct vm_map *sub_map; /* belongs to another map */
+ } object; /* object I point to */
voff_t offset; /* offset into object */
struct vm_aref aref; /* anonymous overlay */
-
int etype; /* entry type */
-
vm_prot_t protection; /* protection code */
vm_prot_t max_protection; /* maximum protection */
vm_inherit_tinheritance;/* inheritance */
-
int wired_count;/* can be paged if == 0 */
int advice; /* madvise advice */
Sync KVE_ET_* with UVM_ET_*
Sync with reality, will help KERN_PROC_VMMAP consumers. Ok?
Index: sys/sysctl.h
===
RCS file: /cvs/src/sys/sys/sysctl.h,v
retrieving revision 1.196
diff -u -p -r1.196 sysctl.h
--- sys/sysctl.h22 Oct 2019 21:19:22 - 1.196
+++ sys/sysctl.h5 Dec 2019 17:11:07 -
@@ -497,24 +497,33 @@ struct kinfo_vmentry {
u_int8_t kve_flags; /* u_int8_t */
};
+/* keep in sync with UVM_ET_* */
#define KVE_ET_OBJ 0x0001
#define KVE_ET_SUBMAP 0x0002
#define KVE_ET_COPYONWRITE 0x0004
#define KVE_ET_NEEDSCOPY 0x0008
#define KVE_ET_HOLE0x0010
#define KVE_ET_NOFAULT 0x0020
-#define KVE_ET_FREEMAPPED 0x0080
+#define KVE_ET_STACK 0x0040
+#define KVE_ET_WC 0x0080
+#define KVE_ET_CONCEAL 0x0100
+#define KVE_ET_SYSCALL 0x0200
+#define KVE_ET_FREEMAPPED 0x0800
+
#define KVE_PROT_NONE 0x
#define KVE_PROT_READ 0x0001
#define KVE_PROT_WRITE 0x0002
#define KVE_PROT_EXEC 0x0004
+
#define KVE_ADV_NORMAL 0x
#define KVE_ADV_RANDOM 0x0001
#define KVE_ADV_SEQUENTIAL 0x0002
+
#define KVE_INH_SHARE 0x
#define KVE_INH_COPY 0x0010
#define KVE_INH_NONE 0x0020
#define KVE_INH_ZERO 0x0030
+
#define KVE_F_STATIC 0x01
#define KVE_F_KMEM 0x02
Index: uvm/uvm.h
===
RCS file: /cvs/src/sys/uvm/uvm.h,v
retrieving revision 1.66
diff -u -p -r1.66 uvm.h
--- uvm/uvm.h 29 Nov 2019 06:34:45 - 1.66
+++ uvm/uvm.h 5 Dec 2019 17:10:57 -
@@ -80,8 +80,9 @@ struct uvm {
/*
* vm_map_entry etype bits:
+ *
+ * keep in sync with KVM_ET_*
*/
-
#define UVM_ET_OBJ 0x0001 /* it is a uvm_object */
#define UVM_ET_SUBMAP 0x0002 /* it is a vm_map submap */
#define UVM_ET_COPYONWRITE 0x0004 /* copy_on_write */
iked(8): fix erroneous responder certreqs with multiple policies
We send certificate request (CERTREQ) payloads to notify the peer which CAs or
public key schemes we accept in the authentication.
Our current behaviour is incorrect when multiple policies between the same two
hosts use different kinds of raw public key authentication.
At this point of the exchange the responder can only guess which policy the
message belongs to, because the ID used to match a policy is not yet known,
and temporarily assumes the last matching policy.
It then sends the certificate request payload for this policy,
which may not necessarily be one that is valid for the actual policy of the
exchange and leads to an error in the peer who doesn't support the requested
method.
The diff fixes the problem by sending CERTREQs for all matching policies
instead.
ok?
Index: ikev2.c
===
RCS file: /mount/openbsd/cvs/src/sbin/iked/ikev2.c,v
retrieving revision 1.183
diff -u -p -r1.183 ikev2.c
--- ikev2.c 3 Dec 2019 12:38:34 - 1.183
+++ ikev2.c 5 Dec 2019 14:45:38 -
@@ -122,6 +122,8 @@ int ikev2_valid_proposal(struct iked_pr
int ikev2_handle_notifies(struct iked *, struct iked_message *);
+ssize_t ikev2_resp_add_certreqs(struct iked *, struct iked_message *,
+struct ibuf *, struct ikev2_payload **, ssize_t );
ssize_t ikev2_add_proposals(struct iked *, struct iked_sa *, struct
ibuf *,
struct iked_proposals *, uint8_t, int, int, int);
ssize_t ikev2_add_cp(struct iked *, struct iked_sa *, struct ibuf *);
@@ -2636,14 +2638,13 @@ ikev2_resp_ike_sa_init(struct iked *env,
goto done;
}
if (sa->sa_statevalid & IKED_REQ_CERT) {
- /* CERTREQ payload(s) */
- if ((len = ikev2_add_certreq(buf, &pld,
- len, env->sc_certreq, env->sc_certreqtype)) == -1)
- goto done;
-
- if (env->sc_certreqtype != sa->sa_policy->pol_certreqtype &&
- (len = ikev2_add_certreq(buf, &pld,
- len, NULL, sa->sa_policy->pol_certreqtype)) == -1)
+ /*
+* At this stage it is unclear which policy this SA belongs
+* to because the ID payload is sent in IKE_AUTH.
+* Add CERTREQ payloads for all matching policies.
+*/
+ if ((len = ikev2_resp_add_certreqs(env, msg, buf, &pld,
+ len)) == -1)
goto done;
}
@@ -2671,6 +2672,85 @@ ikev2_resp_ike_sa_init(struct iked *env,
ikev2_msg_cleanup(env, &resp);
return (ret);
+}
+
+ssize_t
+ikev2_resp_add_certreqs(struct iked *env, struct iked_message *msg,
+struct ibuf *buf, struct ikev2_payload **pld, ssize_t len)
+{
+ struct iked_policy key, *p;
+ int ecdsa_sent = 0;
+ int rsa_sent = 0;
+
+ /* Request at least own certreqtype */
+ switch (env->sc_certreqtype) {
+ case IKEV2_CERT_ECDSA:
+ ecdsa_sent = 1;
+ break;
+ case IKEV2_CERT_RSA_KEY:
+ rsa_sent = 1;
+ break;
+ default:
+ break;
+ }
+ if ((len = ikev2_add_certreq(buf, pld,
+ len, env->sc_certreq, env->sc_certreqtype)) == -1)
+ return (-1);
+
+ /* Add CERTREQS for all matching policies */
+ bzero(&key, sizeof(key));
+ key.pol_af = msg->msg_peer.ss_family;
+ memcpy(&key.pol_peer.addr, &msg->msg_peer, sizeof(msg->msg_peer));
+ memcpy(&key.pol_local.addr, &msg->msg_local, sizeof(msg->msg_local));
+
+ p = TAILQ_FIRST(&env->sc_policies);
+ while (p != NULL) {
+ if (p->pol_flags & IKED_POLICY_SKIP)
+ p = p->pol_skip[IKED_SKIP_FLAGS];
+ else if (key.pol_af && p->pol_af &&
+ key.pol_af != p->pol_af)
+ p = p->pol_skip[IKED_SKIP_AF];
+ else if (key.pol_ipproto && p->pol_ipproto &&
+ key.pol_ipproto != p->pol_ipproto)
+ p = p->pol_skip[IKED_SKIP_PROTO];
+ else if (sockaddr_cmp((struct sockaddr *)&key.pol_peer.addr,
+ (struct sockaddr *)&p->pol_peer.addr,
+ p->pol_peer.addr_mask) != 0)
+ p = p->pol_skip[IKED_SKIP_DST_ADDR];
+ else if (sockaddr_cmp((struct sockaddr *)&key.pol_local.addr,
+ (struct sockaddr *)&p->pol_local.addr,
+ p->pol_local.addr_mask) != 0)
+ p = p->pol_skip[IKED_SKIP_SRC_ADDR];
+ else {
+ /* Policy matches */
+ switch (p->pol_certreqtype) {
+ case IKEV2_CERT_ECDSA:
+ if (ecdsa_sent == 1) {
+ p = TAILQ_NEXT(p, pol_entry);
+
Re: .Aq in smtpd.conf(5)
On Thu, Dec 05, 2019 at 04:34:50PM +0100, Ingo Schwarze wrote: > Hi Jason, > > Jason McIntyre wrote on Thu, Dec 05, 2019 at 02:54:20PM +: > > > i have reverted it, with a heavy heart. > > Do you think i should try and convince the groff folks to always > render .Aq/.Ao/.Ac as ASCII '<' and '>', even in UTF-8, HTML, PDF > output and the like? > > Benefits: > > + easier rules for authors, smaller risk of mistakes, >and ".Aq Mt" would no longer be an exception > + allows nicer and simpler mdoc(7) source code >for configuration file documentation like smtpd.conf and pf.conf >and nicer markup in pages documenting HTML code > + in programming documentation (as opposed to, say, quantum physics >calculations) angle brackets are exceedingly rare, >making .Aq mostly useless under the current rules > > Downside: > > - In cases where authors really want angle brackets - e.g., does >a free software package to help with quantum mechanics calculations >exist? - the output will look slightly worse, but not much worse, >and given the rarity, i think that would be acceptable. Besides, >people who want real angle brackets in some unusual situation >can still use .Eo \(la foobar Ec \(ra . > > Yours, > Ingo > hi. it'd be great if we changed this from my point of view. but then i don;t grasp all the aspects of the situation, and it's you doing the work, so it's entirely up to yourself. jmc
Re: .Aq in smtpd.conf(5)
December 5, 2019 4:34 PM, "Ingo Schwarze" wrote: > Hi Jason, > > Jason McIntyre wrote on Thu, Dec 05, 2019 at 02:54:20PM +: > >> i have reverted it, with a heavy heart. > > Do you think i should try and convince the groff folks to always > render .Aq/.Ao/.Ac as ASCII '<' and '>', even in UTF-8, HTML, PDF > output and the like? > > Benefits: > > + easier rules for authors, smaller risk of mistakes, > and ".Aq Mt" would no longer be an exception > + allows nicer and simpler mdoc(7) source code > for configuration file documentation like smtpd.conf and pf.conf > and nicer markup in pages documenting HTML code > + in programming documentation (as opposed to, say, quantum physics > calculations) angle brackets are exceedingly rare, > making .Aq mostly useless under the current rules > > Downside: > > - In cases where authors really want angle brackets - e.g., does > a free software package to help with quantum mechanics calculations > exist? - the output will look slightly worse, but not much worse, > and given the rarity, i think that would be acceptable. Besides, > people who want real angle brackets in some unusual situation > can still use .Eo \(la foobar Ec \(ra . > To me this already looks like quantum mechanics calculations :-p
Re: .Aq in smtpd.conf(5)
Hi Jason, Jason McIntyre wrote on Thu, Dec 05, 2019 at 02:54:20PM +: > i have reverted it, with a heavy heart. Do you think i should try and convince the groff folks to always render .Aq/.Ao/.Ac as ASCII '<' and '>', even in UTF-8, HTML, PDF output and the like? Benefits: + easier rules for authors, smaller risk of mistakes, and ".Aq Mt" would no longer be an exception + allows nicer and simpler mdoc(7) source code for configuration file documentation like smtpd.conf and pf.conf and nicer markup in pages documenting HTML code + in programming documentation (as opposed to, say, quantum physics calculations) angle brackets are exceedingly rare, making .Aq mostly useless under the current rules Downside: - In cases where authors really want angle brackets - e.g., does a free software package to help with quantum mechanics calculations exist? - the output will look slightly worse, but not much worse, and given the rarity, i think that would be acceptable. Besides, people who want real angle brackets in some unusual situation can still use .Eo \(la foobar Ec \(ra . Yours, Ingo
Re: un-boolean_t i386's pmap
On Thu, Dec 05, 2019 at 04:12:01PM +0100, Martin Pieuchot wrote: > On 05/12/19(Thu) 11:57, Otto Moerbeek wrote: > > On Thu, Dec 05, 2019 at 12:38:34PM +0100, Martin Pieuchot wrote: > > > > > ok? > > > > I'm no kernel hacker but I really do not see the point. > > Most of the kernel doesn't use any type for boolean. The exception is > UVM which uses its own boolean_t. This type is inconsistently used in > some pmap(9) functions as well. > > I'm well aware of the arguments in favor of a boolean type as well as > the arguments against. I'm not taking any position, I'm striving for > coherency. > > On top of that, reducing the dependencies between the UVM and pmap > layers help to draw a line. That's what I'm after. > I grepped the kernel tree and see that uvm and the various pmap subdirs are indeed the odd ones out. So go ahead, I'll go back to userland grumbling about the many examples of wrong boolean usage in mg ;-) -Otto
Re: un-boolean_t i386's pmap
On 05/12/19(Thu) 11:57, Otto Moerbeek wrote: > On Thu, Dec 05, 2019 at 12:38:34PM +0100, Martin Pieuchot wrote: > > > ok? > > I'm no kernel hacker but I really do not see the point. Most of the kernel doesn't use any type for boolean. The exception is UVM which uses its own boolean_t. This type is inconsistently used in some pmap(9) functions as well. I'm well aware of the arguments in favor of a boolean type as well as the arguments against. I'm not taking any position, I'm striving for coherency. On top of that, reducing the dependencies between the UVM and pmap layers help to draw a line. That's what I'm after.
Re: .Aq in smtpd.conf(5)
On Thu, Dec 05, 2019 at 03:15:31PM +0100, Ingo Schwarze wrote: > Hi Jason, > > Jason McIntyre wrote on Thu, Dec 05, 2019 at 06:54:28AM -0700: > > > CVSROOT:/cvs > > Module name:src > > Changes by: j...@cvs.openbsd.org2019/12/05 06:54:28 > > > > Modified files: > > usr.sbin/smtpd : smtpd.conf.5 > > > > Log message: > > replace "Pf < ... Ns >" with Aq; tidy up lists a little; > > Please revert the .Aq part. > > The mdoc(7) manual page explains why: > > Aq line > Enclose the rest of the input line in angle brackets. The only > important use case is for email addresses. See Mt for an example. > > Occasionally, it is used for names of characters and keys, for > example: > > Press the > .Aq escape > key to ... > > For URIs, use Lk instead, and In for "#include" directives. Never > wrap Ar in Aq. > > Since Aq usually renders with non-ASCII characters in non-ASCII > output modes, do not use it where the ASCII characters '<' and '>' > are required as syntax elements. Instead, use these characters > directly in such cases, combining them with the macros Pf, Ns, or Eo > as needed. > > Yours, > Ingo i have reverted it, with a heavy heart. jmc
Re: Split uvm(9)
Hi Martin, Martin Pieuchot wrote on Thu, Dec 05, 2019 at 01:55:00PM +0100: > Diff below split uvm(9) into the following: > > - uvm_init(9) > - uvm_fault(9) > - uvm_km_alloc(9) > - uvm_map(9) > - uvm_pagealloc(9) > - uvn_attach(9) Yes please! In particular, i like how this reduces usage of .nr nS, which is an ugly, OpenBSD-specific hack and a layering violation that isn't very portable. > That will allow us to work on smaller pages and improve the overall > documentation of UVM. Good news. :-) > This split doesn't include changes. Feel free to restore alphabetical ordering to the Makefile while there: uiomove, usb, uvm, uvn, ... > Ok? OK schwarze@ Ingo > Index: Makefile > === > RCS file: /cvs/src/share/man/man9/Makefile,v > retrieving revision 1.297 > diff -u -p -r1.297 Makefile > --- Makefile 8 Nov 2019 07:36:52 - 1.297 > +++ Makefile 5 Dec 2019 12:48:33 - > @@ -39,7 +39,10 @@ MAN= aml_evalnode.9 atomic_add_int.9 ato > socreate.9 sosplice.9 strcmp.9 style.9 syscall.9 sysctl_int.9 \ > task_add.9 tc_init.9 tfind.9 thread_fork.9 \ > time_second.9 timeout.9 tsleep.9 tvtohz.9 \ > - uiomove.9 uvm.9 usb_add_task.9 usbd_close_pipe.9 usbd_open_pipe.9 \ > + uiomove.9 \ > + uvm_fault.9 uvm_init.9 uvm_km_alloc.9 uvm_map.9 uvm_pagealloc.9 \ > + uvn_attach.9 \ > + usb_add_task.9 usbd_close_pipe.9 usbd_open_pipe.9 \ > usbd_ref_wait.9 usbd_transfer.9 vfs.9 vfs_busy.9 \ > vfs_cache.9 vaccess.9 vclean.9 vcount.9 vdevgone.9 vfinddev.9 vflush.9 \ > vflushbuf.9 vget.9 vgone.9 vhold.9 vinvalbuf.9 vnode.9 vnsubr.9 \ [...]
Re: .Aq in smtpd.conf(5)
Hi Jason, Jason McIntyre wrote on Thu, Dec 05, 2019 at 06:54:28AM -0700: > CVSROOT: /cvs > Module name: src > Changes by: j...@cvs.openbsd.org2019/12/05 06:54:28 > > Modified files: > usr.sbin/smtpd : smtpd.conf.5 > > Log message: > replace "Pf < ... Ns >" with Aq; tidy up lists a little; Please revert the .Aq part. The mdoc(7) manual page explains why: Aq line Enclose the rest of the input line in angle brackets. The only important use case is for email addresses. See Mt for an example. Occasionally, it is used for names of characters and keys, for example: Press the .Aq escape key to ... For URIs, use Lk instead, and In for "#include" directives. Never wrap Ar in Aq. Since Aq usually renders with non-ASCII characters in non-ASCII output modes, do not use it where the ASCII characters '<' and '>' are required as syntax elements. Instead, use these characters directly in such cases, combining them with the macros Pf, Ns, or Eo as needed. Yours, Ingo
login_passwd: reject challenge service
Hi,
I read https://www.openwall.com/lists/oss-security/2019/12/04/5 and wondered
how the authentication bypass was possible, since the manpage says:
If this style of authentication does not support challenge response, but
does support the response service (described below) it should issue
reject silent and then exit with a 0 status.
So I checked and indeed:
# /usr/libexec/auth/login_passwd -schallenge foo 3>&1
authorize
The (untested) patch below makes login_passwd behave as described in the
manpage.
Kind regards,
Thomas
diff --git libexec/login_passwd/login.c libexec/login_passwd/login.c
index 09e683a7366..486d8bfcb8a 100644
--- libexec/login_passwd/login.c
+++ libexec/login_passwd/login.c
@@ -137,7 +137,7 @@ main(int argc, char **argv)
password = readpassphrase("Password:", pbuf, sizeof(pbuf),
RPP_ECHO_OFF);
break;
case MODE_CHALLENGE:
- fprintf(back, BI_AUTH "\n");
+ fprintf(back, BI_SILENT "\n");
exit(0);
break;
default:
Re: Split uvm(9)
On Thu, Dec 05, 2019 at 06:06:55AM -0700, Theo de Raadt wrote: > Jason McIntyre wrote: > > > > + uvn_attach.9 \ > > > > uv*m*_attach > > nope, it is correct. uvm object to vnode attach. > oops, sorry!
Re: Split uvm(9)
Jason McIntyre wrote: > > + uvn_attach.9 \ > > uv*m*_attach nope, it is correct. uvm object to vnode attach.
Re: Split uvm(9)
On Thu, Dec 05, 2019 at 01:55:00PM +0100, Martin Pieuchot wrote: > Diff below split uvm(9) into the following: > > - uvm_init(9) > - uvm_fault(9) > - uvm_km_alloc(9) > - uvm_map(9) > - uvm_pagealloc(9) > - uvn_attach(9) > > That will allow us to work on smaller pages and improve the overall > documentation of UVM. > > This split doesn't include changes. > > Ok? > makes sense to me. one comment though: > Index: Makefile > === > RCS file: /cvs/src/share/man/man9/Makefile,v > retrieving revision 1.297 > diff -u -p -r1.297 Makefile > --- Makefile 8 Nov 2019 07:36:52 - 1.297 > +++ Makefile 5 Dec 2019 12:48:33 - > @@ -39,7 +39,10 @@ MAN= aml_evalnode.9 atomic_add_int.9 ato > socreate.9 sosplice.9 strcmp.9 style.9 syscall.9 sysctl_int.9 \ > task_add.9 tc_init.9 tfind.9 thread_fork.9 \ > time_second.9 timeout.9 tsleep.9 tvtohz.9 \ > - uiomove.9 uvm.9 usb_add_task.9 usbd_close_pipe.9 usbd_open_pipe.9 \ > + uiomove.9 \ > + uvm_fault.9 uvm_init.9 uvm_km_alloc.9 uvm_map.9 uvm_pagealloc.9 \ > + uvn_attach.9 \ uv*m*_attach jmc > + usb_add_task.9 usbd_close_pipe.9 usbd_open_pipe.9 \ > usbd_ref_wait.9 usbd_transfer.9 vfs.9 vfs_busy.9 \ > vfs_cache.9 vaccess.9 vclean.9 vcount.9 vdevgone.9 vfinddev.9 vflush.9 \ > vflushbuf.9 vget.9 vgone.9 vhold.9 vinvalbuf.9 vnode.9 vnsubr.9 \ > Index: uvm.9 > === > RCS file: uvm.9 > diff -N uvm.9 > --- uvm.9 5 Nov 2019 08:18:47 - 1.71 > +++ /dev/null 1 Jan 1970 00:00:00 - > @@ -1,1085 +0,0 @@ > -.\" $OpenBSD: uvm.9,v 1.71 2019/11/05 08:18:47 mpi Exp $ > -.\" $NetBSD: uvm.9,v 1.14 2000/06/29 06:08:44 mrg Exp $ > -.\" > -.\" Copyright (c) 1998 Matthew R. Green > -.\" All rights reserved. > -.\" > -.\" 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. > -.\" 3. The name of the author may not be used to endorse or promote products > -.\"derived from this software without specific prior written permission. > -.\" > -.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``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 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. > -.\" > -.\" XXX this manual sets nS to 1 or 0 in the description, to obtain > -.\" synopsis-like function prototypes. any better way? > -.\" > -.Dd $Mdocdate: November 5 2019 $ > -.Dt UVM_INIT 9 > -.Os > -.Sh NAME > -.Nm uvm_init , > -.Nm uvm_init_limits , > -.Nm uvm_setpagesize , > -.Nm uvm_swap_init , > -.Nm uvm_map , > -.Nm uvm_map_pageable , > -.Nm uvm_map_pageable_all , > -.Nm uvm_map_checkprot , > -.Nm uvm_map_protect , > -.Nm uvmspace_alloc , > -.Nm uvmspace_exec , > -.Nm uvmspace_fork , > -.Nm uvmspace_free , > -.Nm uvmspace_share , > -.Nm uvm_uarea_alloc , > -.Nm uvm_uarea_free , > -.Nm UVM_MAPFLAG , > -.Nm uvm_fault , > -.Nm uvn_attach , > -.Nm uvm_vnp_setsize , > -.Nm uvm_vnp_sync , > -.Nm uvm_vnp_terminate , > -.Nm uvm_vnp_uncache , > -.Nm uvm_io , > -.Nm uvm_km_alloc , > -.Nm uvm_km_zalloc , > -.Nm uvm_km_alloc1 , > -.Nm uvm_km_kmemalloc , > -.Nm uvm_km_valloc , > -.Nm uvm_km_valloc_wait , > -.Nm uvm_km_suballoc , > -.Nm uvm_km_free , > -.Nm uvm_km_free_wakeup , > -.Nm uvm_pagealloc , > -.Nm uvm_pagerealloc , > -.Nm uvm_pagefree , > -.Nm uvm_pglistalloc , > -.Nm uvm_pglistfree , > -.Nm uvm_page_physload , > -.Nm uvm_pageout , > -.Nm uao_create , > -.Nm uao_detach , > -.Nm uao_reference , > -.Nm uvm_chgkprot , > -.Nm uvm_kernacc , > -.Nm uvm_vslock , > -.Nm uvm_vsunlock , > -.Nm uvm_meter , > -.Nm uvm_sysctl , > -.Nm uvm_grow , > -.Nm uvm_coredump > -.Nd virtual memory system external interface > -.Sh SYNOPSIS > -.In sys/param.h > -.In uvm/uvm.h > -.Sh DESCRIPTION > -The UVM virtual memory system manages access to the computer's memory > -resources. > -User processes and the kernel access the
Split uvm(9)
Diff below split uvm(9) into the following: - uvm_init(9) - uvm_fault(9) - uvm_km_alloc(9) - uvm_map(9) - uvm_pagealloc(9) - uvn_attach(9) That will allow us to work on smaller pages and improve the overall documentation of UVM. This split doesn't include changes. Ok? Index: Makefile === RCS file: /cvs/src/share/man/man9/Makefile,v retrieving revision 1.297 diff -u -p -r1.297 Makefile --- Makefile8 Nov 2019 07:36:52 - 1.297 +++ Makefile5 Dec 2019 12:48:33 - @@ -39,7 +39,10 @@ MAN= aml_evalnode.9 atomic_add_int.9 ato socreate.9 sosplice.9 strcmp.9 style.9 syscall.9 sysctl_int.9 \ task_add.9 tc_init.9 tfind.9 thread_fork.9 \ time_second.9 timeout.9 tsleep.9 tvtohz.9 \ - uiomove.9 uvm.9 usb_add_task.9 usbd_close_pipe.9 usbd_open_pipe.9 \ + uiomove.9 \ + uvm_fault.9 uvm_init.9 uvm_km_alloc.9 uvm_map.9 uvm_pagealloc.9 \ + uvn_attach.9 \ + usb_add_task.9 usbd_close_pipe.9 usbd_open_pipe.9 \ usbd_ref_wait.9 usbd_transfer.9 vfs.9 vfs_busy.9 \ vfs_cache.9 vaccess.9 vclean.9 vcount.9 vdevgone.9 vfinddev.9 vflush.9 \ vflushbuf.9 vget.9 vgone.9 vhold.9 vinvalbuf.9 vnode.9 vnsubr.9 \ Index: uvm.9 === RCS file: uvm.9 diff -N uvm.9 --- uvm.9 5 Nov 2019 08:18:47 - 1.71 +++ /dev/null 1 Jan 1970 00:00:00 - @@ -1,1085 +0,0 @@ -.\"$OpenBSD: uvm.9,v 1.71 2019/11/05 08:18:47 mpi Exp $ -.\"$NetBSD: uvm.9,v 1.14 2000/06/29 06:08:44 mrg Exp $ -.\" -.\" Copyright (c) 1998 Matthew R. Green -.\" All rights reserved. -.\" -.\" 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. -.\" 3. The name of the author may not be used to endorse or promote products -.\"derived from this software without specific prior written permission. -.\" -.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``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 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. -.\" -.\" XXX this manual sets nS to 1 or 0 in the description, to obtain -.\" synopsis-like function prototypes. any better way? -.\" -.Dd $Mdocdate: November 5 2019 $ -.Dt UVM_INIT 9 -.Os -.Sh NAME -.Nm uvm_init , -.Nm uvm_init_limits , -.Nm uvm_setpagesize , -.Nm uvm_swap_init , -.Nm uvm_map , -.Nm uvm_map_pageable , -.Nm uvm_map_pageable_all , -.Nm uvm_map_checkprot , -.Nm uvm_map_protect , -.Nm uvmspace_alloc , -.Nm uvmspace_exec , -.Nm uvmspace_fork , -.Nm uvmspace_free , -.Nm uvmspace_share , -.Nm uvm_uarea_alloc , -.Nm uvm_uarea_free , -.Nm UVM_MAPFLAG , -.Nm uvm_fault , -.Nm uvn_attach , -.Nm uvm_vnp_setsize , -.Nm uvm_vnp_sync , -.Nm uvm_vnp_terminate , -.Nm uvm_vnp_uncache , -.Nm uvm_io , -.Nm uvm_km_alloc , -.Nm uvm_km_zalloc , -.Nm uvm_km_alloc1 , -.Nm uvm_km_kmemalloc , -.Nm uvm_km_valloc , -.Nm uvm_km_valloc_wait , -.Nm uvm_km_suballoc , -.Nm uvm_km_free , -.Nm uvm_km_free_wakeup , -.Nm uvm_pagealloc , -.Nm uvm_pagerealloc , -.Nm uvm_pagefree , -.Nm uvm_pglistalloc , -.Nm uvm_pglistfree , -.Nm uvm_page_physload , -.Nm uvm_pageout , -.Nm uao_create , -.Nm uao_detach , -.Nm uao_reference , -.Nm uvm_chgkprot , -.Nm uvm_kernacc , -.Nm uvm_vslock , -.Nm uvm_vsunlock , -.Nm uvm_meter , -.Nm uvm_sysctl , -.Nm uvm_grow , -.Nm uvm_coredump -.Nd virtual memory system external interface -.Sh SYNOPSIS -.In sys/param.h -.In uvm/uvm.h -.Sh DESCRIPTION -The UVM virtual memory system manages access to the computer's memory -resources. -User processes and the kernel access these resources through -UVM's external interface. -UVM's external interface includes functions that: -.Pp -.Bl -hyphen -compact -.It -initialise UVM subsystems -.It -manage virtual address spaces -.It -resolve page faults -.It -memory map files and devices -.It -perform uio-based I/O to virtual memory -.It -allocate and free kernel virtual memory -.It -allocate and free p
Re: un-boolean_t i386's pmap
On Thu, Dec 05, 2019 at 12:38:34PM +0100, Martin Pieuchot wrote:
> ok?
I'm no kernel hacker but I really do not see the point.
boolean_t helps to see if a functions is supposed to return a boolean
instead of an error code. I hate reading a function and having to
guess if 0 is supposed to mean success or not.
-Otto
>
> Index: i386/pmap.c
> ===
> RCS file: /cvs/src/sys/arch/i386/i386/pmap.c,v
> retrieving revision 1.204
> diff -u -p -r1.204 pmap.c
> --- i386/pmap.c 18 Jan 2019 01:34:50 - 1.204
> +++ i386/pmap.c 5 Dec 2019 11:23:20 -
> @@ -403,7 +403,7 @@ int pmap_pg_wc = PG_UCMINUS;
> */
>
> uint32_t protection_codes[8];/* maps MI prot to i386 prot
> code */
> -boolean_t pmap_initialized = FALSE; /* pmap_init done yet? */
> +int pmap_initialized = 0;/* pmap_init done yet? */
>
> /*
> * MULTIPROCESSOR: special VAs/ PTEs are actually allocated inside a
> @@ -1120,7 +1120,7 @@ pmap_init(void)
>* done: pmap module is up (and ready for business)
>*/
>
> - pmap_initialized = TRUE;
> + pmap_initialized = 1;
> }
>
> /*
> @@ -1525,7 +1525,7 @@ pmap_deactivate(struct proc *p)
> * pmap_extract: extract a PA for the given VA
> */
>
> -boolean_t
> +int
> pmap_extract_86(struct pmap *pmap, vaddr_t va, paddr_t *pap)
> {
> pt_entry_t *ptes, pte;
> @@ -1535,12 +1535,12 @@ pmap_extract_86(struct pmap *pmap, vaddr
> pte = ptes[atop(va)];
> pmap_unmap_ptes_86(pmap);
> if (!pmap_valid_entry(pte))
> - return (FALSE);
> + return 0;
> if (pap != NULL)
> *pap = (pte & PG_FRAME) | (va & ~PG_FRAME);
> - return (TRUE);
> + return 1;
> }
> - return (FALSE);
> + return 0;
> }
>
> /*
> @@ -1594,7 +1594,7 @@ pmap_zero_phys_86(paddr_t pa)
> * pmap_zero_page_uncached: the same, except uncached.
> */
>
> -boolean_t
> +int
> pmap_zero_page_uncached_86(paddr_t pa)
> {
> #ifdef MULTIPROCESSOR
> @@ -1613,7 +1613,7 @@ pmap_zero_page_uncached_86(paddr_t pa)
> pagezero(zerova, PAGE_SIZE);/* zero */
> *zpte = 0;
>
> - return (TRUE);
> + return 1;
> }
>
> /*
> @@ -2009,7 +2009,7 @@ pmap_page_remove_86(struct vm_page *pg)
> * pmap_test_attrs: test a page's attributes
> */
>
> -boolean_t
> +int
> pmap_test_attrs_86(struct vm_page *pg, int testbits)
> {
> struct pv_entry *pve;
> @@ -2020,7 +2020,7 @@ pmap_test_attrs_86(struct vm_page *pg, i
> testflags = pmap_pte2flags(testbits);
>
> if (pg->pg_flags & testflags)
> - return (TRUE);
> + return 1;
>
> mybits = 0;
> mtx_enter(&pg->mdpage.pv_mtx);
> @@ -2035,20 +2035,20 @@ pmap_test_attrs_86(struct vm_page *pg, i
> mtx_leave(&pg->mdpage.pv_mtx);
>
> if (mybits == 0)
> - return (FALSE);
> + return 0;
>
> atomic_setbits_int(&pg->pg_flags, pmap_pte2flags(mybits));
>
> - return (TRUE);
> + return 1;
> }
>
> /*
> * pmap_clear_attrs: change a page's attributes
> *
> - * => we return TRUE if we cleared one of the bits we were asked to
> + * => we return 1 if we cleared one of the bits we were asked to
> */
>
> -boolean_t
> +int
> pmap_clear_attrs_86(struct vm_page *pg, int clearbits)
> {
> struct pv_entry *pve;
> @@ -2075,7 +2075,7 @@ pmap_clear_attrs_86(struct vm_page *pg,
>
> opte = ptes[ptei(pve->pv_va)];
> if (opte & clearbits) {
> - result = TRUE;
> + result = 1;
> i386_atomic_clearbits_l(&ptes[ptei(pve->pv_va)],
> (opte & clearbits));
> pmap_tlb_shootpage(pve->pv_pmap, pve->pv_va);
> @@ -2276,9 +2276,9 @@ pmap_enter_86(struct pmap *pmap, vaddr_t
> pt_entry_t *ptes, opte, npte;
> struct vm_page *ptp;
> struct pv_entry *pve, *opve = NULL;
> - boolean_t wired = (flags & PMAP_WIRED) != 0;
> - boolean_t nocache = (pa & PMAP_NOCACHE) != 0;
> - boolean_t wc = (pa & PMAP_WC) != 0;
> + int wired = (flags & PMAP_WIRED) != 0;
> + int nocache = (pa & PMAP_NOCACHE) != 0;
> + int wc = (pa & PMAP_WC) != 0;
> struct vm_page *pg = NULL;
> int error, wired_count, resident_count, ptp_count;
>
> @@ -2449,7 +2449,7 @@ enter_now:
> npte |= PG_PVLIST;
> if (pg->pg_flags & PG_PMAP_WC) {
> KASSERT(nocache == 0);
> - wc = TRUE;
> + wc = 1;
> }
> pmap_sync_flags_pte_86(pg, npte);
> }
> @@ -2618,7 +2618,7 @@ pmap_growkernel_86(vaddr_t maxkvaddr)
>
> for (/*null*/ ; nkpde < needed_kpde ; nkpde++) {
>
> - if (uvm.page_init_done == FALSE) {
> + if (uvm.page_init_done ==
un-boolean_t i386's pmap
ok?
Index: i386/pmap.c
===
RCS file: /cvs/src/sys/arch/i386/i386/pmap.c,v
retrieving revision 1.204
diff -u -p -r1.204 pmap.c
--- i386/pmap.c 18 Jan 2019 01:34:50 - 1.204
+++ i386/pmap.c 5 Dec 2019 11:23:20 -
@@ -403,7 +403,7 @@ int pmap_pg_wc = PG_UCMINUS;
*/
uint32_t protection_codes[8]; /* maps MI prot to i386 prot code */
-boolean_t pmap_initialized = FALSE;/* pmap_init done yet? */
+int pmap_initialized = 0; /* pmap_init done yet? */
/*
* MULTIPROCESSOR: special VAs/ PTEs are actually allocated inside a
@@ -1120,7 +1120,7 @@ pmap_init(void)
* done: pmap module is up (and ready for business)
*/
- pmap_initialized = TRUE;
+ pmap_initialized = 1;
}
/*
@@ -1525,7 +1525,7 @@ pmap_deactivate(struct proc *p)
* pmap_extract: extract a PA for the given VA
*/
-boolean_t
+int
pmap_extract_86(struct pmap *pmap, vaddr_t va, paddr_t *pap)
{
pt_entry_t *ptes, pte;
@@ -1535,12 +1535,12 @@ pmap_extract_86(struct pmap *pmap, vaddr
pte = ptes[atop(va)];
pmap_unmap_ptes_86(pmap);
if (!pmap_valid_entry(pte))
- return (FALSE);
+ return 0;
if (pap != NULL)
*pap = (pte & PG_FRAME) | (va & ~PG_FRAME);
- return (TRUE);
+ return 1;
}
- return (FALSE);
+ return 0;
}
/*
@@ -1594,7 +1594,7 @@ pmap_zero_phys_86(paddr_t pa)
* pmap_zero_page_uncached: the same, except uncached.
*/
-boolean_t
+int
pmap_zero_page_uncached_86(paddr_t pa)
{
#ifdef MULTIPROCESSOR
@@ -1613,7 +1613,7 @@ pmap_zero_page_uncached_86(paddr_t pa)
pagezero(zerova, PAGE_SIZE);/* zero */
*zpte = 0;
- return (TRUE);
+ return 1;
}
/*
@@ -2009,7 +2009,7 @@ pmap_page_remove_86(struct vm_page *pg)
* pmap_test_attrs: test a page's attributes
*/
-boolean_t
+int
pmap_test_attrs_86(struct vm_page *pg, int testbits)
{
struct pv_entry *pve;
@@ -2020,7 +2020,7 @@ pmap_test_attrs_86(struct vm_page *pg, i
testflags = pmap_pte2flags(testbits);
if (pg->pg_flags & testflags)
- return (TRUE);
+ return 1;
mybits = 0;
mtx_enter(&pg->mdpage.pv_mtx);
@@ -2035,20 +2035,20 @@ pmap_test_attrs_86(struct vm_page *pg, i
mtx_leave(&pg->mdpage.pv_mtx);
if (mybits == 0)
- return (FALSE);
+ return 0;
atomic_setbits_int(&pg->pg_flags, pmap_pte2flags(mybits));
- return (TRUE);
+ return 1;
}
/*
* pmap_clear_attrs: change a page's attributes
*
- * => we return TRUE if we cleared one of the bits we were asked to
+ * => we return 1 if we cleared one of the bits we were asked to
*/
-boolean_t
+int
pmap_clear_attrs_86(struct vm_page *pg, int clearbits)
{
struct pv_entry *pve;
@@ -2075,7 +2075,7 @@ pmap_clear_attrs_86(struct vm_page *pg,
opte = ptes[ptei(pve->pv_va)];
if (opte & clearbits) {
- result = TRUE;
+ result = 1;
i386_atomic_clearbits_l(&ptes[ptei(pve->pv_va)],
(opte & clearbits));
pmap_tlb_shootpage(pve->pv_pmap, pve->pv_va);
@@ -2276,9 +2276,9 @@ pmap_enter_86(struct pmap *pmap, vaddr_t
pt_entry_t *ptes, opte, npte;
struct vm_page *ptp;
struct pv_entry *pve, *opve = NULL;
- boolean_t wired = (flags & PMAP_WIRED) != 0;
- boolean_t nocache = (pa & PMAP_NOCACHE) != 0;
- boolean_t wc = (pa & PMAP_WC) != 0;
+ int wired = (flags & PMAP_WIRED) != 0;
+ int nocache = (pa & PMAP_NOCACHE) != 0;
+ int wc = (pa & PMAP_WC) != 0;
struct vm_page *pg = NULL;
int error, wired_count, resident_count, ptp_count;
@@ -2449,7 +2449,7 @@ enter_now:
npte |= PG_PVLIST;
if (pg->pg_flags & PG_PMAP_WC) {
KASSERT(nocache == 0);
- wc = TRUE;
+ wc = 1;
}
pmap_sync_flags_pte_86(pg, npte);
}
@@ -2618,7 +2618,7 @@ pmap_growkernel_86(vaddr_t maxkvaddr)
for (/*null*/ ; nkpde < needed_kpde ; nkpde++) {
- if (uvm.page_init_done == FALSE) {
+ if (uvm.page_init_done == 0) {
/*
* we're growing the kernel pmap early (from
@@ -2626,7 +2626,7 @@ pmap_growkernel_86(vaddr_t maxkvaddr)
* handled a little differently.
*/
- if (uvm_page_physget(&ptaddr) == FALSE)
+ if (uvm_page_physget(&ptaddr) == 0)
panic("pmap_growkernel: out of memory");
pmap_zero_phys_86(ptaddr);
@@ -2640,7 +2
Re: Does rpki-client need to unveil(NULL, NULL)?
ok
George Brown(321.geo...@gmail.com) on 2019.12.04 18:57:17 +:
> After pledge is immediately called without the unveil promise so this
> seems redundant.
>
> diff --git a/usr.sbin/rpki-client/main.c b/usr.sbin/rpki-client/main.c
> index f05ec1c5837..53ee4223371 100644
> --- a/usr.sbin/rpki-client/main.c
> +++ b/usr.sbin/rpki-client/main.c
> @@ -1498,8 +1498,6 @@ main(int argc, char *argv[])
> /* Only allow access to BASE_DIR. */
> if (unveil(BASE_DIR, "r") == -1)
> err(1, "%s: unveil", BASE_DIR);
> - if (unveil(NULL, NULL) == -1)
> - err(1, "unveil");
> if (pledge("stdio rpath", NULL) == -1)
> err(1, "pledge");
> proc_parser(fd[0], force);
>
Re: massage tcpdump ip and encapsulation output
Claudio Jeker(cje...@diehard.n-r-g.com) on 2019.12.05 09:53:49 +0100: > I would suggest to just pack most of the headers into one group of (). > > IPv4 ttl 1 [tos 0x20] 10.0.127.15 > 10.0.127.1 > would become > IPv4 (ttl 1 tos 0x20) 10.0.127.15 > 10.0.127.1 > and > IPv4 ttl 1 [tos 0x20] (id 39958, len 84) 10.0.127.15 > 10.0.127.1 > would become > IPv4 (ttl 1 tos 0x20 id 39958 len 84) 10.0.127.15 > 10.0.127.1 > > Maybe add the commas if that is easy to do. its more readable with commas, i think
Re: ldomctl: Add create-vdisk command
Klemens Nanni(k...@openbsd.org) on 2019.11.30 01:44:48 +0100:
> Just like on amd64 with vmctl(8), I want to be able to easily create
> disk images.
>
> ldomctl(8) currently advises to use dd(1), those files are not sparse
> either so creating big images may take a lot of time and the process
> tends to be error prone.
you can create sparse files with dd using seek=
dd if=/dev/zero of=blarf bs=1 count=0 seek=512M
no opinion on the diff.
> `ldomctl create-vdisk -s size file' behaves like
> `vmctl create -s size file' except that size is parsed by scan_scaled(3)
> and not assumed to be megabytes, e.g.
>
> $ ldomctl create-vdisk -s 8G ~/guest01.img
> t4-2$ ./obj/ldomctl create-vdisk -s 8G ~/guest01.img
> t4-2$ ls -l ~/guest01.img
> -rw--- 1 kn kn 8589934592 Nov 30 01:42 /home/kn/guest01.img
> t4-2$ du ~/guest01.img
> 96 /home/kn/guest01.img
>
> Feedback? OK?
>
>
> Index: ldom.conf.5
> ===
> RCS file: /cvs/src/usr.sbin/ldomctl/ldom.conf.5,v
> retrieving revision 1.7
> diff -u -p -r1.7 ldom.conf.5
> --- ldom.conf.5 28 Nov 2019 18:40:42 - 1.7
> +++ ldom.conf.5 29 Nov 2019 23:56:07 -
> @@ -59,8 +59,9 @@ for a list of OpenPROM variables.
> The specified file is used to back a virtual disk of the guest
> domain.
> .Ar file
> -can be a block device node or a disk image file created with
> -.Xr dd 1 .
> +can be a block device node or a disk image file created with the
> +.Cm create-vdisk
> +command.
> This keyword can be used multiple times.
> .It Ic vnet Op Brq Ar keyword Ns = Ns Ar value ...
> Assign a
> Index: ldomctl.8
> ===
> RCS file: /cvs/src/usr.sbin/ldomctl/ldomctl.8,v
> retrieving revision 1.18
> diff -u -p -r1.18 ldomctl.8
> --- ldomctl.8 28 Nov 2019 18:03:33 - 1.18
> +++ ldomctl.8 29 Nov 2019 23:47:01 -
> @@ -34,6 +34,16 @@ information about domains running on the
> .Pp
> The following commands are available:
> .Bl -tag -width Ds
> +.It Cm create-vdisk Fl s Ar size Ar file
> +Create a virtual disk image with the specified
> +.Ar file
> +path and
> +.Ar size ,
> +in bytes.
> +.Ar size
> +can be specified with a human-readable scale, using the format described in
> +.Xr scan_scaled 3 ,
> +e.g. 512M.
> .It Cm console Ar domain
> Using
> .Xr cu 1
> @@ -119,8 +129,8 @@ openbsd [next]
> .Pp
> Create a virtual disk image for each guest domain:
> .Bd -literal -offset indent
> -# dd if=/dev/zero of=/home/puffy/vdisk0 bs=1m count=8192
> -# dd if=/dev/zero of=/home/salmah/vdisk0 bs=1m count=8192
> +# ldomctl create-vdisk -s 8G /home/puffy/vdisk0
> +# ldomctl create-vdisk -s 8G /home/salmah/vdisk0
> .Ed
> .Pp
> The minirootfs install media can be used to boot guest domains:
> Index: ldomctl.c
> ===
> RCS file: /cvs/src/usr.sbin/ldomctl/ldomctl.c,v
> retrieving revision 1.27
> diff -u -p -r1.27 ldomctl.c
> --- ldomctl.c 28 Nov 2019 18:40:42 - 1.27
> +++ ldomctl.c 30 Nov 2019 00:40:49 -
> @@ -18,12 +18,15 @@
>
> #include
> #include
> +#include
> #include
> +#include
> #include
> #include
> #include
> #include
> #include
> +#include
>
> #include "ds.h"
> #include "hvctl.h"
> @@ -53,6 +56,7 @@ void list(int argc, char **argv);
> void list_io(int argc, char **argv);
> void xselect(int argc, char **argv);
> void delete(int argc, char **argv);
> +void create_vdisk(int argc, char **argv);
> void guest_start(int argc, char **argv);
> void guest_stop(int argc, char **argv);
> void guest_panic(int argc, char **argv);
> @@ -67,6 +71,7 @@ struct command commands[] = {
> { "list-io",list_io },
> { "select", xselect },
> { "delete", delete },
> + { "create-vdisk", create_vdisk },
> { "start", guest_start },
> { "stop", guest_stop },
> { "panic", guest_panic },
> @@ -117,6 +122,9 @@ main(int argc, char **argv)
> if (cmdp->cmd_name == NULL)
> usage();
>
> + if (strcmp(argv[0], "create-vdisk") == 0)
> + goto skip_hv;
> +
> hv_open();
>
> /*
> @@ -153,6 +161,7 @@ main(int argc, char **argv)
> add_guest(prop->d.arc.node);
> }
>
> +skip_hv:
> (cmdp->cmd_func)(argc, argv);
>
> exit(EXIT_SUCCESS);
> @@ -165,6 +174,7 @@ usage(void)
> "\t%1$s download directory\n"
> "\t%1$s dump|list|list-io\n"
> "\t%1$s init-system file\n"
> + "\t%1$s create-vdisk -s size file\n"
> "\t%1$s console|panic|start|status|stop [domain]\n", getprogname());
> exit(EXIT_FAILURE);
> }
> @@ -347,6 +357,48 @@ delete(int argc, char **argv)
> ds_conn_handle(dc);
>
> mdstore_delete(dc, argv[1]);
> +}
> +
> +void
> +create_vdisk(int argc, char **argv)
> +{
> + int ch, fd, save_errno;
> +
Infinite sleeps in sys/uvm
Convert them to {m,t}sleep_nsec(9), ok?
Index: uvm/uvm_device.c
===
RCS file: /cvs/src/sys/uvm/uvm_device.c,v
retrieving revision 1.56
diff -u -p -r1.56 uvm_device.c
--- uvm/uvm_device.c18 Jul 2019 23:47:33 - 1.56
+++ uvm/uvm_device.c5 Dec 2019 10:51:57 -
@@ -243,7 +243,8 @@ again:
* lock interleaving. -- this is ok in this case since the
* locks are both IPL_NONE
*/
- msleep(udv, &udv_lock, PVM | PNORELOCK, "udv_detach", 0);
+ msleep_nsec(udv, &udv_lock, PVM | PNORELOCK, "udv_detach",
+ INFSLP);
goto again;
}
Index: uvm/uvm_fault.c
===
RCS file: /cvs/src/sys/uvm/uvm_fault.c,v
retrieving revision 1.96
diff -u -p -r1.96 uvm_fault.c
--- uvm/uvm_fault.c 18 Jul 2019 23:47:33 - 1.96
+++ uvm/uvm_fault.c 5 Dec 2019 10:52:07 -
@@ -1029,7 +1029,7 @@ Case2:
KASSERT(result != VM_PAGER_PEND);
if (result == VM_PAGER_AGAIN) {
- tsleep(&lbolt, PVM, "fltagain2", 0);
+ tsleep_nsec(&lbolt, PVM, "fltagain2", INFSLP);
goto ReFault;
}
Index: uvm/uvm_km.c
===
RCS file: /cvs/src/sys/uvm/uvm_km.c,v
retrieving revision 1.132
diff -u -p -r1.132 uvm_km.c
--- uvm/uvm_km.c18 Jul 2019 23:47:33 - 1.132
+++ uvm/uvm_km.c5 Dec 2019 10:52:22 -
@@ -581,7 +581,7 @@ uvm_km_valloc_prefer_wait(struct vm_map
}
/* failed. sleep for a while (on map) */
- tsleep(map, PVM, "vallocwait", 0);
+ tsleep_nsec(map, PVM, "vallocwait", INFSLP);
}
/*NOTREACHED*/
}
@@ -909,7 +909,7 @@ try_map:
kv->kv_align, UVM_MAPFLAG(prot, prot, MAP_INHERIT_NONE,
MADV_RANDOM, mapflags))) {
if (kv->kv_wait && kd->kd_waitok) {
- tsleep(map, PVM, "km_allocva", 0);
+ tsleep_nsec(map, PVM, "km_allocva", INFSLP);
goto try_map;
}
uvm_pglistfree(&pgl);
Index: uvm/uvm_pager.c
===
RCS file: /cvs/src/sys/uvm/uvm_pager.c,v
retrieving revision 1.71
diff -u -p -r1.71 uvm_pager.c
--- uvm/uvm_pager.c 17 Dec 2014 19:42:15 - 1.71
+++ uvm/uvm_pager.c 5 Dec 2019 10:52:32 -
@@ -166,7 +166,7 @@ pager_seg_restart:
pager_seg_fail:
if ((flags & UVMPAGER_MAPIN_WAITOK) != 0) {
- msleep(&psegs, &uvm_pseg_lck, PVM, "pagerseg", 0);
+ msleep_nsec(&psegs, &uvm_pseg_lck, PVM, "pagerseg", INFSLP);
goto pager_seg_restart;
}
Index: uvm/uvm_pmemrange.c
===
RCS file: /cvs/src/sys/uvm/uvm_pmemrange.c,v
retrieving revision 1.55
diff -u -p -r1.55 uvm_pmemrange.c
--- uvm/uvm_pmemrange.c 3 Jul 2019 22:39:33 - 1.55
+++ uvm/uvm_pmemrange.c 5 Dec 2019 10:52:40 -
@@ -1946,7 +1946,7 @@ uvm_wait_pla(paddr_t low, paddr_t high,
wakeup(&uvm.pagedaemon);/* wake the daemon! */
while (pma.pm_flags & (UVM_PMA_LINKED | UVM_PMA_BUSY))
- msleep(&pma, &uvm.fpageqlock, PVM, wmsg, 0);
+ msleep_nsec(&pma, &uvm.fpageqlock, PVM, wmsg, INFSLP);
if (!(pma.pm_flags & UVM_PMA_FREED) &&
pma.pm_flags & UVM_PMA_FAIL) {
Index: uvm/uvm_vnode.c
===
RCS file: /cvs/src/sys/uvm/uvm_vnode.c,v
retrieving revision 1.104
diff -u -p -r1.104 uvm_vnode.c
--- uvm/uvm_vnode.c 18 Jul 2019 23:47:33 - 1.104
+++ uvm/uvm_vnode.c 5 Dec 2019 10:52:47 -
@@ -1236,7 +1236,7 @@ uvn_io(struct uvm_vnode *uvn, vm_page_t
return(VM_PAGER_OK);
} else {
while (rebooting)
- tsleep(&rebooting, PVM, "uvndead", 0);
+ tsleep_nsec(&rebooting, PVM, "uvndead", INFSLP);
return(VM_PAGER_ERROR);
}
}
Infinite sleeps in kern/vfs_*
Convert them to tsleep_nsec(9), ok?
Index: kern/vfs_bio.c
===
RCS file: /cvs/src/sys/kern/vfs_bio.c,v
retrieving revision 1.193
diff -u -p -r1.193 vfs_bio.c
--- kern/vfs_bio.c 29 Nov 2019 01:04:08 - 1.193
+++ kern/vfs_bio.c 5 Dec 2019 10:45:00 -
@@ -1101,14 +1101,14 @@ buf_get(struct vnode *vp, daddr_t blkno,
curproc != syncerproc && curproc != cleanerproc) {
wakeup(&bd_req);
needbuffer++;
- tsleep(&needbuffer, PRIBIO, "needbuffer", 0);
+ tsleep_nsec(&needbuffer, PRIBIO, "needbuffer", INFSLP);
splx(s);
return (NULL);
}
if (bcstats.dmapages + npages > bufpages) {
/* cleaner or syncer */
nobuffers = 1;
- tsleep(&nobuffers, PRIBIO, "nobuffers", 0);
+ tsleep_nsec(&nobuffers, PRIBIO, "nobuffers", INFSLP);
splx(s);
return (NULL);
}
@@ -1191,7 +1191,7 @@ buf_daemon(void *arg)
needbuffer = 0;
wakeup(&needbuffer);
}
- tsleep(&bd_req, PRIBIO - 7, "cleaner", 0);
+ tsleep_nsec(&bd_req, PRIBIO - 7, "cleaner", INFSLP);
}
while ((bp = bufcache_getdirtybuf())) {
@@ -1247,7 +1247,7 @@ biowait(struct buf *bp)
s = splbio();
while (!ISSET(bp->b_flags, B_DONE))
- tsleep(bp, PRIBIO + 1, "biowait", 0);
+ tsleep_nsec(bp, PRIBIO + 1, "biowait", INFSLP);
splx(s);
/* check for interruption of I/O (e.g. via NFS), then errors. */
Index: kern/vfs_biomem.c
===
RCS file: /cvs/src/sys/kern/vfs_biomem.c,v
retrieving revision 1.46
diff -u -p -r1.46 vfs_biomem.c
--- kern/vfs_biomem.c 29 Nov 2019 22:10:04 - 1.46
+++ kern/vfs_biomem.c 5 Dec 2019 10:45:12 -
@@ -110,7 +110,8 @@ buf_map(struct buf *bp)
bcstats.kvaslots_avail <= RESERVE_SLOTS) ||
vbp == NULL) {
buf_needva++;
- tsleep(&buf_needva, PRIBIO, "buf_needva", 0);
+ tsleep_nsec(&buf_needva, PRIBIO, "buf_needva",
+ INFSLP);
vbp = TAILQ_FIRST(&buf_valist);
}
va = buf_unmap(vbp);
Index: kern/vfs_default.c
===
RCS file: /cvs/src/sys/kern/vfs_default.c,v
retrieving revision 1.43
diff -u -p -r1.43 vfs_default.c
--- kern/vfs_default.c 10 Jan 2017 19:48:32 - 1.43
+++ kern/vfs_default.c 5 Dec 2019 10:45:22 -
@@ -88,8 +88,7 @@ vop_generic_revoke(void *v)
*/
if (vp->v_flag & VXLOCK) {
vp->v_flag |= VXWANT;
- tsleep(vp, PINOD, "vop_generic_revokeall", 0);
-
+ tsleep_nsec(vp, PINOD, "vop_generic_revokeall", INFSLP);
return(0);
}
Index: kern/vfs_subr.c
===
RCS file: /cvs/src/sys/kern/vfs_subr.c,v
retrieving revision 1.293
diff -u -p -r1.293 vfs_subr.c
--- kern/vfs_subr.c 26 Aug 2019 18:56:29 - 1.293
+++ kern/vfs_subr.c 5 Dec 2019 10:45:37 -
@@ -652,7 +652,7 @@ vget(struct vnode *vp, int flags)
}
vp->v_flag |= VXWANT;
- tsleep(vp, PINOD, "vget", 0);
+ tsleep_nsec(vp, PINOD, "vget", INFSLP);
return (ENOENT);
}
@@ -1104,7 +1104,7 @@ vgonel(struct vnode *vp, struct proc *p)
*/
if (vp->v_flag & VXLOCK) {
vp->v_flag |= VXWANT;
- tsleep(vp, PINOD, "vgone", 0);
+ tsleep_nsec(vp, PINOD, "vgone", INFSLP);
return;
}
Index: kern/vfs_sync.c
===
RCS file: /cvs/src/sys/kern/vfs_sync.c,v
retrieving revision 1.60
diff -u -p -r1.60 vfs_sync.c
--- kern/vfs_sync.c 13 Aug 2018 15:26:17 - 1.60
+++ kern/vfs_sync.c 5 Dec 2019 10:45:43 -
@@ -229,7 +229,7 @@ syncer_thread(void *arg)
* filesystem activity.
*/
if (time_second == starttime)
- tsleep(&lbolt, PPAUSE, "syncer", 0);
+ tsleep_nsec(&lbolt, PPAUSE, "syncer", INFSLP);
}
}
Index: kern/vfs_vnops.c
===
RCS file: /cvs/src/sys/kern/vfs_vnops.c,v
retrieving revision 1.
Re: ftp(1): https:// handling with NOSSL
On Wed, Dec 04 2019, Jeremie Courreges-Anglas wrote:
> ftp(1) built with no TLS support is confused (confusing?) when handled
> an https url. I have noticed this during tests with
> /usr/src/distrib/special/ftp.
>
> Now:
> --8<--
> ritchie /usr/src/distrib/special/ftp$ obj/ftp -o/dev/null
> https://www.openbsd.org/
> ftp: https: no address associated with name
> ftp: Can't connect or login to host `https'
> -->8--
>
> The fix is easy: let url_get() decide if it can handle the URL, as
> suggested by the comment which has been there since TLS support has been
> added. The diff below addresses this and also kills the ineffective
> comment.
>
> With the diff:
> --8<--
> ritchie /usr/src/distrib/special/ftp$ obj/ftp -o/dev/null
> https://www.openbsd.org/
> ftp: url_get: Invalid URL 'https://www.openbsd.org/'
> -->8--
>
> --8<--
> ritchie /usr/src/distrib/special/ftp$ size fetch.o obj/fetch.o ftp obj/ftp
> textdatabss dec hex
> 10927 0 104 11031 2b17fetch.o
> 11002 0 104 11106 2b62obj/fetch.o
> 407983 12904 43328 464215 71557 ftp
> 408079 12904 43328 464311 715b7 obj/ftp
> -->8--
>
> ok? (assuming it fits on i386 floppies)
Rebased on top of cvs HEAD, I noticed a bunch of #ifdef inconsistencies
that were just too ugly.
So after feedback from Theo: print an explicit message if ftp(1) was
built without HTTPS support. Printing a helpful message in this case
makes a lot of sense.
No need to show the function name in that case, but I'm keeping the
existing "url_get: Invalid URL '%s'" error as is; it shouldn't happen.
ok?
Index: fetch.c
===
RCS file: /cvs/src/usr.bin/ftp/fetch.c,v
retrieving revision 1.181
diff -u -p -r1.181 fetch.c
--- fetch.c 5 Dec 2019 10:26:25 - 1.181
+++ fetch.c 5 Dec 2019 10:41:14 -
@@ -240,14 +240,16 @@ url_get(const char *origline, const char
#ifndef SMALL
scheme = FILE_URL;
#endif /* !SMALL */
-#ifndef NOSSL
} else if (strncasecmp(newline, HTTPS_URL, sizeof(HTTPS_URL) - 1) == 0)
{
+#ifndef NOSSL
host = newline + sizeof(HTTPS_URL) - 1;
ishttpsurl = 1;
+#else
+ errx(1, "%s: No HTTPS support", newline);
+#endif /* !NOSSL */
#ifndef SMALL
scheme = HTTPS_URL;
#endif /* !SMALL */
-#endif /* !NOSSL */
} else
errx(1, "url_get: Invalid URL '%s'", newline);
@@ -1266,10 +1268,7 @@ auto_fetch(int argc, char *argv[], char
* Try HTTP URL-style arguments first.
*/
if (strncasecmp(url, HTTP_URL, sizeof(HTTP_URL) - 1) == 0 ||
-#ifndef NOSSL
- /* even if we compiled without SSL, url_get will check */
strncasecmp(url, HTTPS_URL, sizeof(HTTPS_URL) -1) == 0 ||
-#endif /* !NOSSL */
strncasecmp(url, FILE_URL, sizeof(FILE_URL) - 1) == 0) {
redirect_loop = 0;
retried = 0;
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: [patch] ftp: improve SMALL and NOSSL #ifdefs
On Wed, Nov 06 2019, Hiltjo Posthuma wrote:
[...]
> Thanks for reviewing the patch. Sadly I noticed and made a stupid mistake.
> When
> NOSSL is set, but SMALL is not set. It will set scheme = HTTPS_URL for the
> file handler.
>
> Below is the full updated patch:
I think we don't want to maintain tons of #ifdef combinations, but
applying your diff just made sense after I tried to modify nearby code
and I noticed the inconsistencies.
Committed, thanks!
> diff --git usr.bin/ftp/fetch.c usr.bin/ftp/fetch.c
> index 4c7e14b04bd..4511fb29fa1 100644
> --- usr.bin/ftp/fetch.c
> +++ usr.bin/ftp/fetch.c
> @@ -201,14 +201,14 @@ url_get(const char *origline, const char *proxyenv,
> const char *outfile, int las
> char *proxyhost = NULL;
> #ifndef NOSSL
> char *sslpath = NULL, *sslhost = NULL;
> - char *full_host = NULL;
> - const char *scheme;
> int ishttpurl = 0, ishttpsurl = 0;
> #endif /* !NOSSL */
> #ifndef SMALL
> + char *full_host = NULL;
> + const char *scheme;
> char *locbase;
> struct addrinfo *ares = NULL;
> -#endif
> +#endif /* !SMALL */
> struct tls *tls = NULL;
> int status;
> int save_errno;
> @@ -221,8 +221,10 @@ url_get(const char *origline, const char *proxyenv,
> const char *outfile, int las
> errx(1, "Can't allocate memory to parse URL");
> if (strncasecmp(newline, HTTP_URL, sizeof(HTTP_URL) - 1) == 0) {
> host = newline + sizeof(HTTP_URL) - 1;
> -#ifndef SMALL
> +#ifndef NOSSL
> ishttpurl = 1;
> +#endif /* !NOSSL */
> +#ifndef SMALL
> scheme = HTTP_URL;
> #endif /* !SMALL */
> } else if (strncasecmp(newline, FTP_URL, sizeof(FTP_URL) - 1) == 0) {
> @@ -234,12 +236,16 @@ url_get(const char *origline, const char *proxyenv,
> const char *outfile, int las
> } else if (strncasecmp(newline, FILE_URL, sizeof(FILE_URL) - 1) == 0) {
> host = newline + sizeof(FILE_URL) - 1;
> isfileurl = 1;
> -#ifndef NOSSL
> +#ifndef SMALL
> scheme = FILE_URL;
> +#endif /* !SMALL */
> +#ifndef NOSSL
> } else if (strncasecmp(newline, HTTPS_URL, sizeof(HTTPS_URL) - 1) == 0)
> {
> host = newline + sizeof(HTTPS_URL) - 1;
> ishttpsurl = 1;
> +#ifndef SMALL
> scheme = HTTPS_URL;
> +#endif /* !SMALL */
> #endif /* !NOSSL */
> } else
> errx(1, "url_get: Invalid URL '%s'", newline);
> @@ -1066,8 +1072,10 @@ improper:
> warnx("Improper response from %s", host);
>
> cleanup_url_get:
> -#ifndef NOSSL
> +#ifndef SMALL
> free(full_host);
> +#endif /* !SMALL */
> +#ifndef NOSSL
> free(sslhost);
> #endif /* !NOSSL */
> ftp_close(&fin, &tls, &fd);
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: massage tcpdump ip and encapsulation output
On Tue, Dec 03, 2019 at 10:00:01PM +1000, David Gwynne wrote: > this is a significant reworking of tcpdump with a couple of goals > twisted together. > > it is becoming increasingly common to encapsulate protocols, leading > to situations where you have some kind of ip packet inside another > ip packet. i am arguing our current ip printing code sucks in this > situation because some of the information about ip headers is printed > AFTER the payload. when you have a few layers of IP floating around, > it is difficult to associate these values back to the relevant header. > even if you don't have multiple IP layers, a big payload makes it > hard for my brain to backtrack. to address this, the diff moves > printing ip header properties to the front of the ip payload printing. > to give them some context, i'm prefixing the ip and ip6 printing > with IPv4 and IPv6 respectively. in practice it looks like this: > > before: > > dlg@v445 tcpdump$ tcpdump -nr /home/dlg/tmp/ping.pcap > 16:31:18.836620 10.0.127.15 > 10.0.127.1: icmp: echo request [tos 0x20] [ttl > 1] > 16:31:18.837074 10.0.127.1 > 10.0.127.15: icmp: echo reply [tos 0x20] > dlg@v445 tcpdump$ tcpdump -nr /home/dlg/tmp/ping.pcap -v > 16:31:18.836620 10.0.127.15 > 10.0.127.1: icmp: echo request (id:b59f seq:0) > [icmp cksum ok] [tos 0x20] [ttl 1] (id 39958, len 84) > 16:31:18.837074 10.0.127.1 > 10.0.127.15: icmp: echo reply (id:b59f seq:0) > [icmp cksum ok] [tos 0x20] (ttl 255, id 36919, len 84) > > after: > > dlg@v445 tcpdump$ ./obj/tcpdump -nr /home/dlg/tmp/ping.pcap > 16:31:18.836620 IPv4 ttl 1 [tos 0x20] 10.0.127.15 > 10.0.127.1: icmp: echo > request > 16:31:18.837074 IPv4 [tos 0x20] 10.0.127.1 > 10.0.127.15: icmp: echo reply > dlg@v445 tcpdump$ ./obj/tcpdump -nr /home/dlg/tmp/ping.pcap -v > 16:31:18.836620 IPv4 ttl 1 [tos 0x20] (id 39958, len 84) 10.0.127.15 > > 10.0.127.1: icmp: echo request (id:b59f seq:0) [icmp cksum ok] > 16:31:18.837074 IPv4 ttl 255 [tos 0x20] (id 36919, len 84) 10.0.127.1 > > 10.0.127.15: icmp: echo reply (id:b59f seq:0) [icmp cksum ok] > I think this is a reasonable start. I would prefer if the IP options "ttl 255 [tos 0x20] (id 36919, len 84)" would be encoded in a somewhat nicer fashion instead of this random collection of [] () and bare keywords. Similar for IPv6: "IPv6 hlim 52 [flowlabel 0x7ed4a] (len 57)" again the line is just hard to scan. I would suggest to just pack most of the headers into one group of (). IPv4 ttl 1 [tos 0x20] 10.0.127.15 > 10.0.127.1 would become IPv4 (ttl 1 tos 0x20) 10.0.127.15 > 10.0.127.1 and IPv4 ttl 1 [tos 0x20] (id 39958, len 84) 10.0.127.15 > 10.0.127.1 would become IPv4 (ttl 1 tos 0x20 id 39958 len 84) 10.0.127.15 > 10.0.127.1 Maybe add the commas if that is easy to do. -- :wq Claudio
