> This actually breaks my machine. malloc() is saying allocation too
> large. OF_getproplen will return -1 on that. Is it possible that
> len is treated as uint64_t as it is an int and sizeof is effectively
> uint64_t?
Ah, yes; size_t is unsigned and wider than int on 64-bit platforms,
On Thu, Nov 10, 2022 at 03:10:32PM -0500, Josiah Frentsos wrote:
> Index: tmux.1
> ===
> RCS file: /cvs/src/usr.bin/tmux/tmux.1,v
> retrieving revision 1.905
> diff -u -p -r1.905 tmux.1
> --- tmux.13 Nov 2022 08:33:57 -
On Thu, Nov 10, 2022 at 02:56:00PM +, Klemens Nanni wrote:
> No point in using the variable for half of the check.
>
> OK?
OK bluhm@
> diff --git a/sys/netinet6/nd6.c b/sys/netinet6/nd6.c
> index e65eeb0c2ac..d88969be617 100644
> --- a/sys/netinet6/nd6.c
> +++ b/sys/netinet6/nd6.c
> @@
Index: tmux.1
===
RCS file: /cvs/src/usr.bin/tmux/tmux.1,v
retrieving revision 1.905
diff -u -p -r1.905 tmux.1
--- tmux.1 3 Nov 2022 08:33:57 - 1.905
+++ tmux.1 10 Nov 2022 20:07:56 -
@@ -23,7 +23,7 @@
.Sh
Hi Scott,
thanks for repeatedly working on time-related library documentation. :-)
Unless noted otherwise, i agree with Todd's comments.
Todd C. Miller wrote on Wed, Nov 09, 2022 at 10:31:15AM -0700:
> On Wed, 09 Nov 2022 16:47:22 +, Scott Cheloha wrote:
>> RETURN VALUES
>>
>> - Pull
On Thu, Nov 10, 2022 at 04:52:13PM +, ssnf wrote:
> Content-Disposition: attachment; filename=fuck
First you fail to provide a proper bug report, so I couldn't help you.
Now you hijack with your mail retitled "fuck", so I won't help you.
On Thu, Nov 10, 2022 at 05:13:40PM +, Patrick Wildt wrote:
> There are other drivers with intro after others. Are we sorting those
> alphabetically or by relevancy?
Which ones?
On Thu, Nov 10, 2022 at 05:13:40PM +, Patrick Wildt wrote:
> There are other drivers with intro after others. Are we sorting those
> alphabetically or by relevancy?
>
alphabetically, and in section order. i am kinda busy at the mo, if
anyone wants to fix these...
jmc
> Von meinem iPhone
There are other drivers with intro after others. Are we sorting those
alphabetically or by relevancy?
Von meinem iPhone gesendet
> Am 10.11.2022 um 16:46 schrieb Josiah Frentsos :
>
> Index: qcpmic.4
> ===
> RCS file:
> On Wed, Nov 09, 2022 at 02:36:57PM +, ssnf wrote:
> > My softraid keydisk did not get initialized during the install process.
> > This fixes it.
>
> On 22/11/09 07:28PM, Klemens Nanni wrote:
> You need to be more specific, installing to a softraid volume has always
> required manual steps,
Index: qcpmic.4
===
RCS file: /cvs/src/share/man/man4/qcpmic.4,v
retrieving revision 1.2
diff -u -p -r1.2 qcpmic.4
--- qcpmic.410 Nov 2022 13:08:57 - 1.2
+++ qcpmic.410 Nov 2022 16:43:07 -
@@ -34,12 +34,12 @@
On Fri, Nov 04, 2022 at 03:40:04PM +0100, Claudio Jeker wrote:
> So mpe(4) is a special device. It is a point-to-multipoint interface that
> does not do multicast. So setting IFF_MULTICAST on the interface is not
> correct but IPv6 depends on it because neighbor discovery.
>
> Now there is no
On Thu, Nov 10, 2022 at 11:59:02PM +1000, David Gwynne wrote:
> On Thu, Nov 10, 2022 at 09:04:22PM +1000, David Gwynne wrote:
> > On Thu, Nov 10, 2022 at 08:10:35AM +1000, David Gwynne wrote:
> > > I know what this is. The barrier at the end of if_idxmap_alloc is
> > > sleeping waiting for cpus
Purely mechanical except for the early function-local sockaddr dance,
same story as with the previous nd6_ioctl() push.
Feedback? OK?
---
sys/netinet6/in6.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sys/netinet6/in6.c b/sys/netinet6/in6.c
index
Purely mechanical except for the early function-local sockaddr dance.
Feedback? OK?
---
sys/netinet6/in6.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sys/netinet6/in6.c b/sys/netinet6/in6.c
index 9e2691c5964..a3737914828 100644
--- a/sys/netinet6/in6.c
+++
On Mon, Jul 04, 2022 at 06:47:33PM +, Miod Vallat wrote:
> When the fdt does not provide a list of brightness states, pwmbl(4)
> builds a 256 state ramp (i.e. state[i] = i with 0 <= i < 256).
>
> The following diff keeps that behaviour, but gets rid of the malloc
> call for that ramp, since
No point in using the variable for half of the check.
OK?
diff --git a/sys/netinet6/nd6.c b/sys/netinet6/nd6.c
index e65eeb0c2ac..d88969be617 100644
--- a/sys/netinet6/nd6.c
+++ b/sys/netinet6/nd6.c
@@ -1025,24 +1025,24 @@ nd6_ioctl(u_long cmd, caddr_t data, struct ifnet *ifp)
case
On 10.11.2022. 14:59, David Gwynne wrote:
> On Thu, Nov 10, 2022 at 09:04:22PM +1000, David Gwynne wrote:
>> On Thu, Nov 10, 2022 at 08:10:35AM +1000, David Gwynne wrote:
>>> I know what this is. The barrier at the end of if_idxmap_alloc is sleeping
>>> waiting for cpus to run that aren't running
ping...
On Fri, Nov 04, 2022 at 10:04:35PM +0300, Vitaliy Makkoveev wrote:
> Each pflow(4) interface has associated socket, referenced as sc->so. We
> set this socket in pflowioctl() which is called with both kernel and net
> locks held. In the pflow_output_process() task we do sc->so
On Thu, Nov 10, 2022 at 09:04:22PM +1000, David Gwynne wrote:
> On Thu, Nov 10, 2022 at 08:10:35AM +1000, David Gwynne wrote:
> > I know what this is. The barrier at the end of if_idxmap_alloc is sleeping
> > waiting for cpus to run that aren't running cos we haven't finished booting
> > yet.
>
Yes please. ok dlg@.
> On 10 Nov 2022, at 10:10 pm, Alexandr Nedvedicky wrote:
>
> Hello,
>
> David (dlg@) asked me to shrink the scope of the change. The new diff
> introduces a mutex to pf_state and adjust pf_detach_state() to utilize the
> newly introduced mutex. I've also added
> On 10 Nov 2022, at 10:56 pm, Claudio Jeker wrote:
>
> On Fri, Nov 04, 2022 at 03:40:04PM +0100, Claudio Jeker wrote:
>> So mpe(4) is a special device. It is a point-to-multipoint interface that
>> does not do multicast. So setting IFF_MULTICAST on the interface is not
>> correct but IPv6
On Fri, Nov 04, 2022 at 03:40:04PM +0100, Claudio Jeker wrote:
> So mpe(4) is a special device. It is a point-to-multipoint interface that
> does not do multicast. So setting IFF_MULTICAST on the interface is not
> correct but IPv6 depends on it because neighbor discovery.
>
> Now there is no
On Thu, Nov 10, 2022 at 10:55:19AM +, Klemens Nanni wrote:
> so->so_state is already read without kernel lock inside soo_ioctl()
> which calls pru_control() aka in6_control() and in_control().
>
> This leaves individual ioctl cases to unlock/push into.
>
> Feedback? OK?
Now with the
Hello,
David (dlg@) asked me to shrink the scope of the change. The new diff
introduces a mutex to pf_state and adjust pf_detach_state() to utilize the
newly introduced mutex. I've also added annotation to pf_state members. The
members with '?' needs our attention. We need to verify if they are
On Thu, Nov 10, 2022 at 08:10:35AM +1000, David Gwynne wrote:
> I know what this is. The barrier at the end of if_idxmap_alloc is sleeping
> waiting for cpus to run that aren't running cos we haven't finished booting
> yet.
>
> I'll back it out and fix it up when I'm actually awake.
i woke up,
so->so_state is already read without kernel lock inside soo_ioctl()
which calls pru_control() aka in6_control() and in_control().
This leaves individual ioctl cases to unlock/push into.
Feedback? OK?
---
sys/netinet/in.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git
Purely mechanical, then in6_control() and in_control() can be pushed
further individually.
Feedback? OK?
---
sys/kern/sys_socket.c | 2 --
sys/netinet/in.c | 4
sys/netinet6/in6.c| 4
3 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/sys/kern/sys_socket.c
28 matches
Mail list logo