wait, Maxdest is a count, see:
dest = emalloc(Maxdest * sizeof *dest); /* dest can't be on stack */
code like:
Dest*curdest; /* pointer to next to fill */
p = dp->dest;
...
if (qp->ndest > qp->curdest - p) {
and
for(p = qp->dest; p < qp->curdest; p++)
indicates that dp->curdest is
Hello,
On 2012/08/22, at 19:32, cinap_len...@gmx.de wrote:
> the result check of that serveraddr() call should really be:
>
> if (j < 0 || j > Maxdest) {
> dnslog("serveraddrs() result %d out of range", j);
> abort();
> }
>
look closely at:
> qp->curdest = &qp->dest[j];
this just takes the address, it doesnt actually dereference anything. you
could write this as qp->curdest = qp->dest + j.
that destck(qp->curdest); call and the j >= Maxdest check after the
serveraddrs() call seem like a confused debug
On Wed Aug 22 08:38:51 EDT 2012, cinap_len...@gmx.de wrote:
> look closely at:
>
> > qp->curdest = &qp->dest[j];
>
> this just takes the address, it doesnt actually dereference anything. you
> could write this as qp->curdest = qp->dest + j.
>
> that destck(qp->curdest); call and the
> and further, after failing to get an answer from 24 different servers, it's
> unlikely
> that the 25th will trying 24 different servers for the same address is already
> i think it should be smaller. but that's just me. :-).
good grief. what that was supposed to say was "the 25th is unlikely
for(n = 0; n < Maxdest; n++, qp->curdest++)
if (setdestoutns(qp->curdest, n) < 0)
On 22 August 2012 09:05, erik quanstrom wrote:
> since qb->curdest is indirected, for example by setdestoutns, this must be
> a valid pointer to remain safe.
>
only when the pointer is valid. I think cinap is ri
> or is here
> any reason why serveraddrs() should *not* fill the whole array up
> to the last element and stop at Maxdest-2?
I'm just guessing here, but Kenji pointed to the need to add a server
address in the case of a straddling server. Would that perhaps be a
factor here?
++L
On Wed Aug 22 09:12:24 EDT 2012, charles.fors...@gmail.com wrote:
> for(n = 0; n < Maxdest; n++, qp->curdest++)
> if (setdestoutns(qp->curdest, n) < 0)
>
>
> On 22 August 2012 09:05, erik quanstrom wrote:
>
> > since qb->curdest is indirected, for example by setdestoutns, this must be
> > a v
that's why cinap removed that line in his diff.
On 22 August 2012 09:18, erik quanstrom wrote:
> you can argue that this is a mistake, but i'm sure there are others.
i just said it like 2 times already that i think this destck() and the
result serveraddrs() check is bogus and is the source of all this
confustion.
the "curdest" is handled as an end pointer in the rest of the code.
its where you start adding stuff, and after writing it, you increment
it to the
On Wed Aug 22 09:34:24 EDT 2012, cinap_len...@gmx.de wrote:
> i just said it like 2 times already that i think this destck() and the
> result serveraddrs() check is bogus and is the source of all this
> confustion.
>
> the "curdest" is handled as an end pointer in the rest of the code.
doesn't thi
No, see the call to procansw
On 22 August 2012 10:22, erik quanstrom wrote:
> since, if qp->curdest is an end pointer, then p!=qp->curdest ≡ 1.
this is interesting. the p != qp->curdest check would just
support my point because it effectively checks if p is valid.
if p would be at qp->curdest, it would be past the last valid
entry and hence invalid so its not written.
but theres another thing, look in queryns() how p comes to be:
On Wed Aug 22 10:51:02 EDT 2012, cinap_len...@gmx.de wrote:
> this is interesting. the p != qp->curdest check would just
> support my point because it effectively checks if p is valid.
> if p would be at qp->curdest, it would be past the last valid
> entry and hence invalid so its not written.
if
here's my copy. it probablly won't work if *ncpu>1 on the standard
system because vmap's no up to the task.
i didn't re-verify that all the vmap() wiggles are necessary with
nix; they are with the pae kernel.
- erik#include"u.h"
#include"../port/lib.h"
#include"mem.h"
#in
On Wed Aug 22 11:34:39 EDT 2012, quans...@quanstro.net wrote:
> here's my copy. it probablly won't work if *ncpu>1 on the standard
> system because vmap's no up to the task.
>
> i didn't re-verify that all the vmap() wiggles are necessary with
> nix; they are with the pae kernel.
>
> - erik
so
I sent this to cinap earlier, who concurred.
On 22 August 2012 11:12, Charles Forsyth wrote:
> Given the comment
>
> /* remove all addrs of responding server from list */
> for(np = qp->dest; np < qp->curdest; np++)
> if(np->s == p->s)
> p->nx = Maxtrans;
>
> I wonder whether np->nx = Maxtrans
I had this problem several years ago
with an adsl router (9fans archive may know about this). There was a bug in my
adsl router (which seems to be common, I have seen it since more than once)
that dropped ethernet frames of size greater than 1480 (someone counted a
header twice probably). Linux
On Wed, Aug 22, 2012 at 10:18 AM, Gorka Guardiola wrote:
> I had this problem several years ago
> with an adsl router (9fans archive may know about this). There was a bug in
> my adsl router (which seems to be common, I have seen it since more than
> once) that dropped ethernet frames of size gr
On Wed Aug 22 14:31:13 EDT 2012, sstall...@gmail.com wrote:
> On Wed, Aug 22, 2012 at 10:18 AM, Gorka Guardiola
> wrote:
> > I had this problem several years ago with an adsl router (9fans
> > archive may know about this). There was a bug in my adsl router
> > (which seems to be common, I have se
i'm probablly wrong again, but we had a crash with this back trace.
the process doing the i/o was given a note. ...
src(0xe010a6b9); // dumpstack+0x10
src(0xe0112653); // panic+0x112
src(0xe010a8d7); // fault386+0x17d
src(0xe0109dc2); // trap+0x15d
src(0xe010066f); // forkret
//passing interrupt f
the mntrpc m->queue is protected by the mnt lock. when
mountmux() unlocks m, it has already removed the rpc from
the queue so how would mntqrm() get to the rpc in that case?
any other cases where the rpc is taken somewhere and then
the mnt lock is (maybe just temporarily) released and then
used ag
ohhh! i see :)
--
cinap
i think this is not so mutch mntflushfree() / mntqrm(), but when we
complete a request for someone else (q != r) and we release m,
the other proc could indeed be woken up already freeing the rpc
while we are are trying to wakeup on that "done with" rpc?
--
cinap
On Wed Aug 22 15:56:43 EDT 2012, cinap_len...@gmx.de wrote:
> i think this is not so mutch mntflushfree() / mntqrm(), but when we
> complete a request for someone else (q != r) and we release m,
> the other proc could indeed be woken up already freeing the rpc
> while we are are trying to wakeup on
i think we'r seeing exactly what russ described on 9fans here:
http://9fans.net/archive/2011/02/358
after we set q->done = 1; (the unlock of m probably doesnt even
matter) it might be possible for mountio()'s sleep() call to return
immidiately and return, freeing the rpc before mountmux()
on anot
On Wed Aug 22 19:33:52 EDT 2012, cinap_len...@gmx.de wrote:
> i think we'r seeing exactly what russ described on 9fans here:
>
> http://9fans.net/archive/2011/02/358
>
> after we set q->done = 1; (the unlock of m probably doesnt even
> matter) it might be possible for mountio()'s sleep() call to
27 matches
Mail list logo
