When the procfs root directory is listed using more than one getdents()
call, the process iterator can mistakenly skip a few processes. The
patch corrects this by making the index of the first process entry match
with the static procfs entries. This prevents over-winding of the
process list during
,
Visa Hankala
Index: sys/miscfs/procfs/procfs_vnops.c
===
RCS file: /cvs/src/sys/miscfs/procfs/procfs_vnops.c,v
retrieving revision 1.60
diff -N -u -p sys/miscfs/procfs/procfs_vnops.c
--- sys/miscfs/procfs/procfs_vnops.c8 Jul 2014 17
On Tue, Aug 19, 2014 at 10:14:59PM -0700, Philip Guenther wrote:
Can you describe what you're using that needs it?
Well, I am not using it. The code has not been sent to the Attic yet and
I happened to take a look at it. That is all.
Hello,
OpenCVS fails to retrieve deltas at ends of revision chains. Because of
this, a checkout of revision 1.1 or the last revision of a branch tends
to give wrong data or crash the program. This issue has been around
several years, and many have reported it in the mailing lists.
The following
The uvm_pmr_get1page() function can fail even when there are suitable
free pages available. If there is no hit in the list of single pages in
a pmemrange, the function continues the lookup in the address tree.
The function takes the root of a size-sorted tree as the starting point
for the address
On Tue, Jun 16, 2015 at 23:57 +0200, Mark Kettenis wrote:
You're definitely on to something. It certainly looks like your diff
fixes the bug. However, if there is no constraint, it would make
sense to pick a page from the size tree of the right type. Not sure
if that optimization would
On Sun, Jul 19, 2015 at 06:33:29PM +0200, Mark Kettenis wrote:
So my unlocking the reaper diff that was committed the other day
breaks the MP architectures that don't have an mpsafe pmap yet (see
my commit message). Is seems hppa's pmap is actually safe enough, but
alpha, m88k, mips64 and
Function mips64_send_ipi() will block if the target core has a pending
IPI request. This will degrade performance in a system that has more
than a few cores and where there is a heavy IPI load.
The blocking can be avoided by coalescing requests. The mips64 code
should handle this just fine. The
The patch below solves stalled IPI processing on octeon. When IPIs are
finally enabled during boot, some kernel threads have already been
started. There seems to be no mechanism that would update interrupt
masks for a running thread, so the early threads run IPIs disabled.
This will lead to a
On Wed, Jul 15, 2015 at 05:07:39AM +, Miod Vallat wrote:
The patch below solves stalled IPI processing on octeon. When IPIs are
finally enabled during boot, some kernel threads have already been
started. There seems to be no mechanism that would update interrupt
masks for a running
On octeon, the single-processor kernel does not work quite right when
booted with multiple cores. Each core begins to boot the system
independently, as if there were no other CPUs, leading to a totally
mixed-up state. The following patch alters the MP init core selection
logic a little and enables
On Thu, Aug 27, 2015 at 12:43:30AM +0200, Mark Kettenis wrote:
miod@ added this back in 2002 (rev 1.36):
Back out a few more uvm changes, especially wrt swap usage.
This unbreaks m68k m88k sparc and perhaps others, which eventually froze
when hitting swap.
Tested by various people
On Fri, Aug 28, 2015 at 12:00:41PM +0200, Mark Kettenis wrote:
As Theo and I noticed yesterday:
$ readelf -a /usr/lib/libc.a
readelf: Error: /usr/lib/libc.a: invalid archive string table offset 0
Turns out that on mips64 binutils creates IRIX-style 64-bit archives
which allegedly can
The dwc2 driver uses too small FIFOs on Octeon. Because of this, the
USB controller can hammer the CPU with an immense flood of interrupts.
A rate of over 50,000 interrupts per second is not uncommon under
IO load.
The adjusted sizes below are from NetBSD. Those might not be the
optimum ones, but
On Fri, Sep 11, 2015 at 09:18:18PM +0200, Maxime Villard wrote:
> _20/ UNINITIALIZED VARIABLE: sys/arch/sgi/dev/if_iec.c rev1.14
Fixed. Thank you.
On Tue, Jan 12, 2016 at 11:44:48PM +0200, Artturi Alm wrote:
> Likely some other configs have more exhaustive list of devices supported,
> but even these would be great to have, especially uhub* at uhub?,
> as ERL physically has only one port limiting it's use to a single umass.
>
> -Artturi
Octeon firmware provides a list of usable memory regions. I would like
to make the memory setup routine use the list instead of hardcoded
assumptions. EdgeRouter Pro has a memory layout that does not match
with the current code, which causes a kernel crash.
I have tested this patch on EdgeRouter
On Tue, Apr 12, 2016 at 05:03:39PM +0200, Mark Kettenis wrote:
> > On Fri, Apr 08, 2016 at 12:16:03PM +, Visa Hankala wrote:
> > > Every now and then I see "spurious interrupt 34" messages on octeon
> > > serial console. The root cause seems to be in com
Every now and then I see "spurious interrupt 34" messages on octeon
serial console. The root cause seems to be in comstart() which enables
the TX holding register empty interrupt before writing data to the TX
register. If the register is empty initially, the early enabling can
trigger a premature
On Fri, Apr 08, 2016 at 12:16:03PM +, Visa Hankala wrote:
> Every now and then I see "spurious interrupt 34" messages on octeon
> serial console. The root cause seems to be in comstart() which enables
> the TX holding register empty interrupt before writing data t
On Thu, Mar 17, 2016 at 11:51:19AM +1000, Jonathan Matthew wrote:
> I've had this sitting around for a while and I figure it's time to get it in
> the tree. Octeon II sensibly got rid of the DWC USB controller and put in
> ehci
> and ohci compliant controllers instead, so all we need to do here
dwctwo(4) should be attached only on those Octeon models that have the
DWC2 controller. The list below is not complete but it covers every
model that has any chance of working with cnmac(4).
OK?
Index: arch/octeon/dev/octdwctwo.c
On Wed, Apr 13, 2016 at 06:15:46AM +, Miod Vallat wrote:
> > It should be latched, at least on modern 16550-like UARTs. From
> > a PC16550D datasheet:
>
> Keep in mind that com(4) is intended to support 16450 chips, which have
> no FIFO. I believe that the current ordering of the operations
This adds MP-safe TX for cnmac(4). OK?
Index: arch/octeon/dev/if_cnmac.c
===
RCS file: src/sys/arch/octeon/dev/if_cnmac.c,v
retrieving revision 1.38
diff -u -p -r1.38 if_cnmac.c
--- arch/octeon/dev/if_cnmac.c 13 Apr 2016 11:34:00
On Tue, Apr 26, 2016 at 05:29:43PM +1000, David Gwynne wrote:
>
> > On 25 Apr 2016, at 02:13, Visa Hankala <v...@openbsd.org> wrote:
> >
> > This adds MP-safe TX for cnmac(4). OK?
>
> nearly. see inline.
Here is a new try. ifq_serialize() is just what the code
On Mon, Apr 25, 2016 at 04:06:08PM +0200, Martin Pieuchot wrote:
> On 25/04/16(Mon) 11:35, Visa Hankala wrote:
> > On Mon, Apr 25, 2016 at 10:20:32AM +0200, Martin Pieuchot wrote:
> > > On 24/04/16(Sun) 16:13, Visa Hankala wrote:
> > > > This adds MP-safe TX for cn
On Mon, Apr 25, 2016 at 10:20:32AM +0200, Martin Pieuchot wrote:
> On 24/04/16(Sun) 16:13, Visa Hankala wrote:
> > This adds MP-safe TX for cnmac(4). OK?
>
> Would it be possible to do that without mutex? Having the same pattern
> across most of our drivers would reduce the
On Tue, May 17, 2016 at 02:02:37AM +0200, Kim Lidström wrote:
> Is this patch better? I have tested it by trying both cnmac0, cnmac1 and
> cnmac2 as rootdev and it seems to work properly.
> I also removed the outdated comment, changed the pointless text (Maybe
> it'd be more appropriate to remove
On Mon, May 16, 2016 at 01:39:31AM +0200, Kim Lidström wrote:
> I am nfs booting my edgerouter lite and didn't like to have to manually
> enter 'cnmac0'
> as my root device every boot.
>
> This is what I came up with. I stole the idea from macppc and modified
> it a little.
>
> Am I way off
sk(4) uses a queue for managing Tx DMA maps. Because the queue would
require synchronization if the driver was unlocked, it might be best
to refactor the code a bit. This patch removes the queue by making
Tx and Rx DMA maps part of struct sk_chain.
OK?
Index: dev/pci/if_sk.c
On Tue, Oct 04, 2016 at 08:08:32PM +, Miod Vallat wrote:
> The sgi boot blocks use the PROM (ARCBios or ARCS) for its I/O routines.
> When using a disk-based path, these routines are using the partition
> table found in the ``volume header''.
>
> In order to be able to use 16 partitions per
With the disklabel read logic in the sgi bootblocks, the 'a' partition
no longer has to be the first partition on a disk, so the positioning
remarks in the install notes and the installer seem outdated. The patch
below removes them.
OK?
Index: distrib/notes/sgi/install
On Sun, Sep 18, 2016 at 03:33:00PM +0200, Ingo Schwarze wrote:
> So, here is a cleaned-up version:
>
> - Move the new page to the proper directory.
> - Mention it in the Makefile.
> - Put the correct manual page author into the Copyright notice.
> - Add the architecture to the .Dt line.
> -
On Mon, Jan 09, 2017 at 04:10:48PM +0100, Martin Pieuchot wrote:
> As reported by Hrvoje Popovski, these two callbacks also need the
> NET_LOCK():
>
> splassert: ip_output: want 1 have 0
> Starting stack trace...
> ip_output() at ip_output+0x7d
> pfsync_sendout() at
On Sat, Jan 07, 2017 at 12:23:31AM +0100, Frederic Cambus wrote:
> Hi tech@,
>
> Here is a diff to use proper RGB values for the ANSI color palette in
> rasops(9).
>
> Comments? OK?
I prefer the old palette because its contrast is higher.
> Index: sys/dev/rasops/rasops.c
>
Network boot triggers a netlock recursion:
panic
rw_enter
sosend <- NET_LOCK()
nfs_send
nfs_request
nfs_lookup
VOP_LOOKUP
vfs_lookup
namei
unp_connect
uipc_usrreq
soconnect <- NET_LOCK()
sys_connect
An XXXSMP workaround seems appropriate here.
OK?
Index: kern/uipc_usrreq.c
NET_LOCK() should raise IPL before acquiring the lock, and NET_UNLOCK()
should restore the level after releasing the lock. Otherwise, lock
recursion can occur, most likely right after the splx(). An example:
nd6_slowtimo <- NET_LOCK()
timeout_run
softclock
softintr_dispatch
dosoftint
interrupt
On Tue, Apr 11, 2017 at 04:55:45PM +0200, Mark Kettenis wrote:
> Se here is an updated diff; thanks for catching this.
>
> ok?
OK visa@
> Index: arch/arm64/dev/pluart.c
> ===
> RCS file: /cvs/src/sys/arch/arm64/dev/pluart.c,v
>
On Tue, Apr 11, 2017 at 03:51:51PM +0200, Mark Kettenis wrote:
> + if (ISSET(sc->sc_hwflags, COM_HW_CONSOLE)) {
> + if (db_console)
> + Debugger();
> + continue;
> +
The current pool cache code increases the number of items that can be
cached locally in response to lock contention. This patch adds a tweak
that lowers the number when contention does not occur. The idea is to
let resources be returned to the common pool when pressure on the cache
has decreased.
On Sun, May 14, 2017 at 10:05:28PM +0200, Mark Kettenis wrote:
> I tried to convert a few more architectures, and things get a bit
> messier than I envisioned on architectures that have an optimized copy
> function and care about alignment. Especially when copyin(9) is
> implemented in assembly.
On Mon, May 01, 2017 at 06:02:24PM +0200, Mark Kettenis wrote:
> The futex(2) syscall needs to be able to atomically copy the futex in
> and out of userland. The current implementation uses copyin(9) and
> copyout(9) for that. The futex is a 32-bit integer, and currently our
> copyin(9) and
Here is a copyin32(9) for mips64. With futex(2) using it, the regress
tests pass on loongson, octeon and sgi. Source addresses with wrong
alignment are handled by the on-fault logic in itsa() trap handler.
OK?
Index: arch/mips64/mips64/lcore_access.S
Currently, access to pflow's sc_outputqueue is not serialized properly.
The producer has the NET_LOCK(), while the consumer does not.
mpi@ suggested using mbuf_queue to solve the issue.
OK?
Index: net/if_pflow.c
===
RCS file:
On Mon, May 29, 2017 at 03:33:35PM +, Visa Hankala wrote:
> Currently, access to pflow's sc_outputqueue is not serialized properly.
> The producer has the NET_LOCK(), while the consumer does not.
> mpi@ suggested using mbuf_queue to solve the issue.
mpi@ commented that the pflow ou
On Mon, May 01, 2017 at 06:02:24PM +0200, Mark Kettenis wrote:
> The futex(2) syscall needs to be able to atomically copy the futex in
> and out of userland. The current implementation uses copyin(9) and
> copyout(9) for that. The futex is a 32-bit integer, and currently our
> copyin(9) and
On Wed, May 31, 2017 at 01:52:31AM +1000, Jonathan Matthew wrote:
> On Tue, May 30, 2017 at 01:04:07PM +0000, Visa Hankala wrote:
> > Index: net/if_pflow.c
> > ===
> > RCS file: src/sys/net/if_pflow.c,v
> &g
On Mon, Oct 09, 2017 at 10:39:47PM +0200, Juan Francisco Cantero Hurtado wrote:
> Marc Feeley (Gambit Scheme) has been helping me with a bug on Gambit on
> Loongson. Apparently the bug is on our side.
>
> I've created this little test based on his code:
>
> #include
> #include
>
> int main()
On Thu, Nov 30, 2017 at 01:05:58AM +0100, Rafael Neves wrote:
> Hi,
>
> The patch below replace one "$loadaddr" to "${loadaddr}" in U-Boot
> instructions of INSTALL.octeon.
>
> Regards,
> Rafael Neves
Committed, thanks.
> Index: install
>
On Mon, Nov 13, 2017 at 01:25:42PM +0100, Martin Pieuchot wrote:
> I'd love is somebody could do the changes in the rwlock API to let us
> check if we're holding a lock. Maybe this is already present in
> witness(4), visa?
witness(4) does maintain data about lock ownership. The patch below
might
On Tue, Nov 14, 2017 at 10:37:16AM +0100, Martin Pieuchot wrote:
> Note that the diff below still includes a false positive. If the
> current thread doesn't have the read-lock but another one has it,
> then RW_READ will still be returned.
That's true if witness(4) has not been enabled.
On Thu, Dec 07, 2017 at 11:43:09AM +0100, Martin Pieuchot wrote:
> On 05/12/17(Tue) 14:52, Visa Hankala wrote:
> > On Tue, Dec 05, 2017 at 11:32:53AM +0100, Martin Pieuchot wrote:
> > > On 04/12/17(Mon) 12:24, Martin Pieuchot wrote:
> > > > Since SMAP is enabled ddb
On Tue, Dec 05, 2017 at 11:32:53AM +0100, Martin Pieuchot wrote:
> On 04/12/17(Mon) 12:24, Martin Pieuchot wrote:
> > Since SMAP is enabled ddb(4)'s 'trace /u' and 'trace /p' for a userland
> > processes result, as expected, in page faults.
> >
> > Diff below disable SMAP for the duration of the
On Wed, Jun 13, 2018 at 08:34:46AM +0200, Janne Johansson wrote:
> The unconditional #define DEBUG in octeon/machdep.c is somewhat weird.
>
> Should we just keep the whole block and remove the #ifdefs, move it to
> #if 1 for later easy removal? Dunno, but it won't compile with DEBUG
> unless
On Wed, Jun 13, 2018 at 10:45:08PM +0200, Christian Ludwig wrote:
> It makes sense to have witness(4) on uniprocessor systems, too. Lock-order
> violations are not an MP-only thing. Since UP kernels do not have the kernel
> lock, wrap the code in appropriate ifdefs.
Committed. Thank you.
On Tue, Jun 19, 2018 at 03:58:51PM +0200, Mark Kettenis wrote:
> > Date: Tue, 19 Jun 2018 15:38:01 +0200
> > From: Martin Pieuchot
> >
> > On 19/06/18(Tue) 14:55, Mark Kettenis wrote:
> > > > To avoid races with another thread that might be clearing our pointer
> > > > in `fd_ofiles', we need
On Sat, Jun 02, 2018 at 01:00:05PM +0200, Frederic Cambus wrote:
> Hi tech@,
>
> Here is a diff to remove unused C3 values.
>
> Comments? OK?
I would keep the definitions because they can at least serve as a weak
form of documentation about the hardware. For example,
C3_CRYPT_CWLO_ALG_M
The open(2) system call uses a problematic locking pattern that can
cause problems when the process has more than one thread. The system
call keeps the file descriptor table locked when calling vn_open(9).
If vn_open(9) blocks, the other threads get blocked too if they try
to modify the descriptor
Here is a new version of the f_count atomic update diff. Now all
updating of the `f_count' field should use atomic operations, and
the `fhdlk' is only used for serializing access to the list of open
files. In addition, the role of the `fd_fplock' should be clearer now:
its only purpose is to let
On Tue, Jun 19, 2018 at 03:36:57PM +, Visa Hankala wrote:
> On Tue, Jun 19, 2018 at 03:58:51PM +0200, Mark Kettenis wrote:
> > > Date: Tue, 19 Jun 2018 15:38:01 +0200
> > > From: Martin Pieuchot
> > >
> > > On 19/06/18(Tue) 14:55, Mark Kettenis wrote
On Thu, Jun 21, 2018 at 04:49:48PM +, Visa Hankala wrote:
> Here is an updated diff that has been adjusted for the current tree.
Hmm, the diff is not right yet. Please ignore.
On Tue, Jan 23, 2018 at 03:23:24PM +0100, Martin Pieuchot wrote:
> On 23/01/18(Tue) 14:06, Visa Hankala wrote:
> > In addition, you should put the common mutex code into kern_mutex.c.
> > Lets keep kern_lock.c for the mplock only.
>
> I'm more in favor of putting everyt
On Mon, Jan 22, 2018 at 11:12:13AM +0100, Martin Pieuchot wrote:
> Diff below moves the common mutex implementation to kern/ and enable it for
> alpha, amd64, arm64, i386, mips64, powerpc.
Your diff seems to miss the necessary bits in .
In addition, you should put the common mutex code into
On Wed, Apr 11, 2018 at 12:34:03PM +0200, Martin Pieuchot wrote:
> On 09/04/18(Mon) 16:10, Martin Pieuchot wrote:
> > Diff below implements most of the missing locking goo for NFS without
> > enabling it. It does the following:
> >
> > - Add a missing PDIRUNLOCK in nfs_lookup()
> >
> > - Change
On Wed, Apr 25, 2018 at 12:12:29PM +0200, Martin Pieuchot wrote:
> The goal is to avoid races between fd_getfile() and FREF(). So we want
> a properly refcounted 'struct file *' as soon as possible.
Boot hangs with this patch. The last line on the console is
"setting tty flags".
Two issues
On Tue, Mar 27, 2018 at 11:00:20AM +0200, Martin Pieuchot wrote:
> Diff below prevents a future lock ordering problem between NFSnode
> locks (similar to Inode locks) and the NET_LOCK().
>
> It ensures the NET_LOCK() is always locked *after* any NFSnode lock
> by fixing the UVM fault case. So we
On Thu, Mar 29, 2018 at 11:57:42AM +0200, Martin Pieuchot wrote:
> On 28/03/18(Wed) 16:09, Visa Hankala wrote:
> > On Wed, Mar 28, 2018 at 11:59:46AM +0200, Martin Pieuchot wrote:
> > > Index: uvm/uvm_vnode.c
> > > ===
On Wed, Mar 28, 2018 at 11:59:46AM +0200, Martin Pieuchot wrote:
> Index: uvm/uvm_vnode.c
> ===
> RCS file: /cvs/src/sys/uvm/uvm_vnode.c,v
> retrieving revision 1.99
> diff -u -p -r1.99 uvm_vnode.c
> --- uvm/uvm_vnode.c 8 Mar 2018
On Sat, Mar 17, 2018 at 07:41:39PM +0100, Mark Kettenis wrote:
> Index: dev/sdmmc/sdhc.c
> ===
> RCS file: /cvs/src/sys/dev/sdmmc/sdhc.c,v
> retrieving revision 1.56
> diff -u -p -r1.56 sdhc.c
> --- dev/sdmmc/sdhc.c 10 Feb 2018
On Sun, Mar 18, 2018 at 06:33:59PM +0100, Mark Kettenis wrote:
> > Date: Sun, 18 Mar 2018 12:17:09 +
> > From: Visa Hankala <v...@openbsd.org>
> >
> > On Sat, Mar 17, 2018 at 07:41:39PM +0100, Mark Kettenis wrote:
On Thu, Apr 26, 2018 at 08:34:08AM +0200, Martin Pieuchot wrote:
> On 25/04/18(Wed) 17:07, Visa Hankala wrote:
> > On Wed, Apr 25, 2018 at 12:12:29PM +0200, Martin Pieuchot wrote:
> > > The goal is to avoid races between fd_getfile() and FREF(). So we want
> > > a prope
On Mon, Dec 17, 2018 at 11:22:40PM -0500, Chris McGee wrote:
> Hi:
>
> I would like to add some info for Edgerouter 6
> (and presumably ER4, and maybe also ER12?) to install64.octeon.
> The document is great but it won't get a new user booting on the new
> 4-core machines with MMC drives.
>
>
On Thu, Dec 20, 2018 at 07:39:44PM -0500, Chris McGee wrote:
> That looks much better to me, though it does get machine-specific
>
> I feel like it would be more clear if the examples uniformly used your
> new variable
> convention, as some do and some do not. This allows us to eliminate one
>
On Sat, Dec 08, 2018 at 05:32:41PM +, Miod Vallat wrote:
> I have noticed, for a while, that my O2 systems were horribly slow
> during installs or upgrades, when fetching sets from the network (28
> *minutes* to fetch base64.tgz).
>
> At first, I thought this was a bsd.rd specific bug, but
On Thu, Jan 03, 2019 at 01:16:05PM +0300, Mikhael Skvortsov wrote:
> Tested by running GENERIC.MP built by
> make CC=clang COMPILER_VERSION=clang
> on a CN6120 device.
Thank you. I have something similar pending and will commit soonish.
Certain things have to be done in concert with loongson and
On Thu, Jan 03, 2019 at 04:06:25PM +0100, Janne Johansson wrote:
> Den tors 3 jan. 2019 kl 15:25 skrev Visa Hankala :
> >
> > On Thu, Jan 03, 2019 at 01:16:05PM +0300, Mikhael Skvortsov wrote:
> > > Tested by running GENERIC.MP built by
> > > make CC=clang COMPILE
On Sat, Jun 01, 2019 at 07:04:23PM -0300, Martin Pieuchot wrote:
> On 01/06/19(Sat) 23:22, Mark Kettenis wrote:
> > > Date: Sat, 1 Jun 2019 17:32:52 -0300
> > > From: Martin Pieuchot
> > >
> > > Currently it isn't safe to call mtx_enter_try(9) if you're already
> > > holding the mutex. That
On Sun, Jun 02, 2019 at 10:29:01AM -0300, Martin Pieuchot wrote:
> On 02/06/19(Sun) 04:30, Visa Hankala wrote:
> > On Sat, Jun 01, 2019 at 07:04:23PM -0300, Martin Pieuchot wrote:
> > > On 01/06/19(Sat) 23:22, Mark Kettenis wrote:
> > > > > Date: Sat, 1 Jun 2
On Sun, Jun 23, 2019 at 02:48:24PM +0200, Moritz Buhl wrote:
> Hi,
> while running regression tests on an octeon ERL, I noticed that
> no-macro-redefined flag was not known to the compiler.
> I added some #undefs and some hours ago a change to art_walk made
> the tests fail too.
>
> The
On Mon, Dec 02, 2019 at 06:08:35PM +0100, Jeremie Courreges-Anglas wrote:
> On Mon, Dec 02 2019, Marc Espie wrote:
> > On Mon, Dec 02, 2019 at 08:31:02AM +, Miod Vallat wrote:
> >> grep(1), when invoked with the -R option but no path, displays a
> >> "recursive search of stdin" warning and
On Thu, Feb 13, 2020 at 12:00:35PM +0100, Martin Pieuchot wrote:
> These structures are only used by autoconf(9) and don't need to be
> modified. Some subsystems already define most of them as 'const'.
> Diff below turn all the remaining one as such.
>
> Only a single driver, de(4), needed a
On Thu, Feb 13, 2020 at 06:07:01PM +0100, Martin Pieuchot wrote:
> On 13/02/20(Thu) 16:53, Visa Hankala wrote:
> > On Thu, Feb 13, 2020 at 12:00:35PM +0100, Martin Pieuchot wrote:
> > > These structures are only used by autoconf(9) and don't need to be
> > > modifie
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
On Tue, Feb 04, 2020 at 01:04:24PM +0100, Martin Pieuchot wrote:
> On 02/02/20(Sun) 09:58, Visa Hankala wrote:
> > tty(4) uses custom code for revoking knotes. It should be changed to use
> > klist_invalidate() to handle the revocation in one place. The following
> > diff
tty(4) uses custom code for revoking knotes. It should be changed to use
klist_invalidate() to handle the revocation in one place. The following
diff does that.
In addition, the patch makes the code store the tty context pointer
in kn_hook directly. This simplifies the code.
Unlike ttkqflush(),
The header defines two sets of assert macros,
one for standard C and another for the traditional cpp. As the header
requires the use of a C compiler (that is, no inclusion from an assembly
file), it looks that the non-__STDC__ parts could be removed.
OK?
Index: lib/libkern/libkern.h
On Tue, Feb 04, 2020 at 02:21:02PM +0100, Martin Pieuchot wrote:
> As recently profiled, the softnet thread which runs mostly without
> KERNEL_LOCK() is still somehow serialized with the rest of the kernel.
> This is because the various subsystems to notify userland, either via
>
Zero knotes on allocation. Parts of struct knote, such as kn_tqe, can
retain their old value quite long, which is not good in this complex
piece of code.
OK?
Index: kern/kern_event.c
===
RCS file: src/sys/kern/kern_event.c,v
Eventually, it will become necessary to add new properties to
struct filterops. One such property is whether the filter is safe to use
without the kernel lock.
The diff below replaces the f_isfd field with a generic flags field in
struct filterops, to allow adding new properties without
On Tue, Feb 04, 2020 at 02:21:02PM +0100, Martin Pieuchot wrote:
> void
> selwakeup(struct selinfo *sip)
> {
> + KERNEL_LOCK();
> + KNOTE(>si_note, NOTE_SUBMIT);
> + doselwakeup(sip);
> + KERNEL_UNLOCK();
> +}
There is a problem with audio code. Audio interrupt handlers
The closing of a file can be a complex operation, and hence it would be
good to hold as few locks as possible when calling closef(). In
particular, the code behind close(2) already releases the file
descriptor table lock before closef(). This might not be strictly
necessary when the type of the
On Sat, Feb 15, 2020 at 09:42:53PM +0100, Martin Pieuchot wrote:
> On 15/02/20(Sat) 16:56, Visa Hankala wrote:
> > When I added the knote_acquire() call in kqueue_register(), I overlooked
> > the fact that the knote could be modified by a (soft) interrupt.
> > Interrupts ha
When I added the knote_acquire() call in kqueue_register(), I overlooked
the fact that the knote could be modified by a (soft) interrupt.
Interrupts have to be blocked when changing kn_status. Otherwise the
state could become confused.
The diff below adds splhigh() where kn_status is modified.
On Fri, Feb 14, 2020 at 06:08:31PM +0100, Martin Pieuchot wrote:
> On 13/02/20(Thu) 17:23, Visa Hankala wrote:
> > On Thu, Feb 13, 2020 at 06:07:01PM +0100, Martin Pieuchot wrote:
> > > On 13/02/20(Thu) 16:53, Visa Hankala wrote:
> > > [...]
> > > > I wo
The following diff makes finishdup() release the file descriptor table
lock before calling closef(). This makes the order of operations similar
to that of fdrelease().
The dup* code still has an issue with file closing that this diff does
not address. If fdalloc() fails in dodup3(), sys_dup() or
On Sun, Dec 29, 2019 at 05:23:43PM -0600, Amit Kulkarni wrote:
> I was preparing a diff and wanted to know if it is safe to disable the
> SMR kthread by commenting it out for testing purposes on amd64. Just a
> simple yes/no would do!
no
On Fri, Jan 03, 2020 at 11:37:22PM -0800, Greg Steuck wrote:
> While playing with chromium u2f support[1] I managed to induce kernel
> crashes in filt_uhidrdetach. It takes a few attempts of plugging/unplugging
> the fido key while trying to authenticate at demo.yubico.com/playground.
> Eventually
jcs@ has reported the following panic which started appearing as
a consequence of the recent file close unlocking:
panic: kernel diagnostic assertion "timo || _kernel_lock_held()" failed: file
"/usr/src/sys/kern/kern_synch.c", line 123
panic
__assert
tsleep
usbd_transfer
usbd_do_request_flags
On Sun, Apr 12, 2020 at 03:26:14PM +0200, Martin Pieuchot wrote:
> The existing variations of the NET_LOCK() macros are confusing. We're
> now all aware of this fact. So let's keep them simple to prevent future
> mistakes :)
>
> The diff below reduces the current set of methods to the
This diff introduces a struct for kqueue scan state. It eases making
scans piecewise by keeping track of the scan's end point. The end point
prevents the scan from recollecting events that are already being
reported to the userspace.
Below is an overview of the goal. It is achieved by combining
1 - 100 of 396 matches
Mail list logo
