On Mon, Jun 14, 2021 at 01:19:21PM -0700, Chris Cappuccio wrote:
[..]
> If you're going to print flags for some unsupported features, why
> not print them all?
>
> The 'features3' line doesn't look clean
>
> Typically uppercase flags like this are formatted like
OK in this next patch (below) t
On 2021/06/14 19:40, Martijn van Duren wrote:
> On Mon, 2021-06-14 at 12:55 +0100, Stuart Henderson wrote:
> > By default, snmpd responds to the frequently abused community strings
> > "public" and "private".
> >
> > To prevent this, at present you must either use "seclevel auth" or
> > "seclevel
On 14/06/21(Mon) 13:45, Visa Hankala wrote:
> When a knote's kn_status is updated, it is necessary to lock the kqueue
> that owns the knote, to ensure proper serialization. filt_proc() has
> a mistake in this, and the following diff fixes it.
The fix is here to ensure `kn_status' cannot be written
On 13 Jun 19:45, Florian Obser wrote:
>
> Implement "classless static routes" dhcp option.
>
> For this we need to be able to handle multiple routes being sent from
> the engine to the main process as well as to the control tool. This also
> lets us handle multiple default routes in the "routers"
Peter J. Philipp [p...@delphinusdns.org] wrote:
>
> Before:
> pvbus0 at mainbus0: Hyper-V 10.0
> hyperv0 at pvbus0: protocol 4.0, features 0x2e7f
> hyperv0: heartbeat, kvp, shutdown, timesync
> hvs0 at hyperv0 channel 2: ide, protocol 6.2
>
> After:
>
> pvbus0 at mainbus0: Hyper-V 10.0
> hyperv0
dz...@disroot.org wrote:
> > "Theo de Raadt" wrote:
> > If it is a shared executable, you would need to encode access to ld.so
> > and all the library environment, and additional strange things used
> > during libc initialization for various subsystems.
> >
> > That would require hard-coding a l
On Mon, 2021-06-14 at 12:55 +0100, Stuart Henderson wrote:
> By default, snmpd responds to the frequently abused community strings
> "public" and "private".
>
> To prevent this, at present you must either use "seclevel auth" or
> "seclevel enc" (if you would like to only use SNMPv3), set an explic
Hi,
I may be interested in looking into hyperv since I have a MS Windows Server 2019
machine that has a hyper-v running OpenBSD (half the resources). I have two
things that would need my attention 1. the time doesn't jump when I patch the
host OS and reboot, hyperv guest gets snapshotted at boot
Currently, if an unveiled process execs another program, it doesn't
inherit the unveil paths. This means that if the unveiled process
hasn't pledged itself out of the exec syscall and it has a suitable
binary inside of its paths, it can trivially bypass unveil. Here's a
short PoC: https://gist.gith
I like it, Ok florian fwiw
--
I'm not entirely sure you are real.
> Date: Mon, 14 Jun 2021 11:53:30 +0200
> From: Martin Pieuchot
>
> The diff below introduces a new macro to generalize the test currently
> present in uvm_km_pgremove(). It also uses it in new places to reduce
> the differences with NetBSD.
>
> This helps me shrink upcoming vmobjlock diff.
>
> Date: Mon, 14 Jun 2021 11:50:24 +0200
> From: Martin Pieuchot
>
> Now that operations on amaps are serialized using a per-map rwlock
> the KERNEL_LOCK() shouldn't be necessary to call amap_unref(). The
> diff below allows the reaper to do this operation before grabbing it.
>
> I haven't seen
On Thu, May 27, 2021 at 06:24:06PM +0200, Claudio Jeker wrote:
> Implement RFC 7313 enhanced route refresh.
>
> While there also change when graceful restart EoR markers are sent.
> In short the graceful restart marker should only be sent initally. After
> that the End of Route Refresh message sho
Theo de Raadt writes:
> dz...@disroot.org wrote:
>
>> If there isn't - what about changing the kernel so unveiled paths persist
>> between execs? That would allow very easy container-like sandboxing.
>
> This last sentence bothers me a lot, I am extremely jaded having heard the
> same ideas over
dz...@disroot.org wrote:
> If there isn't - what about changing the kernel so unveiled paths persist
> between execs? That would allow very easy container-like sandboxing.
This last sentence bothers me a lot, I am extremely jaded having heard the
same ideas over and over and over.
"very easy" is
dz...@disroot.org wrote:
> Currently, if an unveiled process execs another program, it doesn't
> inherit the unveil paths. This means that if the unveiled process
> hasn't pledged itself out of the exec syscall and it has a suitable
> binary inside of its paths, it can trivially bypass unveil. Her
When a knote's kn_status is updated, it is necessary to lock the kqueue
that owns the knote, to ensure proper serialization. filt_proc() has
a mistake in this, and the following diff fixes it.
proc_filtops is MP-unsafe and all its callbacks run with the kernel
locked. The kernel lock should provid
Hi Stefan,
Did we missed the 'umac_prph_offset' constant value in
iwm_clear_persistence_bit function? From linux code, it is read_umac_prph, not
read_prph, so the function should be looks like this:
int
+iwm_clear_persistence_bit(struct iwm_softc *sc)
+{
+ uint32_t hpm, wprot;
+
+ hpm = iwm_re
By default, snmpd responds to the frequently abused community strings
"public" and "private".
To prevent this, at present you must either use "seclevel auth" or
"seclevel enc" (if you would like to only use SNMPv3), set an explicit
string for the read-only community, or set either an explicit stri
The diff below introduces a new macro to generalize the test currently
present in uvm_km_pgremove(). It also uses it in new places to reduce
the differences with NetBSD.
This helps me shrink upcoming vmobjlock diff.
ok?
Index: uvm/uvm_aobj.c
=
Now that operations on amaps are serialized using a per-map rwlock
the KERNEL_LOCK() shouldn't be necessary to call amap_unref(). The
diff below allows the reaper to do this operation before grabbing it.
I haven't seen any relevant contention on the reaper in my profilings,
so I don't expect any
Got it!
I am trying to upgrade iwx firmwares version to -59 to support future gen3
devices and I found this section, so I post the info, that's my fault, thank
you for correct me!
Regards,
zxystd
-- Original --
From: "Stefan Sperling" ;
Date: Mon, Jun 14, 2021 05
Hello,
> > it seems to me we may leak `pd` we took at line 1944. The leak
> > happens in case timeout_del() return zero.
> >
> > diff below ignores the return value from timeout_del() and makes
> > sure we always call pfsync_undefefer()
> >
> > I have not seen such panic in
On Mon, Jun 14, 2021 at 03:58:39PM +0800, zxystd wrote:
> Hi Stefan,
>
> Did we missed the 'umac_prph_offset' constant value in
> iwm_clear_persistence_bit function? From linux code, it is read_umac_prph,
> not read_prph, so the function should be looks like this:
>
> int
> +iwm_clear_persiste
Hello,
looks good to me. I think this should be committed
as-is. I have just one question,
On Mon, Jun 14, 2021 at 01:58:06PM +1000, David Gwynne wrote:
> @@ -1931,6 +1933,9 @@ pfsync_defer(struct pf_state *st, struct
> {
> struct pfsync_softc *sc = pfsyncif;
> struct pfsync_deferra
Hi,
Did we missed the 'umac_prph_offset' constant value in
iwm_clear_persistence_bit function? From linux code, it is read_umac_prph, not
read_prph, so the function should be looks like this:
int
+iwm_clear_persistence_bit(struct iwm_softc *sc)
+{
+ uint32_t hpm, wprot;
+
+ hpm = iwm_read_prph
On 10/06/21(Thu) 19:17, Alexander Bluhm wrote:
> Hi,
>
> I have seen this crash trace on a 6.6 based system, but I think the
> bug exists still in -current. It happened when an ixl(4) interface
> was removed from trunk(4).
>
> uvm_fault(0xfd8739dc6558, 0x0, 0, 1) -> e
> fatal page fault in s
27 matches
Mail list logo
