From patchwork Tue Nov 9 23:19:47 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Wolfram Sang X-Patchwork-Id: 70586 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 64B05B7122 for ; Wed, 10 Nov 2010 10:19:49 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753659Ab0KIXTp (ORCPT ); Tue, 9 Nov 2010 18:19:45 -0500 Received: from metis.ext.pengutronix.de ([92.198.50.35]:55867 "EHLO metis.ext.pengutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753483Ab0KIXTo (ORCPT ); Tue, 9 Nov 2010 18:19:44 -0500 Received: from gallifrey.ext.pengutronix.de ([2001:6f8:1178:4:5054:ff:fe8d:eefb] helo=localhost) by metis.ext.pengutronix.de with esmtp (Exim 4.71) (envelope-from ) id 1PFxTb-0000YD-2o; Wed, 10 Nov 2010 00:19:43 +0100 From: Wolfram Sang To: irda-users@lists.sourceforge.net Cc: netdev@vger.kernel.org, Wolfram Sang , Samuel Ortiz Subject: [RFC] irda: irttp: allow zero byte packets Date: Wed, 10 Nov 2010 00:19:47 +0100 Message-Id: <1289344787-12160-1-git-send-email-w.sang@pengutronix.de> X-Mailer: git-send-email 1.7.2.3 X-SA-Exim-Connect-IP: 2001:6f8:1178:4:5054:ff:fe8d:eefb X-SA-Exim-Mail-From: w.sang@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: netdev@vger.kernel.org Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Sending zero byte packets is not neccessarily an error (AF_INET accepts it, too), so just apply a shortcut. This was discovered because of a non-working software with WINE. See http://bugs.winehq.org/show_bug.cgi?id=19397#c86 http://thread.gmane.org/gmane.linux.irda.general/1643 for very detailed debugging information and a testcase. Kudos to Wolfgang for those! Reported-by: Wolfgang Schwotzer Signed-off-by: Wolfram Sang Tested-by: Mike Evans Cc: Samuel Ortiz --- I found Wolfgang's very detailed report while looking for WINE-bugreports affecting the kernel somehow. His mail sadly went to an almost dead mailing-list and he told me he lost interest meanwhile. This is why I picked the issue up and created this straightforward patch which helps the case at least (thanks Mike for testing!). net/irda/irttp.c | 25 +++++++++++++++++++------ 1 files changed, 19 insertions(+), 6 deletions(-) diff --git a/net/irda/irttp.c b/net/irda/irttp.c index 285761e..6cfaeaf 100644 --- a/net/irda/irttp.c +++ b/net/irda/irttp.c @@ -550,16 +550,23 @@ EXPORT_SYMBOL(irttp_close_tsap); */ int irttp_udata_request(struct tsap_cb *self, struct sk_buff *skb) { + int ret = -1; + IRDA_ASSERT(self != NULL, return -1;); IRDA_ASSERT(self->magic == TTP_TSAP_MAGIC, return -1;); IRDA_ASSERT(skb != NULL, return -1;); IRDA_DEBUG(4, "%s()\n", __func__); + /* Take shortcut on zero byte packets */ + if (skb->len == 0) { + ret = 0; + goto err; + } + /* Check that nothing bad happens */ - if ((skb->len == 0) || (!self->connected)) { - IRDA_DEBUG(1, "%s(), No data, or not connected\n", - __func__); + if (!self->connected) { + IRDA_DEBUG(1, "%s(), Not connected\n", __func__); goto err; } @@ -576,7 +583,7 @@ int irttp_udata_request(struct tsap_cb *self, struct sk_buff *skb) err: dev_kfree_skb(skb); - return -1; + return ret; } EXPORT_SYMBOL(irttp_udata_request); @@ -599,9 +606,15 @@ int irttp_data_request(struct tsap_cb *self, struct sk_buff *skb) IRDA_DEBUG(2, "%s() : queue len = %d\n", __func__, skb_queue_len(&self->tx_queue)); + /* Take shortcut on zero byte packets */ + if (skb->len == 0) { + ret = 0; + goto err; + } + /* Check that nothing bad happens */ - if ((skb->len == 0) || (!self->connected)) { - IRDA_WARNING("%s: No data, or not connected\n", __func__); + if (!self->connected) { + IRDA_WARNING("%s: Not connected\n", __func__); ret = -ENOTCONN; goto err; }