We need to keep building sigframes until no pending signals remain.
Wrap do_notify_resume() calls into loops; do _not_ allow syscall
restart logics to trigger after the first iteration.
Incidentally, comments about pending signals that should (somehow)
be in r18 are pure BS. Doesn't work that way and cannot work that
way, sorry...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
solution a-la arm one - pick a callee-saved register (r30), set it
non-zero when entering a syscall, have sigreturn wrapper zero it out
and pass the value in it to do_notify_resume() as "in_syscall" (actually,
"restarts allowed") argument.
Note that we don't give a damn about ret_from_fork() - return value
is not restart-worthy anyway.
Possible remaining bug: on !MMU we still have _debug_exception()
restartable. If it hits with -ERESTART_... accidentally in r3, fun happens.
MMU does _not_ have _debug_exception() restartable. If that's decided to
be a bug (as I strongly suspect it to be), we'll just need to replace
setting r30 to 1 with setting r30 to 0 in !MMU _debug_exception().
Up to microblaze maintainers...
[folded a fix from Michal]
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Only one caller hasn't done it in assembler - work_pending on !MMU.
Everything else can't reach do_notify_resume() if we are returning
to kernel mode, so move that check to that sole caller and make
do_notify_resume() reachable only when returning to userland.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
we want to do that before branchpoint for arch-* to be able to
consolidate sys_rt_sigsuspend() declarations.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
When releasing a packet socket, the routine packet_set_ring() is reused
to free rings instead of allocating them. But when calling it for the
first time, it fills req->tp_block_nr with the value of rb->pg_vec_len
which in the second invocation makes it bail out since req->tp_block_nr
is greater zero but req->tp_block_size is zero.
This patch solves the problem by passing a zeroed auto-variable to
packet_set_ring() upon each invocation from packet_release().
As far as I can tell, this issue exists even since 69e3c75 (net: TX_RING
and packet mmap), i.e. the original inclusion of TX ring support into
af_packet, but applies only to sockets with both RX and TX ring
allocated, which is probably why this was unnoticed all the time.
Signed-off-by: Phil Sutter <phil.sutter@viprinet.com>
Cc: Johann Baudy <johann.baudy@gnu-log.net>
Cc: Daniel Borkmann <dborkman@redhat.com>
Acked-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
If stmmac_dvr_probe() fails in stmmac_pci_probe(), it breaks off initialization,
deallocates all resources, but returns zero.
The patch adds -ENODEV as return value in this case.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Signed-off-by: David S. Miller <davem@davemloft.net>
Use correct inner offset to set inner_network_offset.
Found by inspection.
Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Commit 9dc274151a (tcp: fix ABC in tcp_slow_start())
uncovered a bug in FRTO code :
tcp_process_frto() is setting snd_cwnd to 0 if the number
of in flight packets is 0.
As Neal pointed out, if no packet is in flight we lost our
chance to disambiguate whether a loss timeout was spurious.
We should assume it was a proper loss.
Reported-by: Pasi Kärkkäinen <pasik@iki.fi>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
Cc: Yuchung Cheng <ycheng@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Since commit 9dc274151a (tcp: fix ABC in tcp_slow_start()),
a nul snd_cwnd triggers an infinite loop in tcp_slow_start()
Avoid this infinite loop and log a one time error for further
analysis. FRTO code is suspected to cause this bug.
Reported-by: Pasi Kärkkäinen <pasik@iki.fi>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Neal Cardwell <ncardwell@google.com>
Cc: Yuchung Cheng <ycheng@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
usual "call force_sigsegv or signal_delivered" logics. Takes
ksignal instead of separate siginfo/k_sigaction.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
On success get_signal_to_deliver() fills k_sigaction and siginfo.
_All_ users pass it addresses of the local variables sitting in
the same function. Then they proceed to pass those addresses
pretty much in tandem to a bunch of helper functions; again, all
callers of those helpers are passing them such a pair, and one that
had been through get_signal_to_deliver() at that.
The obvious cleanup: introduce a new type that would contain a
<k_sigaction,siginfo> pair (struct ksignal) and begin switching to
using it. Turns out that it's convenient to store the signal number
in the same object.
New helper, taking that sucker is a wrapper for get_signal_to_deliver();
takes struct ksignal * and returns bool. On success fills ksignal
with the information for signal handler to be invoked.
For now it's a macro (to avoid header ordering headache), but eventually
it'll be a function in kernel/signal.c, with get_signal_to_deliver()
folded into it.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
