On Fri, 2 Dec 2022, Jeremie Courreges-Anglas wrote:
> clang emits this warning when compiling brk.S and sbrk.S on riscv64:
>
> /tmp/sbrk-06c40b.s:46:2: warning: sbrk changed binding to STB_WEAK
> .weak sbrk
>
> Let's avoid this using the "ENTRY_NB" approach im
updated length value. With this fixed I get a correctly aligned output:
>
> /usr/X11R6/bin/X35
> X: [priv] (Xorg) 0
> xenodm: :0 (xeno 0
>
> ok?
Oops, yeah. ok guenther@
On Mon, Jul 25, 2022 at 7:20 AM Theo de Raadt wrote:
> I've been watching conversation on a mailing list, and it leads me to
> wonder if we should inform the userbase better.
>
Too true. Certification *is* the key thing that protects users, not
careful, well engineered designs.
We should be gi
On Fri, Aug 19, 2022 at 12:42 PM Vitaliy Makkoveev wrote:
> bluhm@ pointed, that many KASSERT()s are not welcomed, so I didn't
> insert them into newly introduced handlers. Anyway except the tcp(4)
> protocol, `so_pcb' cant be NULL here. But the socket lock assertion
> looks reasonable.
>
> Some
presence of the callback to decide whether the
protocol needs anything to be done.)
Side note: pru_rcvd() (and the pru_rcvd implementations) should have a
return type of void.
Philip Guenther
On Mon, Aug 22, 2022 at 1:40 PM Vitaliy Makkoveev wrote:
> Another one.
>
> Since we never u
allows for any order.
>
C99 standard stated:
"The placement of a storage-class specifier other than at the beginning
of the declaration
specifiers in a declaration is an obsolescent feature.
My recall is that it was officially removed in C11.
ok guenther@
On Sat, Aug 27, 2022 at 6:41 PM Jonathan Gray wrote:
> directly use ansi volatile keyword not __volatile__ builtin
>
Yes, please. ok guenther@
On Sat, Aug 27, 2022 at 6:31 PM Jonathan Gray wrote:
> directly use ansi volatile keyword not __volatile from cdefs.h
>
Yay!
ok guenther@
}
>
The iov freeing, IMO,, should be done once, at the end of the loop. Just
keep growing as necessary (tracking the currently allocated size) and free
once.
kdump.c will need at least a SYS_recvmmsg line in the big table, and if you
do a ktrmmsghdr() bit in the kernel a matching decoder will be needed in
kdump.
Philip Guenther
Yes, splitting {tcp,udp}_usrreqs and {tcp,udp}6_usrreqs is clearly the
Right Thing.
ok guenther@
Unrelated to this specific callback, but I think you should consider
splitting out uipc_dgram_usrreqs out from uipc_usrreqs, as the SOCK_DGRAM
case differs from the other two for multiple callbacks
ok guenther@
(Thanks!)
On Sat, Sep 10, 2022 at 10:20 AM Vitaliy Makkoveev wrote:
> We have no interest on pru_rcvd() return value. Also, we call pru_rcvd()
> only if the socket's protocol have PR_WANTRCVD flag set. Such sockets
> are route domain, tcp(4) and unix(4) sockets.
inter to its first
element? I mean, shouldn't that line just (with const) be:
const struct sparc_insn *i_ptr = sparc_i;/* or &sparc_i[0] */
?
Philip Guenther
Yeah, I don't really get what's going on here that Devel::Cover is unhappy
about.
Maybe it's something about how my mkstemps_real() implementation creates
the filehandle that it returns. I see perlxstut(1) now talks about
{Input,InOut,Output}Stream and PerlIO* in the typemap, so maybe I should
ch
On Tue, Jul 11, 2023 at 9:21 PM Masato Asou wrote:
> ok ?
>
ok guenther@
(I think this was simply from how the original example was simplified in
rev 1.25)
Philip Guenther
call is implicitly reducing the len argument mod 2^32
on ILP32 archs, so it may fail with ERANGE if passed a 4GB buffer when it
should succeed, but I don't think that merits any sort of syspatch or such.
Philip Guenther
I think that changing the behavior of the existing API in a way that
gratuitously increases the differences between BSDs is unwise. IMHO, we
should follow NetBSD on this and add kqueue1(), that being obviously
consistent with the previous 'add flags argument' extensions: pipe2(),
dup3(), and accep
On Mon, Sep 11, 2023 at 5:29 AM Marc Espie
wrote:
> On Mon, Sep 11, 2023 at 12:10:17PM +0200, Claudio Jeker wrote:
> > On Mon, Sep 11, 2023 at 11:02:00AM +0200, Marc Espie wrote:
> > > I was reading through ps.1, which has two slightly different options
> > > -H Also display information
hflags(2), chmod(2), chown(2), chroot(2),
> execve(2), getfh(2), ktrace(2), link(2), mkdir(2), mkfifo(2), mknod(2),
> mount(2), open(2), pathconf(2), quotactl(2), readlink(2), rename(2),
> revoke(2), rmdir(2), stat(2), statfs(2), swapctl(2), symlink(2),
> truncate(2), unlink(2), utimes(
ead's process and it goes on the freelist, can't the
vnode vp points to be invalidated and reused?
Maybe this vget() should be split into vref() + vn_lock(), and the vput()
similarly split into VOP_UNLOCK() + vrele(), so the vrele() can be left
after this LIST_FOREACH() while the VOP_UNLOCK() is hoisted to the
"vn_lock() succeeded" path.
Philip Guenther
On Tue, Mar 17, 2020 at 5:18 AM Martin Pieuchot wrote:
> On 17/03/20(Tue) 04:02, Philip Guenther wrote:
> > On Tue, Mar 17, 2020 at 1:07 AM Martin Pieuchot wrote:
> > [...]
> > > @@ -663,8 +668,6 @@ ktrwriteraw(struct proc *curp, struct vn
> > > LIST
;
}
...but it currently blows up on the FD_ZERO() and would blow up in the
EV_SET() with your proposed diff.
Philip Guenther
On Fri, 3 Apr 2020, Martin Pieuchot wrote:
> Thanks, here it is, ok?
ok guenther@
On Fri, 3 Apr 2020, Martin Pieuchot wrote:
> Depending on the operation requested futex(2) might return the number of
> woken threads or an error. That means the following...
>
> mpv CALL futex(0xa58935899b0,0x82,1,0,0)
> mpv RET futex -1 errno 1 Operation not permitted
>
> ...is n
On Sat, 4 Apr 2020, Paul Irofti wrote:
> Here is a proper diff (both sys and libc into one).
Okay, bunch o' comments and thoughts of varying strength of opinion.
> diff --git lib/libc/Symbols.list lib/libc/Symbols.list
> index f9aa62ab6e8..4fa37a835aa 100644
> --- lib/libc/Symbols.list
> +++ lib/
On Sat, 4 Apr 2020, Martin Pieuchot wrote:
> On 03/04/20(Fri) 19:26, Philip Guenther wrote:
> > On Fri, 3 Apr 2020, Martin Pieuchot wrote:
> > > Depending on the operation requested futex(2) might return the number of
> > > woken threads or an error. That means the fo
On Sun, 5 Apr 2020, Stuart Henderson wrote:
> On 2020/04/05 10:28, Martin Pieuchot wrote:
> > Another way to proceed would be to do a port grep for futex and see what
> > the ecosystem is using.
>
> Sorry it's not filtered, but :
>
> https://junkpile.org/grep.futex.gz
Sure looks like the only oc
On Sat, 4 Apr 2020, Theo de Raadt wrote:
> Philip Guenther wrote:
>
> > On Fri, 3 Apr 2020, Martin Pieuchot wrote:
> > > Thanks, here it is, ok?
> >
> > ok guenther@
>
> Should we do the same to all other macros, just in case?
Checking /usr/include/{,
dy do it for AES stuff in the kernel, for
example. c.f. /usr/src/sys/arch/amd64/amd64/aesni.c
Philip Guenther
output
\x61
and not
a
FreeBSD 12's /usr/bin/printf does this, for example, however at least some
on the list seemed to feel the spec should be changed to make it
unspecified behavior.
The behavior of
printf '%b\n' '\x61'
is clearly unspecified already.
Philip
On Sun, Apr 18, 2021 at 12:04 PM Martijn van Duren <
openbsd+t...@list.imperialat.at> wrote:
> On Sun, 2021-04-18 at 11:17 -0900, Philip Guenther wrote:
> >
> > I'll just throw in a note that the current POSIX spec does not include
> support for \x in the printf(1)
oed out.
If we want to protect against that sort of hardware lossage, then a
filesystem which does so is the way to go, not an alarm on one window of a
glass house.
Philip Guenther
ndeed
noise/pessimization; it's the lock-less accesses where the compiler can
pull a rabbit from its hat and stab you with it.
Philip Guenther
ammer. READ/WRITE_ONCE use it carefully to
build a sharper tool. Unifying on "just plain volatile" when the work has
already been done to use a sharper tool correctly..well, if that's a good
idea then why have SMR at all when locks would be easier for everyone to
think about, despite being a blunter hammer? /s
Philip Guenther
Elf_Addr relro_addr = exe_obj->relro_addr;
> + relro_addr = exe_obj->relro_addr;
> if (dynp->d_tag == DT_DEBUG &&
> ((Elf_Addr)map_link + sizeof(*map_link) <= relro_addr
> ||
> (Elf_Addr)map_link >= relro_addr +
> exe_obj->relro_size)) {
>
>
ok guenther@
(This still assumes PT_GNU_RELRO comes after PT_PHDR, for exe_loff, but I
suspect even patchelf wouldn't screw with that.)
g the manpage fts_statp's value is undefined for various
values of fts_info.
Philip Guenther
On Fri, Jul 2, 2021 at 4:46 AM Claudio Jeker
wrote:
> Hit this today while doing some tests. symlink_read() needs to use just
> the filename and not the full path because fts_read(3) does ch
On Thu, Jul 12, 2018 at 2:11 PM Philip Guenther
wrote:
> CVSROOT:/cvs
> Module name:src
> Changes by: guent...@cvs.openbsd.org2018/07/12 08:11:11
>
> Modified files:
> sys/arch/amd64/amd64: cpu.c identcpu.c locore.
On Tue, Jul 24, 2018 at 1:02 PM Mark Kettenis
wrote:
> Diff below switches to the MI equivalent and kills the MD-specific
> API.
>
> ok?
>
ok guenther@
if
the symptoms have improved (or changed at all) there.
Philip Guenther
f should be done in the upstream, not
just to minimize OpenBSD costs in this area, but so that all OSes that draw
from that base can benefit.
Philip Guenther
On Mon, 10 Sep 2018, Todd C. Miller wrote:
> This is a port of uid_from_user() and gid_from_group() from NetBSD (also
> present in FreeBSD).
...
> --- lib/libc/gen/pwcache.c25 Nov 2015 23:16:01 - 1.13
> +++ lib/libc/gen/pwcache.c10 Sep 2018 15:04:35 -
...
> +/*
> + * routines
On Mon, 10 Sep 2018, Todd C. Miller wrote:
...
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ lib/libc/gen/pwcache.h10 Sep 2018 00:46:44 -
...
> +/*
> + * Constants and data structures used to implement group and password file
> + * caches. Traditional passwd/group cache routines perform q
On Mon, 10 Sep 2018, Todd C. Miller wrote:
> This removes cache.c from pax in favor of using the new uid_from_user()
> and gid_from_group() functions in libc. I've added explicit calls to
> setpassent() and setgroupent() since they are no longer implicitly
> called.
This pa
names in the future.
ok guenther@
> +/*
> + * Constants and data structures used to implement group and password file
> + * caches. Name lengths have been chosen to be as large as those supported
> + * by the passwd and group files as well as the standard archive formats.
> + * CAC
current documentation matches both the POSIX specification and the
utility behavior. Consider:
$ touch file
$ chmod 666 file
$ mkdir -m 777 dir
$ ls -l
total 2
drwxrwxrwx 2 guenther wheel 512 Sep 13 22:24 dir
-rw-rw-rw- 1 guenther wheel0 Sep 13 22:24 file
$ umask
002
$ chmod -rw *
$ ls -l
total 2
d-
found a bug in it. I've generated a new
diff that should fix this, so a future snap should fix this, though when
that'll happend depends on the snap builder's schedule.
Philip Guenther
\
RB_RIGHT(RB_PARENT(old, field), field) =
elm;\
RB_AUGMENT(RB_PARENT(old, field)); \
...
ok guenther@
On Thu, Oct 18, 2018 at 4:00 PM wrote:
> getsockopt(2) and setsockopt(2) take a void pointer for the third
> parameter so there is no need for any of these casts.
>
Yep.
> I can do other style(9)-type cleanup in a subsequent diff or I can
> cook this diff and do it all in one.
>
> Thoughts, p
On Fri, Oct 19, 2018 at 6:20 AM Scott Cheloha
wrote:
...
> Sure, looks cleaner. ok?
ok guenther@
On Sat, Oct 20, 2018 at 2:34 PM Edgar Pettijohn III
wrote:
> I'm guessing the if block will never hit since listen returns either 0 or
> -1.
>
Uh, but -1 is true.
Philip
On Sat, Oct 20, 2018 at 2:41 PM Edgar Pettijohn III
wrote:
> On 10/20/18 6:40 PM, Philip Guenther wrote:
>
> On Sat, Oct 20, 2018 at 2:34 PM Edgar Pettijohn III <
> ed...@pettijohn-web.com> wrote:
>
>> I'm guessing the if block will never hit since listen retu
On Fri, Nov 2, 2018 at 4:14 AM Hiltjo Posthuma
wrote:
> I noticed many ctype functions (such as isalpha, isdigit, tolower) are
> cast to
> unsigned char in httpd. This patch changes it also for one remaining check.
>
Yep. Committed. Thanks!
Philip Guenther
particularly Theo's comments, is that no one
actually demonstrated a case where lack of 64bit DMA caused any problems or
limitations.
If you have a system and use where lack of 64bit DMA creates a performance
limitation, then describe it and, *more importantly*, *why* you think the
DMA limit is involved.
Philip Guenther
ng in one of mknod() or mknodat().
As the guy who did the last type bump that invasive, Just Say No.
Philip Guenther
On Sun, Nov 11, 2018 at 10:03 PM David Gwynne wrote:
...
> so like this?
>
...
> --- if_tun.c24 Feb 2018 07:20:04 - 1.181
> +++ if_tun.c12 Nov 2018 06:02:51 -
> @@ -193,6 +193,9 @@ tun_create(struct if_clone *ifc, int uni
> struct tun_softc*tp;
> stru
is could
> breakage?
>
"set -o posix" is, IMO, about dealing with the places where ksh and posix
diverge. Using it as a hammer for strict compliance eliminates that middle
ground of "posix behavior with extensions". I would not consider that a
positive direction.
Philip Guenther
495,7 +495,7 @@ to the index of the next variable to be
> The string
> .Ar optstring
> contains a list of acceptable options;
> -a colon following an option indicates it may take an argument.
> +a colon following an option indicates it requires an argument.
> If an option not recognised by
> .Ar optstring
> is found,
>
"requires" is correct there.
ok guenther@
pects type 'char *', but argument 3
> has type 'void *'
> search.c:365: warning: format '%s' expects type 'char *', but argument 2
> has type 'void *'
>
> This diff fixes those. Now neither clang nor gcc complain.
> OK?
>
ok guenther@
@@ -1357,7 +1356,7 @@ proc_stop(struct proc *p, int sw)
> */
> softintr_schedule(proc_stop_si);
> if (sw)
> - mi_switch();
> + mi_switch(SSTOP);
>
This pair of chunks is wrong, as then the proc_stop(p, 0) call in
ptsignal() doesn't change the process from SSLEEP to SSTOP. Sending a stop
signal to a blocked process needs to change its state.
Philip Guenther
sleep 1
> done
> fi
>
I can't figure out what problem you think this could solve. Can you
explain the circumstances under which those quotes could make a difference?
Philip Guenther
On Fri, Oct 8, 2021 at 8:57 AM Theo de Raadt wrote:
> Philip Guenther wrote:
>
> > On Thu, Oct 7, 2021 at 5:57 PM bm1les wrote:
> >
> > > --- netstart2 Sep 2021 19:38:20 - 1.216
> > > +++ netstart8 Oct 2021 02:43:30 -
> > &
th works when the expansion is empty, such as
(( $(sysctl blah) + 0 != 0 ))
which is unary plus when it's empty, or
(( $(sysctl blah)0 != 0 ))
which multiplies the value by 10 when not empty and is zero when it's
empty.
Philip Guenther
(Per POSIX rules, any arithmetic expres
On Tue, Nov 9, 2021 at 3:29 PM Jan Stary wrote:
> On Nov 10 00:21:59, h...@stare.cz wrote:
> > Regarding C states, this machine has
> >
> > acpicpu0 at acpi0: C3(350@96 mwait.1@0x20), C2(500@64 mwait.1@0x10),
> C1(1000@1 mwait.1), PSS
> >
> > I suppose the cpu supports C1, C2, C3, but can someone
o break it?
(I'm not even sure the failover from profhz to hz should be kept: the
kernel does that itself in initclocks(9) so if profhz is 0 then hz is too,
sysctl(2) failed, and your CPU is on fire.)
ok guenther@
, generally on the first mmap(2), and you'll need
to reboot to a bsd.rd or similar and put a matching kernel+libc+ld.so in
place.
This might be a good time to just install an official snapshot instead.
-- Forwarded message -
From: Philip Guenther
Date: Thu, Dec 23, 2021 at 10:51 AM
Su
Skipping all leading double-underbar symbols makes sense to me.
Tempting to skip all symbols with more than one digit (or maybe just more
than one consecutive digit?), as guessing among per-chip symbols from, say,
the ar* or dc* families is an exercise in futility.
On Fri, Dec 24, 2021 at 5:23 AM
use $f instead of
> ${.IMPSRC}. However, this does not work as $f is then missing
> the path prefix and yacc won't find it if an obj directory is
> used. This is probably the reason for the use of ${.IMPSRC} in
> the first place.
>
Ah, nice analysis! The suggested fix looks safe to me (can't see how a .c
could have two .y direct prerequisites, so this can't be ambiguous).
ok guenther@
but the code still assumes that the previous (smaller) size is
> the correct one.
>
> Thoughts on this approach?
>
Analysis makes sense.
To bikeshed slightly I would be inclined to do the work progressively,
perhaps like the diff below...but your diff works too.
Philip Guenther
Index: li
t; Where's the signed/unsigned confusion hiding?
>
No where. The difference in behavior is that of 'sh' when signaled. Run
your test programs under "ktrace -i" and compare the behavioral difference
of the child 'sh' process after reception of the SIGINT.
Philip Guenther
Yeah, it makes sense to move our base C environment to match the values
seen in the output of 'readelf' and in the broader programming environment.
Philip
On Mon, Jan 10, 2022 at 3:34 PM Mark Kettenis
wrote:
> > Date: Sun, 09 Jan 2022 23:54:23 +0100
> > From: Leo Larnack
> >
> > Daniel Dickma
lation.
Standard "make lots of noise so when a failure occurs we can see the
leadup, but we'll ignore it otherwise" style of output, like a base build.
You read the lead up to the warnings and errors only. )
Philip Guenther
d in 2000 as part of some
sort of sync-with-upstream, weren't used then, and never used after.
Deleting them seems perfectly fine to me.
ok guenther@ on the entire diff
On Mon, Jan 17, 2022 at 5:02 AM Klemens Nanni wrote:
> These don't hurt on !VMM architectures but I was still surprised to see
> them on e.g. sparc64:
>
> # arch -s ; btrace -l | grep vmm
> sparc64
> tracepoint:vmm:guest_enter
> tracepoint:vmm:guest_exit
>
> Like s
On Mon, Jan 17, 2022 at 6:36 AM Christian Weisgerber
wrote:
> usr.sbin/ospf6ctl: fix -Wunused-but-set-variable warning
>
> Maybe this is uncompleted code, but I think we can remove it for
> the time being.
>
> M usr.sbin/ospf6ctl/ospf6ctl.c
>
Agreed. ok guenther@
On Sun, Jan 16, 2022 at 1:51 PM Christian Weisgerber
wrote:
> usr.sbin/eigrpd: fix -Wunused-but-set-variable warning
>
ok guenther@
On Sun, Jan 16, 2022 at 12:51 PM Christian Weisgerber
wrote:
> usr.sbin/dvmrpctl: fix -Wunused-but-set-variable warning
>
> This looks like /* not yet implemented */, but the companion functions
> show_rib_detail_msg() and show_mfc_detail_msg() are equally empty.
>
ok guenther@
.
>
> OK?
>
ok guenther@
On Mon, Jan 24, 2022 at 11:41 AM Mark Kettenis
wrote:
> > Date: Mon, 24 Jan 2022 20:19:46 +0100
> > From: Anton Lindqvist
> >
> > On Mon, Jan 24, 2022 at 05:31:49PM +0100, Mark Kettenis wrote:
> > > Currently we attach ACPI devices that are present in a machine.
> > > However, in some cases ACPI
M (implies a race by different users to create the
file), and close() could only return EIO. For any of those errors, you're
going to handle them the same whether they're from open, futimens, or
close, no?
Philip Guenther
On Fri, Jan 28, 2022 at 7:37 AM Scott Cheloha
wrote:
> On Fri, Jan 28, 2022 at 07:28:40AM -0700, Todd C. Miller wrote:
> > On Thu, 27 Jan 2022 20:02:18 -0800, Philip Guenther wrote:
> >
> > > > I think futimens(2) and close(2) failures are exotic enough to
> warra
use of 125 documented?
Philip Guenther
ter a possible call
to early_static_init(), and definitely after any fixup by ld.so) that it
should work Just Fine.
I would flip the test to check the environment before running issetugid(2)
because the syscall is more expensive and it's nice not to clutter the
kdump output. ;-)
Philip Guenther
) and an lfence before the
second rdtsc (so that the sequence is actually complete before the second
one). In this case, is it a problem if instructions after the rdtsc that
are not dependent on its result may be started before it's actually
complete? If not, then there's no reason to bracket that side.
Philip Guenther
gt;ps_pptr->ps_pid;
> > + if (p->p_p->ps_flags & PS_TRACED)
> > + *retval = p->p_p->ps_oppid;
> > + else
> > + *retval = p->p_p->ps_pptr->ps_pid;
> > +
> > return (0);
> > }
>
> This is definitely a bare minimum fix, but it does the job.
>
ptrace() has behaved like this for the life of OpenBSD and an indefinite
number of years previous in the BSD releases. What has happened that a
definitely incomplete fix is needed Right Now?
Philip Guenther
On Fri, Sep 4, 2020 at 2:59 PM Mateusz Guzik wrote:
> On 9/5/20, Philip Guenther wrote:
> > On Fri, Sep 4, 2020 at 1:06 PM Mateusz Guzik wrote:
> >
> >> On 9/4/20, Vitaliy Makkoveev wrote:
> >> > On Fri, Sep 04, 2020 at 05:24:42PM +0200, Mateusz Guzik wr
eva = F80002250B000
> blockend = 080012240
>
...
> Does anyone have an idea how to fix this issue?
So, blockend is clearly wrong for va and eva. I suspect the use of
L2_FRAME here:
blockend = (va & L2_FRAME) + NBPD_L2;
is wrong here and it should be
blockend = (va & VA_SIGN_NEG(L2_FRAME)) + NBPD_L2;
or some equivalent expression to keep all the bits above the frame.
Philip Guenther
that reach-around.
ok guenther@
> diff --git misc.c misc.c
> index 9e6e9db5e76..7226f74eccf 100644
> --- misc.c
> +++ misc.c
> @@ -713,7 +713,7 @@ do_gmatch(const unsigned char *s, const unsigned char
> *se,
> static int
> posix_cclass(const unsigned char
d relying on that, which is easy in this case by just casting to
"char *" instead.
Philip Guenther
e particular item of concern and the proposed fix is
agreed upon before spending the time to search and edit many other pages.
This is true not just for documentation changes but code changes, of
course: doing lots of work before there's "buy-in" is risking your time.
Philip Guenther
Makes sense. This code is just the space reservation, the relocation
generation or whatever fills them in is suppressed already, yes? Assuming
so, r+
On Sat, Oct 31, 2020 at 2:46 PM Mark Kettenis
wrote:
> > Date: Sat, 10 Oct 2020 23:19:19 +0200 (CEST)
> > From: Mark Kettenis
> >
> > On powerp
On Fri, Nov 6, 2020 at 4:51 PM George Koehler wrote:
> Your ilogb fix is ok gkoehler@
>
It's annoying that C and/or ieee754 and the original hardware
implementation in the x87 instructions diverged in their definitions, but
the former is what matters and libm needs to follow that.
e not willing to assume
it then the "is allocated" test needs to not use _flags but be some
other state change which can be relied on to not have false-positives,
but otherwise the other bits above still apply, I believe. Would
be a major ABI change...and if we do that there's like 3 other
things we should do at the same time (merge __sfileext into FILE,
grow _file to an int, and maybe move the recursive mutex for
f{,un}lockfile() into FILE?)
Philip Guenther
On Fri, Nov 27, 2020 at 10:35 PM Philip Guenther wrote:
...
> So yeah, maybe it does work to:
> 1) make __sfp() FLOCKFILE() the allocated FILE before unlocking sfp_mutex
> 2) update f{,d,mem,un}open() and open_*memstream() to match (1), unlocking
>in all paths when the FILE i
les:
usr.bin/netstat/inet.c
usr.bin/fstat/fstat.c
usr.bin/fstat/fuser.c
usr.bin/systat/netstat.c
Philip Guenther
On Sun, Nov 29, 2020 at 12:14 PM Martijn van Duren <
openbsd+t...@list.imperialat.at> wrote:
> On Sat, 2020-11-28 at 16:23 -0800, Philip Guenther wrote:
> > On Thu, Nov 26, 2020 at 1:08 PM Martijn van Duren <
> openbsd+t...@list.imperialat.at> wrote:
> > > I'
On Mon, Nov 30, 2020 at 6:10 PM Scott Cheloha
wrote:
> On Sat, Nov 28, 2020 at 01:41:50PM -0800, Philip Guenther wrote:
>
...
> > After thinking through states more, #4 isn't safe: _fwalk() can't take
> > sfp_mutex because it's called from __srefill() which has
On Tue, Dec 1, 2020 at 5:48 AM Martin Pieuchot wrote:
...
> exit1() for a multi-threaded process does the following:
>
> atomic_setbits_int(&p->p_flag, P_WEXIT);
> single_thread_check(p, 0); // directly or via single_thread_set()
> SMR_TAILQ_REMOVE_LOCKED(&pr->ps_threads,
On Mon, Dec 7, 2020 at 11:16 AM Alexandr Nedvedicky <
alexandr.nedvedi...@oracle.com> wrote:
> What's the plan for rw_write_held()? Currently macro is true, if whoever
> holds
> the lock.
>
> >
> > +#define rw_write_held(rwl) (rw_status(rwl) == RW_WRITE)
>
Nope. rw_status() returns RW_
k4.
>
> ok?
>
ok guenther@
tBSD getconf does not.
> Desirable? OK?
>
That's the way to do it, I just have this vague "what tempting lunacy has
led them to this?" lurking in my mind.
Philip Guenther
Testing something else I needed to call syslog(3) with LOG_CONS. Diff
below adds support to logger(1) for doing that. Option choice is
compatible with NetBSD.
ok?
Philip Guenther
Index: logger.1
===
RCS file: /data/src
1 - 100 of 1085 matches
Mail list logo
