On Fri, 2022-01-07 at 15:00 -0600, Scott Cheloha wrote:
> On Fri, Jan 07, 2022 at 01:43:24PM -0600, Scott Cheloha wrote:
> >
> > [...]
> >
> > Like this?
> >
> > [...]
>
> Updated: make the for-loop update expressions match.
>
Why not go for the following diff?
It has a comparable speed increa
> As the kernel currently contains (at least) 1946 pointers leak by using
> printf(9) and %p, it might be more efficient to scramble %p with a
> static value (randomly assigned at boot time).
Oh come on. That proposal has no security property!
Over time we need to delete all such printf's, and l
On Fri, Jan 07, 2022 at 12:25:25PM -0700, Theo de Raadt wrote:
> > I agree, but the intent is replacing a debugging method with another
> > debugging method (hoping it is more useful). The messages showed here
> > are the same that the ones which would be shown on the console before
> > the diff.
>
This adds attribute `sdhc' to sys/conf/files so that non-glue code,
such as mvpxa(4), can indicate the sdhc dependency.
OK?
Index: arch/armv7/marvell/files.marvell
===
RCS file: src/sys/arch/armv7/marvell/files.marvell,v
retrieving r
On Fri, 07 Jan 2022 15:00:52 -0600, Scott Cheloha wrote:
> Updated: make the for-loop update expressions match.
Looks good to me. OK millert@
- todd
On Fri, Jan 07, 2022 at 01:43:24PM -0600, Scott Cheloha wrote:
>
> [...]
>
> Like this?
>
> [...]
Updated: make the for-loop update expressions match.
Index: rev.c
===
RCS file: /cvs/src/usr.bin/rev/rev.c,v
retrieving revision 1.13
On 07/01/22(Fri) 10:54, Sebastien Marie wrote:
> Hi,
>
> Debugging some code paths is complex: for example, unveil(2) code is
> involved inside VFS, and using DEBUG_UNVEIL means that the kernel is
> spamming printf() for all processes using unveil(2) (a lot of
> processes) instead of just the inte
On Fri, Jan 07, 2022 at 07:28:30PM +0100, Ingo Schwarze wrote:
>
> [...]
>
> Scott Cheloha wrote on Fri, Jan 07, 2022 at 09:45:41AM -0600:
>
> > In rev(1), we call MB_CUR_MAX for every byte in the input stream.
> > This is extremely expensive.
>
> [...]
>
> So i agree with jour general idea to
> I agree, but the intent is replacing a debugging method with another
> debugging method (hoping it is more useful). The messages showed here
> are the same that the ones which would be shown on the console before
> the diff.
the thing about the kernel messages, is you see the pointers and you
kn
Hi Scott,
thank you for spending quite some work on our small utility programs,
and sorry for failing to follow up as often as i should.
Scott Cheloha wrote on Fri, Jan 07, 2022 at 09:45:41AM -0600:
> In rev(1), we call MB_CUR_MAX for every byte in the input stream.
> This is extremely expensive
On Fri, 07 Jan 2022 09:29:01 -0800, Greg Steuck wrote:
> Ah, so it's our ksh after all. Unless there's a good reason for it to be
> different, should we change it to match the rest of the pack behavior?
Probably, it is just not the nicest code base to play with ;-)
- todd
"Todd C. Miller" writes:
> On Fri, 07 Jan 2022 00:45:47 -0800, Philip Guenther wrote:
>
>> 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 SI
Why not just store the result of MB_CUR_MAX in a variable and use
that? It's value is not going to change during execution of the
program. This made a big difference in sort(1) once upon a time.
- todd
On Fri, 07 Jan 2022 00:45:47 -0800, Philip Guenther wrote:
> 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.
To add to this, the shell
> If this gets added, more care is needed with the messages. For example,
> kernel memory addresses should not be shown because they are privileged
> information.
No kidding. We spent a decade cleaning that up, and don't want to go back
to exposing.
In rev(1), we call MB_CUR_MAX for every byte in the input stream.
This is extremely expensive.
It is much cheaper to call it once per line and use a simpler loop
(see the inlined patch below) if the current locale doesn't handle
multibyte characters:
# -current rev(1),
$ for i in $(jot 10); do na
On Fri, Jan 07, 2022 at 11:06:30AM +, Visa Hankala wrote:
> On Fri, Jan 07, 2022 at 10:54:54AM +0100, Sebastien Marie wrote:
> > Debugging some code paths is complex: for example, unveil(2) code is
> > involved inside VFS, and using DEBUG_UNVEIL means that the kernel is
> > spamming printf() fo
On Fri, Jan 07, 2022 at 10:54:54AM +0100, Sebastien Marie wrote:
> Debugging some code paths is complex: for example, unveil(2) code is
> involved inside VFS, and using DEBUG_UNVEIL means that the kernel is
> spamming printf() for all processes using unveil(2) (a lot of
> processes) instead of just
Hi,
Debugging some code paths is complex: for example, unveil(2) code is
involved inside VFS, and using DEBUG_UNVEIL means that the kernel is
spamming printf() for all processes using unveil(2) (a lot of
processes) instead of just the interested cases I want to follow.
So I cooked the following d
On Thu, Jan 6, 2022 at 10:47 PM Greg Steuck wrote:
> I started by debugging a weird test failure in ghc. I narrowed it
> down to a simple C program which behaves differently between OpenBSD and
> FreeBSD. I stared at the headers of both systems for a bit and still
> don't see why on OpenBSD the p
20 matches
Mail list logo
