Re: libressl: crash in DES_fcrypt

Thank you Jan. This is a good thing to fix, but I had a hard time envisioning a security issue with it. Will see about backporting it though. Regards - Brent > On Oct 26, 2017, at 6:50 PM, Jan Engelhardt wrote: > > > libressl-2.6.2 is susceptible to an out-of-bounds read: >

primes: use strtonum(3)

Hi, This seems like a textbook case for strtonum(3). Change in behavior: when the start value is read from stdin, trailing whitespace is now an error instead of being ignored. I can revise the diff to stub out the trailing whitespace before strtonum(3) sees it, though, if that's preferable. Any

Re: ctfconv(1) & forward declaration

On Sun, Oct 29, 2017 at 10:48:09PM +0100, Martin Pieuchot wrote: > On 29/10/17(Sun) 17:27, Mark Johnston wrote: > > On Sat, Oct 28, 2017 at 04:05:23PM +0200, Martin Pieuchot wrote: > > > Diff below makes ctfconv(1) aware of forward declarations and merge them > > > with the corresponding type as

Re: ctfconv(1) & forward declaration

On 29/10/17(Sun) 17:27, Mark Johnston wrote: > On Sat, Oct 28, 2017 at 04:05:23PM +0200, Martin Pieuchot wrote: > > Diff below makes ctfconv(1) aware of forward declarations and merge them > > with the corresponding type as soon as they are known. > > > > This reduces the number of type entries

Re: ctfconv(1) & forward declaration

On Sat, Oct 28, 2017 at 04:05:23PM +0200, Martin Pieuchot wrote: > Diff below makes ctfconv(1) aware of forward declarations and merge them > with the corresponding type as soon as they are known. > > This reduces the number of type entries in a kernel CTF section by ~4K. > > After applying this

Re: kill net/slip.h

On Sun, Oct 29 2017, Martin Pieuchot wrote: > contains a handful of defines optionally used by > tcpdump(8). Nothing in codesearch.debian.net includes it. > > So I'd like to remove it, to reduce the number of network headers. > > ok? ok -- jca | PGP : 0x1524E7EE / 5135

Re: pms: reset announcement

Looks fine to me. I made some tests on a T420, with explicitly triggered resets, and the detection and the "reset task" worked as expected. There are noticeable delays, but I don't think optimizing would be worth the effort (if it happens too often, you may want to repair or exchange your

remove NET_LOCK from ip_slowtimo()

on top of previous... OK? diff --git netinet/ip_input.c netinet/ip_input.c index dc1bb9d8ec1..95c9194efcb 100644 --- netinet/ip_input.c +++ netinet/ip_input.c @@ -1028,7 +1028,6 @@ ip_slowtimo(void) { struct ipq *fp, *nfp; - NET_LOCK(); mtx_enter(_mutex);

move NET_LOCK into pr_{slow,fast}timo() functions

intentionally (mostly) mechanical OK? diff --git kern/uipc_domain.c kern/uipc_domain.c index 4cfbe5de4ff..0f4d05f7492 100644 --- kern/uipc_domain.c +++ kern/uipc_domain.c @@ -238,13 +238,11 @@ pfslowtimo(void *arg) struct protosw *pr; int i; - NET_LOCK(); for (i =

Re: Implement VFS read clustering for MSDOSFS, third try

On 15/08/17(Tue) 17:20, Stefan Fritsch wrote: > Hi, > > this is another try at making read clustering work for msdosfs. > > Last year, mpi@ implemented VFS read clustering for MSDOSFS in > > sys/msdosfs/denode.h 1.28 > sys/msdosfs/msdosfs_vnops.c 1.105 > > This caused regressions when doing

Re: [PATCH] intel_uncore.c - Horrible, ugly hack to avoid dmesg spam

Enough lines are printed out to completely fill the dmesg buffer as such: % dmesg | sort -n | uniq -c 6 error: [drm:pid22060:intel_uncore_check_errors] *ERROR* Unclaimed register before interrupt 209 error: [drm:pid25769:intel_uncore_check_errors] *ERROR* Unclaimed register before

kill net/slip.h

contains a handful of defines optionally used by tcpdump(8). Nothing in codesearch.debian.net includes it. So I'd like to remove it, to reduce the number of network headers. ok? Index: sys/net/slip.h === RCS file: sys/net/slip.h

pms: reset announcement

Hi, Every now and then, my Synaptics touchpad stops working and no further interrupts are received for the device. The following message appears in the log: pms0: not in sync yet, discard input (state = 0) Examining the bytes received prior to the halt reveals the sequence [0xaa, 0x00] which

Re: [PATCH] intel_uncore.c - Horrible, ugly hack to avoid dmesg spam

On 29/10/17(Sun) 14:20, Bryan Linton wrote: > Hello tech@ > > First, I want to say that I'm in no way advocating that this patch > be committed to the tree. I'm sending it solely for the others > who have encountered the same issue I have. It's only purpose is > to suppress dmesg spam on boot

[PATCH] ratecheck.9 - Fix variable names in EXAMPLES

Hello tech@, I noticed that the EXAMPLE in the ratecheck.9 manual page declares the following variables: struct timeval drv_lasterr1time; /* time of last err1 message */ struct timeval drv_lasterr2time; /* time of last err2 message */ However the code later on actually uses the following

Re: [PATCH] intel_uncore.c - Horrible, ugly hack to avoid dmesg spam

On 2017-10-29 06:40:35, Miod Vallat wrote: > > The patch below simply stops printing additional messages after 10 > > lines have been printed. > > > > You might want to use ratecheck(9) rather than a simple limit. > Done. Thanks for the tip! -- Bryan Index: intel_uncore.c

Re: [PATCH] intel_uncore.c - Horrible, ugly hack to avoid dmesg spam

> The patch below simply stops printing additional messages after 10 > lines have been printed. > You might want to use ratecheck(9) rather than a simple limit.