kqueue.2: Add a comma
Index: kqueue.2 === RCS file: /cvs/src/lib/libc/sys/kqueue.2,v retrieving revision 1.46 diff -u -p -r1.46 kqueue.2 --- kqueue.231 Mar 2022 17:27:16 - 1.46 +++ kqueue.221 Oct 2022 23:02:57 - @@ -105,7 +105,7 @@ is zero, .Fn kevent will return immediately even if there is a .Fa timeout -specified unlike +specified, unlike .Xr select 2 . If .Fa timeout @@ -494,7 +494,7 @@ creates a new kernel event queue and ret If there was an error creating the kernel event queue, a value of -1 is returned and .Va errno -set. +is set. .Pp .Fn kevent returns the number of events placed in the
Re: sparc64: constify ddb instruction table
Todd C. Miller wrote: > On Fri, 21 Oct 2022 22:55:57 +0200, Mark Kettenis wrote: > > > Be careful. By moving more stuff into .rodata, you may overflow the > > .text/.rodata block. Make sure you build and test the kernels and > > also test an actual bsd.rd. > > Do we know exactly what these limits are? If so, couldn't we test > for them in the kernel Makefile after the kernel is linked? Sure, and the poeple making MI kernel changes will have no idea they just broke sparc64 kernels for everyone else. Eventually the kernel TLB management will need to change.
Re: sparc64: constify ddb instruction table
On Fri, 21 Oct 2022 22:55:57 +0200, Mark Kettenis wrote: > Be careful. By moving more stuff into .rodata, you may overflow the > .text/.rodata block. Make sure you build and test the kernels and > also test an actual bsd.rd. Do we know exactly what these limits are? If so, couldn't we test for them in the kernel Makefile after the kernel is linked? - todd
Re: sparc64: constify ddb instruction table
Mark Kettenis wrote: > Be careful. By moving more stuff into .rodata, you may overflow the > .text/.rodata block. Make sure you build and test the kernels and > also test an actual bsd.rd. Unless it fits, just barely, and then a commit three weeks later breaks it. Or three months. Or two years from now.
Re: sparc64: constify ddb instruction table
> Date: Fri, 21 Oct 2022 20:02:48 +
> From: Klemens Nanni
>
> This is the second biggest read-write global in a sparc64 bsd.mp:
> 01c091b8 g O .data 2cb8 sparc_i
>
> ddb(4) does not ever write to it and happily decodes instructions after
> moving it to .rodata:
>
> ddb{3}> x /i %pc
> db_inst_branch+0x10:be,pn db_inst_branch+0x64
> ddb{3}> x /i db_enter
> db_enter: add %sp, -0xd0, %sp
> ddb{3}> x /i 0
> 0: illtrap 0
>
> Fix two comment typos while here.
>
> OK?
Be careful. By moving more stuff into .rodata, you may overflow the
.text/.rodata block. Make sure you build and test the kernels and
also test an actual bsd.rd.
> diff --git a/sys/arch/sparc64/sparc64/db_disasm.c
> b/sys/arch/sparc64/sparc64/db_disasm.c
> index b697ad5e163..8924a762dc0 100644
> --- a/sys/arch/sparc64/sparc64/db_disasm.c
> +++ b/sys/arch/sparc64/sparc64/db_disasm.c
> @@ -153,7 +153,7 @@ char *prefetch[] = {
> /* The sparc instruction table has a format field which tells what
> the operand structure for this instruction is. Here are the codes:
>
> -Modifiers (nust be first):
> +Modifiers (must be first):
> a -- opcode has annul bit
> p -- opcode has branch prediction bit
>
> @@ -201,7 +201,7 @@ V8 only:
> */
>
>
> -struct sparc_insn sparc_i[] = {
> +const struct sparc_insn sparc_i[] = {
>
> /*
>* Format 1: Call
> @@ -217,7 +217,7 @@ struct sparc_insn sparc_i[] = {
> /* Note: if imm22 is zero then this is actually a "nop" grrr... */
> {(FORMAT2(0, 0x4)), "sethi", "Cd"},
>
> - /* Branch on Integer Co`ndition Codes "Bicc" */
> + /* Branch on Integer Condition Codes "Bicc" */
> {(FORMAT2(0, 2) | COND(8)), "ba", "a,m"},
> {(FORMAT2(0, 2) | COND(0)), "bn", "a,m"},
> {(FORMAT2(0, 2) | COND(9)), "bne", "a,m"},
> @@ -877,7 +877,7 @@ struct sparc_insn sparc_i[] = {
> vaddr_t
> db_disasm(vaddr_t loc, int altfmt)
> {
> - struct sparc_insn* i_ptr = (struct sparc_insn *)_i;
> + const struct sparc_insn *i_ptr = (const struct sparc_insn *)_i;
>
> unsigned int insn, you_lose, bitmask;
> int matchp;
>
>
Re: sparc64: constify ddb instruction table
On Fri, Oct 21, 2022 at 11:29:32AM -0900, Philip Guenther wrote:
> On Fri, Oct 21, 2022 at 11:04 AM Klemens Nanni wrote:
>
> > --- a/sys/arch/sparc64/sparc64/db_disasm.c
> > +++ b/sys/arch/sparc64/sparc64/db_disasm.c
> >
> ...
>
> > @@ -877,7 +877,7 @@ struct sparc_insn sparc_i[] = {
> > vaddr_t
> > db_disasm(vaddr_t loc, int altfmt)
> > {
> > - struct sparc_insn* i_ptr = (struct sparc_insn *)_i;
> > + const struct sparc_insn *i_ptr = (const struct sparc_insn
> > *)_i;
> >
>
> What's with that cast? Is it only there because sparc_i is an array and
> it's wrong to take its address when we just want a pointer to its first
> element? I mean, shouldn't that line just (with const) be:
> const struct sparc_insn *i_ptr = sparc_i;/* or _i[0] */
Sure, that also works.
diff --git a/sys/arch/sparc64/sparc64/db_disasm.c
b/sys/arch/sparc64/sparc64/db_disasm.c
index b697ad5e163..7f7056f6753 100644
--- a/sys/arch/sparc64/sparc64/db_disasm.c
+++ b/sys/arch/sparc64/sparc64/db_disasm.c
@@ -153,7 +153,7 @@ char *prefetch[] = {
/* The sparc instruction table has a format field which tells what
the operand structure for this instruction is. Here are the codes:
-Modifiers (nust be first):
+Modifiers (must be first):
a -- opcode has annul bit
p -- opcode has branch prediction bit
@@ -201,7 +201,7 @@ V8 only:
*/
-struct sparc_insn sparc_i[] = {
+const struct sparc_insn sparc_i[] = {
/*
* Format 1: Call
@@ -217,7 +217,7 @@ struct sparc_insn sparc_i[] = {
/* Note: if imm22 is zero then this is actually a "nop" grrr... */
{(FORMAT2(0, 0x4)), "sethi", "Cd"},
- /* Branch on Integer Co`ndition Codes "Bicc" */
+ /* Branch on Integer Condition Codes "Bicc" */
{(FORMAT2(0, 2) | COND(8)), "ba", "a,m"},
{(FORMAT2(0, 2) | COND(0)), "bn", "a,m"},
{(FORMAT2(0, 2) | COND(9)), "bne", "a,m"},
@@ -877,7 +877,7 @@ struct sparc_insn sparc_i[] = {
vaddr_t
db_disasm(vaddr_t loc, int altfmt)
{
- struct sparc_insn* i_ptr = (struct sparc_insn *)_i;
+ const struct sparc_insn *i_ptr = sparc_i;
unsigned int insn, you_lose, bitmask;
int matchp;
Re: sparc64: constify ddb instruction table
On Fri, Oct 21, 2022 at 11:04 AM Klemens Nanni wrote:
> --- a/sys/arch/sparc64/sparc64/db_disasm.c
> +++ b/sys/arch/sparc64/sparc64/db_disasm.c
>
...
> @@ -877,7 +877,7 @@ struct sparc_insn sparc_i[] = {
> vaddr_t
> db_disasm(vaddr_t loc, int altfmt)
> {
> - struct sparc_insn* i_ptr = (struct sparc_insn *)_i;
> + const struct sparc_insn *i_ptr = (const struct sparc_insn
> *)_i;
>
What's with that cast? Is it only there because sparc_i is an array and
it's wrong to take its address when we just want a pointer to its first
element? I mean, shouldn't that line just (with const) be:
const struct sparc_insn *i_ptr = sparc_i;/* or _i[0] */
?
Philip Guenther
sparc64: constify ddb instruction table
This is the second biggest read-write global in a sparc64 bsd.mp:
01c091b8 g O .data 2cb8 sparc_i
ddb(4) does not ever write to it and happily decodes instructions after
moving it to .rodata:
ddb{3}> x /i %pc
db_inst_branch+0x10:be,pn db_inst_branch+0x64
ddb{3}> x /i db_enter
db_enter: add %sp, -0xd0, %sp
ddb{3}> x /i 0
0: illtrap 0
Fix two comment typos while here.
OK?
diff --git a/sys/arch/sparc64/sparc64/db_disasm.c
b/sys/arch/sparc64/sparc64/db_disasm.c
index b697ad5e163..8924a762dc0 100644
--- a/sys/arch/sparc64/sparc64/db_disasm.c
+++ b/sys/arch/sparc64/sparc64/db_disasm.c
@@ -153,7 +153,7 @@ char *prefetch[] = {
/* The sparc instruction table has a format field which tells what
the operand structure for this instruction is. Here are the codes:
-Modifiers (nust be first):
+Modifiers (must be first):
a -- opcode has annul bit
p -- opcode has branch prediction bit
@@ -201,7 +201,7 @@ V8 only:
*/
-struct sparc_insn sparc_i[] = {
+const struct sparc_insn sparc_i[] = {
/*
* Format 1: Call
@@ -217,7 +217,7 @@ struct sparc_insn sparc_i[] = {
/* Note: if imm22 is zero then this is actually a "nop" grrr... */
{(FORMAT2(0, 0x4)), "sethi", "Cd"},
- /* Branch on Integer Co`ndition Codes "Bicc" */
+ /* Branch on Integer Condition Codes "Bicc" */
{(FORMAT2(0, 2) | COND(8)), "ba", "a,m"},
{(FORMAT2(0, 2) | COND(0)), "bn", "a,m"},
{(FORMAT2(0, 2) | COND(9)), "bne", "a,m"},
@@ -877,7 +877,7 @@ struct sparc_insn sparc_i[] = {
vaddr_t
db_disasm(vaddr_t loc, int altfmt)
{
- struct sparc_insn* i_ptr = (struct sparc_insn *)_i;
+ const struct sparc_insn *i_ptr = (const struct sparc_insn *)_i;
unsigned int insn, you_lose, bitmask;
int matchp;
malloc diff
Hi,
this diff has been sent out earlier, but now that more or the
immutable parts are in, it is time to test it in this new environment.
Thanks,
-Otto
Index: stdlib/malloc.c
===
RCS file: /cvs/src/lib/libc/stdlib/malloc.c,v
retrieving revision 1.274
diff -u -p -r1.274 malloc.c
--- stdlib/malloc.c 30 Jun 2022 17:15:48 - 1.274
+++ stdlib/malloc.c 29 Sep 2022 09:42:57 -
@@ -142,6 +142,7 @@ struct dir_info {
int malloc_junk;/* junk fill? */
int mmap_flag; /* extra flag for mmap */
int mutex;
+ int malloc_mt; /* multi-threaded mode? */
/* lists of free chunk info structs */
struct chunk_head chunk_info_list[MALLOC_MAXSHIFT + 1];
/* lists of chunks with free slots */
@@ -181,8 +182,6 @@ struct dir_info {
#endif /* MALLOC_STATS */
u_int32_t canary2;
};
-#define DIR_INFO_RSZ ((sizeof(struct dir_info) + MALLOC_PAGEMASK) & \
- ~MALLOC_PAGEMASK)
static void unmap(struct dir_info *d, void *p, size_t sz, size_t clear);
@@ -208,7 +207,6 @@ struct malloc_readonly {
/* Main bookkeeping information */
struct dir_info *malloc_pool[_MALLOC_MUTEXES];
u_int malloc_mutexes; /* how much in actual use? */
- int malloc_mt; /* multi-threaded mode? */
int malloc_freecheck; /* Extensive double free check */
int malloc_freeunmap; /* mprotect free pages PROT_NONE? */
int def_malloc_junk;/* junk fill? */
@@ -257,7 +255,7 @@ static void malloc_exit(void);
static inline void
_MALLOC_LEAVE(struct dir_info *d)
{
- if (mopts.malloc_mt) {
+ if (d->malloc_mt) {
d->active--;
_MALLOC_UNLOCK(d->mutex);
}
@@ -266,7 +264,7 @@ _MALLOC_LEAVE(struct dir_info *d)
static inline void
_MALLOC_ENTER(struct dir_info *d)
{
- if (mopts.malloc_mt) {
+ if (d->malloc_mt) {
_MALLOC_LOCK(d->mutex);
d->active++;
}
@@ -291,7 +289,7 @@ hash(void *p)
static inline struct dir_info *
getpool(void)
{
- if (!mopts.malloc_mt)
+ if (mopts.malloc_pool[1] == NULL || !mopts.malloc_pool[1]->malloc_mt)
return mopts.malloc_pool[1];
else/* first one reserved for special pool */
return mopts.malloc_pool[1 + TIB_GET()->tib_tid %
@@ -496,46 +494,22 @@ omalloc_init(void)
}
static void
-omalloc_poolinit(struct dir_info **dp, int mmap_flag)
+omalloc_poolinit(struct dir_info *d, int mmap_flag)
{
- char *p;
- size_t d_avail, regioninfo_size;
- struct dir_info *d;
int i, j;
- /*
-* Allocate dir_info with a guard page on either side. Also
-* randomise offset inside the page at which the dir_info
-* lies (subject to alignment by 1 << MALLOC_MINSHIFT)
-*/
- if ((p = MMAPNONE(DIR_INFO_RSZ + (MALLOC_PAGESIZE * 2), mmap_flag)) ==
- MAP_FAILED)
- wrterror(NULL, "malloc init mmap failed");
- mprotect(p + MALLOC_PAGESIZE, DIR_INFO_RSZ, PROT_READ | PROT_WRITE);
- d_avail = (DIR_INFO_RSZ - sizeof(*d)) >> MALLOC_MINSHIFT;
- d = (struct dir_info *)(p + MALLOC_PAGESIZE +
- (arc4random_uniform(d_avail) << MALLOC_MINSHIFT));
-
- rbytes_init(d);
- d->regions_free = d->regions_total = MALLOC_INITIAL_REGIONS;
- regioninfo_size = d->regions_total * sizeof(struct region_info);
- d->r = MMAP(regioninfo_size, mmap_flag);
- if (d->r == MAP_FAILED) {
- d->regions_total = 0;
- wrterror(NULL, "malloc init mmap failed");
- }
+ d->r = NULL;
+ d->rbytesused = sizeof(d->rbytes);
+ d->regions_free = d->regions_total = 0;
for (i = 0; i <= MALLOC_MAXSHIFT; i++) {
LIST_INIT(>chunk_info_list[i]);
for (j = 0; j < MALLOC_CHUNK_LISTS; j++)
LIST_INIT(>chunk_dir[i][j]);
}
- STATS_ADD(d->malloc_used, regioninfo_size + 3 * MALLOC_PAGESIZE);
d->mmap_flag = mmap_flag;
d->malloc_junk = mopts.def_malloc_junk;
d->canary1 = mopts.malloc_canary ^ (u_int32_t)(uintptr_t)d;
d->canary2 = ~d->canary1;
-
- *dp = d;
}
static int
@@ -550,7 +524,8 @@ omalloc_grow(struct dir_info *d)
if (d->regions_total > SIZE_MAX / sizeof(struct region_info) / 2)
return 1;
- newtotal = d->regions_total * 2;
+ newtotal = d->regions_total == 0 ? MALLOC_INITIAL_REGIONS :
+ d->regions_total * 2;
newsize = PAGEROUND(newtotal * sizeof(struct region_info));
mask = newtotal - 1;
@@ -575,10 +550,12 @@ omalloc_grow(struct dir_info *d)
}
}
-
Re: netstart: fix synopsis
On Fri, Oct 21, 2022 at 06:39:59PM +0100, Jason McIntyre wrote:
> i was going to incliude this in my answer, but eventually thought it
> looks like a seperate diff:
>
> the text currently reads as though only a singular interface is
> specified, and -n is kind of hidden. so i reworked the text. i went with
> an example which basically mirrors synopsis, because it works with the
> -n text, and i wanted to avoid marking up interface, but not doing so
> added other ambiguities.
>
> so is this better? it's as unobtrusive as i could make it.
I agree with the singular -> plural change to make clear that multiple
interfaces work.
However, I don't see much value in an example invocation at the first
place: the synopsis is trivial, echo(1) doesn't have examples, either.
But now that I see your diff, I think we should actually include `sh'
in the synopsis since /etc/netstart is not executable, so the documented
form does not actually work (I just never noticed this missing bit):
$ man -h netstart
/etc/netstart [-n] [interface ...]
$ /etc/netstart
ksh: /etc/netstart: cannot execute - Permission denied
Feedback? Objection? OK?
Index: share/man/man8/netstart.8
===
RCS file: /cvs/src/share/man/man8/netstart.8,v
retrieving revision 1.28
diff -u -p -r1.28 netstart.8
--- share/man/man8/netstart.8 21 Oct 2022 12:04:51 - 1.28
+++ share/man/man8/netstart.8 21 Oct 2022 18:57:40 -
@@ -32,7 +32,7 @@
.Nm netstart
.Nd command script for network startup
.Sh SYNOPSIS
-.Nm /etc/netstart
+.Cm sh Pa /etc/netstart
.Op Fl n
.Op Ar interface ...
.Sh DESCRIPTION
Index: etc/netstart
===
RCS file: /cvs/src/etc/netstart,v
retrieving revision 1.220
diff -u -p -r1.220 netstart
--- etc/netstart21 Oct 2022 12:04:51 - 1.220
+++ etc/netstart21 Oct 2022 18:56:45 -
@@ -7,7 +7,7 @@ set +o sh
# Show usage of the netstart script and exit.
usage() {
- print -u2 "usage: ${0##*/} [-n] [interface ...]"
+ print -u2 "usage: sh ${0##*/} [-n] [interface ...]"
exit 1
}
Re: ZZZ and extra mountpoints
Mark Kettenis wrote: > > I tend to agree that the complexity of this is out of scope for > > man pages. Understanding this properly requires reading books > > about computer architecture first. > > So I would phrase this as something like "device that the OpenBSD > kernel considers removable". And also note that the opposite happens > as well: there are devices that our kernel considers non-removable > that are in fact removable. For example ExpressCard devices, which > are considered non-removable since they are indistinguishable from > normal PCIe devices. Now you've really stepped in it. I have an expresscard storage device. At suspend time, it gets powered off. It detaches and reattaches at resume time. Any partition mounts are forceably unmounted when that happens. Would softraid work in those conditions? I don't know, and I don't care. I want us all to take a step back here. Some of you want to describe the situation as accurately as possible, and obviously then our users will take what they read as promises that it works that way, it won't change, and they can build complicated layers on top of it. Describing it accurately will only encourage more people to create fragile configurations, write blogs about it, and thus encourage even more people to create more broken situations. I think that procedure is hogwash. A more accurate picture is that the machines don't provide us with sufficient information, and therefore we will do whatever it takes in the kernel to ensure that suspend/resume works for 99% of the people, and the other 1% of people will lose. If people start constructing complicated scenarios, the number of losing cases will increase.
ubcmtp: constify device table
As usual, a global that's only ever read during match and attach.
The device type pointer gets stored in the softc, so that member must be
const as well.
Builds on amd64 but I don't have Apple notebooks to run-test:
820dd550 l O .rodata0410 ubcmtp_devices
Tests? OK?
Index: ubcmtp.c
===
RCS file: /cvs/src/sys/dev/usb/ubcmtp.c,v
retrieving revision 1.23
diff -u -p -r1.23 ubcmtp.c
--- ubcmtp.c22 Nov 2021 22:12:37 - 1.23
+++ ubcmtp.c21 Oct 2022 18:26:19 -
@@ -135,7 +135,7 @@ struct ubcmtp_dev {
struct ubcmtp_limit l_orientation;
};
-static struct ubcmtp_dev ubcmtp_devices[] = {
+static const struct ubcmtp_dev ubcmtp_devices[] = {
/* type 1 devices with separate buttons */
{
USB_VENDOR_APPLE,
@@ -312,7 +312,7 @@ static struct ubcmtp_dev ubcmtp_devices[
struct ubcmtp_softc {
struct device sc_dev; /* base device */
- struct ubcmtp_dev *dev_type;
+ const struct ubcmtp_dev *dev_type;
struct usbd_device *sc_udev;
struct device *sc_wsmousedev;
Re: ZZZ and extra mountpoints
> Date: Fri, 21 Oct 2022 20:11:49 +0200 > From: Stefan Sperling > > On Fri, Oct 21, 2022 at 06:46:14PM +0100, Jason McIntyre wrote: > > pluggable? The word "removable" is probably a better choice as this is the language used by the ACPI and device tree standards. > It really is a very machine-specific question. It depends > on how the manufaturer decided to connect devices to the > mainboard, which is not always possible to tell from the > perspective of software which runs on the machine. We probably can do a better job than we do now, but there will always be machines where the firmware lies to us. > There can be flash disks soldered into laptops which are > connected via an sdmmc bus, which will be detached because > they look just like a pluggable SD card. Actually that is a case where we do take into account what the firmware tells us. In ACPI there is a _RMV() method that will return 0 if a device cannot be removed. And device trees have a "non-removable" property. But that information isn't always correct and there are weird corner cases like eMMC modules that aren't soldered but are not quite so removable as a pluggable SD card. > There are machines with internal USB disks, e.g. the Edge > Router lite, which, granted, is not an amd64 machine and > does not suspend/resume. But a similar embedded amd64 with > a USB slot for internal disk could exist. Perhaps as a custom > build where someone plugged a USB stick into a USB header on > the motherboard. Certainly feasible. > > Several laptops I own have internal webcams on the USB bus. > Which will be detached because there isn't a generic way to > tell whether they are on an internal or external USB port. > And perhaps the entire USB bus will be powered down when > the host controller goes to sleep, and all connected devices > will lose power. Losing power isn't reall what's relevant. Most devices should lose power during suspend/hibernate. > I tend to agree that the complexity of this is out of scope for > man pages. Understanding this properly requires reading books > about computer architecture first. So I would phrase this as something like "device that the OpenBSD kernel considers removable". And also note that the opposite happens as well: there are devices that our kernel considers non-removable that are in fact removable. For example ExpressCard devices, which are considered non-removable since they are indistinguishable from normal PCIe devices.
Re: uvideo: constify device table
On Fri, Oct 21, 2022 at 02:25:52PM +, Klemens Nanni wrote:
> Not that big, but quirks are likely to grow in the feature and there is
> no reason to keep them writable:
> 822c0750 g O .data 0160 uvideo_devs
>
> Builds fine on amd64 but I don't have uvideo(4) attaching anywhere.
> OK?
No issues spotted with this diff.
ok mglocker@
> diff --git a/sys/dev/usb/uvideo.c b/sys/dev/usb/uvideo.c
> index de4784beb63..f947ed56133 100644
> --- a/sys/dev/usb/uvideo.c
> +++ b/sys/dev/usb/uvideo.c
> @@ -106,7 +106,7 @@ struct uvideo_softc {
> uint8_t *sc_uplayer_fbuffer;
> void (*sc_uplayer_intr)(void *);
>
> - struct uvideo_devs *sc_quirk;
> + const struct uvideo_devs*sc_quirk;
> usbd_status (*sc_decode_stream_header)
> (struct uvideo_softc *,
> uint8_t *, int);
> @@ -303,7 +303,7 @@ const struct video_hw_if uvideo_hw_if = {
> #define UVIDEO_FLAG_REATTACH 0x2
> #define UVIDEO_FLAG_VENDOR_CLASS 0x4
> #define UVIDEO_FLAG_NOATTACH 0x8
> -struct uvideo_devs {
> +const struct uvideo_devs {
> struct usb_devno uv_dev;
> char*ucode_name;
> usbd_status (*ucode_loader)(struct uvideo_softc *);
> @@ -386,7 +386,7 @@ struct uvideo_devs {
> },
> };
> #define uvideo_lookup(v, p) \
> - ((struct uvideo_devs *)usb_lookup(uvideo_devs, v, p))
> + ((const struct uvideo_devs *)usb_lookup(uvideo_devs, v, p))
>
> int
> uvideo_open(void *addr, int flags, int *size, uint8_t *buffer,
> @@ -440,7 +440,7 @@ uvideo_match(struct device *parent, void *match, void
> *aux)
> {
> struct usb_attach_arg *uaa = aux;
> usb_interface_descriptor_t *id;
> - struct uvideo_devs *quirk;
> + const struct uvideo_devs *quirk;
>
> if (uaa->iface == NULL)
> return (UMATCH_NONE);
>
Re: ZZZ and extra mountpoints
Stefan Sperling wrote: > And perhaps the entire USB bus will be powered down when > the host controller goes to sleep, and all connected devices > will lose power. but oh ... the situation is even more complicated: There are situations where a machine won't suspend because a bus has power-draw on it, because we didn't evict the sub-devices, so some code kicks devices off, otherwise you can't suspend. Now hibernate could be a bit different, but who is going to write this code and validate it on all machines?? Not me. Not anyone. But oh, we can try to describe this strange situation in a manual page which noone will read before they hit the situation of a device disconnecting during suspend? So helpful /sarc.
malloc: constify memname table
These are the compile-time constant strings behind vmstat(1)'s "malloc",
the kern.malloc.kmemnames sysctl(8) and panic strings.
Boots and displays unchanged on amd64:
82068690 g O .rodata0490 memname
OK?
Index: kern/kern_malloc.c
===
RCS file: /cvs/src/sys/kern/kern_malloc.c,v
retrieving revision 1.148
diff -u -p -r1.148 kern_malloc.c
--- kern/kern_malloc.c 14 Aug 2022 01:58:27 - 1.148
+++ kern/kern_malloc.c 21 Oct 2022 18:10:37 -
@@ -111,7 +111,7 @@ char *kmembase, *kmemlimit;
char buckstring[16 * sizeof("123456,")];
int buckstring_init = 0;
#if defined(KMEMSTATS) || defined(DIAGNOSTIC)
-char *memname[] = INITKMEMNAMES;
+const char * const memname[] = INITKMEMNAMES;
char *memall = NULL;
struct rwlock sysctl_kmemlock = RWLOCK_INITIALIZER("sysctlklk");
#endif
@@ -163,7 +163,7 @@ malloc(size_t size, int type, int flags)
int s;
#ifdef DIAGNOSTIC
int freshalloc;
- char *savedtype;
+ const char *savedtype;
#endif
#ifdef KMEMSTATS
struct kmemstats *ksp = [type];
Re: ZZZ and extra mountpoints
On Fri, Oct 21, 2022 at 06:46:14PM +0100, Jason McIntyre wrote: > pluggable? It really is a very machine-specific question. It depends on how the manufaturer decided to connect devices to the mainboard, which is not always possible to tell from the perspective of software which runs on the machine. There can be flash disks soldered into laptops which are connected via an sdmmc bus, which will be detached because they look just like a pluggable SD card. There are machines with internal USB disks, e.g. the Edge Router lite, which, granted, is not an amd64 machine and does not suspend/resume. But a similar embedded amd64 with a USB slot for internal disk could exist. Perhaps as a custom build where someone plugged a USB stick into a USB header on the motherboard. Certainly feasible. Several laptops I own have internal webcams on the USB bus. Which will be detached because there isn't a generic way to tell whether they are on an internal or external USB port. And perhaps the entire USB bus will be powered down when the host controller goes to sleep, and all connected devices will lose power. I tend to agree that the complexity of this is out of scope for man pages. Understanding this properly requires reading books about computer architecture first.
Re: ZZZ and extra mountpoints
Jason McIntyre wrote: > > It is extremely complicated, there is no way to accurately explain > > in user-speak what devices detach and what devices don't detach. > > > > pluggable? Sorry, that is completely untrue. What kind of plug? A USB plug? A MMC plug? A PCI plug? A MINI-PCIE plug? A docking station which has both USB or PCI plugins? An internal USB plug? How about an internal SDMMC device? And how about thunderbolt? How about an extern scsi chassis with it's own power? I could probably write a 5-sentence paragraph delineating the boundaries with great precision and yet the people reading it would find they still cannot discern exactly what devices will be detached. "If it loses power" isn't accurate either. Some of our drivers even self-protect themselves by FORCING a detach of their children. you all seem to want a single word or a simple sentence, but I'm sorry it isn't simple at all. > > And if we can't write a correct sentence for that, maybe we should realize > > we don't need to? > > > > Make a proposal. > > > > i agree that the original proposal was wrong. if anything, you'd maybe > want to know, for example, how to make it that you *were* asked for your > password when resuming an encrypted mount. that seems more pertinent to > softraid(4) than apm(8). I think that is nonsense. These subsystems were not designed to work together in the way that people _now believe_ they should work together. Now they want to document small little edges of their experience without understanding how the layers of different code actually works? It is trying to document based upon ignorance.
Re: ZZZ and extra mountpoints
On Fri, Oct 21, 2022 at 10:34:23AM -0600, Theo de Raadt wrote: > Sol??ne Rapenne wrote: > > > I agree my sentence isn't good enough or is too much, but I think ZZZ > > explanations isn't enough in its current form > > Maybe it is lacking. But your previous diff didn't help anyone. > > > from your reply I got > > information such as external devices that wasn't described in the man > > page. > > External devices have to get detached. They lose their configuration > because they lose their power. > > The problem is that it is very difficult to explain to users, in a > precise way, what an 'external device' is versus an 'internal device'. > > It is extremely complicated, there is no way to accurately explain > in user-speak what devices detach and what devices don't detach. > pluggable? > And if we can't write a correct sentence for that, maybe we should realize > we don't need to? > > Make a proposal. > i agree that the original proposal was wrong. if anything, you'd maybe want to know, for example, how to make it that you *were* asked for your password when resuming an encrypted mount. that seems more pertinent to softraid(4) than apm(8). jmc
Re: netstart: fix synopsis
On Fri, Oct 21, 2022 at 12:55:49PM +0100, Jason McIntyre wrote: > On Fri, Oct 21, 2022 at 09:30:08AM +, Klemens Nanni wrote: > > Using -n does not require an interface: > > > > # sh /etc/netstart -n ; echo $? > > ifconfig lo0 inet 127.0.0.1/8 > > route -qn add -inet6 fe80:: -prefixlen 10 ::1 -reject > > ... > > 0 > > > > OK? > > > > ok. > jmc > i was going to incliude this in my answer, but eventually thought it looks like a seperate diff: the text currently reads as though only a singular interface is specified, and -n is kind of hidden. so i reworked the text. i went with an example which basically mirrors synopsis, because it works with the -n text, and i wanted to avoid marking up interface, but not doing so added other ambiguities. so is this better? it's as unobtrusive as i could make it. jmc Index: netstart.8 === RCS file: /cvs/src/share/man/man8/netstart.8,v retrieving revision 1.28 diff -u -p -r1.28 netstart.8 --- netstart.8 21 Oct 2022 12:04:51 - 1.28 +++ netstart.8 21 Oct 2022 17:36:32 - @@ -88,19 +88,21 @@ and .Xr wg 4 . .El .Pp -After the system is completely initialized, it is possible to start a -newly created interface or bridges or apply the configuration from a +After the system is completely initialized +it is possible to start newly created interfaces or bridges, +or apply the configuration from .Xr hostname.if 5 -file to an existing interface, by invoking the following, where -.Ar foo0 -is the interface or bridge name: +files to existing interfaces, +by invoking +.Nm +in this fashion: .Pp -.D1 # sh /etc/netstart foo0 +.D1 # sh /etc/netstart [-n] [interface] .Pp Using the .Fl n option reports the steps that would be taken, -without actually configuring the interface. +without actually configuring anything. .Sh SEE ALSO .Xr multicast 4 , .Xr defaultdomain 5 ,
Re: ZZZ and extra mountpoints
Solène Rapenne wrote: > I agree my sentence isn't good enough or is too much, but I think ZZZ > explanations isn't enough in its current form Maybe it is lacking. But your previous diff didn't help anyone. > from your reply I got > information such as external devices that wasn't described in the man > page. External devices have to get detached. They lose their configuration because they lose their power. The problem is that it is very difficult to explain to users, in a precise way, what an 'external device' is versus an 'internal device'. It is extremely complicated, there is no way to accurately explain in user-speak what devices detach and what devices don't detach. And if we can't write a correct sentence for that, maybe we should realize we don't need to? Make a proposal.
Re: ZZZ and extra mountpoints
I disagree with this sentence. The machine is unhiberated in the same way that an unsuspend happens. EVERYTHING is as it was before, except for one thing: Devices which are not known to be part of the machine, will have become detached, and if/when they reattach, configuration of them will be missing. But that is not what you are describing here, in fact it is wrong, because a softraid partition on a usb device (or similar) will be gone. So you are adding a detail which is unneccesary, but also inaccurate. If you add this sentence, the next one sentence someone will propose will likely be "network configuration" remains the same. Then, a sentence that your programs are still running. And on and on, trying to explain that this isn't like a reboot. But all of that "state-maintained" information is already implied, because that is what suspend/resume and hibernate/unhibernate means. Solène Rapenne wrote: > hi > > I'm using an dedicated encrypted partition for a mountpoint and I was > wondering what would happen if I use ZZZ and then resume. > > - will it work out of the box? > - will it fail because the softraid device won't exist? > - am I going to be asked the passphrase by my rc.local script? > > It turned it worked out of the box, which mean the partitions remains > unlocked. In my opinion it's worth documenting, however I'm really not > sure how to word this in apm(8), here is an attempt > > diff --git a/usr.sbin/apm/apm.8 b/usr.sbin/apm/apm.8 > index ed110e11f14..61d414da8f1 100644 > --- a/usr.sbin/apm/apm.8 > +++ b/usr.sbin/apm/apm.8 > @@ -105,6 +105,8 @@ boot will occur, followed by the reading of the saved > memory image. > The image will then be unpacked and the system resumed > at the point immediately after the hibernation request. > +This implies that extra encrypted partitions (like an > +external disk) will remain unlocked after the resume. > .It Fl z > Put the system into suspend (deep sleep) state. > .El >
uvideo: constify device table
Not that big, but quirks are likely to grow in the feature and there is
no reason to keep them writable:
822c0750 g O .data 0160 uvideo_devs
Builds fine on amd64 but I don't have uvideo(4) attaching anywhere.
OK?
diff --git a/sys/dev/usb/uvideo.c b/sys/dev/usb/uvideo.c
index de4784beb63..f947ed56133 100644
--- a/sys/dev/usb/uvideo.c
+++ b/sys/dev/usb/uvideo.c
@@ -106,7 +106,7 @@ struct uvideo_softc {
uint8_t *sc_uplayer_fbuffer;
void (*sc_uplayer_intr)(void *);
- struct uvideo_devs *sc_quirk;
+ const struct uvideo_devs*sc_quirk;
usbd_status (*sc_decode_stream_header)
(struct uvideo_softc *,
uint8_t *, int);
@@ -303,7 +303,7 @@ const struct video_hw_if uvideo_hw_if = {
#define UVIDEO_FLAG_REATTACH 0x2
#define UVIDEO_FLAG_VENDOR_CLASS 0x4
#define UVIDEO_FLAG_NOATTACH 0x8
-struct uvideo_devs {
+const struct uvideo_devs {
struct usb_devno uv_dev;
char*ucode_name;
usbd_status (*ucode_loader)(struct uvideo_softc *);
@@ -386,7 +386,7 @@ struct uvideo_devs {
},
};
#define uvideo_lookup(v, p) \
- ((struct uvideo_devs *)usb_lookup(uvideo_devs, v, p))
+ ((const struct uvideo_devs *)usb_lookup(uvideo_devs, v, p))
int
uvideo_open(void *addr, int flags, int *size, uint8_t *buffer,
@@ -440,7 +440,7 @@ uvideo_match(struct device *parent, void *match, void *aux)
{
struct usb_attach_arg *uaa = aux;
usb_interface_descriptor_t *id;
- struct uvideo_devs *quirk;
+ const struct uvideo_devs *quirk;
if (uaa->iface == NULL)
return (UMATCH_NONE);
Re: loop_clone_destroy: read ifnetlist/rdomain with shared net lock
On Fri, Oct 21, 2022 at 12:14:16PM +, Klemens Nanni wrote: > On Fri, Oct 21, 2022 at 03:02:33PM +0300, Vitaliy Makkoveev wrote: > > netlock could be completely dropped here. > > We could probably drop the net lock around ifnetlist wherever the kernel > lock is currently held, but that would just make it harder to reason > about ifnetlist locking, imho. > > Eventually, the net lock (or its own lock) would be reintroduced anyway > when the kernel lock goes away, so I prefer grabbing the appropiate lock > now even when it is running with a bigger lock already. > I missed the netlock protects `if_rdomain' here. Your initial diff diff is ok by me.
weird behavior with timeout(1) in a script
hi I found a weird behavior trying to use timeout(1) in a script with interactive commands. My use case is to ask for unlocking /home from /etc/rc.local but continue if I don't type it in time. this is working: timeout 2s less /etc/fstab the same command isn't working from a script, running it get stuck and can't be stopped with ctrl+C #!/bin/sh timeout 2s less /etc/fstab However, using timeout with a non interactive command in a script doesn't create troubles in the issue case, a ktrace gives the following last lines, but I don't know how to interpret them 21097 timeout PSIG SIGCHLD caught handler=0xb1d715d6b00 mask=0x86007 21097 timeout RET sigsuspend -1 errno 4 Interrupted system call 21097 timeout CALL sigreturn(0x7f7e3540) 21097 timeout RET sigreturn JUSTRETURN 21097 timeout CALL kbind(0x7f7e3868,24,0xd30add790970a7bd) 21097 timeout RET kbind 0 21097 timeout CALL wait4(WAIT_ANY,0x7f7e39f4,0<>,0)
rpki-client: add support for draft-ietf-sidrops-signed-tal-12
Dear all,
I've authored an extension to rpki-client(8) to support validation of
Signed Objects containing Trust Anchor Keys (aka 'Signed TALs'). Signed
TALs provide a mechanism for RIRs to distribute and sign the next Trust
Anchor with the current Trust Anchor. This might be an improvement over
going to RIR websites and copy+pasting TAL data.
The Signed TAL specification is available here:
https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-signed-tal
A testbed is available here:
https://github.com/APNIC-net/rpki-signed-tal-demo/blob/master/testbed-tas.md
This implementation deviates from the specification in a small number of
ways:
* omitted to implement the notion of acceptance timers.
* omitted to check (and disallow) multiple TAK objects under a single
TA.
* Because of the unveil() write barrier between the parser subprocess
and the system operator 'owned' roots in /etc/rpki, this
implementation does not use successor TAKeys for top-down validation.
Below is a terminal transcript of the workflow I envision distributors
of RPKI TALs would use to cryptographically verify a new TAL originated
from a given Trust Anchor operator.
Kind regards,
Job
$ doas rpki-client -R -t two_taks.tal
Processing time 12 seconds (0 seconds user, 0 seconds system)
Skiplist entries: 0
Route Origin Authorizations: 0 (0 failed parse, 0 invalid)
AS Provider Attestations: 0 (0 failed parse, 0 invalid)
BGPsec Router Certificates: 0
Certificates: 2 (0 invalid)
Trust Anchor Locators: 1 (0 invalid)
Manifests: 2 (0 failed parse, 0 stale)
Certificate revocation lists: 2
Ghostbuster records: 0
Repositories: 2
Cleanup: removed 531 files, 228 directories, 0 superfluous
VRP Entries: 0 (0 unique)
VAP Entries: 0 (0 unique)
$ cd /var/cache/rpki-client/
$ find * -name '*.tak'
rpki-testbed.apnic.net/repository/ED9D6A424DA911EDB9AC0C5B9E174E93/05F53BCE4DAA11EDB9AC0C5B9E174E93.tak
$ cd rpki-testbed.apnic.net/repository/ED9D6A424DA911EDB9AC0C5B9E174E93/
$ rpki-client -t two_taks.tal -f 05F53BCE4DAA11EDB9AC0C5B9E174E93.tak
File: 05F53BCE4DAA11EDB9AC0C5B9E174E93.tak
Hash identifier: jTSYpCn4ceH4eSfpvehCtg9B4vr2pZYfyhAZg1z34L8=
Subject key identifier:
37:AF:B3:64:3A:EA:0F:50:82:E9:20:D4:F2:72:C3:5B:88:A2:23:3A
Certificate serial: 05
Authority key identifier:
08:C4:85:FC:A8:A3:59:F2:AD:09:47:E8:0F:CD:1F:48:52:93:4D:8F
Authority info access:
rsync://rpki-testbed.apnic.net/repository/ED9D5F8E4DA911EDB9AC0C5B9E174E93/root.cer
TAK EE certificate valid until: 2037-01-01T00:00:00Z
TAL derived from the 'current' Trust Anchor Key:
# Current key for original TAL
rsync://rpki-testbed.apnic.net/repository/ED9D5F8E4DA911EDB9AC0C5B9E174E93/root.cer
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyYT3tLDtrBW4xeBnhNWM
jgRkJJKlUyh3TodVDLxF+7r2CZOpTqSjkNO68G7HEmlRJnIxT6OyY+E4vg9kHmIU
cYyy9Cf3AP1GN9PbgR2TD6BCZzinxhQZSvm8tN0D16jjWBLh23FXbNr0a0lhnbPa
MGuLVIN2mHQ1eLyUSqhx6G40f+yVfOvmjW2vgkfiYkOSjbDPIGSVSn8jHzwDAVMY
QZdqPgHniw3RHlCmJRJWFVGxgG4qBdjeZfnlCRZamv3/MA8HJMMu6knLc4xj7uFC
kd/+I40pmZHrubsyWgLN4RBfx62hAOF/TTKzCqoncc45PYe8KOFHeEIR5fna0RjW
sQIDAQAB
TAL derived from the 'successor' Trust Anchor Key:
# Successor key for original TAL
rsync://rpki-testbed.apnic.net/repository/F785A7404DA911EDB9AC0C5B9E174E93/root.cer
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1lGORSJFEjbf8t6zEANM
F6ROAjSGs9mFMX5DnPUFoMzRcjc6mdgE1T4XsThm+oHc7lxlr4mhaZ08QPePHGuT
UilXOBNZTyZS2Ed75fQTN12biVaOdP/XQCUEEllqpCiNpKt7+C0YjMmbzS1jEK76
3WgaXQsKSiDolyHr4xfxmhf+/e3F8C6nU9OYaVSKU3grlr/rpfTZl7CSe7Gq1BNW
A3BWuYHA/wmlGIQdV60GcvkHWZPzJTdxkRQLgeCQUHY22YHpiRtqckVCx9jHOU8v
ygp62bERlCRT7PtGmgdUJE7Co40289/sgWWo2R0CncrvhPFdBEoaDNT/s+I+eTtx
UQIDAQAB
Validation: OK
End of terminal transcript, proposed changeset follows below:
Index: Makefile
===
RCS file: /cvs/src/usr.sbin/rpki-client/Makefile,v
retrieving revision 1.26
diff -u -p -r1.26 Makefile
--- Makefile30 Aug 2022 18:56:49 - 1.26
+++ Makefile21 Oct 2022 13:07:29 -
@@ -5,7 +5,7 @@ SRCS= as.c aspa.c cert.c cms.c crl.c enc
ip.c log.c main.c mft.c mkdir.c output.c output-bgpd.c output-bird.c \
output-csv.c output-json.c parser.c print.c repo.c roa.c rrdp.c \
rrdp_delta.c rrdp_notification.c rrdp_snapshot.c rrdp_util.c \
- rsc.c rsync.c tal.c validate.c x509.c
+ rsc.c rsync.c tak.c tal.c validate.c x509.c
MAN= rpki-client.8
LDADD+= -lexpat -ltls -lssl -lcrypto -lutil
Index: extern.h
===
RCS file: /cvs/src/usr.sbin/rpki-client/extern.h,v
retrieving revision 1.156
diff -u -p -r1.156 extern.h
--- extern.h3 Sep 2022 21:24:02 - 1.156
+++ extern.h21 Oct 2022 13:07:29 -
@@ -183,6 +183,7 @@ enum rtype {
RTYPE_FILE,
RTYPE_RSC,
RTYPE_ASPA,
+ RTYPE_TAK,
};
Re: loop_clone_destroy: read ifnetlist/rdomain with shared net lock
On Fri, Oct 21, 2022 at 03:02:33PM +0300, Vitaliy Makkoveev wrote: > netlock could be completely dropped here. We could probably drop the net lock around ifnetlist wherever the kernel lock is currently held, but that would just make it harder to reason about ifnetlist locking, imho. Eventually, the net lock (or its own lock) would be reintroduced anyway when the kernel lock goes away, so I prefer grabbing the appropiate lock now even when it is running with a bigger lock already.
grdc: show timezone when TZ is set
I am the author of the original patch, and I have to say it is very neat seeing the attention it is getting. I am really enjoying the discussion about how to make the patch better, but note that the original patch was deliberately kept extremely, almost offensivly, simple. like one early comment found I even tried to avoid an extra variable, because it is already a variable, an environment variable. While I think the modifications make the patch better and should be kept, I wanted to provide some context and justification for my original choices. > The recent change to grdc(6), to display additional information if TZ is > set, has a few issues. > > 1. Time zone offset incorrectly reported in Newfoundland. > > Some time zones have offsets of 30 or 45 minutes. The displayed time > offset is currently truncated to the closest hour. (Australia/Eucla > is a fun time zone too.) After a bit of soul searching I decided to abandon those souls in a non hour aligned TZ this is partialy because it is still mostly correct and I did not want to waste the space. But mainly because the numerical offset was only there for a secret underhanded reason. > > 2. The new, additional information disappears if the window is sized too > small (wintoosmall). There's basically room for it though... except I felt this was a feature, for free even. > 3. The TZ information is a string of unknown length, and so it doesn't > necessarily display correctly. > > Yeah, I know with pledge() you can't do testing like > TZ=:/home/pjanzen/dev/usr/share/zoneinfo/testing/2022/America/Kentucky/Monticello > any more, even though that's a perfectly cromulent and functional TZ on my > system otherwise. So for the time being, probably any TZ that exists and > doesn't abort grdc is 38 bytes or shorter. Which works. > > But, if your timezone exists, it already has its name in short form > included in tm->tm_zone. That's what I think should be > printed, even if "EDT" is way less cool than "America/Pangnirtung". I > mean, if the point is just to be able to label clocks with nice places, > instead of the time zone it's showing, maybe it could be a different option. > > Counterpoint: some of the timezones have short names that are just the UTC > offset, which is really boring and duplicated given that we print out the > offset already. Hey, maybe we could just print the offset... > > 4. There's no indication if you type an invalid TZ--you get UTC and a > misleading label onscreen. > > Timezone handling defaults to UTC if anything breaks along the chain, as > the tzset(3) man page makes clear. That means if you misspell Antarctica > while setting your TZ=Antartica/McMurdo, you'll end up half a day off from > all your pals at McMurdo as your screen happily tells you that you're > seeing McMurdo +0 time. > > There's no simple way to tell if your $TZ is valid or not (if you get back > UTC, maybe that's really what it should be!). At least if we display > tm->tm_zone rather than $TZ, we're not misleading. I had this exact problem, I looked into what it would take to validate that a TZ was correct and decided that loading the entire tz ecosystem just to to figure this out was far too much complication for grdc to take. So the solution was simple. Show the hour offset numericly, If this was different from the expected offset, you knew your TZ was wrong. And thus the neferious reason why the the numerical hour exists. I then decided I really liked seeing the offset numericly so double win. > > > I was going to be upset that the man page for grdc(6) is way pickier on TZ > than tzset(3), but it's quite accurate given the pledge() call. Speaking > of which, I don't expect any one else plays with timezone files, and surely > one doesn't want one's general utilities to be pwned by possible bugs in > the time-handling code exploited with custom files created outside > /usr/share/zoneinfo. But it's still a touch irritating-should-be-fixable > that, because the pledge() has to be after initscr(), grdc has the > possibility of leaving the terminal in the wrong state when it aborts on > test TZ files. > > > > Paul Janzen. > Cheers, Thank you very much for sharing your interest in the subject.
Re: loop_clone_destroy: read ifnetlist/rdomain with shared net lock
On Fri, Oct 21, 2022 at 10:28:04AM +, Klemens Nanni wrote:
> All interface ioctls always run with the kernel lock anyway, so this
> doesn't make a difference, except that it reflects how ifnetlist is not
> modified.
>
> OK?
>
netlock could be completely dropped here.
> diff --git a/sys/net/if_loop.c b/sys/net/if_loop.c
> index a15820420ef..16006c4c102 100644
> --- a/sys/net/if_loop.c
> +++ b/sys/net/if_loop.c
> @@ -204,16 +204,16 @@ loop_clone_destroy(struct ifnet *ifp)
> return (EPERM);
>
> /* if there is any other interface in this rdomain, deny */
> - NET_LOCK();
> + NET_LOCK_SHARED();
> TAILQ_FOREACH(p, , if_list) {
> if (p->if_rdomain != ifp->if_rdomain)
> continue;
> if (p->if_index == ifp->if_index)
> continue;
> - NET_UNLOCK();
> + NET_UNLOCK_SHARED();
> return (EBUSY);
> }
> - NET_UNLOCK();
> + NET_UNLOCK_SHARED();
>
> rdomain = ifp->if_rdomain;
> }
>
Re: netstart: fix synopsis
On Fri, Oct 21, 2022 at 09:30:08AM +, Klemens Nanni wrote:
> Using -n does not require an interface:
>
> # sh /etc/netstart -n ; echo $?
> ifconfig lo0 inet 127.0.0.1/8
> route -qn add -inet6 fe80:: -prefixlen 10 ::1 -reject
> ...
> 0
>
> OK?
>
ok.
jmc
> Index: etc/netstart
> ===
> RCS file: /cvs/src/etc/netstart,v
> retrieving revision 1.219
> diff -u -p -r1.219 netstart
> --- etc/netstart 3 Jul 2022 12:14:36 - 1.219
> +++ etc/netstart 21 Oct 2022 09:27:23 -
> @@ -7,7 +7,7 @@ set +o sh
>
> # Show usage of the netstart script and exit.
> usage() {
> - print -u2 "usage: ${0##*/} [[-n] interface ...]"
> + print -u2 "usage: ${0##*/} [-n] [interface ...]"
> exit 1
> }
>
> Index: share/man/man8/netstart.8
> ===
> RCS file: /cvs/src/share/man/man8/netstart.8,v
> retrieving revision 1.27
> diff -u -p -r1.27 netstart.8
> --- share/man/man8/netstart.8 5 Jul 2022 08:14:12 - 1.27
> +++ share/man/man8/netstart.8 21 Oct 2022 09:28:36 -
> @@ -33,7 +33,8 @@
> .Nd command script for network startup
> .Sh SYNOPSIS
> .Nm /etc/netstart
> -.Op Oo Fl n Oc Ar interface ...
> +.Op Fl n
> +.Op Ar interface ...
> .Sh DESCRIPTION
> .Nm
> is the command script that is invoked by
>
loop_clone_destroy: read ifnetlist/rdomain with shared net lock
All interface ioctls always run with the kernel lock anyway, so this
doesn't make a difference, except that it reflects how ifnetlist is not
modified.
OK?
diff --git a/sys/net/if_loop.c b/sys/net/if_loop.c
index a15820420ef..16006c4c102 100644
--- a/sys/net/if_loop.c
+++ b/sys/net/if_loop.c
@@ -204,16 +204,16 @@ loop_clone_destroy(struct ifnet *ifp)
return (EPERM);
/* if there is any other interface in this rdomain, deny */
- NET_LOCK();
+ NET_LOCK_SHARED();
TAILQ_FOREACH(p, , if_list) {
if (p->if_rdomain != ifp->if_rdomain)
continue;
if (p->if_index == ifp->if_index)
continue;
- NET_UNLOCK();
+ NET_UNLOCK_SHARED();
return (EBUSY);
}
- NET_UNLOCK();
+ NET_UNLOCK_SHARED();
rdomain = ifp->if_rdomain;
}
netstart: fix synopsis
Using -n does not require an interface:
# sh /etc/netstart -n ; echo $?
ifconfig lo0 inet 127.0.0.1/8
route -qn add -inet6 fe80:: -prefixlen 10 ::1 -reject
...
0
OK?
Index: etc/netstart
===
RCS file: /cvs/src/etc/netstart,v
retrieving revision 1.219
diff -u -p -r1.219 netstart
--- etc/netstart3 Jul 2022 12:14:36 - 1.219
+++ etc/netstart21 Oct 2022 09:27:23 -
@@ -7,7 +7,7 @@ set +o sh
# Show usage of the netstart script and exit.
usage() {
- print -u2 "usage: ${0##*/} [[-n] interface ...]"
+ print -u2 "usage: ${0##*/} [-n] [interface ...]"
exit 1
}
Index: share/man/man8/netstart.8
===
RCS file: /cvs/src/share/man/man8/netstart.8,v
retrieving revision 1.27
diff -u -p -r1.27 netstart.8
--- share/man/man8/netstart.8 5 Jul 2022 08:14:12 - 1.27
+++ share/man/man8/netstart.8 21 Oct 2022 09:28:36 -
@@ -33,7 +33,8 @@
.Nd command script for network startup
.Sh SYNOPSIS
.Nm /etc/netstart
-.Op Oo Fl n Oc Ar interface ...
+.Op Fl n
+.Op Ar interface ...
.Sh DESCRIPTION
.Nm
is the command script that is invoked by
Re: ZZZ and extra mountpoints
I think this adds nothing. It already states your system will be restored to its previous state, and so it will, as far as possible. Actually, specifically external (USB) disks, are probably *not* properly restored though... /Alexander On October 21, 2022 9:05:25 AM GMT+02:00, "Solène Rapenne" wrote: >hi > >I'm using an dedicated encrypted partition for a mountpoint and I was >wondering what would happen if I use ZZZ and then resume. > >- will it work out of the box? >- will it fail because the softraid device won't exist? >- am I going to be asked the passphrase by my rc.local script? > >It turned it worked out of the box, which mean the partitions remains >unlocked. In my opinion it's worth documenting, however I'm really not >sure how to word this in apm(8), here is an attempt > >diff --git a/usr.sbin/apm/apm.8 b/usr.sbin/apm/apm.8 >index ed110e11f14..61d414da8f1 100644 >--- a/usr.sbin/apm/apm.8 >+++ b/usr.sbin/apm/apm.8 >@@ -105,6 +105,8 @@ boot will occur, followed by the reading of the saved > memory image. > The image will then be unpacked and the system resumed > at the point immediately after the hibernation request. >+This implies that extra encrypted partitions (like an >+external disk) will remain unlocked after the resume. > .It Fl z > Put the system into suspend (deep sleep) state. > .El >
