> " " == David S Miller <[EMAIL PROTECTED]> writes:
> Trond, did you actually look at how this code works before you
> made modifications to my fixes?
> xprt_lock serializes sleep/wakeup sequences in the xprt code,
> so you cannot remove xprt_lock from the sections where
" " == David S Miller [EMAIL PROTECTED] writes:
Trond, did you actually look at how this code works before you
made modifications to my fixes?
xprt_lock serializes sleep/wakeup sequences in the xprt code,
so you cannot remove xprt_lock from the sections where I added
Trond, did you actually look at how this code works before
you made modifications to my fixes?
xprt_lock serializes sleep/wakeup sequences in the xprt code, so you
cannot remove xprt_lock from the sections where I added holding of
xprt_sock_lock to protect the state of xprt->snd_task. So for
Trond, did you actually look at how this code works before
you made modifications to my fixes?
xprt_lock serializes sleep/wakeup sequences in the xprt code, so you
cannot remove xprt_lock from the sections where I added holding of
xprt_sock_lock to protect the state of xprt-snd_task. So for
The following patch (taken from the zero copy networking) upgrades the
spinlocking of the xprt_(up|down)_transmit() 'semaphores' in order to
work safely with the networking bottom halves. Several of the latter
(cf. xprt.c:tcp_write_space() & friends) do want to test the value of
The following patch (taken from the zero copy networking) upgrades the
spinlocking of the xprt_(up|down)_transmit() 'semaphores' in order to
work safely with the networking bottom halves. Several of the latter
(cf. xprt.c:tcp_write_space() friends) do want to test the value of
'xprt-snd_task'.
6 matches
Mail list logo
