Yes, but it's IMO far better to have the memory problem in userspace than in
kernel space. If mountd runs out of memory, then new clients can't connect. If
the kernel runs out of memory, ... worse things happen.
> The hacking is not that fundamental. In fact, the request doesn't
> have to travel up to mountd at all.
> Do this in sunrpc/svcsock.c:
<code deleted>
Nice, but I'd be far happier if we could have the malloc() in userspace
instead of kernel space.
We can do this with a simple variation of your code:
Remove the deferred queue. Instead of svc_defer() sticking the request on the
deferred queue, it instead passes it up the netlink to mountd.
When mountd makes a decision, it then passes the request back down to the
kernel via the netlink, at which point it can be copied onto the deferred_ready
queue.
(In fact, we won't copy it - we'll just declare the deferred_ready queue to be
a queue of skbs, and let svc_recv deal with that. But that's an implementation
detail.)
It would be nice to allow mountd to inject a _reply_ rather than just the
original request. That way we can ditch the negative exportents -
if the answer is ESTALE, then mountd can answer itself, and the kernel doesn't
need to bother.
To do this, can we declare a new procedure which always returns ESTALE, and let
mountd change the rq_proc accordingly if it wants the request to be refused?
> Still, I vote for just dropping the request, and wait for the client
> to retransmit. It's KISS.
It's nice, but as someone pointed out, it's not necessarily the right thing to
do for TCP, where clients may assume that the request got through, and not
attempt to retransmit.
> > There should be a way of selectively disabling the cached entries
> > which are obsoleted, rather than just trashing the cache entirely.
okir@monad.swb.de said:
> I've twice written the kind of code that does this -- once for unfsd
> and once for knfsd. Just nuking the cache sounds like a good
> alternative to me :-)
Fair enough. I wouldn't suggest that we tried to be very clever - just avoid
nuking the entries that blatantly aren't relevant to the change that's just
been made. So we remove all entries for a certain device, rather than
absolutely every entry.
---- ---- ----
David Woodhouse David.Woodhouse@mvhi.com Office: (+44) 1223 810302
Project Leader, Process Information Systems Mobile: (+44) 7976 658355
Axiom (Cambridge) Ltd., Swaffham Bulbeck, Cambridge, CB5 0NA, UK.
finger dwmw2@ferret.lmh.ox.ac.uk for PGP key.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/