From patchwork Wed Nov 7 12:52:14 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Woodhouse X-Patchwork-Id: 197658 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id D06C22C00EC for ; Wed, 7 Nov 2012 23:52:39 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754914Ab2KGMwY (ORCPT ); Wed, 7 Nov 2012 07:52:24 -0500 Received: from merlin.infradead.org ([205.233.59.134]:40399 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753099Ab2KGMwX (ORCPT ); Wed, 7 Nov 2012 07:52:23 -0500 Received: from shinybook.infradead.org ([2001:8b0:10b:1:e6ce:8fff:fe1f:f2c0]) by merlin.infradead.org with esmtpsa (Exim 4.76 #1 (Red Hat Linux)) id 1TW57B-0006a5-DJ; Wed, 07 Nov 2012 12:52:18 +0000 Message-ID: <1352292734.7340.35.camel@shinybook.infradead.org> Subject: [PATCH v3 8/7] pppoatm: fix missing wakeup in pppoatm_send() From: David Woodhouse To: Krzysztof Mazur Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Chas Williams - CONTRACTOR , davem@davemloft.net Date: Wed, 07 Nov 2012 12:52:14 +0000 In-Reply-To: <1352240222-363-1-git-send-email-krzysiek@podlesie.net> References: <1352240222-363-1-git-send-email-krzysiek@podlesie.net> X-Mailer: Evolution 3.6.1 (3.6.1-1.fc18) Mime-Version: 1.0 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Now that we can return zero from pppoatm_send() for reasons *other* than the queue being full, that means we can't depend on a subsequent call to pppoatm_pop() waking the queue, and we might leave it stalled indefinitely. Fix this by immediately scheduling the wakeup tasklet. As documented already elsewhere, the PPP channel's ->downl lock protects against the wakeup happening too soon and effectively being missed. Signed-off-by: David Woodhouse ---- Untested. With this sorted, Acked-By: David Woodhouse vcc; bh_lock_sock(sk_atm(vcc)); if (sock_owned_by_user(sk_atm(vcc))) - goto nospace; + goto nospace_sched_wakeup; if (test_bit(ATM_VF_RELEASED, &vcc->flags) - || test_bit(ATM_VF_CLOSE, &vcc->flags) - || !test_bit(ATM_VF_READY, &vcc->flags)) - goto nospace; + || test_bit(ATM_VF_CLOSE, &vcc->flags) + || !test_bit(ATM_VF_READY, &vcc->flags)) + goto nospace_sched_wakeup; switch (pvcc->encaps) { /* LLC encapsulation needed */ case e_llc: @@ -328,7 +328,17 @@ static int pppoatm_send(struct ppp_channel *chan, struct sk_buff *skb) ? DROP_PACKET : 1; bh_unlock_sock(sk_atm(vcc)); return ret; -nospace: + nospace_sched_wakeup: + /* If we're returning zero for reasons *other* than the queue + * being full, then we need to ensure that a wakeup will + * happen and not just leave the channel stalled for ever. + * Just schedule the wakeup tasklet directly. As observed in + * pppoatm_pop(), it'll take the channel's ->downl lock which + * is also held by our caller, so it can't happen "too soon" + * and cause us to effectively miss a wakeup. + */ + tasklet_schedule(&pvcc->wakeup_tasklet); + nospace: bh_unlock_sock(sk_atm(vcc)); /* * We don't have space to send this SKB now, but we might have