On Sat, Sep 16, 2023 at 9:47 AM Ingo Schwarze wrote:
> Janne Johansson wrote on Sat, Sep 16, 2023 at 11:49:10AM +0200:
>
> > In case someone wants the change in a diff format, those 5 seconds
> > of work are available here:
> > http://c66.it.su.se:8080/obsd/unveil.2.diff
>
> How come jj@ forgot
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
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
ng 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
On Wed, May 10, 2023 at 1:29 PM Alexander Bluhm
wrote:
> We use Perl syscall(2) function to implement sysctl(2) system calls.
> This is broken since OpenBSD 7.3. A sample program looks like this:
>
...
> kdump shows two problems:
> 1. The mib is not printed correctly.
> 2. The final argument
: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
erface, 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
ep 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
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 -AHf | grep vmd
> 30584
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 perfect "negative
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
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 wrote
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 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
I mean, shouldn't that line just (with const) be:
const struct sparc_insn *i_ptr = sparc_i;/* or _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.
>
> This diff
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.
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@
On Sun, Aug 28, 2022 at 2:11 PM Anders Andersson wrote:
> On Sun, Aug 28, 2022 at 3:15 PM Jonathan Gray wrote:
> >
> > diff --git lib/libc/locale/wctoint.h lib/libc/locale/wctoint.h
> > index ea50c5ae1b6..14c7f0c466d 100644
> > --- lib/libc/locale/wctoint.h
> > +++ lib/libc/locale/wctoint.h
> >
the 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
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
(u & 0xff00) == 0 ||
(u & 0x00ff) == 0)
break;
count++;
}
printf("%08x\t%ld\n", u, count);
return 0;
}
: bleys; cc f.c
: bleys; ./a.out
00b82e5c58
ab47880036
: bleys;
Philip Guenther
le, 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
ot 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 do
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
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
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
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
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
On Mon, Feb 21, 2022 at 9:47 PM David Gwynne wrote:
> this lets ifconfig show the MTU on interfaces like nvgre, vxlan, etc.
> they currently don't show it because they also implement a bridge ioctl,
> so ifconfig thinks they're a bridge.
>
> why ifconfig hides the mtu on bridges looks to be a
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
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
5 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
(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
On Sun, Jan 16, 2022 at 8:10 AM Christian Weisgerber
wrote:
> usr.bin/mg: fix -Wunused-but-set-variable warnings
>
> * strtonum() is only called to verify that a string is numerical, the
> return value is unused.
> * inlist is no longer used after the code was refactored.
>
> OK?
>
ok
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
On Sat, Jan 15, 2022 at 12:36 PM Christian Weisgerber
wrote:
> sbin/isakmpd: fix -Wunused-but-set-variable warnings
>
> The one in pf_key_v2.c could use an extra set of eyes, but I don't
> think there are any side effects.
>
The involved variables in pf_key_v2.c were added in 2000 as part of
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
gt; 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
ssumes 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: line.c
===
On Fri, Dec 31, 2021 at 7:44 AM Christian Ehrhardt
wrote:
> Here at genua, trying to build libpcap sometimes breaks in
> libpcap with the following error message:
>
> | Using $< in a non-suffix rule context is a GNUmake idiom \
> |(/data/git/ehrhardt/genuos/os/mk/bsd.dep.mk:47)
>
> The bug
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
, 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
Subject
On Mon, Dec 6, 2021 at 10:30 AM Scott Cheloha
wrote:
> In the moncontrol(3) code we have this fallback function, hertz().
> The idea is to use an undocumented side effect of setitimer(2) to
> determine the width of the hardclock(9) tick.
>
> hertz() has a number of problems:
>
> So, I want to
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
syntax with 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 expression is ef
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
*/
> 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
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 chdir
> i
On Mon, May 24, 2021 at 4:59 AM Klemens Nanni wrote:
> When tinkering with ld.so crashes due to file corruption the other day
> I tested a few changes but did not want to replace /usr/libexec/ld.so
> and since recompiling executable to change their interpreter is not
> always an option, I went
AD/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
; it's the lock-less accesses where the compiler can
pull a rabbit from its hat and stab you with it.
Philip Guenther
inst 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) f
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 Guenther
On Sun, Apr 18, 2021 at 7:02
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
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_flag, P_WEXIT);
> single_thread_check(p, 0); // directly or via single_thread_set()
> SMR_TAILQ_REMOVE_LOCKED(>ps_threads, p,
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 its FILE locke
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
n/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
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
inated in (large) part from what Kahan did
with Intel, see
https://people.eecs.berkeley.edu/~wkahan/ieee754status/754story.html
I'm not nearly enough of a numerical analyst to judge the decision of the
standard.
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
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
relying on that, which is easy in this case by just casting to
"char *" instead.
Philip Guenther
On Mon, Oct 26, 2020 at 8:35 AM Matthew Martin wrote:
> Recently cclasses in lib/libc/gen/charclass.h was made const.[1]
> Mark the pointer used to walk the array in ksh const as well.
>
> 1: https://marc.info/?l=openbsd-cvs=160256416506433=2
>
Ugh, I totally missed that reach-around.
ok
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
_p->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
efore 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
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
S 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
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
> +++
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
On Fri, 3 Apr 2020, Martin Pieuchot wrote:
> Thanks, here it is, ok?
ok guenther@
ut it currently blows up on the FD_ZERO() and would blow up in the
EV_SET() with your proposed diff.
Philip Guenther
1 - 100 of 983 matches
Mail list logo
