On 02/19/15 12:01, Stefan Sperling wrote:
This fixes IPv6 autoconf over iwm for me. iwm users please test.
Does the trick for me.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
On Feb 13, 2015, at 7:29 AM, David Higgs wrote:
> On Friday, February 13, 2015, Martin Pieuchot wrote:
> On 13/02/15(Fri) 00:28, David Higgs wrote:
> > I guess nobody else has tried calling uhidev_get_report_async() yet. :)
> >
> > First I was getting a NULL pointer deref in the uhidev async cal
On Thu, Feb 19, 2015 at 08:01:01PM -0500, Ted Unangst wrote:
> Yes. That is consistent with other callers.
OK bluhm@
> Index: pf_ioctl.c
> ===
> RCS file: /cvs/src/sys/net/pf_ioctl.c,v
> retrieving revision 1.282
> diff -u -p -r1.282
Alexander Bluhm wrote:
> On Thu, Feb 19, 2015 at 06:31:01PM -0500, Ted Unangst wrote:
> > Maxime Villard wrote:
> > > Hi,
> > > I put here a bug among others:
> >
> > Thanks. I see two cases here where we need to pool_put the qs. Also need to
> > change return to break so that we release the rwloc
On Thu, Feb 19, 2015 at 06:31:01PM -0500, Ted Unangst wrote:
> Maxime Villard wrote:
> > Hi,
> > I put here a bug among others:
>
> Thanks. I see two cases here where we need to pool_put the qs. Also need to
> change return to break so that we release the rwlock.
>
>
> Index: pf_ioctl.c
> ==
On Thu, 19 Feb 2015 18:31:01 -0500, "Ted Unangst" wrote:
> Thanks. I see two cases here where we need to pool_put the qs. Also need to
> change return to break so that we release the rwlock.
Not to mention the splx(). OK millert@
- todd
Maxime Villard wrote:
> Hi,
> I put here a bug among others:
Thanks. I see two cases here where we need to pool_put the qs. Also need to
change return to break so that we release the rwlock.
Index: pf_ioctl.c
===
RCS file: /cvs/src/
Hi,
I put here a bug among others:
-- sys/net/pf_ioctl.c --
1027qs = pool_get(&pf_queue_pl, PR_WAITOK|PR_LIMITFAIL|PR_ZERO);
if (qs == NULL) {
error = ENOMEM;
break;
Alexander Bluhm wrote:
> Anyway, libtls is locked. We can either release a broken syslogd
> over TLS implementation or commit this diff. It has the smallest
> impact of everything I have tried.
>
> ok or better idea?
ok
On Thu, Feb 19, 2015 at 09:30:40PM +0100, Alexander Bluhm wrote:
> On Wed, Feb 18, 2015 at 12:14:15PM +0100, Matthieu Herrb wrote:
> > Feb 18 12:09:59 castor /bsd: splassert: rtrequest1: want 5 have 0
> > Feb 18 12:09:59 castor /bsd: Starting stack trace...
> > Feb 18 12:09:59 castor /bsd: splasser
On 19 February 2015 at 21:30, Alexander Bluhm wrote:
> On Wed, Feb 18, 2015 at 12:14:15PM +0100, Matthieu Herrb wrote:
>> Feb 18 12:09:59 castor /bsd: splassert: rtrequest1: want 5 have 0
>> Feb 18 12:09:59 castor /bsd: Starting stack trace...
>> Feb 18 12:09:59 castor /bsd: splassert_check() at s
On Tue, Feb 17, 2015 at 09:10:05AM +0100, Reyk Floeter wrote:
> But workaround is a harsh word - this is the way you were supposed to
> use SSL_write(). It is adapted from relayd and was turned into
> tls_write().
I came from the other direction. I had no idea about SSL API and
expected to use l
On Wed, Feb 18, 2015 at 12:14:15PM +0100, Matthieu Herrb wrote:
> Feb 18 12:09:59 castor /bsd: splassert: rtrequest1: want 5 have 0
> Feb 18 12:09:59 castor /bsd: Starting stack trace...
> Feb 18 12:09:59 castor /bsd: splassert_check() at splassert_check+0x78
> Feb 18 12:09:59 castor /bsd: rtreques
> > @@ -733,6 +734,9 @@
> >
> > fb_delete(fbuf);
> > }
> > +
> > + if (!error && ap->a_eofflag != NULL)
> > + *ap->a_eofflag = eofflag;
>
> Is the null check here necessary? Other file systems don't do this, so I'm
> wondering if you encountered a null pointer here.
I
This fixes IPv6 autoconf over iwm for me. iwm users please test.
Index: if_iwm.c
===
RCS file: /cvs/src/sys/dev/pci/if_iwm.c,v
retrieving revision 1.18
diff -u -p -r1.18 if_iwm.c
--- if_iwm.c11 Feb 2015 01:12:42 - 1.18
++
For after release, but since I was looking in the file...
Some of the checks in xmalloc.c are excessive. I think we've moved past the
mid-90s era when coping with various busted libcs was important for ssh (where
this file originated). I'll note that the error messages aren't particuarly
helpful i
Hi all
When I was trying to debug a double fault on 5.6, I found the trap frame
looked a bit strange. After some investigation and reading source
code, I found that double fault handling looked problematic.
Per Intel SDM volume 3A, processor will push 0 to stack as error code when
double fault oc
Martin Natano wrote:
> fuse_readdir() fails to set the eofflag correctly. The consequence of
> this is, that callers of VOP_READDIR, that examine the value of the
> eofflag after the call, might be mislead about the eof status, as the
> flag hasn't been modified (and my even be uninitialized).
>
>
On Feb 19 10:01:22, j...@insec.sh wrote:
> On Wed, Feb 18, 2015 at 11:23:15AM +1000, David Gwynne wrote:
> > it looks like it reads the DCSR register and then keeps everything
> > except the MPS field.
> >
> > this might cause it to erronously consider the mps to be much bigger
> > than 2048, whic
19 matches
Mail list logo
