On Wed, Feb 26, 2020 at 11:41:49PM +0100, Tobias Heider wrote:
> Due to the design of the IKEv2 protocol, the receiver does not
> know which policy the initiator tries to negotiate an SA for
> until the second exchange (IKE_AUTH). The IKE_AUTH request contains
> the ID payload which the responder
Hi,
I have a patch for dump(8) if it is generally considered bad if percentage
done is over 100.0%. I checked the archives on marc.info for this and didn't
see any discussion whether this was a topic before.
Here is the odd DUMP message I got on a host:
DUMP: 102.41% done, finished in 0:00
There is a bug in how rw_exit_read() and rw_exit_write() use
WITNESS_UNLOCK(). The fast paths call WITNESS_UNLOCK() after releasing
the actual lock. This leads to a use-after-free in the checker if the
lock is dynamically allocated and another thread happens to free it
too early.
The following
This is only hiding a problem in the estimation math, rather
than fixing it.
I don't like it.
Peter J. Philipp wrote:
> Hi,
>
> I have a patch for dump(8) if it is generally considered bad if percentage
> done is over 100.0%. I checked the archives on marc.info for this and didn't
> see any
Hi,
1) pr->ps_ru is already NULL, so code can be shrunk.
2) missing timeout_del, we clear the 2 timeouts in struct process, but not from
struct proc.
3) ps_mainproc is allocated in thread_new(), passed to process_new(), and then
to process_initialize(). ps_mainproc never gets a call to
On 28/02/20(Fri) 18:24, Martin Pieuchot wrote:
> Diff below fixes multiple issues with traced process, exposed by the
> regression test attached:
>
> - When a debugging process exit, give back the traced process to its
> original parent, if it exists, instead of init(8).
>
> - When a traced
Hi,
> @@ -303,6 +312,7 @@ struct process {
> #define PS_PLEDGE 0x0010 /* Has called pledge(2) */
> #define PS_WXNEEDED 0x0020 /* Process may violate W^X */
> #define PS_EXECPLEDGE 0x0040 /* Has exec pledges */
> +#define PS_ORPHAN
