5.3-RELEASE TODO

[Giorgos Keramidas]

On 2004-10-08 07:46, Robert Watson <rwatson at freebsd.org> wrote:
> On Fri, 8 Oct 2004, Giorgos Keramidas wrote:
>
> > Are we allowed to change the prototype of ether_demux()?
> >
> > If yes, we could make ether_demux() return -1 if it frees the mbuf, and
> > avoid calling random_harvest() on that particular frame.  Note that I
> > haven't had a chance to test build or run the following patch yet, but
> > if anyone has a better idea or comments that would help us improve it,
> > they're welcome.
> >
> > One note that I have taken down while writing this and I have to check
> > is the possibility of calling random_harvest(m->m_data, 16, ...) with an
> > mbuf whose m->m_data contains less than 16 bytes.
>
> I looked at a couple of things:
>
> - Move the harvesting before the call to ether_demux()
> - Delete the harvesting call

There are many ways in which the mbuf can get "taken away" from under
ether_input()'s feet, now that I look at teh changes in more detail.

The mbuf can go away in ether_demux() or ip_fastforward() or even deeper
in netisr_dispatch() or ... so it's not very safe to keep the harvesting
call after ether_demux().

I've added a sysctl to count the packets that are indeed passed to the
random_harvest() function with my proposed patch, but I have a lingering
suspicion that none is (because the mbuf is handled in ether_demux() and
freed before the harvester has a chance to run).

More on that later...

> I haven't yet tried to make the harvesting call use real mbuf data, but
> I'm somewhat dubious of the real value of that: Bill Simpson has pointed
> out that in practice most hosts talk primarily to their default gateway or
> a very small set of local peers.

In a local area network where several machines are on the same LAN
(virtual or not), the machines might be more than a handful though.
I regularly ssh into 3-4 development/testing Solaris machines here.
Then we have the DNS server, the Samba fileshares, and yes there's
a gateway too.

It all depends on what one considers a "very small set of local peers",
I guess.

> In interrupt-driven operation, you're
> already reaping entropy from receiving the interrupt, so in that scenario,
> I think there are diminishing returns from trying to also reap entropy at
> the ether_demux() point.  In the netperf branch, I've simply deleted it --
> that said, in polling operation, you don't get network interrupts so there
> may be some benefit here for that.

Hmmm, that sounds very reasonable.  Can we make the call to the harvest
function conditional on non-interrupt driven operation?

> I'll prepare a candidate patch and post it in the next couple of days.

Sure.  I'll go on reading the source.  I know you've been sort of
offline so there's no reason to rush anything.  Take your time ;-)

- Giorgos

PS: I dropped RE from the Cc: list since I'm sure they get too many email
messages already.