Re: [net] protecting interfaces from races between control and d

--089e013a1666d6e88d04e337b81a
Content-Type: text/plain; charset=ISO-8859-1

What do you think about this change?

Cheers,

Jack

On Mon, Aug 5, 2013 at 10:58 AM, Luigi Rizzo <rizzo@iet.unipi.it> wrote:

> On Mon, Aug 5, 2013 at 7:49 PM, Jack Vogel <jfvogel@gmail.com> wrote:
>
>> Sigh, this ends up being ugly I'm afraid. I need some time to look at
>> code and think about it.
>>
>>
> actually the intel drivers seem in decent shape,
> especially if we reuse IFF_DRV_RUNNING as the reset flag
> and the core+queue lock in the control path.
>
> cheers
> luigi
>
>
>
>> Jack
>>
>>
>>
>> On Mon, Aug 5, 2013 at 10:36 AM, Luigi Rizzo <rizzo@iet.unipi.it> wrote:
>>
>>> On Mon, Aug 5, 2013 at 7:17 PM, Adrian Chadd <adrian@freebsd.org> wrote:
>>>
>>> > I'm travelling back to San Jose today; poke me tomorrow and I'll brain
>>> > dump what I did in ath(4) and the lessons learnt.
>>> >
>>> > The TL;DR version - you don't want to grab an extra lock in the
>>> > read/write paths as that slows things down. Reuse the same per-queue
>>> > TX/RX lock and have:
>>> >
>>> > * a reset flag that is set when something is resetting; that says to
>>> > the queue "don't bother processing anything, just dive out";
>>> > * 'i am doing Tx / Rx' flags per queue that is set at the start of
>>> > TX/RX servicing and finishes at the end; that way the reset code knows
>>> > if there's something pending;
>>> > * have the reset path grab each lock, set the 'reset' flag on each,
>>> > then walk each queue again and make sure they're all marked as 'not
>>> > doing TX/RX'. At that point the reset can occur, then the flag cna be
>>> > cleared, then TX/RX can resume.
>>> >
>>>
>>> so this is slightly different from what Bryan suggested (and you
>>> endorsed)
>>> before, as in that case there was a single 'reset' flag IFF_DRV_RUNNING
>>> protected by the 'core' lock, then a nested round on all tx and rx locks
>>> to make sure that all customers have seen it.
>>> In both cases the tx and rx paths only need the per-queue lock.
>>>
>>> As i see it, having a per-queue reset flag removes the need for nesting
>>> core + queue locks, but since this is only in the control path perhaps
>>> it is not a big deal (and is better to have a single place to look at to
>>> tell whether or not we should bail out).
>>>
>>> cheers
>>> luigi
>>>
>>> _______________________________________________
>>> freebsd-net@freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
>>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
>>>
>>
>>
>
>
> --
> -----------------------------------------+-------------------------------
>  Prof. Luigi RIZZO, rizzo@iet.unipi.it  . Dip. di Ing. dell'Informazione
>  http://www.iet.unipi.it/~luigi/        . Universita` di Pisa
>  TEL      +39-050-2211611               . via Diotisalvi 2
>  Mobile   +39-338-6809875               . 56122 PISA (Italy)
> -----------------------------------------+-------------------------------
>

--089e013a1666d6e88d04e337b81a
Content-Type: application/octet-stream; name="quiesce.diff"
Content-Disposition: attachment; filename="quiesce.diff"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_hk012dni0

UHJveHlDaGFpbnMtMy4xIChodHRwOi8vcHJveHljaGFpbnMuc2YubmV0KQpJbmRleDogaXhnYmUu
Ywo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09Ci0tLSBpeGdiZS5jCShyZXZpc2lvbiAyNTM5NjUpCisrKyBpeGdiZS5jCSh3
b3JraW5nIGNvcHkpCkBAIC0xMDczLDYgKzEwNzMsNyBAQAogCiAJbXR4X2Fzc2VydCgmYWRhcHRl
ci0+Y29yZV9tdHgsIE1BX09XTkVEKTsKIAlJTklUX0RFQlVHT1VUKCJpeGdiZV9pbml0X2xvY2tl
ZDogYmVnaW4iKTsKKwlpeGdiZV9xdWllc2NlX3F1ZXVlcyhhZGFwdGVyKTsKIAlody0+YWRhcHRl
cl9zdG9wcGVkID0gRkFMU0U7CiAJaXhnYmVfc3RvcF9hZGFwdGVyKGh3KTsKICAgICAgICAgY2Fs
bG91dF9zdG9wKCZhZGFwdGVyLT50aW1lcik7CkBAIC0xMzM2LDcgKzEzMzcsMjYgQEAKIAlyZXR1
cm47CiB9CiAKKy8qCisqKiBNYWtlIHN1cmUgYWxsIHF1ZXVlcyBoYXZlIHNlZW4gSUZGX0RSVl9S
VU5OSU5HCisqKiBpcyBjbGVhcmVkIGFuZCBzdG9wIHByb2Nlc3NpbmcuCisqLworc3RhdGljIGlu
bGluZSB2b2lkCitpeGdiZV9xdWllc2NlX3F1ZXVlcyhzdHJ1Y3QgYWRhcHRlciAqYWRhcHRlcikK
K3sKKwlzdHJ1Y3QgaWZuZXQgICAqaWZwID0gYWRhcHRlci0+aWZwOworCXN0cnVjdCB0eF9yaW5n
CSp0eHIgPSBhZGFwdGVyLT50eF9yaW5nczsKKwlzdHJ1Y3QgcnhfcmluZyAqcnhyID0gYWRhcHRl
ci0+cnhfcmluZ3M7CiAKKwlpZnAtPmlmX2Rydl9mbGFncyAmPSB+SUZGX0RSVl9SVU5OSU5HOwor
CWZvciAoaW50IGkgPSAwOyBpIDwgYWRhcHRlci0+bnVtX3F1ZXVlczsgaSsrLCByeHIrKywgdHhy
KyspIHsKKwkJSVhHQkVfVFhfTE9DSyh0eHIpOworCQlJWEdCRV9UWF9VTkxPQ0sodHhyKTsKKwkJ
SVhHQkVfUlhfTE9DSyhyeHIpOworCQlJWEdCRV9SWF9VTkxPQ0socnhyKTsKKwl9Cit9CisKIC8q
CiAqKgogKiogTVNJWCBJbnRlcnJ1cHQgSGFuZGxlcnMgYW5kIFRhc2tsZXRzCg==
--089e013a1666d6e88d04e337b81a
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
--089e013a1666d6e88d04e337b81a--