Re: [PATCH 2.6] serialization of kernelcapi work

[Andrew Morton]

Armin Schindler <armin@xxxxxxxxxx> wrote:
>
> Hi all,
> 
> the ISDN kernelcapi function recv_handler() is triggered by
> schedule_work() and dispatches the CAPI messages to the applications.
> 
> Since a workqueue function may run on another CPU at the same time,
> reordering of CAPI messages may occur.

TCP has the same problem.

> For serialization I suggest a mutex semaphore in recv_handler(),
> patch is appended (yet untested).

It will work OK.  It isn't very scalable of course, but I assume you're
dealing with relatively low bandwidths.

I would suggest that you look at avoiding the global semaphore.  Suppose
someone has 64 interfaces or something.  Is that possible?  It might be
better to put the semaphore into struct capi_ctr so you can at least
process frames from separate cards in parallel.

> Is there a better way to do user-context work serialized ?

Not really - you've been bitten by the compulsory per-cpuness of the
workqueue handlers.

You could have a standalone kernel thread or always queue the work onto CPU
#0 (the function to do this isn't merged, but exists).  But both these are
unscalable.

So apart from moving recv_handler_lock into struct capi_ctr I can't think
of anything clever.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/