> } I would be interested in knowing an actual example of the comparison
> } problem with the CIRCLEQ macro, if the concern isn't theoretical. Since
>
> Uh, do you really think people would be doing all this work
> for something that was theoretical? The problem is that gcc 4.8
> optimises
Edgar Fuß wrote:
> > If not, calls are serialised under kernel lock and it may not necessary
> > have to be reetrant (terms and conditions apply).
> I'm sorry to say that I know rather little about these T&Cs.
>
> > Keep in mind that multi-thread safety and reentrancy are not the same.
> I'm afr
On Sat, 23 Nov 2013 11:46:19 -0200
Lourival Vieira Neto wrote:
> On Sat, Nov 23, 2013 at 1:22 AM, James K. Lowden
> wrote:
> > On Mon, 18 Nov 2013 09:07:52 +0100
> > Marc Balmer wrote:
> >
> >> After discussion we lneto@ and others we realised that there are
> >> several such libraries around, a
> If not, calls are serialised under kernel lock and it may not necessary
> have to be reetrant (terms and conditions apply).
I'm sorry to say that I know rather little about these T&Cs.
> Keep in mind that multi-thread safety and reentrancy are not the same.
I'm afraid I don't get that.
My appl
Edgar Fuß wrote:
> If I install the same function on two different callouts, i.e.
> callout_reset(&c1, n1, f, &x1);
> and
> callout_reset(&c2, n2, f, &x2);
> does anything prevent f being called twice concurrently?
If you pass CALLOUT_MPSAFE flag, then you should assume that the funct
If I install the same function on two different callouts, i.e.
callout_reset(&c1, n1, f, &x1);
and
callout_reset(&c2, n2, f, &x2);
does anything prevent f being called twice concurrently?
I.e., am I correct that f has to be re-entrant in this case?
On Sun, Nov 24, 2013 at 07:29:25PM +0100, Edgar Fuß wrote:
> > You shouln't bus_dmamap_unload() before stopping the IOC.
> Thanks.
>
> Well, in my case, it's not going to matter because I will, on timeout,
> restart the IOC anyway.
> But if I could get away without restarting the IOC, what am I s
On Nov 24, 5:25am, Mouse wrote:
}
} Well, mrg wrote, when starting the thread,
}
} < while preparing to update to GCC 4.8 i discovered that our
} < sys/queue.h CIRCLEQ macros violate C aliasing rules, ultimately
} < leading to the compiler eliding comparisons it declared as always
} < false.
}
> You shouln't bus_dmamap_unload() before stopping the IOC.
Thanks.
Well, in my case, it's not going to matter because I will, on timeout,
restart the IOC anyway.
But if I could get away without restarting the IOC, what am I supposed to do?
I can't know whether the IOC thinks its still processin
On Sun, Nov 24, 2013 at 06:44:32PM +0100, Edgar Fuß wrote:
> Further digging through mpt(4)'s timeout handling, I'm getting the impression
> that there's a missing bus_dmamap_unload() for the data buffer
> (for xs->datalen != 0).
>
> However, I neither know whether that's doing any harm nor what
On Sun, Nov 24, 2013 at 12:41:12PM +0100, Edgar Fuß wrote:
> So, to partially answer myself:
>
> > scsipi/driver interaction (is there documentation on this?)
> I had missed the comprehensive scsipi(9) man page. I guess I mis-typed
> "scsipi" when looking for it.
>
> > First question: what's the
On Sun, Nov 24, 2013 at 05:51:34PM +0100, Edgar Fuß wrote:
> While looking for examples of scsipi's XS_RESET usage, I stumbled over
> xs->error = XS_NOERROR | XS_RESET;
> in sys/dev/pci/trm.c.
> I don't think this does anything useful.
Yes, we want XS_RESET. This is harmless because XS_NOERR
Further digging through mpt(4)'s timeout handling, I'm getting the impression
that there's a missing bus_dmamap_unload() for the data buffer
(for xs->datalen != 0).
However, I neither know whether that's doing any harm nor what happens in case
the IOC is still using the buffer.
While looking for examples of scsipi's XS_RESET usage, I stumbled over
xs->error = XS_NOERROR | XS_RESET;
in sys/dev/pci/trm.c.
I don't think this does anything useful.
> (I think that) strict aliasing rules implies that if two types
> "type{1,2}" do not match any of the aliasing rules (e.g. type1 is of
> the same type as the first member of type2, or type1 is a char, or
> ...), then any two pointers ptr{1,2} on type{1,2} respectively _ARE_
> different, because *p
So, to partially answer myself:
> scsipi/driver interaction (is there documentation on this?)
I had missed the comprehensive scsipi(9) man page. I guess I mis-typed
"scsipi" when looking for it.
> First question: what's the appropriate xs->error?
So this has been answered both by me finding that
> [The compiler] also couldn't know if pointers whose types it did know
> were referring to different members of the same union, perhaps with
> the union declared in another compilation unit
The text I have says
[#5] One special guarantee is made in order to simplify the
use of uni
BB> I know we've been corresponding on this for a while
Yes, thaks again for that.
EF> Now, what's the correct way of reset/init the IOC and returning everything
EF> to scsipi? I guess the correct order is to reset (which leave the IOC in
EF> the stopped state), then to set xs->error and call sc
>> the C standard explicitly allows a pointer to a structure type to be
>> converted to the type of its first member and back, to another
>> structure type and back, or to char * or void * and back,
> I rather doubt that you can convert to a different structure type and
> back.
I feel sure Dennis
> It isn't perfectly clear to me that this code has an aliasing problem
> the way it is, though.
gcc thinks it does, apparently.
> The only thing that matters in the standard are the types of the
> lvalue expressions used to access object in storage. The lvalue
> expression types used to access
>> To be type-correct, the various structs sockaddr_* really need to be
>> a single discriminated union...and I'm not sure sockaddr_un can ever
>> be done type-correctly; I'd have to think about it more.)
> GCC's transparent unions are really nice for this.
Yes, though all they do is remove an oth
On Saturday, at 19:08, Dennis Ferguson wrote:
| gcc can't correctly eliminate the comparison just because you are asking
| it to compare pointers to different structure types. No aliasing issues
| arise in any case unless you actually use the pointers to access something,
| and there are many ways
22 matches
Mail list logo
