Re: [9fans] bug in authdial()

hello skip, it is too late but I should say many thanks. > 2016/05/21 7:04、Skip Tavakkolian <9...@9netics.com> のメール： > > supermic% time ./cpu -h grid.nyx.link -k 'dom=outside.plan9.bell-labs.com' -c > pwd > dial took: 165268068 ns > negotiate auth took: 159047373 ns > factotum autenticate

Re: [9fans] bug in authdial()

On Sat May 21 16:05:58 PDT 2016, 9...@9netics.com wrote: > >> >> Waitmsg *exitsts = nil; > > i see; it's set but not used before it is assigned to again. > > i would expect the compiler to get the hint that it's initialization > -- especially given that the value is 0 and the assignment

Re: [9fans] bug in authdial()

> Yes, exactly. And doesn't/didn't ndb have a tag that was used to indicate > whether a system or network used il? (proto=il? I don't have access to a > 9labs machine to check at the moment.) > > Determining ip6 connectivity shouldn't be that hard. If you have a route, > you connect. If

Re: [9fans] bug in authdial()

> On May 21, 2016, at 10:04 AM, erik quanstrom wrote: > > this problem is a little easier to fix. cs needs to do a little more work to > filter out > impossible connection types. for example, if one's internet connection is > not ip6 > capable, then cs should be

Re: [9fans] bug in authdial()

>> >> Waitmsg *exitsts = nil; i see; it's set but not used before it is assigned to again. i would expect the compiler to get the hint that it's initialization -- especially given that the value is 0 and the assignment is right with the declaration.

Re: [9fans] bug in authdial()

> also, > > 209c203 > < char exitsts[2*ERRMAX]; > --- > > Waitmsg *exitsts = nil; > > is likely to generate used-and-not-set on amd64. Wouldn't it be "set and not used" instead? -- David du Colombier

Re: [9fans] bug in authdial()

On Sat May 21 15:19:06 PDT 2016, 9...@9netics.com wrote: > > < char exitsts[2*ERRMAX]; > > --- > >>Waitmsg *exitsts = nil; > > > > is likely to generate used-and-not-set on amd64. > > > > - erik > > i'm not sure i understand how. can you explain? since the only code path that uses

Re: [9fans] bug in authdial()

> < char exitsts[2*ERRMAX]; > --- >> Waitmsg *exitsts = nil; > > is likely to generate used-and-not-set on amd64. > > - erik i'm not sure i understand how. can you explain?

Re: [9fans] bug in authdial()

> i believe this is missing a free. > > - erik good catch; thanks.

Re: [9fans] bug in authdial()

also, 209c203 < char exitsts[2*ERRMAX]; --- > Waitmsg *exitsts = nil; is likely to generate used-and-not-set on amd64. - erik

Re: [9fans] bug in authdial()

On Sat May 21 14:47:24 PDT 2016, 9...@9netics.com wrote: > > a better solution is to just use waitmsg (see wait(2)). the parsing rules > > and sizing are > > already implemented there. > > yes, i agree. i changed my patch. i believe this is missing a free. - erik

Re: [9fans] bug in authdial()

> a better solution is to just use waitmsg (see wait(2)). the parsing rules > and sizing are > already implemented there. yes, i agree. i changed my patch. diff /n/dump/2016/0519/sys/src/libc/9sys/dial.c /sys/src/libc/9sys/dial.c 167c167 < notedeath(Dest *dp, char *exitsts) --- >

Re: [9fans] bug in authdial()

On Fri May 20 15:27:56 PDT 2016, charles.fors...@gmail.com wrote: > On 20 May 2016 at 23:04, Skip Tavakkolian <9...@9netics.com> wrote: > > > i'm a little confused by the discussion of il + tcp on authdial > > causing the delay. if ndb/cs returns multiple dial strings, dialmulti > > function

Re: [9fans] bug in authdial()

On Fri May 20 21:48:40 PDT 2016, aris...@ar.aichi-u.ac.jp wrote: > parallel dialing would be fine. > I guess both cinap and erik have examined labs code. > any problem with it? i don't use this code. i think the problem with parallel dial is that like the tricks we used to play in nsec()—it

Re: [9fans] bug in authdial()

> static int > reap(Dest *dp) > { > char exitsts[2*ERRMAX]; > + int n; > - if (outstandingprocs(dp) && await(exitsts, sizeof exitsts) >= 0) { > + if (outstandingprocs(dp) && (n = await(exitsts, sizeof exitsts-1)) >= > 0) { > + exitsts[n] = 0; >

Re: [9fans] bug in authdial()

Hello, > 2016/05/21 11:25、Skip Tavakkolian <9...@9netics.com> のメール： > > i think this fix is correct; i'm not sure why tokenize didn't have a > problem walking a buffer it expects to be null terminated. I agree with skip. the man wait(2) says: The underlying system call is await, which

Re: [9fans] bug in authdial()

parallel dialing would be fine. I guess both cinap and erik have examined labs code. any problem with it? > 2016/05/21 7:25、Charles Forsyth のメール： > > > On 20 May 2016 at 23:04, Skip Tavakkolian <9...@9netics.com> wrote: > i'm a little confused by the discussion of il

Re: [9fans] bug in authdial()

I am sorry that I didn’t give enough information but I din’t know there is so much difference on the subject among 9front, 9atom and labs plan9. > 2016/05/21 7:04、Skip Tavakkolian <9...@9netics.com> のメール： > > i'm a little confused by the discussion of ...

Re: [9fans] bug in authdial()

i think this fix is correct; i'm not sure why tokenize didn't have a problem walking a buffer it expects to be null terminated. supermic% yesterday -d dial.c diff /n/dump/2016/0520/sys/src/libc/9sys/dial.c /sys/src/libc/9sys/dial.c 209a210 > int n; 211c212,213 < if

Re: [9fans] bug in authdial()

On 20 May 2016 at 23:04, Skip Tavakkolian <9...@9netics.com> wrote: > i'm a little confused by the discussion of il + tcp on authdial > causing the delay. if ndb/cs returns multiple dial strings, dialmulti > function (/sys/src/libc/9sys/dial.c) dials them all in parallel > (rfork) and the first

Re: [9fans] bug in authdial()

can you spot the problem in reap() function in /sys/src/libc/9sys/dial.c? hint: in notedeath() there is a tokenize(exitsts, ...) static int reap(Dest *dp) { char exitsts[2*ERRMAX]; if (outstandingprocs(dp) && await(exitsts, sizeof exitsts) >= 0) { notedeath(dp,

Re: [9fans] bug in authdial()

i'm a little confused by the discussion of il + tcp on authdial causing the delay. if ndb/cs returns multiple dial strings, dialmulti function (/sys/src/libc/9sys/dial.c) dials them all in parallel (rfork) and the first one that returns, wins. btw, i found a bug in dial.c (i'll send it in

Re: [9fans] bug in authdial()

nice idea. I’ve put an option to cs so that il isn’t listed first. > 2016/05/20 0:48、Charles Forsyth のメール： > > It's not just il. There are other networks, other protocols, other than tcp > and IP. > It's one of the advantages of plan 9 that it's easy to try and use

Re: [9fans] bug in authdial()

cinap is right but I wonder if we should take care of IL forever. > 2016/05/18 18:14、cinap_len...@felloff.net のメール： > > yes, passing netroot to netmkaddr() is wrong. however, i dont see where > we pass anything other than netroot=nil to authdial(). > > i suspect what you'r experiencing is that

Re: [9fans] bug in authdial()

hello, thanks for the information. the lookup depends on dns cache but I also don’t think it has a problem. I think the negotiation process is innocent. plan9 auth negotiation is fairly simple, that needs only a single step: C→A: ticket request A→C: encrypted ticket I measured

Re: [9fans] bug in authdial()

i don't think it's the auth lookup: supermic% time ndb/csquery /net/cs net!luna.nyx.link!ticket /net/tcp/clone 115.36.102.252!567 /net/tcp/clone 2402:6b00:4040:b600::8!567 0.00u 0.00s 0.34r ndb/csquery /net/cs net!luna.nyx.link!ticket supermic% time ndb/csquery /net/cs net!grid.nyx.link!cpu

Re: [9fans] bug in authdial()

On 18 May 2016 at 01:43, arisawa wrote: > - p = netmkaddr(nt->val, netroot, "ticket"); > rv = dial(p, 0, 0, 0); > if(rv >= 0) > break; > > + p =

Re: [9fans] bug in authdial()

yes, passing netroot to netmkaddr() is wrong. however, i dont see where we pass anything other than netroot=nil to authdial(). i suspect what you'r experiencing is that dial() tried IL first (with !fasttimeout option), which fails and then tries TCP causing the delay. so you changing it to try

[9fans] bug in authdial()

Hello, authdial() is slow. so I have inspected the code: /sys/src/libauthsrv/authdial.c I suspect netroot causes the problem. int authdial(char *netroot, char *dom) { [snip] if(dom == nil) /* look for one relative to my machine */ return