On Tue, Dec 15, 2020 at 10:59:50PM +, Stuart Henderson wrote:
> On 2020/12/15 23:07, Jan Klemkow wrote:
> > for frequent performance test it would be nice to just start tcpbench
> > as a regular service. tcpbench gets an extra user and group with this
> > diff and is already pledged to
On Tue, Dec 15, 2020 at 03:43:38PM -0700, Theo de Raadt wrote:
> Jan Klemkow wrote:
>
> > for frequent performance test it would be nice to just start tcpbench
> > as a regular service. tcpbench gets an extra user and group with this
> > diff and is already pledged to "stdio". Thus, there
Hi,
for frequent performance test it would be nice to just start tcpbench
as a regular service. tcpbench gets an extra user and group with this
diff and is already pledged to "stdio". Thus, there should be no
security risk to do this even in hostile environments.
OK?
bye,
Jan
Index:
On 2020/12/15 17:19, Theo de Raadt wrote:
> Stuart Henderson wrote:
>
> > On 2020/12/15 16:33, Theo de Raadt wrote:
> > > Jan Klemkow wrote:
> > >
> > > > On Tue, Dec 15, 2020 at 03:43:38PM -0700, Theo de Raadt wrote:
> > > > > Jan Klemkow wrote:
> > > > >
> > > > > > for frequent
Stuart Henderson wrote:
> On 2020/12/15 16:33, Theo de Raadt wrote:
> > Jan Klemkow wrote:
> >
> > > On Tue, Dec 15, 2020 at 03:43:38PM -0700, Theo de Raadt wrote:
> > > > Jan Klemkow wrote:
> > > >
> > > > > for frequent performance test it would be nice to just start tcpbench
> > > > > as
On 2020/12/15 16:33, Theo de Raadt wrote:
> Jan Klemkow wrote:
>
> > On Tue, Dec 15, 2020 at 03:43:38PM -0700, Theo de Raadt wrote:
> > > Jan Klemkow wrote:
> > >
> > > > for frequent performance test it would be nice to just start tcpbench
> > > > as a regular service. tcpbench gets an extra
On Tue, 15 Dec 2020 at 15:03, Mark Kettenis wrote:
>
>
> Thanks. This is committed now. However, there may be other case
> where we use uvm_km_valloc() early on that will trip over the kernel
> lock assertion that mpi@ added in uvm_km_pgremove(). Ideally we
> should get rid of all the
Jan Klemkow wrote:
> On Tue, Dec 15, 2020 at 03:43:38PM -0700, Theo de Raadt wrote:
> > Jan Klemkow wrote:
> >
> > > for frequent performance test it would be nice to just start tcpbench
> > > as a regular service. tcpbench gets an extra user and group with this
> > > diff and is already
> Date: Tue, 15 Dec 2020 21:21:37 +0100
> From: Alexander Bluhm
>
> On Tue, Dec 15, 2020 at 06:57:03PM +0100, Mark Kettenis wrote:
> > Does the diff below fix this?
>
> I can reproduce the panic and your diff fixes it.
>
> Usually my regress machines do not trigger it as I do not install
>
On 2020/12/15 23:07, Jan Klemkow wrote:
> Hi,
>
> for frequent performance test it would be nice to just start tcpbench
> as a regular service. tcpbench gets an extra user and group with this
> diff and is already pledged to "stdio". Thus, there should be no
> security risk to do this even in
Jan Klemkow wrote:
> for frequent performance test it would be nice to just start tcpbench
> as a regular service. tcpbench gets an extra user and group with this
> diff and is already pledged to "stdio". Thus, there should be no
> security risk to do this even in hostile environments.
You're
Hi all
When using the 'combined' or 'forwarded' log style, the request,
referrer and user-agent are all wrapped in double-quotes (") like this:
ifconfig.se 127.0.0.1 - - [15/Dec/2020:22:38:54 +0100] "GET / HTTP/1.1" 200
6320 "Referrer" "User-Agent" 10.0.10.5 -
Since all three are provided by
On 15/12/20(Tue) 16:30, Mark Kettenis wrote:
> > Date: Tue, 15 Dec 2020 12:15:30 -0300
> > From: Martin Pieuchot
> >
> > When the first thread of multimedia/mpv exits after having played a video
> > with the "gpu" (default) output, the programs receives a SIGSEV when it
> > tries to execute one
Hello,
I am investigating a usb issue on my imx6-based novena, and I tried to
set a breakpoint to inspect the backtrace when the issue occurs. The
problem is, when resuming execution out of ddb, I get a uvm_fault and
then the only way forward is to reboot the system.
Am I missing a step ? or is
On Tue, Dec 15, 2020 at 06:57:03PM +0100, Mark Kettenis wrote:
> Does the diff below fix this?
I can reproduce the panic and your diff fixes it.
Usually my regress machines do not trigger it as I do not install
firmware. fw_update and reboot makes it crash.
bluhm
OpenBSD 6.8-current
On 15.12.2020. 18:57, Mark Kettenis wrote:
>> From: jungle Boogie
>> Date: Tue, 15 Dec 2020 08:07:04 -0800
>>
>> Hi All,
>>
>> On my i386 Toshiba netbook machine, I am getting a kernel panic with
>> the latest i386 snapshot.
>>
>> I hope this information helps someone with the issue.
>>
>>> show
> From: jungle Boogie
> Date: Tue, 15 Dec 2020 08:07:04 -0800
>
> Hi All,
>
> On my i386 Toshiba netbook machine, I am getting a kernel panic with
> the latest i386 snapshot.
>
> I hope this information helps someone with the issue.
>
> > show panic
> kernel diagnostic assertion
On Tue, Dec 15, 2020 at 01:47:24PM +0100, Mark Kettenis wrote:
> > Date: Tue, 15 Dec 2020 13:32:22 +0100
> > From: Claudio Jeker
> >
> > On Fri, Dec 11, 2020 at 07:07:56PM -0600, Scott Cheloha wrote:
> > > Hi,
> > >
> > > I'd like to remove lbolt from the kernel. I think having it in the
> > >
On Tue, Dec 15, 2020 at 09:58:16AM -0300, Martin Pieuchot wrote:
> On 11/12/20(Fri) 17:37, Visa Hankala wrote:
> > Index: kern/kern_event.c
> > ===
> > RCS file: src/sys/kern/kern_event.c,v
> > retrieving revision 1.147
> > diff -u -p
On Tue, Dec 15, 2020 at 07:46:01AM -0300, Martin Pieuchot wrote:
> @@ -636,43 +651,59 @@ dopselect(struct proc *p, int nd, fd_set
> if (sigmask)
> dosigsuspend(p, *sigmask &~ sigcantmask);
>
> -retry:
> - ncoll = nselcoll;
> - atomic_setbits_int(>p_flag, P_SELECT);
>
On 15.12.2020. 17:07, jungle Boogie wrote:
> Hi All,
>
> On my i386 Toshiba netbook machine, I am getting a kernel panic with
> the latest i386 snapshot.
>
> I hope this information helps someone with the issue.
>
>> show panic
> kernel diagnostic assertion "_kernel_lock_held()" failed:
>
On 15 December 2020 14:56:41 CET, Stuart Henderson wrote:
>On 2020/12/15 10:18, Solene Rapenne wrote:
>> This is a small change to acme-client(1) because I find
>> the explanation of -F flag not being obvious that you
>> need it when you add/remove an alternative name in your
>> domain config.
Hi,
I took on old idea and diff [1] from bluhm and finished it for the IPv4
case.
This change uses mbuf chains in tcp/ip/ether_output instead of single
mbufs. This approach takes lesser processing power per packets, which
we want to send out. In several code path it optimises the
processing
Hi All,
On my i386 Toshiba netbook machine, I am getting a kernel panic with
the latest i386 snapshot.
I hope this information helps someone with the issue.
> show panic
kernel diagnostic assertion "_kernel_lock_held()" failed:
"/usr/src/sys/uvm/uvm_km.c", line 246
> bt
On Mon, Dec 14, 2020 at 06:22:09PM +, Job Snijders wrote:
> Hi all,
>
> This patch appears to be a very elegant solution to a thorny subtle
> problem: what to do when a peer is not accepting new routing information
> from you?
One thing I'm unsure about is the value of the SendHold timer. I
> Date: Tue, 15 Dec 2020 12:15:30 -0300
> From: Martin Pieuchot
>
> When the first thread of multimedia/mpv exits after having played a video
> with the "gpu" (default) output, the programs receives a SIGSEV when it
> tries to execute one of its destructor:
>
> void
>
When the first thread of multimedia/mpv exits after having played a video
with the "gpu" (default) output, the programs receives a SIGSEV when it
tries to execute one of its destructor:
void
_rthread_tls_destructors(pthread_t thread)
{
[...]
for (i = 0; i <
On 2020/12/15 10:18, Solene Rapenne wrote:
> This is a small change to acme-client(1) because I find
> the explanation of -F flag not being obvious that you
> need it when you add/remove an alternative name in your
> domain config.
This only works directly for adding. For removal you need to rm
On Tue, Dec 15, 2020 at 10:18:41AM +0100, Solene Rapenne wrote:
> This is a small change to acme-client(1) because I find
> the explanation of -F flag not being obvious that you
> need it when you add/remove an alternative name in your
> domain config.
>
> Maybe wording could be better, if a
On Sat, Dec 12, 2020 at 09:20:26PM -0500, Aisha Tammy wrote:
> Hi,
> ?? While creating a portable version of imsg, I noticed
> a small typo in the imsg_init.3 man page which says
> the returned value is 'len' instead of 'datalen'.
> Attached the patch to fix it.
>
> OK?
>
fixed, thanks.
jmc
>
On Tue, 2020-12-15 at 15:10 +0300, Vadim Zhukov wrote:
> > I very rarely use fortune and I'm not familiar with the codebase, but
> > from some quick testing and code-scanning I found the following:
> > is_fortfile appends .dat to the input file and sees if it's accessible.
> > Adding a symlink to
This is a small change to acme-client(1) because I find
the explanation of -F flag not being obvious that you
need it when you add/remove an alternative name in your
domain config.
Maybe wording could be better, if a native English
speaker could give it a look.
ok?
Index: acme-client.1
On 11/12/20(Fri) 17:37, Visa Hankala wrote:
> This patch extends struct klist with a callback descriptor and
> an argument. The main purpose of this is to let the kqueue subsystem
> assert when a klist should be locked, and operate the klist lock
> in klist_invalidate().
Lovely!
> Access to a
> Date: Tue, 15 Dec 2020 13:32:22 +0100
> From: Claudio Jeker
>
> On Fri, Dec 11, 2020 at 07:07:56PM -0600, Scott Cheloha wrote:
> > Hi,
> >
> > I'd like to remove lbolt from the kernel. I think having it in the
> > kernel complicates otherwise simple code.
> >
> > We can start with sdmmc(4).
On Fri, Dec 11, 2020 at 07:07:56PM -0600, Scott Cheloha wrote:
> Hi,
>
> I'd like to remove lbolt from the kernel. I think having it in the
> kernel complicates otherwise simple code.
>
> We can start with sdmmc(4).
>
> The goal in sdmmc_io_function_enable() is calling
On 11/12/20(Fri) 19:17, Scott Cheloha wrote:
> Here's another sleep that doesn't need lbolt.
>
> The idea here is to call apm_periodic_check() once a second.
> We can do that without lbolt.
>
> Is there some other address that would be more appropriate for this
> thread to sleep on? It doesn't
On 11/12/20(Fri) 19:07, Scott Cheloha wrote:
> I'd like to remove lbolt from the kernel. I think having it in the
> kernel complicates otherwise simple code.
Decoupling code is IMHO a good thing. I like this move.
> We can start with sdmmc(4).
>
> The goal in sdmmc_io_function_enable() is
> I very rarely use fortune and I'm not familiar with the codebase, but
> from some quick testing and code-scanning I found the following:
> is_fortfile appends .dat to the input file and sees if it's accessible.
> Adding a symlink to the corresponding .dat file make the thing work
> perfectly
On 12/12/20(Sat) 11:29, Visa Hankala wrote:
> On Fri, Dec 11, 2020 at 09:35:59AM -0300, Martin Pieuchot wrote:
> > On 10/12/20(Thu) 09:59, Martin Pieuchot wrote:
> > > All previous kqueue refactoring have been committed, here's a final diff
> > > to modify the internal implementation of
I very rarely use fortune and I'm not familiar with the codebase, but
from some quick testing and code-scanning I found the following:
is_fortfile appends .dat to the input file and sees if it's accessible.
Adding a symlink to the corresponding .dat file make the thing work
perfectly well for me.
40 matches
Mail list logo
