No way to config_finalize_unregister() ?

[paul]

It seems that config_finalize_register() intends to accomodate drivers
that are loaded after the bulk of kernel configuration is complete.  If
config_finalize_done is already set, the specified callback is invoked
immediately.

Whether or not we do the immediate callback, we check to see if the
callback is already registerd and if not, we add it to the list.

This seems pretty useless to me.  The only other place where callbacks
are invoked is in config_finalize(), which is only called from
init_main().

Is there any reason to keep the post-boottime-loaded driver's callbacks
in the list, if nothing will process the list?



+--+--++
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:  |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com   |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+--+--++

Re: a parallel operation problem about softint(9)

[Thor Lancelot Simon]

On Fri, Dec 18, 2015 at 11:09:17AM +0900, Kengo NAKAHARA wrote:
> 
> I think softint_disestablish should wait not only SOFTINT_ACTIVE
> but also SOFTINT_PENDING flag, that is, the following patch is
> required

I agree.

> 
> --- a/sys/kern/kern_softint.c
> +++ b/sys/kern/kern_softint.c
> @@ -443,7 +443,7 @@ softint_disestablish(void *arg)
> flags |= sh->sh_flags;
> }
> /* Inactive on all CPUs? */
> -   if ((flags & SOFTINT_ACTIVE) == 0) {
> +   if ((flags & (SOFTINT_PENDING | SOFTINT_ACTIVE)) == 0) {
> break;
> }
> /* Oops, still active.  Wait for it to clear. */
> 
> Under my environment, this patch fixes above panic, and does not cause
> new problems.

This looks right.

Thor

a parallel operation problem about softint(9)

[Kengo NAKAHARA]

Hi,

I found a parallel operation problem between softint_execute()
and softint_disestablish().

The following single CPU operation of softint(9) is ok.
- softint_establish()
  - set function, argument, and so on to the appropriate softint_t
- softint_schedule()
  - the softhand_t is set SOFTINT_PENDING flag
  - the softhand_t is inserted to si->si_q queue
- wait for softint is scheduled
- softint_execute()
  - the softhand_t is removed form si->si_q queue
  - the softhand_t is unset SOFTINT_PENDING flag
  - the softhand_t is set SOFTINT_ACTIVE flag
  - do softint handler of the softhand_t
  - the softhand_t is unset SOFTINT_ACTIVE flag
- softint_disestablish()
  - wait until softhand_t's SOFTINT_ACTIVE of all CPUs is clear
  - unset function of the softint_t

In contrast, the following parallel operation causes panic.
(0) softint handler "handler A" is established
(1) CPU#X do softint_schedule() for "handler A"
- the softhand_t is set SOFTINT_PENDING flag
- the softhand_t is NOT set SOFTINT_ACTIVE flag yet
(2) CPU#X begin other H/W interrupt processing
(3) CPU#Y do softint_disestablish() for "handler A"
- wait until softhand_t's SOFTINT_ACTIVE of all CPUs is clear
- the softhand_t is set not SOFTINT_ACTIVE but SOFTINT_PENDING,
  so CPU#Y does not wait
- unset function of "handler A"
(4) CPU#X do softint_execute()
- the function of "handler A" is already clear, so panic

I think softint_disestablish should wait not only SOFTINT_ACTIVE
but also SOFTINT_PENDING flag, that is, the following patch is
required

--- a/sys/kern/kern_softint.c
+++ b/sys/kern/kern_softint.c
@@ -443,7 +443,7 @@ softint_disestablish(void *arg)
flags |= sh->sh_flags;
}
/* Inactive on all CPUs? */
-   if ((flags & SOFTINT_ACTIVE) == 0) {
+   if ((flags & (SOFTINT_PENDING | SOFTINT_ACTIVE)) == 0) {
break;
}
/* Oops, still active.  Wait for it to clear. */

Under my environment, this patch fixes above panic, and does not cause
new problems.

Could you comment this patch? 


Thanks,

-- 
//
Internet Initiative Japan Inc.

Device Engineering Section,
Core Product Development Department,
Product Division,
Technology Unit

Kengo NAKAHARA 

Re: Freeze with BPF BIOCSFEEDBACK

[Rhialto]

On Thu 17 Dec 2015 at 17:38:33 -0500, Christos Zoulas wrote:
> 
> I think that we need to add extra code to be able to communicate with
> localhost, since that's special... But it is not a significant limitation...

I thought I'd found a workaround: use bpf on a tap device which is
bridged to a real device. However that doesn't seem to help, and also it
breaks external communication too. But it (klh10, I said simh
incorrectly before) still replies to ARP requests, so it does still get
to see those. Although it seems that this scenario causes confusion over
which ethernet address to use, and responds. (Changing the tap's
ethernet address to be the same as the physical interface causes no
error message from ifconfig tap0 link , but doesn't work either)

Normally one would of course use a tap device in the normal fashion
(which works for 2-way communication), but I'm reorganising things and
needed to try this out.

The deeper story behind it that I want to use libpcap for packet
capture, so that I can remove crufty code for DLPI, PFLT, NIT (and
BPF).

> christos
-Olaf.
-- 
___ Olaf 'Rhialto' Seibert  -- The Doctor: No, 'eureka' is Greek for
\X/ rhialto/at/xs4all.nl-- 'this bath is too hot.'


signature.asc
Description: PGP signature

Re: Freeze with BPF BIOCSFEEDBACK

[Christos Zoulas]

On Dec 17, 11:28pm, rhia...@falu.nl (Rhialto) wrote:
-- Subject: Re: Freeze with BPF BIOCSFEEDBACK

| Thanks! That fixes this problem.
| 
| Interestingly enough, I still can't seem to communicate (I tried with
| telnet) between the host system and the emulated system.
| 
| As before, it works between the emulated system and any other one on the
| network.
| 
| (The original problem is that packets sent out via bpf are seen on the
| wire, i.e. the external network, but not by the host. The data does flow
| in the other direction though. I can see on the console of simh that it
| (tries to) send(s) ARP replies for its IPv4 address.)
| 
| I thought this ioctl was supposed to fix this limitation, but it seems
| something still doesn't work for me.

I think that we need to add extra code to be able to communicate with
localhost, since that's special... But it is not a significant limitation...

christos

Re: Freeze with BPF BIOCSFEEDBACK

[Rhialto]

On Wed 16 Dec 2015 at 23:15:11 +, Christos Zoulas wrote:
> Update to bpf.c to head, I just committed a fix.

Thanks! That fixes this problem.

Interestingly enough, I still can't seem to communicate (I tried with
telnet) between the host system and the emulated system.

As before, it works between the emulated system and any other one on the
network.

(The original problem is that packets sent out via bpf are seen on the
wire, i.e. the external network, but not by the host. The data does flow
in the other direction though. I can see on the console of simh that it
(tries to) send(s) ARP replies for its IPv4 address.)

I thought this ioctl was supposed to fix this limitation, but it seems
something still doesn't work for me.

> christos
-Olaf.
-- 
___ Olaf 'Rhialto' Seibert  -- The Doctor: No, 'eureka' is Greek for
\X/ rhialto/at/xs4all.nl-- 'this bath is too hot.'


signature.asc
Description: PGP signature