On 8.7.2021. 0:10, Vitaliy Makkoveev wrote:
> On Wed, Jul 07, 2021 at 11:07:08PM +0200, Hrvoje Popovski wrote:
>> On 7.7.2021. 22:36, Vitaliy Makkoveev wrote:
>>> Thanks. ipsp_spd_lookup() stopped panic in pool_get(9).
>>>
>>> I guess the panics continue because simultaneous modifications of
>>> 't
Hi,
The properties of the crypto algorithms never change. So they can
be declared constant and mapped as read only.
ok?
bluhm
Index: arch/amd64/amd64/aesni.c
===
RCS file: /data/mirror/openbsd/cvs/src/sys/arch/amd64/amd64/aesni.c,
One issue I have on amd64 while trying to build the kernel with all uvmexp
members promoted to uint64_t is the use of atomic operations. For example,
swpgonly is modified atomically in several places and those expect an int. I
think only a few members are accessed in this way.
On Sat, Jul 03, 2021
On Wed, Jul 07, 2021 at 11:07:08PM +0200, Hrvoje Popovski wrote:
> On 7.7.2021. 22:36, Vitaliy Makkoveev wrote:
> > Thanks. ipsp_spd_lookup() stopped panic in pool_get(9).
> >
> > I guess the panics continue because simultaneous modifications of
> > 'tdbp->tdb_policy_head' break it. Could you try
On 7.7.2021. 22:36, Vitaliy Makkoveev wrote:
> Thanks. ipsp_spd_lookup() stopped panic in pool_get(9).
>
> I guess the panics continue because simultaneous modifications of
> 'tdbp->tdb_policy_head' break it. Could you try the diff below? It
> introduces `tdb_polhd_mtx' mutex(9) and uses it to pro
On Wed, Jul 07, 2021 at 10:01:59PM +0200, Hrvoje Popovski wrote:
> On 7.7.2021. 19:38, Vitaliy Makkoveev wrote:
> > Hi,
> >
> > It seems the first the first panic occured because ipsp_spd_lookup()
> > modifies tdbp->tdb_policy_head and simultaneous execution breaks it.
> > I guess at least mutex(9
On Tue, Jul 06, 2021 at 11:05:47PM +0200, Alexander Bluhm wrote:
> Hi,
>
> Thank a lot to Hrvoje Popovski for testing my diff and to sashan@
> and dlg@ for fixing all the fallout in pf and pseudo drivers.
>
> Are there any bugs left? I think everything has been fixed.
>
I've just committed
On Wed, Jul 07, 2021 at 01:15:00PM -0700, Chris Cappuccio wrote:
> Alexandr Nedvedicky [alexandr.nedvedi...@oracle.com] wrote:
> > diff --git a/sys/net/if_tpmr.c b/sys/net/if_tpmr.c
> > index f6eb99f347c..4ffa5b18293 100644
> > @@ -725,10 +759,9 @@ tpmr_p_dtor(struct tpmr_softc *sc, struct tpmr_por
Alexandr Nedvedicky [alexandr.nedvedi...@oracle.com] wrote:
> diff --git a/sys/net/if_tpmr.c b/sys/net/if_tpmr.c
> index f6eb99f347c..4ffa5b18293 100644
> @@ -725,10 +759,9 @@ tpmr_p_dtor(struct tpmr_softc *sc, struct tpmr_port *p,
> const char *op)
> if_detachhook_del(ifp0, &p->p_dtask);
>
On 7.7.2021. 19:38, Vitaliy Makkoveev wrote:
> Hi,
>
> It seems the first the first panic occured because ipsp_spd_lookup()
> modifies tdbp->tdb_policy_head and simultaneous execution breaks it.
> I guess at least mutex(9) should be used to protect `tdb_policy_head'.
>
> The second panic occured
On Wed, Jul 07, 2021 at 08:38:23PM +0300, Vitaliy Makkoveev wrote:
> The second panic occured because ipsp_acquire_sa() does
> `ipsec_acquire_pool' initialization in runtime so parallel execution
> breaks it. It's easy to fix.
>
> Could you try the diff below? It moves `ipsec_acquire_pool'
> initi
Hello,
On Wed, Jul 07, 2021 at 06:14:35PM +0200, Alexander Bluhm wrote:
> On Wed, Jul 07, 2021 at 10:20:01AM +0200, Alexandr Nedvedicky wrote:
> > we still need to agree on whether pf_test() can sleep (give up CPU),
> > when processing packet. I don't mind if pf_test() gives up CPU (sleeps
On Wed, Jul 07, 2021 at 02:09:23PM +0200, Alexander Bluhm wrote:
> On Wed, Jul 07, 2021 at 12:52:26PM +0200, Hrvoje Popovski wrote:
> > On 7.7.2021. 12:46, Hrvoje Popovski wrote:
> > > Panic can be triggered when i have parallel diff and sending traffic
> > Different panic on same setup ...
>
> Th
On Wed, Jul 07, 2021 at 10:20:01AM +0200, Alexandr Nedvedicky wrote:
> we still need to agree on whether pf_test() can sleep (give up CPU),
> when processing packet. I don't mind if pf_test() gives up CPU (sleeps),
> when waiting for other packets to finish their business in pf(4).
I t
On Wed, Jul 07, 2021 at 03:13:37PM +0100, Edd Barrett wrote:
> Hi,
>
> This diff is an attempt to make identifying audio devices easier by
> giving each device a human-readable description that can be read from
> userspace (and without scraping dmesg).
>
> This is implemented on a per-audio-devic
On Wed, Jul 07, 2021 at 08:25:16AM -0600, Theo de Raadt wrote:
> > This diff is an attempt to make identifying audio devices easier by
> > giving each device a human-readable description that can be read from
> > userspace (and without scraping dmesg).
>
> But why does anyone want that?
>
> Isn't
> This diff is an attempt to make identifying audio devices easier by
> giving each device a human-readable description that can be read from
> userspace (and without scraping dmesg).
But why does anyone want that?
Isn't everyone served best when there is a public portable interface,
and all the
Hi,
This diff is an attempt to make identifying audio devices easier by
giving each device a human-readable description that can be read from
userspace (and without scraping dmesg).
This is implemented on a per-audio-device basis using a new `descr`
interface to `audio_hw_if`. For now I've only i
On Wed, Jul 07, 2021 at 12:52:26PM +0200, Hrvoje Popovski wrote:
> On 7.7.2021. 12:46, Hrvoje Popovski wrote:
> > Panic can be triggered when i have parallel diff and sending traffic
> Different panic on same setup ...
Thanks a lot for the report.
I can see the same stop of traffic and crashes he
On 7.7.2021. 12:46, Hrvoje Popovski wrote:
> Panic can be triggered when i have parallel diff and sending traffic
> over ipsec tunnel and on other side while traffic is flowing i'm
> restarting isakmpd daemon and while negotiating ipsec doing ifconfig ix1
> down && ifconfig ix1 up ... sometimes it
Hi,
i don't want to pollute bluhm@ parallel forwarding mail on tech@ so i'm
sending this report as a separate thread. this panic it's dependent on
bluhm@ parallel diff ... and i found it yesterday
I'm having ipsec tunnel between two hosts without pf and i'm sending
traffic over that tunnel .. i'm
Hello,
On Tue, Jul 06, 2021 at 11:05:47PM +0200, Alexander Bluhm wrote:
> Hi,
>
> Thank a lot to Hrvoje Popovski for testing my diff and to sashan@
> and dlg@ for fixing all the fallout in pf and pseudo drivers.
>
> Are there any bugs left? I think everything has been fixed.
>
there is on
22 matches
Mail list logo
