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(
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
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
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
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
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
ains the KTRC_CODE_SYSCALL flag, but
> the kernel checks code == SYS_sysctl. So the mib is not added to
> ktrace output. Fix is easy by using KTRC_CODE_MASK.
>
ok guenther@ on the first chunk, the ktrsyscall() change.
The flag is only passed to ktrsyscall(), not ktrsysret(), so the second
c
ettled on too.
- lambdas (anonymous subs) can use signatures. Note that stuff like
> File::Find explicitly takes 0 parameters, whereas stuff like signal handler
> is woefully underspecified !
>
Yeah, the downside of signatures is that by default it makes adding
parameters a breaking change and can thus calcify the interface. Something
for authors of shared modules that have callbacks to carefully consider. :/
Philip Guenther
On Fri, Apr 7, 2023 at 9:44 AM Dave Voutila wrote:
...
> Touch longer, but won't generate ktrace noise by blind calls to close(2)
> and also accounts for the other error conditions (EINTR, EIO).
>
> For EIO, not sure yet how we want to handle it other than log it.
>
> For EINTR, we want to accoun
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@
pecific interface, just add a route
for 224.0.0.0/4 pointing to that interface. (Of course, if you haven't set
multicast=YES in /etc/rc.conf.local then /etc/netstart will create one of
those routes itself with the 'reject' flag set to block all multicast, but
presumably you've already set that correctly.)
Philip Guenther
going to keep the
segments page-aligned then it should be adjusting the virtaddr field of the
LOAD segment to keep the offset aligned with the virtaddr (and adjusting
the sizes so the LOAD continues to cover the total data).
Or it shouldn't be screwing with the packing like that.
Philip Guenther
On Sat, Jan 7, 2023 at 11:04 AM Dave Voutila wrote:
> Bringing this to tech@ to increase my chance of someone testing my
> diff.
>
> As reported in this thread on misc@ [1], I believe newer Intel hardware
> may be experiencing issues hosting Linux guests under vmm/vmd. It looks
> like there are s
On Sun, Jan 8, 2023 at 8:50 AM Dave Voutila wrote:
> Now that guenther@ landed thread names, this should help users
> understand vmd host cpu utilization better as it lets us distinguish
> between the libevent thread and the vcpu thread.
>
> Example ps output:
>
> $ ps -A
On Sat, Dec 31, 2022 at 3:41 PM Crystal Kolipe
wrote:
> The KASSERT macro is a NOP unless DIAGNOSTIC is defined, so it doesn't
> need to
> be in an #ifdef here:
>
ok guenther@
Note: you should hold this diff until 2023 in Calgary and then commit, so
you can start 2023 with a
On Thu, Dec 22, 2022 at 12:04 PM Jason McIntyre wrote:
> On Thu, Dec 22, 2022 at 11:49:09AM -0800, Philip Guenther wrote:
> > On Thu, Dec 22, 2022 at 11:33 AM Jason McIntyre
> wrote:
> > ...
> >
> > > i have to say, i'm getting nowhere with this SYNOPSIS:
On Thu, Dec 22, 2022 at 11:33 AM Jason McIntyre wrote:
...
> i have to say, i'm getting nowhere with this SYNOPSIS:
>
> netstat -r [-AFu] [-f address_family] [-M core] [-N system]
> [-p protocol] [-T rtable]
>
> i mean the combination of -r and -p. is it wholly redundant
On Fri, Dec 2, 2022 at 3:17 PM Jeremie Courreges-Anglas
wrote:
>
> WEAK_REFERENCE seems to come from FreeBSD, it's not used in our tree.
> (WEAK_ALIAS is defined a few lines above).
>
> ok?
>
ok guenther@
Took a couple tries due to my farting around (and not wanting to leave the
power-sucking hppa running when I couldn't monitor progress) but it
completed a make kernel, make build, make release cycle with reboots.
Ship it?
Philip Guenther
On Sat, Dec 3, 2022 at 9:26 PM Philip Guenther
lting bsd.rd upgrade).
>
> GENERIC.MP testing is the missing piece before this is ready to
> commit.
>
Have rebooted to a kernel with this and now building userland (w/-j3) on a
(2 cpu) J6700.
Both cpus are showing about as busy as usual in 'top'. Will report back
when it either completes, fails, or blows up.
Philip Guenther
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
On Thu, Dec 1, 2022 at 10:31 AM Vitaliy Makkoveev wrote:
...
> --- sys/sys/sysctl.h7 Nov 2022 14:25:44 - 1.231
> +++ sys/sys/sysctl.h1 Dec 2022 18:15:06 -
> @@ -587,7 +587,7 @@ struct kinfo_vmentry {
>
> #define_FILL_KPROC_MIN(a,b) (((a)<(b))?(a):(b))
>
> -#define F
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
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.
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
}
>
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
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@
On Sat, Aug 27, 2022 at 6:41 PM Jonathan Gray wrote:
> directly use ansi volatile keyword not __volatile__ builtin
>
Yes, please. ok guenther@
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@
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
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
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 Sun, Jul 10, 2022 at 1:08 PM Scott Cheloha
wrote:
> ok?
>
> Index: echo.c
> ===
> RCS file: /cvs/src/bin/echo/echo.c,v
> retrieving revision 1.10
> diff -u -p -r1.10 echo.c
> --- echo.c 9 Oct 2015 01:37:06 - 1.10
>
On Mon, 13 Jun 2022, Theo de Raadt wrote:
> Scott Cheloha wrote:
> > > Am I wrong that kbind is never called twice in the same address space?
> >
> > Isn't this exactly what happened the last time we tried this?
>
> Tried what? kbind has never been NOLOCK.
Scott's referring to rev 1.237 of kern_
(u & 0x00ff) == 0 ||
(u & 0xff00) == 0 ||
(u & 0x000000ff) == 0)
break;
count++;
}
printf("%08x\t%ld\n", u, count);
return 0;
}
: bleys; cc f.c
: bleys; ./a.out
00b82e5c58
ab47880036
: bleys;
Philip Guenther
anwhile, you talk about getting
only just enough random data as if there's some sort of limited supply
when there isn't.
"My version may be wrong, but at least it doesn't look naive!"
That is utterly the wrong attitude for OpenBSD code.
Best wishes.
Philip Guenther
others are low.
Luke's implementation does not correctly implement the API. Doesn't
matter if it's a million times faster when it doesn't deliver the goal.
Philip Guenther
On Sat, 14 May 2022, Philip Guenther wrote:
> On Sat, 14 May 2022, Theo de Raadt wrote:
> > I worry a little about having libc use an undocumented mmap(2) flag.
> > About as much as using mquery, which is non-standard.
> >
> > Maybe __MAP_NOREPLACE should get document
On Sat, 14 May 2022, Theo de Raadt wrote:
> I worry a little about having libc use an undocumented mmap(2) flag.
> About as much as using mquery, which is non-standard.
>
> Maybe __MAP_NOREPLACE should get documentation? __MAP_NOFAULT is in the
> same situation. The behaviour of these flags shou
If you try to grow a 'large' (at least half a page) allocation with
realloc(3), it'll try to extend the memory mapping for it and if that
works it won't need to move it.
Currently, it does that by using mquery(2) to see if that area is
available and if so then trying to mmap it, munmaping it if
fseek(3) is implemented by just calling fseeko(3), the POSIX addition
version that takes an off_t instead of a long:
int
fseek(FILE *fp, long offset, int whence)
{
return (fseeko(fp, offset, whence));
}
...so there's no reason for libc to be using fseek() internally, as that
just loses
I suspect most people dig into that only
after time spent on more portable (and frankly, usable) levels. Not
knowing what your interests and energy are in, I can give no specific
recommendation.
Philip Guenther
On Mon, Mar 14, 2022 at 12:47 AM Visa Hankala wrote:
> On Sun, Mar 13, 2022 at 06:26:19PM -0700, Philip Guenther wrote:
> > On Sun, Mar 13, 2022 at 10:27 AM Visa Hankala wrote:
> >
> > > On Sun, Mar 13, 2022 at 04:29:44PM +0100, Mark Kettenis wrote:
> > &g
sibly not seeing
the update to w->w_var even _before_ the refcnt_rele(), so putting a membar
in refcnt_rele() hides the incorrect code by suppressing the later crash!
If these membars appear to help then the code is and remains broken. This
change should not be done.
Philip Guenther
three times ioctl(SIOCBRDGRTS) is used
on each interface. This will drop it to twice per interface ;)
ok guenther@
On Sun, Feb 13, 2022 at 11:29 PM Philip Guenther wrote:
> On Sun, Feb 13, 2022 at 11:18 PM Mark Kettenis
> wrote:
>
>> > From: Greg Steuck
>> > Date: Sun, 13 Feb 2022 22:37:13 -0800
>> >
>> > To give a sense of the kind of change required to get
On Sun, Feb 13, 2022 at 11:18 PM Mark Kettenis
wrote:
> > From: Greg Steuck
> > Date: Sun, 13 Feb 2022 22:37:13 -0800
> >
> > To give a sense of the kind of change required to get the feature I
> > want, see the patch at the end. The change in DriverUtils.cpp is just to
> > show that the same fu
use of 125 documented?
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
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 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
.
>
> OK?
>
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@
On Sun, Jan 16, 2022 at 1:51 PM Christian Weisgerber
wrote:
> usr.sbin/eigrpd: fix -Wunused-but-set-variable warning
>
ok guenther@
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 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
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
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
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
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
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
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@
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
, 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
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@
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
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 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 -
> > &
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
@@ -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
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
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.)
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
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
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
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)
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 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_
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, 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 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'
les:
usr.bin/netstat/inet.c
usr.bin/fstat/fstat.c
usr.bin/fstat/fuser.c
usr.bin/systat/netstat.c
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
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 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.
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
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
d relying on that, which is easy in this case by just casting to
"char *" instead.
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
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
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
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
) 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
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
dy do it for AES stuff in the kernel, for
example. c.f. /usr/src/sys/arch/amd64/amd64/aesni.c
Philip Guenther
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/{,
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, 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 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 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
1 - 100 of 1085 matches
Mail list logo
