Re: Numeric config variables
wrote: > I think I am missing some basic bit of configuration lore. > > I hacked my kernel to change the font size selected by rasops, but I > would like to make a proper configuration interface for it, something > like an integer that biased the default size calculation. > > It would be nice to be able to use /etc/wsconsctl.conf to set it, but > screens can't be reconfigured after they are created (I want to fix > that in the future), and it would be better to have it take effect on > console startup, well before anything else gets loaded. > > It feels like what I want is an integer variable that can be set to a > default in the kernel config file, then modified on an existing kernel > with config(8), or temporarily overridden with a parameter from > boot(8). > > I see how I can make a numeric option in the config file, but it just > turns into a #define that can't be modified. > > Is there any facility like this? Yes, there is. boot -c can change kernel configuration datastructures (including attach flags), and config -e /bsd can do this to a kernel on a permanent basis. However, it was originally intended just for development purposes, and not really for users to directly use. With the advent of KARL, config -e becomes incompatible with /bsd modification. If the binary is modified, the hash is wrong, and a new kernel binary isn't randomly link at each boot. I don't like generic reuse of this. You also mention passing arguments to the kernel. Unfortunately the parameterization from boot to kernel varies greatly between architectures, so doing something nice there will be difficult. Furthermore, many architectures don't have a /etc/boot.conf mechanism, either... So nothing ideal for what you want.
Numeric config variables
I think I am missing some basic bit of configuration lore. I hacked my kernel to change the font size selected by rasops, but I would like to make a proper configuration interface for it, something like an integer that biased the default size calculation. It would be nice to be able to use /etc/wsconsctl.conf to set it, but screens can't be reconfigured after they are created (I want to fix that in the future), and it would be better to have it take effect on console startup, well before anything else gets loaded. It feels like what I want is an integer variable that can be set to a default in the kernel config file, then modified on an existing kernel with config(8), or temporarily overridden with a parameter from boot(8). I see how I can make a numeric option in the config file, but it just turns into a #define that can't be modified. Is there any facility like this?
Re: cpu_rnd_messybits() for arm64
> It's a 64-bit counter, which we reduce to 32 bits. Since there is > progressively less entropy in the higher bits of a counter than in > the lower bits, it intuitively makes sense not just to do hi^lo, > but to bit-reverse one half in order to extract maximal entropy, > and on aarch64 bit reversal is a simple instruction. That doesn't matter at all. First of all, this is +='d to multiple rounds in the ring which never clean. Then a crc is run over it ^= over old contents. Then at some timeout it does a sha256 and ^= it again, leaving that in a buffer, which a different timeout merges into the chacha state, yes you guess right some more ^=. But if it makes you feel better :)
Re: cpu_rnd_messybits() for arm64
ok deraadt
Christian Weisgerber wrote:
> Mark Kettenis:
>
> > > Here is a cpu_rnd_messybits() implementation for arm64.
> > > It reads the virtual counter and xors it with a bit-reversed copy
> > > of itself.
> > >
> > > The virtual counter is used by the only timecounter implementation
> > > used on arm64, so I assume it is generally available.
> > >
> > > It's a 64-bit counter, which we reduce to 32 bits. Since there is
> > > progressively less entropy in the higher bits of a counter than in
> > > the lower bits, it intuitively makes sense not just to do hi^lo,
> > > but to bit-reverse one half in order to extract maximal entropy,
> > > and on aarch64 bit reversal is a simple instruction.
> >
> > Can you make that uint64_t?
> > Can you use %0 and %1 instead of %x0 and %x1?
>
> Right.
>
> Index: arch/arm64/arm64/machdep.c
> ===
> RCS file: /cvs/src/sys/arch/arm64/arm64/machdep.c,v
> retrieving revision 1.52
> diff -u -p -r1.52 machdep.c
> --- arch/arm64/arm64/machdep.c31 May 2020 06:23:57 - 1.52
> +++ arch/arm64/arm64/machdep.c5 Jun 2020 20:00:20 -
> @@ -1247,12 +1247,3 @@ dumpregs(struct trapframe *frame)
> printf("pc: 0x%016lx\n", frame->tf_elr);
> printf("spsr: 0x%016lx\n", frame->tf_spsr);
> }
> -
> -unsigned int
> -cpu_rnd_messybits(void)
> -{
> - struct timespec ts;
> -
> - nanotime();
> - return (ts.tv_nsec ^ (ts.tv_sec << 20));
> -}
> Index: arch/arm64/include/cpu.h
> ===
> RCS file: /cvs/src/sys/arch/arm64/include/cpu.h,v
> retrieving revision 1.17
> diff -u -p -r1.17 cpu.h
> --- arch/arm64/include/cpu.h 31 May 2020 06:23:57 - 1.17
> +++ arch/arm64/include/cpu.h 5 Jun 2020 22:13:07 -
> @@ -183,7 +183,16 @@ void cpu_boot_secondary_processors(void)
>
> #define curpcb curcpu()->ci_curpcb
>
> -unsigned int cpu_rnd_messybits(void);
> +static inline unsigned int
> +cpu_rnd_messybits(void)
> +{
> + uint64_t val, rval;
> +
> + __asm volatile("mrs %0, CNTVCT_EL0; rbit %1, %0;"
> + : "=r" (val), "=r" (rval));
> +
> + return (val ^ rval);
> +}
>
> /*
> * Scheduling glue
> --
> Christian "naddy" Weisgerber na...@mips.inka.de
>
Re: cpu_rnd_messybits() for arm64
> Date: Sat, 6 Jun 2020 00:30:51 +0200
> From: Christian Weisgerber
> Cc: tech@openbsd.org
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
>
> Mark Kettenis:
>
> > > Here is a cpu_rnd_messybits() implementation for arm64.
> > > It reads the virtual counter and xors it with a bit-reversed copy
> > > of itself.
> > >
> > > The virtual counter is used by the only timecounter implementation
> > > used on arm64, so I assume it is generally available.
> > >
> > > It's a 64-bit counter, which we reduce to 32 bits. Since there is
> > > progressively less entropy in the higher bits of a counter than in
> > > the lower bits, it intuitively makes sense not just to do hi^lo,
> > > but to bit-reverse one half in order to extract maximal entropy,
> > > and on aarch64 bit reversal is a simple instruction.
> >
> > Can you make that uint64_t?
> > Can you use %0 and %1 instead of %x0 and %x1?
>
> Right.
ok kettenis@
> Index: arch/arm64/arm64/machdep.c
> ===
> RCS file: /cvs/src/sys/arch/arm64/arm64/machdep.c,v
> retrieving revision 1.52
> diff -u -p -r1.52 machdep.c
> --- arch/arm64/arm64/machdep.c31 May 2020 06:23:57 - 1.52
> +++ arch/arm64/arm64/machdep.c5 Jun 2020 20:00:20 -
> @@ -1247,12 +1247,3 @@ dumpregs(struct trapframe *frame)
> printf("pc: 0x%016lx\n", frame->tf_elr);
> printf("spsr: 0x%016lx\n", frame->tf_spsr);
> }
> -
> -unsigned int
> -cpu_rnd_messybits(void)
> -{
> - struct timespec ts;
> -
> - nanotime();
> - return (ts.tv_nsec ^ (ts.tv_sec << 20));
> -}
> Index: arch/arm64/include/cpu.h
> ===
> RCS file: /cvs/src/sys/arch/arm64/include/cpu.h,v
> retrieving revision 1.17
> diff -u -p -r1.17 cpu.h
> --- arch/arm64/include/cpu.h 31 May 2020 06:23:57 - 1.17
> +++ arch/arm64/include/cpu.h 5 Jun 2020 22:13:07 -
> @@ -183,7 +183,16 @@ void cpu_boot_secondary_processors(void)
>
> #define curpcb curcpu()->ci_curpcb
>
> -unsigned int cpu_rnd_messybits(void);
> +static inline unsigned int
> +cpu_rnd_messybits(void)
> +{
> + uint64_t val, rval;
> +
> + __asm volatile("mrs %0, CNTVCT_EL0; rbit %1, %0;"
> + : "=r" (val), "=r" (rval));
> +
> + return (val ^ rval);
> +}
>
> /*
> * Scheduling glue
> --
> Christian "naddy" Weisgerber na...@mips.inka.de
>
Re: cpu_rnd_messybits() for arm64
Mark Kettenis:
> > Here is a cpu_rnd_messybits() implementation for arm64.
> > It reads the virtual counter and xors it with a bit-reversed copy
> > of itself.
> >
> > The virtual counter is used by the only timecounter implementation
> > used on arm64, so I assume it is generally available.
> >
> > It's a 64-bit counter, which we reduce to 32 bits. Since there is
> > progressively less entropy in the higher bits of a counter than in
> > the lower bits, it intuitively makes sense not just to do hi^lo,
> > but to bit-reverse one half in order to extract maximal entropy,
> > and on aarch64 bit reversal is a simple instruction.
>
> Can you make that uint64_t?
> Can you use %0 and %1 instead of %x0 and %x1?
Right.
Index: arch/arm64/arm64/machdep.c
===
RCS file: /cvs/src/sys/arch/arm64/arm64/machdep.c,v
retrieving revision 1.52
diff -u -p -r1.52 machdep.c
--- arch/arm64/arm64/machdep.c 31 May 2020 06:23:57 - 1.52
+++ arch/arm64/arm64/machdep.c 5 Jun 2020 20:00:20 -
@@ -1247,12 +1247,3 @@ dumpregs(struct trapframe *frame)
printf("pc: 0x%016lx\n", frame->tf_elr);
printf("spsr: 0x%016lx\n", frame->tf_spsr);
}
-
-unsigned int
-cpu_rnd_messybits(void)
-{
- struct timespec ts;
-
- nanotime();
- return (ts.tv_nsec ^ (ts.tv_sec << 20));
-}
Index: arch/arm64/include/cpu.h
===
RCS file: /cvs/src/sys/arch/arm64/include/cpu.h,v
retrieving revision 1.17
diff -u -p -r1.17 cpu.h
--- arch/arm64/include/cpu.h31 May 2020 06:23:57 - 1.17
+++ arch/arm64/include/cpu.h5 Jun 2020 22:13:07 -
@@ -183,7 +183,16 @@ void cpu_boot_secondary_processors(void)
#define curpcb curcpu()->ci_curpcb
-unsigned int cpu_rnd_messybits(void);
+static inline unsigned int
+cpu_rnd_messybits(void)
+{
+ uint64_t val, rval;
+
+ __asm volatile("mrs %0, CNTVCT_EL0; rbit %1, %0;"
+ : "=r" (val), "=r" (rval));
+
+ return (val ^ rval);
+}
/*
* Scheduling glue
--
Christian "naddy" Weisgerber na...@mips.inka.de
Re: cpu_rnd_messybits() for arm64
> Date: Fri, 5 Jun 2020 23:27:13 +0200
> From: Christian Weisgerber
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
>
> Here is a cpu_rnd_messybits() implementation for arm64.
> It reads the virtual counter and xors it with a bit-reversed copy
> of itself.
>
> The virtual counter is used by the only timecounter implementation
> used on arm64, so I assume it is generally available.
>
> It's a 64-bit counter, which we reduce to 32 bits. Since there is
> progressively less entropy in the higher bits of a counter than in
> the lower bits, it intuitively makes sense not just to do hi^lo,
> but to bit-reverse one half in order to extract maximal entropy,
> and on aarch64 bit reversal is a simple instruction.
>
> This patch I have tested!
>
> ok?
>
> Index: arch/arm64/arm64/machdep.c
> ===
> RCS file: /cvs/src/sys/arch/arm64/arm64/machdep.c,v
> retrieving revision 1.52
> diff -u -p -r1.52 machdep.c
> --- arch/arm64/arm64/machdep.c31 May 2020 06:23:57 - 1.52
> +++ arch/arm64/arm64/machdep.c5 Jun 2020 20:00:20 -
> @@ -1247,12 +1247,3 @@ dumpregs(struct trapframe *frame)
> printf("pc: 0x%016lx\n", frame->tf_elr);
> printf("spsr: 0x%016lx\n", frame->tf_spsr);
> }
> -
> -unsigned int
> -cpu_rnd_messybits(void)
> -{
> - struct timespec ts;
> -
> - nanotime();
> - return (ts.tv_nsec ^ (ts.tv_sec << 20));
> -}
> Index: arch/arm64/include/cpu.h
> ===
> RCS file: /cvs/src/sys/arch/arm64/include/cpu.h,v
> retrieving revision 1.17
> diff -u -p -r1.17 cpu.h
> --- arch/arm64/include/cpu.h 31 May 2020 06:23:57 - 1.17
> +++ arch/arm64/include/cpu.h 5 Jun 2020 20:32:01 -
> @@ -183,7 +183,16 @@ void cpu_boot_secondary_processors(void)
>
> #define curpcb curcpu()->ci_curpcb
>
> -unsigned int cpu_rnd_messybits(void);
> +static inline unsigned int
> +cpu_rnd_messybits(void)
> +{
> + u_int64_t val, rval;
Can you make that uint64_t?
> +
> + __asm volatile("mrs %x0, CNTVCT_EL0; rbit %x1, %x0;"
> + : "=r" (val), "=r" (rval));
Can you use %0 and %1 instead of %x0 and %x1?
> +
> + return (val ^ rval);
> +}
>
> /*
> * Scheduling glue
> --
> Christian "naddy" Weisgerber na...@mips.inka.de
>
>
cpu_rnd_messybits() for arm64
Here is a cpu_rnd_messybits() implementation for arm64.
It reads the virtual counter and xors it with a bit-reversed copy
of itself.
The virtual counter is used by the only timecounter implementation
used on arm64, so I assume it is generally available.
It's a 64-bit counter, which we reduce to 32 bits. Since there is
progressively less entropy in the higher bits of a counter than in
the lower bits, it intuitively makes sense not just to do hi^lo,
but to bit-reverse one half in order to extract maximal entropy,
and on aarch64 bit reversal is a simple instruction.
This patch I have tested!
ok?
Index: arch/arm64/arm64/machdep.c
===
RCS file: /cvs/src/sys/arch/arm64/arm64/machdep.c,v
retrieving revision 1.52
diff -u -p -r1.52 machdep.c
--- arch/arm64/arm64/machdep.c 31 May 2020 06:23:57 - 1.52
+++ arch/arm64/arm64/machdep.c 5 Jun 2020 20:00:20 -
@@ -1247,12 +1247,3 @@ dumpregs(struct trapframe *frame)
printf("pc: 0x%016lx\n", frame->tf_elr);
printf("spsr: 0x%016lx\n", frame->tf_spsr);
}
-
-unsigned int
-cpu_rnd_messybits(void)
-{
- struct timespec ts;
-
- nanotime();
- return (ts.tv_nsec ^ (ts.tv_sec << 20));
-}
Index: arch/arm64/include/cpu.h
===
RCS file: /cvs/src/sys/arch/arm64/include/cpu.h,v
retrieving revision 1.17
diff -u -p -r1.17 cpu.h
--- arch/arm64/include/cpu.h31 May 2020 06:23:57 - 1.17
+++ arch/arm64/include/cpu.h5 Jun 2020 20:32:01 -
@@ -183,7 +183,16 @@ void cpu_boot_secondary_processors(void)
#define curpcb curcpu()->ci_curpcb
-unsigned int cpu_rnd_messybits(void);
+static inline unsigned int
+cpu_rnd_messybits(void)
+{
+ u_int64_t val, rval;
+
+ __asm volatile("mrs %x0, CNTVCT_EL0; rbit %x1, %x0;"
+ : "=r" (val), "=r" (rval));
+
+ return (val ^ rval);
+}
/*
* Scheduling glue
--
Christian "naddy" Weisgerber na...@mips.inka.de
Re: mountd: Remove dead *netent(3) code
On Sun, May 24, 2020 at 03:17:31PM +0200, Klemens Nanni wrote:
> schwarze neutered the *netent(3) family as well as networks(5) in 2018,
> mountd(8) remains the only user of these functions in base.
>
> setnetent() and endnetent() are empty functions now, getnetent() always
> returns NULL unconditionally so the while loop is never entered, the
> entire if block is code that does nothing and inetaddr2 eventually
> becomes unused alltogether.
>
> See lib/libc/net/getnetent.c or getnetent(3).
>
> get_net()'s maskflg parameter is still used, so nothing to be removed
> there.
>
> Feedback? OK?
Ping.
Index: mountd.c
===
RCS file: /cvs/src/sbin/mountd/mountd.c,v
retrieving revision 1.88
diff -u -p -r1.88 mountd.c
--- mountd.c24 Jan 2020 18:51:45 - 1.88
+++ mountd.c5 Jun 2020 21:05:06 -
@@ -2052,29 +2052,13 @@ do_mount(struct exportlist *ep, struct g
int
get_net(char *cp, struct netmsk *net, int maskflg)
{
- struct in_addr inetaddr, inetaddr2;
+ struct in_addr inetaddr;
in_addr_t netaddr;
struct netent *np;
char *name;
if ((netaddr = inet_network(cp)) != INADDR_NONE) {
inetaddr = inet_makeaddr(netaddr, 0);
- /*
-* Due to arbitrary subnet masks, you don't know how many
-* bits to shift the address to make it into a network,
-* however you do know how to make a network address into
-* a host with host == 0 and then compare them.
-* (What a pest)
-*/
- if (!maskflg) {
- setnetent(0);
- while ((np = getnetent())) {
- inetaddr2 = inet_makeaddr(np->n_net, 0);
- if (inetaddr2.s_addr == inetaddr.s_addr)
- break;
- }
- endnetent();
- }
} else {
if ((np = getnetbyname(cp)))
inetaddr = inet_makeaddr(np->n_net, 0);
Re: BIOCINSTALLBOOT/sparc64 installboot: EFBIG on too big boot loaders
On Mon, Jun 01, 2020 at 11:48:05PM +0200, Klemens Nanni wrote:
> Installing an unstripped boot loader on softraid on sparc64 fails
> without proper error message.
>
> Make BIOCINSTALLBOOT return a proper errno, make installboot(8) use it
> to provide proper usage errors plus unique code paths for debugging.
>
> At first, I made sr_ioctl_installboot() use sr_error() in the relevant
> spot and this made the kernel print my errors, however the following
> piece in softraid.c:sr_bio_handler() means using sr_error() will hide
> the error code from the ioctl(2) call, i.e. installboot(8) would
> report no error message on stderr and exit zero:
>
> if (sc->sc_status.bs_msg_count > 0)
> rv = 0;
>
> So instead, use a proper errno that yields a simple
>
> # ./obj/installboot sd2 /usr/mdec/bootblk /ofwboot.new
> installboot.sr: softraid installboot failed: File too large
>
>
>
> Background: I built ofwboot on one machine ("make" without
> "make install", then copy obj/ofwboot over), the resulting executable
> was not stripped during build (happens during "make install") and was
> about twice as big:
>
> # ls -l /ofwboot*
> -rw-r--r-- 1 root wheel 106688 May 23 22:42 /ofwboot
> -rwxr-xr-x 1 knwheel 272452 May 24 00:20 /ofwboot.new
> -rwxr-xr-x 1 root wheel 106752 May 24 01:21 /ofwboot.new.strip
>
> It took me longer than anticipated to find out that installboot(8)
> fails beause my new boot loader was too big:
>
> # installboot sd2 /usr/mdec/bootblk /ofwboot.new
> installboot: softraid installboot failed
>
> # installboot -v sd2 /usr/mdec/bootblk /ofwboot.new
> Using / as root
> installing bootstrap on /dev/rsd2c
> using first-stage /usr/mdec/bootblk, second-stage /ofwboot.new
> boot block is 6882 bytes (14 blocks @ 512 bytes = 7168 bytes)
> sd2: softraid volume with 1 disk(s)
> sd2: installing boot loader on softraid volume
> installboot: softraid installboot failed
>
> That's it, no details or additional messages from the kernel.
> While this was primarily my own fault, perhaps there are more legitimate
> reasons foor bootblk/ofwboot builds to exceed their maximum size.
In a i386 VM with root on crypto softraid, I built a much bigger second
stage boot loader and performed the same tests as on sparc64: i386 does
not try to install the bogus boot code due to checks in i386_softraid.c
up front:
# ls -l /usr/mdec/boot /boot.efbig
-r-xr-xr-x 1 root bin 89728 Jun 5 03:02 /usr/mdec/boot
-rwxr-xr-x 1 root wheel 176172 Jun 5 22:16 /boot.efbig
# installboot -v sd1 /usr/mdec/biosboot /boot.efbig
Using / as root
installing bootstrap on /dev/rsd1c
using first-stage /usr/mdec/biosboot, second-stage /boot.efbig
sd1: softraid volume with 1 disk(s)
installboot: boot code will not fit
So for installboot(8) on sparc64 and i386 as the only two users of
BIOCINSTALLBOOT, this makes root on softraid on sparc64 the only use
that actually hits size checks in the ioctl code.
sr_ioctl_installboot() seems inconsistent to me in how it reports some
errors through sr_error() (causing ioctl() to return zero) and returing
proper error codes (causing ioctl() and therefore installboot to fail);
Assuming my EFBIG approach is still sensible (for sparc64), diff below
adjusts the errx() call to err() in installboot for both platforms, even
though i386 never reaches it.
Feedback? OK?
Index: sys/dev/softraid.c
===
RCS file: /cvs/src/sys/dev/softraid.c,v
retrieving revision 1.401
diff -u -p -r1.401 softraid.c
--- sys/dev/softraid.c 14 Apr 2020 07:38:21 - 1.401
+++ sys/dev/softraid.c 5 Jun 2020 20:41:20 -
@@ -3704,11 +3704,11 @@ sr_ioctl_installboot(struct sr_softc *sc
goto done;
}
- if (bb->bb_bootblk_size > SR_BOOT_BLOCKS_SIZE * DEV_BSIZE)
- goto done;
-
- if (bb->bb_bootldr_size > SR_BOOT_LOADER_SIZE * DEV_BSIZE)
+ if (bb->bb_bootblk_size > SR_BOOT_BLOCKS_SIZE * DEV_BSIZE ||
+ bb->bb_bootldr_size > SR_BOOT_LOADER_SIZE * DEV_BSIZE) {
+ rv = EFBIG;
goto done;
+ }
secsize = sd->sd_meta->ssdi.ssd_secsize;
Index: usr.sbin/installboot/i386_softraid.c
===
RCS file: /cvs/src/usr.sbin/installboot/i386_softraid.c,v
retrieving revision 1.15
diff -u -p -r1.15 i386_softraid.c
--- usr.sbin/installboot/i386_softraid.c9 Mar 2020 06:16:56 -
1.15
+++ usr.sbin/installboot/i386_softraid.c5 Jun 2020 20:39:54 -
@@ -177,7 +177,7 @@ sr_install_bootldr(int devfd, char *dev)
fprintf(stderr, "%s: installing boot loader on "
"softraid volume\n", dev);
if (ioctl(devfd,
Re: userland clock_gettime proof of concept
On 05.06.2020 20:25, Mark Kettenis wrote:
Date: Fri, 5 Jun 2020 01:33:16 +0300
From: Paul Irofti
On Wed, Jun 03, 2020 at 05:13:42PM +0300, Paul Irofti wrote:
On 2020-05-31 20:46, Mark Kettenis wrote:
Forget about all that for a moment. Here is an alternative suggestion:
On sparc64 we need to support both tick_timecounter and
sys_tick_timecounter. So we need some sort of clockid value to
distnguish between those two. I already suggested to use the tc_user
field of the timecounter for that. 0 means that a timecounter is not
usable in userland, a (small) positive integer means a specific
timecounter type. The code in libc will need to know whether a
particular timecounter type can be supported. My proposal would be to
implement a function*on all architecture* that takes the clockid as
an argument and returns a pointer to the function that implements
support for that timecounter. On architectures without support, ir
when called with a clockid that isn't supported, that function would
simply return NULL.
I am sorry, but the more I try to implement this in a sane way, the more
obvious it is that it is not possible. I would rather have a define sausage
than something like this.
I will try to think of something else that avoids the defines, but I do not
think that your proposal is a valid solution.
OK. I think I found an elegant way around this using the Makefile
system: if usertc.c is not present in the arch/${MACHINE}/gen, then a
stub gen/usertc.c file is built that just sets the function pointer to
NULL. This avoids the need for the define checks in dlfcn/init.c and I
think fixes the rest of the issues discussed around this bit.
Also included in the diff are a few other fixes and regression tests.
I left the rdtsc and acpihpet example (with no functional acpihpet
support) just to show-case how we can handle multiple clocks on
architectures that have them.
You're still using tk_user unconditionally. If the kernel returns a
tk_user value that is larger than what's supported by libc you have an
out-of-bounds array access.
Also if the machine switches to a timecounter that has tk_user == 0
you have an out-of-bounds array access. If that happens you need to
detect this and fall back on the system call.
Right. Even though we test in the beginning for tk_user=0 it might
change until the access to tc_get_timecount(). I will fix this in my
next diff. Thanks!
Re: userland clock_gettime proof of concept
> > Is the Makefile approach good enough? > > Not sure. Others should judge that. I don't know why the complexity of Makefile hackery is needed. Give all the other architectures a MD file. Some contain code and array handling, others contain fewer lines of code marking it NULL. And that would be the end of the story. Why do you need a .if !exists point at a different file, confusing all of it. Is cp(1) of a file with 1 line of code some deep-seated attack on OOP or something? Is there going to be a bug found in this years from now, and all of them will get fixed except someone will forget to fix the powerpc file leading to a massive security hole? This type of complexity is *WORSE*.
Re: userland clock_gettime proof of concept
> Date: Fri, 5 Jun 2020 01:33:16 +0300
> From: Paul Irofti
>
> On Wed, Jun 03, 2020 at 05:13:42PM +0300, Paul Irofti wrote:
> > On 2020-05-31 20:46, Mark Kettenis wrote:
> > > Forget about all that for a moment. Here is an alternative suggestion:
> > >
> > > On sparc64 we need to support both tick_timecounter and
> > > sys_tick_timecounter. So we need some sort of clockid value to
> > > distnguish between those two. I already suggested to use the tc_user
> > > field of the timecounter for that. 0 means that a timecounter is not
> > > usable in userland, a (small) positive integer means a specific
> > > timecounter type. The code in libc will need to know whether a
> > > particular timecounter type can be supported. My proposal would be to
> > > implement a function*on all architecture* that takes the clockid as
> > > an argument and returns a pointer to the function that implements
> > > support for that timecounter. On architectures without support, ir
> > > when called with a clockid that isn't supported, that function would
> > > simply return NULL.
> >
> > I am sorry, but the more I try to implement this in a sane way, the more
> > obvious it is that it is not possible. I would rather have a define sausage
> > than something like this.
> >
> > I will try to think of something else that avoids the defines, but I do not
> > think that your proposal is a valid solution.
>
> OK. I think I found an elegant way around this using the Makefile
> system: if usertc.c is not present in the arch/${MACHINE}/gen, then a
> stub gen/usertc.c file is built that just sets the function pointer to
> NULL. This avoids the need for the define checks in dlfcn/init.c and I
> think fixes the rest of the issues discussed around this bit.
>
> Also included in the diff are a few other fixes and regression tests.
> I left the rdtsc and acpihpet example (with no functional acpihpet
> support) just to show-case how we can handle multiple clocks on
> architectures that have them.
You're still using tk_user unconditionally. If the kernel returns a
tk_user value that is larger than what's supported by libc you have an
out-of-bounds array access.
Also if the machine switches to a timecounter that has tk_user == 0
you have an out-of-bounds array access. If that happens you need to
detect this and fall back on the system call.
> I could not add support for other architectures as I still do not have
> access to my machines.
arm64 can be done; I'm waiting with sparc64 until you have worked out
how to handle the multiple clocks properly...
> Is the Makefile approach good enough?
Not sure. Others should judge that.
> diff --git lib/libc/arch/amd64/gen/Makefile.inc
> lib/libc/arch/amd64/gen/Makefile.inc
> index e995309ed71..f6349e2b974 100644
> --- lib/libc/arch/amd64/gen/Makefile.inc
> +++ lib/libc/arch/amd64/gen/Makefile.inc
> @@ -2,6 +2,7 @@
>
> SRCS+= _setjmp.S fabs.S infinity.c ldexp.c modf.S nan.c setjmp.S \
> sigsetjmp.S
> -SRCS+= fpclassifyl.c isfinitel.c isinfl.c isnanl.c isnormall.c
> signbitl.c
> +SRCS+= fpclassifyl.c isfinitel.c isinfl.c isnanl.c isnormall.c
> signbitl.c \
> + usertc.c
> SRCS+= flt_rounds.S fpgetmask.S fpgetround.S fpgetsticky.S fpsetmask.S
> \
> fpsetround.S fpsetsticky.S
> diff --git lib/libc/arch/amd64/gen/usertc.c lib/libc/arch/amd64/gen/usertc.c
> new file mode 100644
> index 000..cec1b484865
> --- /dev/null
> +++ lib/libc/arch/amd64/gen/usertc.c
> @@ -0,0 +1,46 @@
> +/* $OpenBSD$ */
> +/*
> + * Copyright (c) 2020 Paul Irofti
> + *
> + * Permission to use, copy, modify, and distribute this software for any
> + * purpose with or without fee is hereby granted, provided that the above
> + * copyright notice and this permission notice appear in all copies.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
> + * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
> + * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
> + * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> + * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
> + * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
> + * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> + */
> +
> +#include
> +#include
> +
> +static uint64_t
> +rdtsc()
> +{
> + uint32_t hi, lo;
> + asm volatile("rdtsc" : "=a"(lo), "=d"(hi));
> + return ((uint64_t)lo)|(((uint64_t)hi)<<32);
> +}
> +
> +static uint64_t
> +acpihpet()
> +{
> + return rdtsc(); /* JUST TO COMPILE */
> +}
> +
> +static uint64_t (*get_tc[])(void) =
> +{
> + rdtsc,
> + acpihpet,
> +};
> +
> +uint64_t
> +tc_get_timecount(struct timekeep *tk)
> +{
> + return (*get_tc[tk->tk_user - 1])();
> +}
> +uint64_t (*const _tc_get_timecount)(struct timekeep *tk) = tc_get_timecount;
> diff --git lib/libc/asr/asr.c lib/libc/asr/asr.c
> index
Re: Some redundant code lines in sys
On Fri, 2020-06-05 at 14:20 +0100, Stuart Henderson wrote:
> On 2020/06/05 13:50, Denis Fondras wrote:
> > On Fri, Jun 05, 2020 at 12:56:21PM +0200, Prof. Dr. Steffen Wendzel wrote:
> > > Dear all:
> > >
> > > just in case this appears useful to you: I found some redundant code
> > > lines in the following files.
> > >
> > > sys/net/pipex.h:
> > >struct pipex_session *pipex_pppoe_lookup_session (struct mbuf *);
> > >struct pipex_session *pipex_pppoe_lookup_session (struct mbuf *);
> > >
> > > usr.sbin/relayd/agentx.c
> > >snmp_agentx_oid(pdu, oid) == -1 ||
> > >snmp_agentx_oid(pdu, oid) == -1 ||
> > >
> > > usr.sbin/snmpd/agentx.c:
> > > snmp_agentx_oid(pdu, oid) == -1 ||
> > > snmp_agentx_oid(pdu, oid) == -1 ||
>
> My first thought for these two was "were they just accidentally
> duplicated, or was something else meant to be there instead". Looking at
> the commit and code (the function is identical in snmpd and relayd) I am
> going more on the side of accidental dup (plus removing it doesn't
> change behaviour of code that been running for a while) so OK with me.
It's definitely a duplicate. This is when an unregister-pdu is created,
which only contains a single OID. Ranges can be specified, that's done
via the range_index/range_bound combo, or as the RFC names them:
range_subid/upper_bound.
Since the unregister pdu is a client generated pdu it's by definition
not being called in snmpd(8). A quick grep in relayd shows that it's
also never called there.
>
> > > usr.sbin/bgpd/rde.h:
> > > void path_init(u_int32_t);
> > > void path_init(u_int32_t);
> > >
> > > lib/libcurses/nc_tparm.h:
> > > #define TPARM_1(a,b) TPARM_2(a,b,0)
> > > #define TPARM_1(a,b) TPARM_2(a,b,0)
> > >
> >
> > Nice catch, thank you.
> >
> >
> > Index: lib/libcurses/nc_tparm.h
> > ===
> > RCS file: /cvs/src/lib/libcurses/nc_tparm.h,v
> > retrieving revision 1.1
> > diff -u -p -r1.1 nc_tparm.h
> > --- lib/libcurses/nc_tparm.h12 Jan 2010 23:21:59 - 1.1
> > +++ lib/libcurses/nc_tparm.h5 Jun 2020 11:45:41 -
> > @@ -62,6 +62,5 @@
> > #define TPARM_3(a,b,c,d) TPARM_4(a,b,c,d,0)
> > #define TPARM_2(a,b,c) TPARM_3(a,b,c,0)
> > #define TPARM_1(a,b) TPARM_2(a,b,0)
> > -#define TPARM_1(a,b) TPARM_2(a,b,0)
> > #define TPARM_0(a) TPARM_1(a,0)
> > #endif
> > Index: sys/net/pipex.h
> > ===
> > RCS file: /cvs/src/sys/net/pipex.h,v
> > retrieving revision 1.22
> > diff -u -p -r1.22 pipex.h
> > --- sys/net/pipex.h 26 May 2020 07:06:37 - 1.22
> > +++ sys/net/pipex.h 5 Jun 2020 11:45:44 -
> > @@ -206,7 +206,6 @@ int pipex_notify_close
> >
> > struct mbuf *pipex_output (struct mbuf *, int, int, struct
> > pipex_iface_context *);
> > struct pipex_session *pipex_pppoe_lookup_session (struct mbuf *);
> > -struct pipex_session *pipex_pppoe_lookup_session (struct mbuf *);
> > struct mbuf *pipex_pppoe_input (struct mbuf *, struct
> > pipex_session *);
> > struct pipex_session *pipex_pptp_lookup_session (struct mbuf *);
> > struct mbuf *pipex_pptp_input (struct mbuf *, struct
> > pipex_session *);
> > Index: usr.sbin/bgpd/rde.h
> > ===
> > RCS file: /cvs/src/usr.sbin/bgpd/rde.h,v
> > retrieving revision 1.233
> > diff -u -p -r1.233 rde.h
> > --- usr.sbin/bgpd/rde.h 24 Jan 2020 05:44:05 - 1.233
> > +++ usr.sbin/bgpd/rde.h 5 Jun 2020 11:45:45 -
> > @@ -557,7 +557,6 @@ re_rib(struct rib_entry *re)
> > }
> >
> > voidpath_init(u_int32_t);
> > -voidpath_init(u_int32_t);
> > voidpath_shutdown(void);
> > voidpath_hash_stats(struct rde_hashstats *);
> > int path_compare(struct rde_aspath *, struct rde_aspath *);
> > Index: usr.sbin/relayd/agentx.c
> > ===
> > RCS file: /cvs/src/usr.sbin/relayd/agentx.c,v
> > retrieving revision 1.14
> > diff -u -p -r1.14 agentx.c
> > --- usr.sbin/relayd/agentx.c28 May 2017 10:39:15 - 1.14
> > +++ usr.sbin/relayd/agentx.c5 Jun 2020 11:45:45 -
> > @@ -654,7 +654,6 @@ snmp_agentx_unregister_pdu(struct snmp_o
> >
> > if (snmp_agentx_raw(pdu, , sizeof(uhdr)) == -1 ||
> > snmp_agentx_oid(pdu, oid) == -1 ||
> > - snmp_agentx_oid(pdu, oid) == -1 ||
> > (range_index && snmp_agentx_int(pdu, _bound) == -1)) {
> > snmp_agentx_pdu_free(pdu);
> > return (NULL);
> > Index: usr.sbin/snmpd/agentx.c
> > ===
> > RCS file: /cvs/src/usr.sbin/snmpd/agentx.c,v
> > retrieving revision 1.13
> > diff -u -p -r1.13 agentx.c
> > --- usr.sbin/snmpd/agentx.c 17 Jun 2018 18:19:59 -
Re: filesystem code integer and many inodes
Hi Otto, * Otto Moerbeek wrote: > > Did anyone look closer at this? > > Did anyone test? I compiled kernel + world with your diff in a VM and performed the following tests. * fdisk, disklablel, newfs of an external disk * disklabel, growfs, fsck on a partition on an external disk * fsirand on a partition (not sure how to test this but fsirand -p showed different numbers afterwards...) * Extract src.tgz, powered off the VM, reboot and fsck upon boot * Same while extracting src.tgz on a second mounted disk To the best of my knowledge the tools did the jobs they were supposed to. Let me know if there is something else I should test. Cheers Matthias
Re: Some redundant code lines in sys
OK martijn@
On Fri, 2020-06-05 at 13:50 +0200, Denis Fondras wrote:
> On Fri, Jun 05, 2020 at 12:56:21PM +0200, Prof. Dr. Steffen Wendzel wrote:
> > Dear all:
> >
> > just in case this appears useful to you: I found some redundant code
> > lines in the following files.
> >
> > sys/net/pipex.h:
> >struct pipex_session *pipex_pppoe_lookup_session (struct mbuf *);
> >struct pipex_session *pipex_pppoe_lookup_session (struct mbuf *);
> >
> > usr.sbin/relayd/agentx.c
> >snmp_agentx_oid(pdu, oid) == -1 ||
> >snmp_agentx_oid(pdu, oid) == -1 ||
> >
> > usr.sbin/snmpd/agentx.c:
> > snmp_agentx_oid(pdu, oid) == -1 ||
> > snmp_agentx_oid(pdu, oid) == -1 ||
> >
> > usr.sbin/bgpd/rde.h:
> > void path_init(u_int32_t);
> > void path_init(u_int32_t);
> >
> > lib/libcurses/nc_tparm.h:
> > #define TPARM_1(a,b) TPARM_2(a,b,0)
> > #define TPARM_1(a,b) TPARM_2(a,b,0)
> >
>
> Nice catch, thank you.
>
>
> Index: lib/libcurses/nc_tparm.h
> ===
> RCS file: /cvs/src/lib/libcurses/nc_tparm.h,v
> retrieving revision 1.1
> diff -u -p -r1.1 nc_tparm.h
> --- lib/libcurses/nc_tparm.h 12 Jan 2010 23:21:59 - 1.1
> +++ lib/libcurses/nc_tparm.h 5 Jun 2020 11:45:41 -
> @@ -62,6 +62,5 @@
> #define TPARM_3(a,b,c,d) TPARM_4(a,b,c,d,0)
> #define TPARM_2(a,b,c) TPARM_3(a,b,c,0)
> #define TPARM_1(a,b) TPARM_2(a,b,0)
> -#define TPARM_1(a,b) TPARM_2(a,b,0)
> #define TPARM_0(a) TPARM_1(a,0)
> #endif
> Index: sys/net/pipex.h
> ===
> RCS file: /cvs/src/sys/net/pipex.h,v
> retrieving revision 1.22
> diff -u -p -r1.22 pipex.h
> --- sys/net/pipex.h 26 May 2020 07:06:37 - 1.22
> +++ sys/net/pipex.h 5 Jun 2020 11:45:44 -
> @@ -206,7 +206,6 @@ int pipex_notify_close
>
> struct mbuf *pipex_output (struct mbuf *, int, int, struct
> pipex_iface_context *);
> struct pipex_session *pipex_pppoe_lookup_session (struct mbuf *);
> -struct pipex_session *pipex_pppoe_lookup_session (struct mbuf *);
> struct mbuf *pipex_pppoe_input (struct mbuf *, struct
> pipex_session *);
> struct pipex_session *pipex_pptp_lookup_session (struct mbuf *);
> struct mbuf *pipex_pptp_input (struct mbuf *, struct pipex_session
> *);
> Index: usr.sbin/bgpd/rde.h
> ===
> RCS file: /cvs/src/usr.sbin/bgpd/rde.h,v
> retrieving revision 1.233
> diff -u -p -r1.233 rde.h
> --- usr.sbin/bgpd/rde.h 24 Jan 2020 05:44:05 - 1.233
> +++ usr.sbin/bgpd/rde.h 5 Jun 2020 11:45:45 -
> @@ -557,7 +557,6 @@ re_rib(struct rib_entry *re)
> }
>
> void path_init(u_int32_t);
> -void path_init(u_int32_t);
> void path_shutdown(void);
> void path_hash_stats(struct rde_hashstats *);
> int path_compare(struct rde_aspath *, struct rde_aspath *);
> Index: usr.sbin/relayd/agentx.c
> ===
> RCS file: /cvs/src/usr.sbin/relayd/agentx.c,v
> retrieving revision 1.14
> diff -u -p -r1.14 agentx.c
> --- usr.sbin/relayd/agentx.c 28 May 2017 10:39:15 - 1.14
> +++ usr.sbin/relayd/agentx.c 5 Jun 2020 11:45:45 -
> @@ -654,7 +654,6 @@ snmp_agentx_unregister_pdu(struct snmp_o
>
> if (snmp_agentx_raw(pdu, , sizeof(uhdr)) == -1 ||
> snmp_agentx_oid(pdu, oid) == -1 ||
> - snmp_agentx_oid(pdu, oid) == -1 ||
> (range_index && snmp_agentx_int(pdu, _bound) == -1)) {
> snmp_agentx_pdu_free(pdu);
> return (NULL);
> Index: usr.sbin/snmpd/agentx.c
> ===
> RCS file: /cvs/src/usr.sbin/snmpd/agentx.c,v
> retrieving revision 1.13
> diff -u -p -r1.13 agentx.c
> --- usr.sbin/snmpd/agentx.c 17 Jun 2018 18:19:59 - 1.13
> +++ usr.sbin/snmpd/agentx.c 5 Jun 2020 11:45:45 -
> @@ -658,7 +658,6 @@ snmp_agentx_unregister_pdu(struct snmp_o
>
> if (snmp_agentx_raw(pdu, , sizeof(uhdr)) == -1 ||
> snmp_agentx_oid(pdu, oid) == -1 ||
> - snmp_agentx_oid(pdu, oid) == -1 ||
> (range_index && snmp_agentx_int(pdu, _bound) == -1)) {
> snmp_agentx_pdu_free(pdu);
> return (NULL);
>
Re: Some redundant code lines in sys
On 2020/06/05 13:50, Denis Fondras wrote:
> On Fri, Jun 05, 2020 at 12:56:21PM +0200, Prof. Dr. Steffen Wendzel wrote:
> > Dear all:
> >
> > just in case this appears useful to you: I found some redundant code
> > lines in the following files.
> >
> > sys/net/pipex.h:
> >struct pipex_session *pipex_pppoe_lookup_session (struct mbuf *);
> >struct pipex_session *pipex_pppoe_lookup_session (struct mbuf *);
> >
> > usr.sbin/relayd/agentx.c
> >snmp_agentx_oid(pdu, oid) == -1 ||
> >snmp_agentx_oid(pdu, oid) == -1 ||
> >
> > usr.sbin/snmpd/agentx.c:
> > snmp_agentx_oid(pdu, oid) == -1 ||
> > snmp_agentx_oid(pdu, oid) == -1 ||
My first thought for these two was "were they just accidentally
duplicated, or was something else meant to be there instead". Looking at
the commit and code (the function is identical in snmpd and relayd) I am
going more on the side of accidental dup (plus removing it doesn't
change behaviour of code that been running for a while) so OK with me.
> >
> > usr.sbin/bgpd/rde.h:
> > void path_init(u_int32_t);
> > void path_init(u_int32_t);
> >
> > lib/libcurses/nc_tparm.h:
> > #define TPARM_1(a,b) TPARM_2(a,b,0)
> > #define TPARM_1(a,b) TPARM_2(a,b,0)
> >
>
> Nice catch, thank you.
>
>
> Index: lib/libcurses/nc_tparm.h
> ===
> RCS file: /cvs/src/lib/libcurses/nc_tparm.h,v
> retrieving revision 1.1
> diff -u -p -r1.1 nc_tparm.h
> --- lib/libcurses/nc_tparm.h 12 Jan 2010 23:21:59 - 1.1
> +++ lib/libcurses/nc_tparm.h 5 Jun 2020 11:45:41 -
> @@ -62,6 +62,5 @@
> #define TPARM_3(a,b,c,d) TPARM_4(a,b,c,d,0)
> #define TPARM_2(a,b,c) TPARM_3(a,b,c,0)
> #define TPARM_1(a,b) TPARM_2(a,b,0)
> -#define TPARM_1(a,b) TPARM_2(a,b,0)
> #define TPARM_0(a) TPARM_1(a,0)
> #endif
> Index: sys/net/pipex.h
> ===
> RCS file: /cvs/src/sys/net/pipex.h,v
> retrieving revision 1.22
> diff -u -p -r1.22 pipex.h
> --- sys/net/pipex.h 26 May 2020 07:06:37 - 1.22
> +++ sys/net/pipex.h 5 Jun 2020 11:45:44 -
> @@ -206,7 +206,6 @@ int pipex_notify_close
>
> struct mbuf *pipex_output (struct mbuf *, int, int, struct
> pipex_iface_context *);
> struct pipex_session *pipex_pppoe_lookup_session (struct mbuf *);
> -struct pipex_session *pipex_pppoe_lookup_session (struct mbuf *);
> struct mbuf *pipex_pppoe_input (struct mbuf *, struct
> pipex_session *);
> struct pipex_session *pipex_pptp_lookup_session (struct mbuf *);
> struct mbuf *pipex_pptp_input (struct mbuf *, struct pipex_session
> *);
> Index: usr.sbin/bgpd/rde.h
> ===
> RCS file: /cvs/src/usr.sbin/bgpd/rde.h,v
> retrieving revision 1.233
> diff -u -p -r1.233 rde.h
> --- usr.sbin/bgpd/rde.h 24 Jan 2020 05:44:05 - 1.233
> +++ usr.sbin/bgpd/rde.h 5 Jun 2020 11:45:45 -
> @@ -557,7 +557,6 @@ re_rib(struct rib_entry *re)
> }
>
> void path_init(u_int32_t);
> -void path_init(u_int32_t);
> void path_shutdown(void);
> void path_hash_stats(struct rde_hashstats *);
> int path_compare(struct rde_aspath *, struct rde_aspath *);
> Index: usr.sbin/relayd/agentx.c
> ===
> RCS file: /cvs/src/usr.sbin/relayd/agentx.c,v
> retrieving revision 1.14
> diff -u -p -r1.14 agentx.c
> --- usr.sbin/relayd/agentx.c 28 May 2017 10:39:15 - 1.14
> +++ usr.sbin/relayd/agentx.c 5 Jun 2020 11:45:45 -
> @@ -654,7 +654,6 @@ snmp_agentx_unregister_pdu(struct snmp_o
>
> if (snmp_agentx_raw(pdu, , sizeof(uhdr)) == -1 ||
> snmp_agentx_oid(pdu, oid) == -1 ||
> - snmp_agentx_oid(pdu, oid) == -1 ||
> (range_index && snmp_agentx_int(pdu, _bound) == -1)) {
> snmp_agentx_pdu_free(pdu);
> return (NULL);
> Index: usr.sbin/snmpd/agentx.c
> ===
> RCS file: /cvs/src/usr.sbin/snmpd/agentx.c,v
> retrieving revision 1.13
> diff -u -p -r1.13 agentx.c
> --- usr.sbin/snmpd/agentx.c 17 Jun 2018 18:19:59 - 1.13
> +++ usr.sbin/snmpd/agentx.c 5 Jun 2020 11:45:45 -
> @@ -658,7 +658,6 @@ snmp_agentx_unregister_pdu(struct snmp_o
>
> if (snmp_agentx_raw(pdu, , sizeof(uhdr)) == -1 ||
> snmp_agentx_oid(pdu, oid) == -1 ||
> - snmp_agentx_oid(pdu, oid) == -1 ||
> (range_index && snmp_agentx_int(pdu, _bound) == -1)) {
> snmp_agentx_pdu_free(pdu);
> return (NULL);
>
Re: Some redundant code lines in sys
On Fri, Jun 05, 2020 at 12:56:21PM +0200, Prof. Dr. Steffen Wendzel wrote:
> Dear all:
>
> just in case this appears useful to you: I found some redundant code
> lines in the following files.
>
> sys/net/pipex.h:
>struct pipex_session *pipex_pppoe_lookup_session (struct mbuf *);
>struct pipex_session *pipex_pppoe_lookup_session (struct mbuf *);
>
> usr.sbin/relayd/agentx.c
>snmp_agentx_oid(pdu, oid) == -1 ||
>snmp_agentx_oid(pdu, oid) == -1 ||
>
> usr.sbin/snmpd/agentx.c:
> snmp_agentx_oid(pdu, oid) == -1 ||
> snmp_agentx_oid(pdu, oid) == -1 ||
>
> usr.sbin/bgpd/rde.h:
> void path_init(u_int32_t);
> void path_init(u_int32_t);
>
> lib/libcurses/nc_tparm.h:
> #define TPARM_1(a,b) TPARM_2(a,b,0)
> #define TPARM_1(a,b) TPARM_2(a,b,0)
>
Nice catch, thank you.
Index: lib/libcurses/nc_tparm.h
===
RCS file: /cvs/src/lib/libcurses/nc_tparm.h,v
retrieving revision 1.1
diff -u -p -r1.1 nc_tparm.h
--- lib/libcurses/nc_tparm.h12 Jan 2010 23:21:59 - 1.1
+++ lib/libcurses/nc_tparm.h5 Jun 2020 11:45:41 -
@@ -62,6 +62,5 @@
#define TPARM_3(a,b,c,d) TPARM_4(a,b,c,d,0)
#define TPARM_2(a,b,c) TPARM_3(a,b,c,0)
#define TPARM_1(a,b) TPARM_2(a,b,0)
-#define TPARM_1(a,b) TPARM_2(a,b,0)
#define TPARM_0(a) TPARM_1(a,0)
#endif
Index: sys/net/pipex.h
===
RCS file: /cvs/src/sys/net/pipex.h,v
retrieving revision 1.22
diff -u -p -r1.22 pipex.h
--- sys/net/pipex.h 26 May 2020 07:06:37 - 1.22
+++ sys/net/pipex.h 5 Jun 2020 11:45:44 -
@@ -206,7 +206,6 @@ int pipex_notify_close
struct mbuf *pipex_output (struct mbuf *, int, int, struct
pipex_iface_context *);
struct pipex_session *pipex_pppoe_lookup_session (struct mbuf *);
-struct pipex_session *pipex_pppoe_lookup_session (struct mbuf *);
struct mbuf *pipex_pppoe_input (struct mbuf *, struct pipex_session
*);
struct pipex_session *pipex_pptp_lookup_session (struct mbuf *);
struct mbuf *pipex_pptp_input (struct mbuf *, struct pipex_session
*);
Index: usr.sbin/bgpd/rde.h
===
RCS file: /cvs/src/usr.sbin/bgpd/rde.h,v
retrieving revision 1.233
diff -u -p -r1.233 rde.h
--- usr.sbin/bgpd/rde.h 24 Jan 2020 05:44:05 - 1.233
+++ usr.sbin/bgpd/rde.h 5 Jun 2020 11:45:45 -
@@ -557,7 +557,6 @@ re_rib(struct rib_entry *re)
}
voidpath_init(u_int32_t);
-voidpath_init(u_int32_t);
voidpath_shutdown(void);
voidpath_hash_stats(struct rde_hashstats *);
int path_compare(struct rde_aspath *, struct rde_aspath *);
Index: usr.sbin/relayd/agentx.c
===
RCS file: /cvs/src/usr.sbin/relayd/agentx.c,v
retrieving revision 1.14
diff -u -p -r1.14 agentx.c
--- usr.sbin/relayd/agentx.c28 May 2017 10:39:15 - 1.14
+++ usr.sbin/relayd/agentx.c5 Jun 2020 11:45:45 -
@@ -654,7 +654,6 @@ snmp_agentx_unregister_pdu(struct snmp_o
if (snmp_agentx_raw(pdu, , sizeof(uhdr)) == -1 ||
snmp_agentx_oid(pdu, oid) == -1 ||
- snmp_agentx_oid(pdu, oid) == -1 ||
(range_index && snmp_agentx_int(pdu, _bound) == -1)) {
snmp_agentx_pdu_free(pdu);
return (NULL);
Index: usr.sbin/snmpd/agentx.c
===
RCS file: /cvs/src/usr.sbin/snmpd/agentx.c,v
retrieving revision 1.13
diff -u -p -r1.13 agentx.c
--- usr.sbin/snmpd/agentx.c 17 Jun 2018 18:19:59 - 1.13
+++ usr.sbin/snmpd/agentx.c 5 Jun 2020 11:45:45 -
@@ -658,7 +658,6 @@ snmp_agentx_unregister_pdu(struct snmp_o
if (snmp_agentx_raw(pdu, , sizeof(uhdr)) == -1 ||
snmp_agentx_oid(pdu, oid) == -1 ||
- snmp_agentx_oid(pdu, oid) == -1 ||
(range_index && snmp_agentx_int(pdu, _bound) == -1)) {
snmp_agentx_pdu_free(pdu);
return (NULL);
Re: Some redundant code lines in sys
On Fri, 5 Jun 2020 12:56:21 +0200
"Prof. Dr. Steffen Wendzel" wrote:
> Dear all:
>
> just in case this appears useful to you: I found some redundant code
> lines in the following files.
>
> sys/net/pipex.h:
>struct pipex_session *pipex_pppoe_lookup_session (struct mbuf *);
>struct pipex_session *pipex_pppoe_lookup_session (struct mbuf *);
>
> usr.sbin/relayd/agentx.c
>snmp_agentx_oid(pdu, oid) == -1 ||
>snmp_agentx_oid(pdu, oid) == -1 ||
>
> usr.sbin/snmpd/agentx.c:
> snmp_agentx_oid(pdu, oid) == -1 ||
> snmp_agentx_oid(pdu, oid) == -1 ||
>
> usr.sbin/bgpd/rde.h:
> void path_init(u_int32_t);
> void path_init(u_int32_t);
>
> lib/libcurses/nc_tparm.h:
> #define TPARM_1(a,b) TPARM_2(a,b,0)
> #define TPARM_1(a,b) TPARM_2(a,b,0)
>
> Kind regards,
> Steffen
>
Interesting enought to spend a few minutes on it :-)
Index: lib/libcurses/nc_tparm.h
===
RCS file: /cvs/src/lib/libcurses/nc_tparm.h,v
retrieving revision 1.1
diff -u -p -r1.1 nc_tparm.h
--- lib/libcurses/nc_tparm.h12 Jan 2010 23:21:59 - 1.1
+++ lib/libcurses/nc_tparm.h5 Jun 2020 12:15:42 -
@@ -62,6 +62,5 @@
#define TPARM_3(a,b,c,d) TPARM_4(a,b,c,d,0)
#define TPARM_2(a,b,c) TPARM_3(a,b,c,0)
#define TPARM_1(a,b) TPARM_2(a,b,0)
-#define TPARM_1(a,b) TPARM_2(a,b,0)
#define TPARM_0(a) TPARM_1(a,0)
#endif
Index: sys/net/pipex.h
===
RCS file: /cvs/src/sys/net/pipex.h,v
retrieving revision 1.22
diff -u -p -r1.22 pipex.h
--- sys/net/pipex.h 26 May 2020 07:06:37 - 1.22
+++ sys/net/pipex.h 5 Jun 2020 12:10:11 -
@@ -206,7 +206,6 @@ int pipex_notify_close
struct mbuf *pipex_output (struct mbuf *, int, int, struct
pipex_iface_context *);
struct pipex_session *pipex_pppoe_lookup_session (struct mbuf *);
-struct pipex_session *pipex_pppoe_lookup_session (struct mbuf *);
struct mbuf *pipex_pppoe_input (struct mbuf *, struct pipex_session
*);
struct pipex_session *pipex_pptp_lookup_session (struct mbuf *);
struct mbuf *pipex_pptp_input (struct mbuf *, struct pipex_session
*);
Index: usr.sbin/bgpd/rde.h
===
RCS file: /cvs/src/usr.sbin/bgpd/rde.h,v
retrieving revision 1.233
diff -u -p -r1.233 rde.h
--- usr.sbin/bgpd/rde.h 24 Jan 2020 05:44:05 - 1.233
+++ usr.sbin/bgpd/rde.h 5 Jun 2020 12:14:50 -
@@ -557,7 +557,6 @@ re_rib(struct rib_entry *re)
}
voidpath_init(u_int32_t);
-voidpath_init(u_int32_t);
voidpath_shutdown(void);
voidpath_hash_stats(struct rde_hashstats *);
int path_compare(struct rde_aspath *, struct rde_aspath *);
Index: usr.sbin/relayd/agentx.c
===
RCS file: /cvs/src/usr.sbin/relayd/agentx.c,v
retrieving revision 1.14
diff -u -p -r1.14 agentx.c
--- usr.sbin/relayd/agentx.c28 May 2017 10:39:15 - 1.14
+++ usr.sbin/relayd/agentx.c5 Jun 2020 12:12:06 -
@@ -654,7 +654,6 @@ snmp_agentx_unregister_pdu(struct snmp_o
if (snmp_agentx_raw(pdu, , sizeof(uhdr)) == -1 ||
snmp_agentx_oid(pdu, oid) == -1 ||
- snmp_agentx_oid(pdu, oid) == -1 ||
(range_index && snmp_agentx_int(pdu, _bound) == -1)) {
snmp_agentx_pdu_free(pdu);
return (NULL);
Index: usr.sbin/snmpd/agentx.c
===
RCS file: /cvs/src/usr.sbin/snmpd/agentx.c,v
retrieving revision 1.13
diff -u -p -r1.13 agentx.c
--- usr.sbin/snmpd/agentx.c 17 Jun 2018 18:19:59 - 1.13
+++ usr.sbin/snmpd/agentx.c 5 Jun 2020 12:12:53 -
@@ -658,7 +658,6 @@ snmp_agentx_unregister_pdu(struct snmp_o
if (snmp_agentx_raw(pdu, , sizeof(uhdr)) == -1 ||
snmp_agentx_oid(pdu, oid) == -1 ||
- snmp_agentx_oid(pdu, oid) == -1 ||
(range_index && snmp_agentx_int(pdu, _bound) == -1)) {
snmp_agentx_pdu_free(pdu);
return (NULL);
urtwn(4) hardware crypto
This enables use of hardware crypto for CCMP in urtwn(4). As with other
drivers, this reduces cpu usage significantly when moving lots of data.
I've tested this on an assortment of hardware (RTL8188CUS, RTL8188EU,
RTL8192EU) with no problems, and this is one of the few things that
remains constant across a lot of Realtek wifi chips, but some wider
testing couldn't hurt. Since this touches the code shared with rtwn(4),
I've also tested that that still works.
Index: ic/r92creg.h
===
RCS file: /cvs/src/sys/dev/ic/r92creg.h,v
retrieving revision 1.24
diff -u -p -r1.24 r92creg.h
--- ic/r92creg.h11 Mar 2019 06:19:33 - 1.24
+++ ic/r92creg.h5 Jun 2020 11:52:21 -
@@ -688,6 +688,16 @@
#define R92C_CAMCMD_CLR0x4000
#define R92C_CAMCMD_POLLING0x8000
+/* Bits for R92C_SECCFG. */
+#define R92C_SECCFG_TXUCKEY_DEF 0x0001
+#define R92C_SECCFG_RXUCKEY_DEF0x0002
+#define R92C_SECCFG_TXENC_ENA 0x0004
+#define R92C_SECCFG_RXENC_ENA 0x0008
+#define R92C_SECCFG_CMP_A2 0x0010
+#define R92C_SECCFG_MC_SRCH_DIS0x0020
+#define R92C_SECCFG_TXBCKEY_DEF 0x0040
+#define R92C_SECCFG_RXBCKEY_DEF 0x0080
+
/* IMR */
/*Beacon DMA interrupt 6 */
Index: ic/rtwn.c
===
RCS file: /cvs/src/sys/dev/ic/rtwn.c,v
retrieving revision 1.49
diff -u -p -r1.49 rtwn.c
--- ic/rtwn.c 9 Jan 2020 14:35:19 - 1.49
+++ ic/rtwn.c 5 Jun 2020 11:52:22 -
@@ -3154,6 +3154,14 @@ rtwn_init(struct ifnet *ifp)
/* Clear per-station keys table. */
rtwn_cam_init(sc);
+ /* Enable decryption / encryption. */
+ if (sc->chip & RTWN_CHIP_USB) {
+ rtwn_write_2(sc, R92C_SECCFG,
+ R92C_SECCFG_TXUCKEY_DEF | R92C_SECCFG_RXUCKEY_DEF |
+ R92C_SECCFG_TXENC_ENA | R92C_SECCFG_RXENC_ENA |
+ R92C_SECCFG_TXBCKEY_DEF | R92C_SECCFG_RXBCKEY_DEF);
+ }
+
/* Enable hardware sequence numbering. */
rtwn_write_1(sc, R92C_HWSEQ_CTRL, 0xff);
@@ -3204,14 +3212,14 @@ rtwn_init(struct ifnet *ifp)
ifq_clr_oactive(>if_snd);
ifp->if_flags |= IFF_RUNNING;
-#ifdef notyet
- if (ic->ic_flags & IEEE80211_F_WEPON) {
+ if ((ic->ic_flags & IEEE80211_F_WEPON) &&
+ (sc->chip & RTWN_CHIP_USB)) {
/* Install WEP keys. */
for (i = 0; i < IEEE80211_WEP_NKID; i++)
ic->ic_set_key(ic, NULL, >ic_nw_keys[i]);
sc->sc_ops.wait_async(sc->sc_ops.cookie);
}
-#endif
+
if (ic->ic_opmode == IEEE80211_M_MONITOR)
ieee80211_new_state(ic, IEEE80211_S_RUN, -1);
else
Index: usb/if_urtwn.c
===
RCS file: /cvs/src/sys/dev/usb/if_urtwn.c,v
retrieving revision 1.89
diff -u -p -r1.89 if_urtwn.c
--- usb/if_urtwn.c 26 May 2020 06:04:30 - 1.89
+++ usb/if_urtwn.c 5 Jun 2020 11:52:22 -
@@ -490,10 +490,8 @@ urtwn_attach(struct device *parent, stru
ic->ic_updateslot = urtwn_updateslot;
ic->ic_updateedca = urtwn_updateedca;
-#ifdef notyet
ic->ic_set_key = urtwn_set_key;
ic->ic_delete_key = urtwn_delete_key;
-#endif
/* Override state transition machine. */
ic->ic_newstate = urtwn_newstate;
@@ -1035,6 +1033,10 @@ urtwn_set_key(struct ieee80211com *ic, s
struct urtwn_softc *sc = (struct urtwn_softc *)self;
struct urtwn_cmd_key cmd;
+ /* Only handle keys for CCMP */
+ if (k->k_cipher != IEEE80211_CIPHER_CCMP)
+ return ieee80211_set_key(ic, ni, k);
+
/* Defer setting of WEP keys until interface is brought up. */
if ((ic->ic_if.if_flags & (IFF_UP | IFF_RUNNING)) !=
(IFF_UP | IFF_RUNNING))
@@ -1065,6 +1067,12 @@ urtwn_delete_key(struct ieee80211com *ic
struct urtwn_softc *sc = (struct urtwn_softc *)self;
struct urtwn_cmd_key cmd;
+ /* Only handle keys for CCMP */
+ if (k->k_cipher != IEEE80211_CIPHER_CCMP) {
+ ieee80211_delete_key(ic, ni, k);
+ return;
+ }
+
if (!(ic->ic_if.if_flags & IFF_RUNNING) ||
ic->ic_state != IEEE80211_S_RUN)
return; /* Nothing to do. */
@@ -1084,6 +1092,52 @@ urtwn_delete_key_cb(struct urtwn_softc *
rtwn_delete_key(ic, cmd->ni, >key);
}
+int
+urtwn_ccmp_decap(struct urtwn_softc *sc, struct mbuf *m,
+struct ieee80211_node *ni)
+{
+ struct ieee80211com *ic = >sc_sc.sc_ic;
+ struct ieee80211_key *k;
+ struct ieee80211_frame *wh;
+ uint64_t pn, *prsc;
+ uint8_t *ivp;
+ uint8_t tid;
+ int hdrlen, hasqos;
+
+ k = ieee80211_get_rxkey(ic, m, ni);
+ if (k == NULL)
+ return 1;
+
+ wh = mtod(m, struct ieee80211_frame *);
+ hdrlen =
Some redundant code lines in sys
Dear all: just in case this appears useful to you: I found some redundant code lines in the following files. sys/net/pipex.h: struct pipex_session *pipex_pppoe_lookup_session (struct mbuf *); struct pipex_session *pipex_pppoe_lookup_session (struct mbuf *); usr.sbin/relayd/agentx.c snmp_agentx_oid(pdu, oid) == -1 || snmp_agentx_oid(pdu, oid) == -1 || usr.sbin/snmpd/agentx.c: snmp_agentx_oid(pdu, oid) == -1 || snmp_agentx_oid(pdu, oid) == -1 || usr.sbin/bgpd/rde.h: void path_init(u_int32_t); void path_init(u_int32_t); lib/libcurses/nc_tparm.h: #define TPARM_1(a,b) TPARM_2(a,b,0) #define TPARM_1(a,b) TPARM_2(a,b,0) Kind regards, Steffen -- Prof. Dr. Steffen Wendzel Hochschule Worms Stellv. wiss. Leiter ZTT Fachbereich Informatik Erenburgerstr. 19 Raum/Room N 334 D-67549 Worms T: +49(0)6241.509-213 F: +49(0)6241.509-221 https://www.hs-worms.de/wendzel/
Re: sparc64: bootblocks vs ofwboot load address
On Fri, Jun 05, 2020 at 10:12:40AM +0200, Otto Moerbeek wrote: > Miod remarked the overwriting of the bootblocks actually is a > regression I introduced. So teintroduce the lost comment and load > ofwboot at 0x6000. OK kn
Re: sparc64: bootblocks vs ofwboot load address
> Date: Fri, 5 Jun 2020 10:12:40 +0200 > From: Otto Moerbeek > > Hi, > > Miod remarked the overwriting of the bootblocks actually is a > regression I introduced. So teintroduce the lost comment and load > ofwboot at 0x6000. > > OK? ok kettenis@ > Index: bootblk.fth > === > RCS file: /cvs/src/sys/arch/sparc64/stand/bootblk/bootblk.fth,v > retrieving revision 1.9 > diff -u -p -r1.9 bootblk.fth > --- bootblk.fth 2 Apr 2020 06:06:22 - 1.9 > +++ bootblk.fth 5 Jun 2020 08:09:33 - > @@ -716,7 +716,15 @@ create cur-blockno -1 l, -1 l, \ Curren > 2drop > ; > > -" load-base " evaluate constant loader-base > +\ > +\ According to the 1275 addendum for SPARC processors: > +\ Default load-base is 0x4000. At least 0x8. or > +\ 512KB must be available at that address. > +\ > +\ The Fcode bootblock can take up up to 8KB (O.K., 7.5KB) > +\ so load programs at 0x4000 + 0x2000=> 0x6000 > +\ > +" load-base " evaluate 2000 + constant loader-base > > : load-file-signon ( load-file len boot-path len -- load-file len boot-path > len ) > ." Loading file" space 2over type cr ." from device" space 2dup type cr > @@ -821,7 +829,7 @@ create cur-blockno -1 l, -1 l,\ Curren > ; > > : do-boot ( bootfile -- ) > - ." OpenBSD IEEE 1275 Bootblock 2.0" cr > + ." OpenBSD IEEE 1275 Bootblock 2.1" cr > > \ Open boot device > boot-path ( boot-path len ) > >
sparc64: bootblocks vs ofwboot load address
Hi, Miod remarked the overwriting of the bootblocks actually is a regression I introduced. So teintroduce the lost comment and load ofwboot at 0x6000. OK? -Otto Index: bootblk.fth === RCS file: /cvs/src/sys/arch/sparc64/stand/bootblk/bootblk.fth,v retrieving revision 1.9 diff -u -p -r1.9 bootblk.fth --- bootblk.fth 2 Apr 2020 06:06:22 - 1.9 +++ bootblk.fth 5 Jun 2020 08:09:33 - @@ -716,7 +716,15 @@ create cur-blockno -1 l, -1 l, \ Curren 2drop ; -" load-base " evaluate constant loader-base +\ +\ According to the 1275 addendum for SPARC processors: +\ Default load-base is 0x4000. At least 0x8. or +\ 512KB must be available at that address. +\ +\ The Fcode bootblock can take up up to 8KB (O.K., 7.5KB) +\ so load programs at 0x4000 + 0x2000=> 0x6000 +\ +" load-base " evaluate 2000 + constant loader-base : load-file-signon ( load-file len boot-path len -- load-file len boot-path len ) ." Loading file" space 2over type cr ." from device" space 2dup type cr @@ -821,7 +829,7 @@ create cur-blockno -1 l, -1 l, \ Curren ; : do-boot ( bootfile -- ) - ." OpenBSD IEEE 1275 Bootblock 2.0" cr + ." OpenBSD IEEE 1275 Bootblock 2.1" cr \ Open boot device boot-path ( boot-path len )
