On Sat, Aug 06, 2022 at 02:19:31AM +0200, Jeremie Courreges-Anglas wrote:
> On Fri, Aug 05 2022, Sebastien Marie wrote:
> > Hi,
> >
> > When initially ported blist from DragonFlyBSD, we used custom type bsblk_t
> > and
> > bsbmp_t instead of the one used by DragonFlyBSD (swblk_t and u_swblk_t).
On Tue, 2 Aug 2022 19:55:02 +0200 (CEST)
Mark Kettenis wrote:
> > Date: Tue, 2 Aug 2022 11:56:59 -0500
> > From: Scott Cheloha
> >
> > At what point do we consider the patch safe? Have you seen any hangs?
> >
> > Wanna run with it another week?
>
> Sorry. I'm not set up to run my powerpc64
On Fri, Aug 05, 2022 at 11:06:06AM -0700, Andrew Hewus Fresh wrote:
> On Tue, Jun 21, 2022 at 02:58:46PM +1000, Jonathan Gray wrote:
> > Intel CPUs used to have strings like
> > cpu0: Intel(R) Pentium(R) M processor 1200MHz ("GenuineIntel" 686-class)
> > 1.20 GHz
> > cpu0: Intel(R) Core(TM) i7-560
Todd C. Miller wrote:
> On Sat, 06 Aug 2022 02:19:31 +0200, Jeremie Courreges-Anglas wrote:
>
> > This seems fair, but maybe we should just zap the type from sys/types.h and
> > define it only in sys/blist.h, as done in DragonflyBSD?
>
> Fine with me. It is a non-standard type not used by base
On Sat, 06 Aug 2022 02:19:31 +0200, Jeremie Courreges-Anglas wrote:
> This seems fair, but maybe we should just zap the type from sys/types.h and
> define it only in sys/blist.h, as done in DragonflyBSD?
Fine with me. It is a non-standard type not used by base.
- todd
On Fri, Aug 05 2022, Sebastien Marie wrote:
> Hi,
>
> When initially ported blist from DragonFlyBSD, we used custom type bsblk_t
> and
> bsbmp_t instead of the one used by DragonFlyBSD (swblk_t and u_swblk_t).
>
> The reason was swblk_t is already defined on OpenBSD, and was incompatible
> with
Hi Theo,
> ?: could be used here:
>
> if (unveil("/", rflag ? "r" : "rwc") == -1)
> err(1, "unveil /");
Right, I find it a bit verbose too.
>> -/* Don't allow directory traversal. */
>> -if (strchr(devp, '/')) {
>> -
Hi,
Why do we need NET_RLOCK_IN_SOFTNET and NET_RLOCK_IN_IOCTL macros
which do the same?
I would prefer to call both of them _SHARED. Also the W and R are
hard to see, I think NET_ASSERT_LOCKED_EXCLUSIVE is more obvious.
Some comments were pretty outdated.
ok?
bluhm
Index: net/if.c
=
On Sat, Aug 06, 2022 at 01:07:31AM +0300, Vitaliy Makkoveev wrote:
> I thought you will introduce something like below. This does the
> same but it has no heuristic under the hood.
>
> int
> sbwait_shared(struct socket *so, struct sockbuf *sb)
> {
> int error;
>
> i
> On 6 Aug 2022, at 01:07, Vitaliy Makkoveev wrote:
>
> I thought you will introduce something like below. This does the
> same but it has no heuristic under the hood.
>
> int
> sbwait_shared(struct socket *so, struct sockbuf *sb)
> {
>int error;
>
>if (so->so_proto->pr_u
> On 6 Aug 2022, at 00:36, Alexander Bluhm wrote:
>
> On Sat, Aug 06, 2022 at 12:20:48AM +0300, Vitaliy Makkoveev wrote:
>>> On 5 Aug 2022, at 23:50, Alexander Bluhm wrote:
>>>
>>> On Thu, Aug 04, 2022 at 06:07:49PM +0300, Vitaliy Makkoveev wrote:
Yes please. Also I like (*pr_usrreq)() be
On Fri, Aug 05, 2022 at 07:10:24AM +, Klemens Nanni wrote:
> All of them are passed to inspect/copy out fields, none of the functions
> writes to the struct.
>
> This makes it easier to argue about code (in MP context) and syncs ND6 code
> with NetBSD and FreeBSD.
>
> Builds and runs fine on
On Sat, Aug 06, 2022 at 12:20:48AM +0300, Vitaliy Makkoveev wrote:
> > On 5 Aug 2022, at 23:50, Alexander Bluhm wrote:
> >
> > On Thu, Aug 04, 2022 at 06:07:49PM +0300, Vitaliy Makkoveev wrote:
> >> Yes please. Also I like (*pr_usrreq)() be splitted to multiple handlers.
> >
> > With all you fee
> On 5 Aug 2022, at 23:50, Alexander Bluhm wrote:
>
> On Thu, Aug 04, 2022 at 06:07:49PM +0300, Vitaliy Makkoveev wrote:
>> Yes please. Also I like (*pr_usrreq)() be splitted to multiple handlers.
>
> With all you feedback diff looks like this now.
>
Did you missed sbwait() modification? I als
On Fri, Aug 05, 2022 at 02:12:35PM -0500, luci...@bronze.ctrl-c.club wrote:
> So this is the final verison of the patch solving the following
> problems:
>
> >The program is broken in multiple ways: return value clamping, casting
> >from double to uint32_t, wrong error checking for putchar, lack o
On Thu, Aug 04, 2022 at 06:07:49PM +0300, Vitaliy Makkoveev wrote:
> Yes please. Also I like (*pr_usrreq)() be splitted to multiple handlers.
With all you feedback diff looks like this now.
bluhm
Index: kern/uipc_socket.c
===
RCS fi
So this is the final verison of the patch solving the following
problems:
>The program is broken in multiple ways: return value clamping, casting
>from double to uint32_t, wrong error checking for putchar, lack of
>warnings when compiling.
Now the program is more pedantic and complicated, but at
On 05/08/22(Fri) 18:10, Sebastien Marie wrote:
> Hi,
>
> When initially ported blist from DragonFlyBSD, we used custom type bsblk_t
> and
> bsbmp_t instead of the one used by DragonFlyBSD (swblk_t and u_swblk_t).
>
> The reason was swblk_t is already defined on OpenBSD, and was incompatible
>
On Tue, Jun 21, 2022 at 02:58:46PM +1000, Jonathan Gray wrote:
> Intel CPUs used to have strings like
> cpu0: Intel(R) Pentium(R) M processor 1200MHz ("GenuineIntel" 686-class) 1.20
> GHz
> cpu0: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 2494.61 MHz, 06-3d-04
> recent CPUs use
> cpu0: 11th Gen Int
On Fri, Aug 05, 2022 at 10:00:26AM -0600, Theo de Raadt wrote:
> For it to be an advantage, it must have actually helped at least once.
> Did it find any pieces of code casting a struct mbuf * to a sockaddr *,
> or similar?
I started to care about satosin with this bug:
https://marc.info/?l=openb
Hi,
When initially ported blist from DragonFlyBSD, we used custom type bsblk_t and
bsbmp_t instead of the one used by DragonFlyBSD (swblk_t and u_swblk_t).
The reason was swblk_t is already defined on OpenBSD, and was incompatible with
blist (int32_t). It is defined, but not used (outside some
Alexander Bluhm wrote:
> On Fri, Aug 05, 2022 at 09:03:03AM -0600, Theo de Raadt wrote:
> > But I also disagree with the idea of wrapping a trivial piece of C into
> > a function located in another header file
>
> I added many of them a few years ago. We have them for all sockaddr
> derivates.
On Thu, Aug 04, 2022 at 02:19:58PM +, Klemens Nanni wrote:
> IPv6 pendant to bluhm's sys/netinet/if_ether.c r1.249:
> Instead of calling getuptime() all the time in ARP code, do it only
> once per function. This gives a more consistent time value.
> OK claudio@ miod@ mvs@
>
> Feed
On Fri, Aug 05, 2022 at 09:03:03AM -0600, Theo de Raadt wrote:
> But I also disagree with the idea of wrapping a trivial piece of C into
> a function located in another header file
I added many of them a few years ago. We have them for all sockaddr
derivates. They are handy when doing network pr
On Fri, Aug 05, 2022 at 02:51:14PM +, Klemens Nanni wrote:
> On Fri, Aug 05, 2022 at 08:08:17AM -0600, Theo de Raadt wrote:
> > I struggle to see any value of this concept: If you put a cast in-line
> > in the code, as a coder you can know what it means. But if you abstract
> > the typecast t
Klemens Nanni wrote:
> satosin(), sin6tosa(), etc. are convenient helpers to avoid manually
> casting all over the place.
>
> struct sockaddr aka. sa, struct sockaddr_in6 aka. sin6, etc. are well
> known abbreviations in networking code.
Your diff does not touch satosin.
You are mentioning the
On Fri, Aug 05, 2022 at 08:08:17AM -0600, Theo de Raadt wrote:
> I struggle to see any value of this concept: If you put a cast in-line
> in the code, as a coder you can know what it means. But if you abstract
> the typecast to some function in a header file, how do you remember
> that it only do
Andre Stoebe wrote:
> So I added unveil and removed the limitation on forward slashes as well
> as symbolic links when using the -d option. I believe (please correct me
> if I'm wrong) these limitations were added to prevent breaking out of
> the directory while keeping the code simple. With unve
Hi,
To make protocol input functions MP safe, internet PCB need protection.
Let's use their reference counter in more places.
The in_pcb lookup functions hold the PCBs in hash tables protected
by table->inpt_mtx mutex. Whenever a result is returned, increment
the ref count before releasing the m
I struggle to see any value of this concept: If you put a cast in-line
in the code, as a coder you can know what it means. But if you abstract
the typecast to some function in a header file, how do you remember
that it only does a typecast, and doesn't do something else? I think this
is a foolis
satosin() gets a satocin() sibling, satosdl() gets satocsdl(), etc.
These inline functions are identical except the const version expects
and returns a pointer to a const struct.
This only adds unused inline functions be used in upcoming commits,
where we can then more easily add const to functio
On Thu, Aug 04, 2022 at 07:26:23PM +0200, Stefan Sperling wrote:
> This adds support for booting from RAID 1C volumes on amd64.
> Only boot-loader changes are needed. Both installboot(8) and
> the kernel already do what is required to make this work.
>
> I have tested with biosboot in vmm. The cha
All of them are passed to inspect/copy out fields, none of the functions
writes to the struct.
This makes it easier to argue about code (in MP context) and syncs ND6 code
with NetBSD and FreeBSD.
Builds and runs fine on sparc64.
Feedback? OK?
diff --git a/sys/netinet6/nd6.c b/sys/netinet6/nd6.c
On Fri, Aug 05, 2022 at 03:37:41AM +0200, Theo Buehler wrote:
> On Fri, Aug 05, 2022 at 03:34:57AM +0200, Theo Buehler wrote:
> > If you want games, opt into it. They are very old, full of bugs and not
> > really maintained. It's very easy to get a PATH containing games via
> > /etc/skel. I think t
34 matches
Mail list logo
