ok.
> On 28 Mar 2018, at 10:07, Jonathan Matthew wrote:
>
> Reading through if_pppx.c I spotted a couple of places we need NET_LOCK().
>
> ok?
>
> Index: if_pppx.c
> ===
> RCS file: /cvs/src/sys/net/if_pppx.c,v
> retrieving revisi
On Tue, Mar 27, 2018 at 9:30 PM David Gwynne wrote:
> On Thu, Mar 15, 2018 at 03:25:46PM +0100, Martin Pieuchot wrote:
> > On 14/03/18(Wed) 13:00, David Gwynne wrote:
> > > this adds transmit mitigation back to the tree.
> > >
> > > it is basically the same diff as last time. the big difference t
On Thu, Mar 15, 2018 at 03:25:46PM +0100, Martin Pieuchot wrote:
> On 14/03/18(Wed) 13:00, David Gwynne wrote:
> > this adds transmit mitigation back to the tree.
> >
> > it is basically the same diff as last time. the big difference this
> > time is that all the tunnel drivers all defer ip_output
the priority field in vlan headers needs some translation before
it's displayed because the values of 0 and 1 are swapped when coming
off the wire. ie, priority 0 on the wire is 1 in the system, and 1
on the wire is priority 0. 2 through 7 map to 2 to 7.
the goal is to make the value printed with
at the moment, vlan(4) takes the priority from mbufs and maps it
to the vlan priority field on the wire when sending packets out.
however, some isps now use pppoe on a vlan for connectivity, but
only accept vlan packets with a specific priority level set, usually
1 (which is 0 on the wire). to forc
Reading through if_pppx.c I spotted a couple of places we need NET_LOCK().
ok?
Index: if_pppx.c
===
RCS file: /cvs/src/sys/net/if_pppx.c,v
retrieving revision 1.63
diff -u -p -u -p -r1.63 if_pppx.c
--- if_pppx.c 12 Aug 2017 20:27:2
Hi Tobias,
Tobias Stoeckmann wrote on Tue, Mar 27, 2018 at 11:51:29PM +0200:
> On Tue, Mar 27, 2018 at 11:47:27PM +0200, Ingo Schwarze wrote:
>> See inline for one optional suggestion.
>>> if (!stop || !start)
>>> errx(1, "[-bcf] list: values may not include zero"
On Tue, Mar 27, 2018 at 11:47:27PM +0200, Ingo Schwarze wrote:
> See inline for one optional suggestion.
>
> > if (!stop || !start)
> > errx(1, "[-bcf] list: values may not include zero");
>
> Consider deleting these two lines, too.
>
> You new function read_numbe
Hi Tobias,
Tobias Stoeckmann wrote on Tue, Mar 27, 2018 at 01:30:03PM +0200:
> This patch fixes an out of boundary write in cut:
>
> $ cut -c 2147483648 -
> Segmentation fault (core dumped)
>
> The supplied number can be parsed by strtol, but the result is casted
> into a signed int, therefore
On Tue, Mar 27, 2018 at 10:48:51PM +0200, Tobias Stoeckmann wrote:
> On Tue, Mar 27, 2018 at 10:36:17PM +0200, Ingo Schwarze wrote:
> > > + int sig;
> >
> > Drop this variable, it does no good but only harm.
>
> Yeah, too bad that I didn't notice this left-over from a previous
> development step.
On Tue, Mar 27, 2018 at 10:36:17PM +0200, Ingo Schwarze wrote:
> > + int sig;
>
> Drop this variable, it does no good but only harm.
Yeah, too bad that I didn't notice this left-over from a previous
development step. Strange enough that regression tests didn't
choke on it...
> > + /* skip le
On Tue, Mar 27, 2018 at 11:28:03AM +0200, Martin Pieuchot wrote:
> Here's a diff to move FREF() just after fd_getfile_mode() in
> sys_pread(), sys_preadv(), sys_pwrite() and sys_pwritev().
>
> As explained recently [0], I'd like to make sure all operations
> manipulating a 'struct file *' do so wi
On Tue, Mar 27, 2018 at 11:24:00AM +0200, Martin Pieuchot wrote:
> Here's a diff to move FREF() just after fd_getfile() in getsock().
>
> As explained recently [0], I'd like to make sure all operations
> manipulating a 'struct file *' do so with a properly refcounted
> element.
>
> [0] https://ma
On Tue, Mar 27, 2018 at 11:18:29AM +0200, Martin Pieuchot wrote:
> FREF() is currently needed before any sleep point. That's because
> there's almost no parallelism in the top half of the kernel. I'd
> like to improve that.
>
> The first step is to make sure all operations manipulating a
> 'stru
Hi Tobias,
Tobias Stoeckmann wrote on Tue, Mar 27, 2018 at 07:37:32PM +0200:
> While at it, -t has a proper 0-INT_MAX limitation now as well.
Looks correct.
> Please note that we have overflows in pdksh's builtin test as well.
> If bin/test is refactored, I'll try to unify both implementations
Hi,
On Tue, Mar 27, 2018 at 09:05:12PM +0200, Klemens Nanni wrote:
> FWIW, see "test: Catch integer overflow, fail on trailing whitespaces"
> from 24.07.2017 on tech@:
>
> https://marc.info/?l=openbsd-tech&m=150091968903042
sorry I didn't intend to ignore your mail. I didn't follow t
Hi Tobias,
one quick remark regarding POSIX:
The relevant text is
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html
section 12.1 Utility Argument Syntax, number 6.
Together with
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/test.html
we have the followin
FWIW, see "test: Catch integer overflow, fail on trailing whitespaces"
from 24.07.2017 on tech@:
https://marc.info/?l=openbsd-tech&m=150091968903042
Ignore for now.
A lovely regress/ test exposes a problem in my diff. :)
On Tue, Mar 27, 2018 at 01:11:19PM -0400, David Hill wrote:
> Hello -
>
> The hash tables are allocated with hashinit, so free them with hashfree.
> This gives the bonus of calling free() with a size as well.
>
On Tue, Mar 27, 2018 at 12:46:03PM +0200, Tobias Stoeckmann wrote:
> Resending this old diff. Adjusted to apply with -current source:
>
> Illegal fragmentation block sizes can trigger division by zero in the
> disklabel and fsck_ffs tools.
>
> See this sequence of commands to reproduce:
>
> # d
The test(1) utility is prone to integer overflows on 64 bit systems.
By using strtol and casting the result to an int, it is possible to
run tests which succeed even though they should fail:
$ arch
OpenBSD.amd64
$ /bin/test 4294967296 -eq 0; echo $?
0
I could have chosen the way of FreeBSD, NetBS
Hello -
The hash tables are allocated with hashinit, so free them with hashfree.
This gives the bonus of calling free() with a size as well.
OK?
Index: in_pcb.c
===
RCS file: /cvs/src/sys/netinet/in_pcb.c,v
retrieving revision 1.228
Hello -
A few bcopy conversions to memcpy where the memory does not overlap,
otherwise memmove.
OK?
Index: netinet/ip_ah.c
===
RCS file: /cvs/src/sys/netinet/ip_ah.c,v
retrieving revision 1.138
diff -u -p -r1.138 ip_ah.c
--- netine
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
Resending this old diff. Adjusted to apply with -current source:
Illegal fragmentation block sizes can trigger division by zero in the
disklabel and fsck_ffs tools.
See this sequence of commands to reproduce:
# dd if=/dev/zero of=nofrag.iso bs=1M count=1
# vnconfig vnd0 nofrag.iso
# disklabel -e
This patch fixes an out of boundary write in cut:
$ cut -c 2147483648 -
Segmentation fault (core dumped)
The supplied number can be parsed by strtol, but the result is casted
into a signed int, therefore turning negative. Afterwards, it is used
as an offset into a char array to write data at the
Hi,
most of the time I've observed that thunar ends with a core if I start
an application (in my case OpenOffice or envince) using the context menu
or by clicking twice on the icon.
core file has the size 0 (no write access?)
Kind regards
Felix
OpenBSD 6.3 (GENERIC.MP) #102: Fri Mar 23 00:0
Here's a diff to move FREF() just after fd_getfile_mode() in
sys_pread(), sys_preadv(), sys_pwrite() and sys_pwritev().
As explained recently [0], I'd like to make sure all operations
manipulating a 'struct file *' do so with a properly refcounted
element.
[0] https://marc.info/?l=openbsd-tech&m=
Here's a diff to move FREF() just after fd_getfile() in getsock().
As explained recently [0], I'd like to make sure all operations
manipulating a 'struct file *' do so with a properly refcounted
element.
[0] https://marc.info/?l=openbsd-tech&m=152214234530708&w=2
Ok?
Index: kern/uipc_syscalls.c
FREF() is currently needed before any sleep point. That's because
there's almost no parallelism in the top half of the kernel. I'd
like to improve that.
The first step is to make sure all operations manipulating a
'struct file *' do so with a properly refcounted element. So here's
a diff moving
This lock is here to prevent a race between multiple threads wanting
to insert and element in the RB-tree. This race is possible because
both getnewvnode() and pool_get() can wait. However this lock adds
some lock ordering problems as soon as we'll try to use proper NFSnode
locks. I'd prefer not
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 have always have:
VFS -> NFS -> NFSnode lock -> socket -> NET_LOCK().
O
On 27/03/18(Tue) 13:02, Tomohiro Kusumi wrote:
> 2018-03-27 0:57 GMT+09:00 Martin Pieuchot :
> > On 25/03/18(Sun) 03:53, Tomohiro Kusumi wrote:
> [...]
> > - Since file(1) on OpenBSD is privilege separated and pledge(2)'d do we
> > really need fstyp(8)? What does it buy us?
>
> Nothing really.
33 matches
Mail list logo
