On 25.1.2017. 7:32, Martin Pieuchot wrote:
> I just enabled the NET_LOCK() again and I'm looking for test reports.
> Please go build a kernel from sources or wait for the next snapshot,
> run it and report back.
>
> If you're looking for some small coding tasks related to the NET_LOCK()
> just
On 31.1.2017. 21:35, David Hill wrote:
> On Tue, Jan 31, 2017 at 09:11:37PM +0100, Alexander Bluhm wrote:
>> On Tue, Jan 31, 2017 at 12:14:35PM -0500, David Hill wrote:
>>> with mpi@'s suggestion to pass a struct mbuf *
>> We call mbuf variables m and mbuf pointer mp. So you should rename
>> *mp
On Tue, Jan 31, 2017 at 03:35:47PM -0500, David Hill wrote:
> Updated diff.
OK bluhm@
>
> Index: kern/uipc_socket.c
> ===
> RCS file: /cvs/src/sys/kern/uipc_socket.c,v
> retrieving revision 1.175
> diff -u -p -r1.175 uipc_socket.c
boot to console:
/etc/hostname.re0:
inet n.n.n.n 0xff00
/etc/hostname.ral0:
nwid xyz
wpakey ""
mode 11g
dhcp
dmesg:
OpenBSD 6.0-current (GENERIC.MP) #4: Tue Jan 31 19:42:25 EST 2017
r...@cq58-b.test:/usr/src/sys/arch/amd64/compile/GENERIC.MP
RTC BIOS diagnostic error 80
real mem =
On Tue, Jan 31, 2017 at 09:11:37PM +0100, Alexander Bluhm wrote:
> On Tue, Jan 31, 2017 at 12:14:35PM -0500, David Hill wrote:
> > with mpi@'s suggestion to pass a struct mbuf *
>
> We call mbuf variables m and mbuf pointer mp. So you should rename
> *mp to m.
>
> The different policy who has
On Tue, Jan 31, 2017 at 12:14:35PM -0500, David Hill wrote:
> with mpi@'s suggestion to pass a struct mbuf *
We call mbuf variables m and mbuf pointer mp. So you should rename
*mp to m.
The different policy who has to free the mbuf with
if (op == PRCO_SETOPT)
On 31.1.2017. 18:14, David Hill wrote:
> On Tue, Jan 31, 2017 at 10:43:26AM +0100, Martin Pieuchot wrote:
>> On 27/01/17(Fri) 14:33, David Hill wrote:
>>> [...]
>>> Forgot a file... Try this:
>> Is it now possible to pass a 'struct mbuf *' instead of a 'struct mbuf **'
>> to the pr_ctloutput()
On Tue, Jan 31, 2017 at 10:43:26AM +0100, Martin Pieuchot wrote:
> On 27/01/17(Fri) 14:33, David Hill wrote:
> > [...]
> > Forgot a file... Try this:
>
> Is it now possible to pass a 'struct mbuf *' instead of a 'struct mbuf **'
> to the pr_ctloutput() functions?
>
> Changing the signature
On 27/01/17(Fri) 14:33, David Hill wrote:
> [...]
> Forgot a file... Try this:
Is it now possible to pass a 'struct mbuf *' instead of a 'struct mbuf **'
to the pr_ctloutput() functions?
Changing the signature would ensure we do not miss a call. This would
also simplify the SETOPT case.
>
Hi, I've also ran into this.
Reported here [1] (a new email with some more stack traces should be
landing soon).
BR,
Pedro Caetano
[1] https://marc.info/?l=openbsd-bugs=148581520804370=2
On Mon, Jan 30, 2017 at 11:12 PM, Hrvoje Popovski wrote:
> On 25.1.2017. 7:32, Martin
On 25.1.2017. 7:32, Martin Pieuchot wrote:
> I just enabled the NET_LOCK() again and I'm looking for test reports.
> Please go build a kernel from sources or wait for the next snapshot,
> run it and report back.
>
> If you're looking for some small coding tasks related to the NET_LOCK()
> just
On 27.1.2017. 20:33, David Hill wrote:
> On Fri, Jan 27, 2017 at 08:09:36PM +0100, Hrvoje Popovski wrote:
>> On 27.1.2017. 19:14, David Hill wrote:
splassert: yield: want 0 have 1
Starting stack trace...
yield() at yield+0xac
pool_get() at pool_get+0x1ca
m_get() at
On Fri, Jan 27, 2017 at 08:09:36PM +0100, Hrvoje Popovski wrote:
> On 27.1.2017. 19:14, David Hill wrote:
> >> splassert: yield: want 0 have 1
> >> Starting stack trace...
> >> yield() at yield+0xac
> >> pool_get() at pool_get+0x1ca
> >> m_get() at m_get+0x28
> >> ip_ctloutput() at
On 27.1.2017. 19:14, David Hill wrote:
>> splassert: yield: want 0 have 1
>> Starting stack trace...
>> yield() at yield+0xac
>> pool_get() at pool_get+0x1ca
>> m_get() at m_get+0x28
>> ip_ctloutput() at ip_ctloutput+0x4bf
>> sogetopt() at sogetopt+0x7e
>> sys_getsockopt() at sys_getsockopt+0xbf
On Wed, Jan 25, 2017 at 11:14:57AM -0500, David Hill wrote:
> On Wed, Jan 25, 2017 at 04:32:25PM +1000, Martin Pieuchot wrote:
> > I just enabled the NET_LOCK() again and I'm looking for test reports.
> > Please go build a kernel from sources or wait for the next snapshot,
> > run it and report
On 01/25/17 01:32, Martin Pieuchot wrote:
> I just enabled the NET_LOCK() again and I'm looking for test reports.
> Please go build a kernel from sources or wait for the next snapshot,
> run it and report back.
>
> If you're looking for some small coding tasks related to the NET_LOCK()
> just do:
On 01/25/17 01:32, Martin Pieuchot wrote:
> I just enabled the NET_LOCK() again and I'm looking for test reports.
> Please go build a kernel from sources or wait for the next snapshot,
> run it and report back.
>
> If you're looking for some small coding tasks related to the NET_LOCK()
> just do:
On 25.1.2017. 7:32, Martin Pieuchot wrote:
> I just enabled the NET_LOCK() again and I'm looking for test reports.
> Please go build a kernel from sources or wait for the next snapshot,
> run it and report back.
>
> If you're looking for some small coding tasks related to the NET_LOCK()
> just
On 25/01/17(Wed) 20:12, David Hill wrote:
> > splassert: yield: want 0 have 1
> > Starting stack trace...
> > yield() at yield+0xac
> > malloc() at malloc+0x406
> > ip6_setmoptions() at ip6_setmoptions+0x65
> > ip6_ctloutput() at ip6_ctloutput+0x6d9
> > sosetopt() at sosetopt+0x8e
> >
On Wed, Jan 25, 2017 at 11:11:03AM -0500, David Hill wrote:
> On Wed, Jan 25, 2017 at 04:32:25PM +1000, Martin Pieuchot wrote:
> > I just enabled the NET_LOCK() again and I'm looking for test reports.
> > Please go build a kernel from sources or wait for the next snapshot,
> > run it and report
On 25/01/17(Wed) 20:04, David Hill wrote:
> [...]
> Allocate the mbuf beforehand. Also, move the setting of nflag closer
> to where its value is used.
ok mpi@
> Index: uipc_syscalls.c
> ===
> RCS file:
On Wed, Jan 25, 2017 at 04:32:25PM +1000, Martin Pieuchot wrote:
> I just enabled the NET_LOCK() again and I'm looking for test reports.
> Please go build a kernel from sources or wait for the next snapshot,
> run it and report back.
>
> If you're looking for some small coding tasks related to
On 25/01/17(Wed) 15:52, Theo de Raadt wrote:
> I have the same diff.
>
> It does not help the pr_usrreq path though.
Sure but, let's do baby step. :)
> >On Wed, Jan 25, 2017 at 11:02:22AM -0500, David Hill wrote:
> >> splassert: yield: want 0 have 1
> >> Starting stack trace...
> >> yield() at
I have the same diff.
It does not help the pr_usrreq path though.
>On Wed, Jan 25, 2017 at 11:02:22AM -0500, David Hill wrote:
>> splassert: yield: want 0 have 1
>> Starting stack trace...
>> yield() at yield+0xac
>> pool_get() at pool_get+0x1ca
>> socreate() at socreate+0xba
>> sys_socket() at
On 25/01/17(Wed) 19:04, Alexander Bluhm wrote:
> On Wed, Jan 25, 2017 at 11:02:22AM -0500, David Hill wrote:
> > splassert: yield: want 0 have 1
> > Starting stack trace...
> > yield() at yield+0xac
> > pool_get() at pool_get+0x1ca
> > socreate() at socreate+0xba
> > sys_socket() at
On Wed, Jan 25, 2017 at 04:32:25PM +1000, Martin Pieuchot wrote:
> I just enabled the NET_LOCK() again and I'm looking for test reports.
> Please go build a kernel from sources or wait for the next snapshot,
> run it and report back.
>
> If you're looking for some small coding tasks related to
On Wed, Jan 25, 2017 at 07:04:19PM +0100, Alexander Bluhm wrote:
> On Wed, Jan 25, 2017 at 11:02:22AM -0500, David Hill wrote:
> > splassert: yield: want 0 have 1
> > Starting stack trace...
> > yield() at yield+0xac
> > pool_get() at pool_get+0x1ca
> > socreate() at socreate+0xba
> > sys_socket()
On Wed, Jan 25, 2017 at 11:02:22AM -0500, David Hill wrote:
> splassert: yield: want 0 have 1
> Starting stack trace...
> yield() at yield+0xac
> pool_get() at pool_get+0x1ca
> socreate() at socreate+0xba
> sys_socket() at sys_socket+0x135
> syscall() at syscall+0x27b
> --- syscall (number 97) ---
On Wed, Jan 25, 2017 at 04:32:25PM +1000, Martin Pieuchot wrote:
> I just enabled the NET_LOCK() again and I'm looking for test reports.
> Please go build a kernel from sources or wait for the next snapshot,
> run it and report back.
>
> If you're looking for some small coding tasks related to
On Wed, Jan 25, 2017 at 04:32:25PM +1000, Martin Pieuchot wrote:
> I just enabled the NET_LOCK() again and I'm looking for test reports.
> Please go build a kernel from sources or wait for the next snapshot,
> run it and report back.
>
> If you're looking for some small coding tasks related to
On Wed, Jan 25, 2017 at 04:32:25PM +1000, Martin Pieuchot wrote:
> I just enabled the NET_LOCK() again and I'm looking for test reports.
> Please go build a kernel from sources or wait for the next snapshot,
> run it and report back.
>
> If you're looking for some small coding tasks related to
I just enabled the NET_LOCK() again and I'm looking for test reports.
Please go build a kernel from sources or wait for the next snapshot,
run it and report back.
If you're looking for some small coding tasks related to the NET_LOCK()
just do:
# sysctl kern.splassert=2
# sysctl
32 matches
Mail list logo