From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752379AbcEKLI3 (ORCPT ); Wed, 11 May 2016 07:08:29 -0400 Received: from mga01.intel.com ([192.55.52.88]:59178 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751333AbcEKLI1 (ORCPT ); Wed, 11 May 2016 07:08:27 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,608,1455004800"; d="asc'?scan'208";a="950855492" From: Felipe Balbi To: changbin.du@intel.com Cc: gregkh@linuxfoundation.org, mina86@mina86.com, rui.silva@linaro.org, k.opasiak@samsung.com, lars@metafoo.de, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, "Du\, Changbin" Subject: Re: [PATCH] usb: gadget: f_fs: report error if excess data received In-Reply-To: <1462961970-2001-1-git-send-email-changbin.du@intel.com> References: <1462961970-2001-1-git-send-email-changbin.du@intel.com> User-Agent: Notmuch/0.22+11~g124a67e (http://notmuchmail.org) Emacs/25.0.93.2 (x86_64-pc-linux-gnu) Date: Wed, 11 May 2016 13:59:25 +0300 Message-ID: <87twi4g8s2.fsf@linux.intel.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, changbin.du@intel.com writes: > From: "Du, Changbin" > > Since the buffer size for req is rounded up to maxpacketsize, > then we may end up with more data then user space has space > for. only for OUT direction with the controller you're using ;-) > If it happen, we can keep the excess data for next i/o, or > report an error. But we cannot silently drop data, because > USB layer should ensure the data integrality it has transferred, > otherwise applications may get corrupt data if it doesn't > detect this case. and when has this actually happened ? Host should not send more data in this case, if it does, it's an error on the host side. Also, returning =2DEOVERFLOW is not exactly correct here, because you'd violate POSIX specification of read(), right ? > Here, we simply report an error to userspace to let userspace > proccess. Actually, userspace applications should negotiate no, this violates POSIX. Care to explain what problem are you actually facing ? =2D-=20 balbi --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXMxCNAAoJEIaOsuA1yqREwdcP/1iVnnr3eNX1qZ+6NCFxSVDl bfozg0wkBI/koqznoinBenUkgcTyJQqHhyuq+RcMRC1scje/NlluOtrKBseL+XRY ry913ATTScGn8BZedPjuUYs6ZTdoRTNmllgdW/eDv5V8d4ReY+d+zpNgZtYHA5DN JXcE2MMIwHpcG5TLN3pYrD6R8eB7abr4Bwrsun4APy0Np61yw8+6nzPP/+KEMs2r +6Ogxi8LpfpkGPlRQBsT1fCYl4t9ncITzhmHURUJzn/74neWnFwcaYzgS2pjBIod ksqZcsbsE63kebnySCBqqRgLMGP1GyQZm4Bnl6WJf0nOFakGMBRC6EgfthVZgBwf iXjXwaGDYphlATy2WU4/6U0V09GBgTNDc6soBUskh2gnuAoGqMb/Voh26+KyY3GK Y/XMkd2snnOs0Mida2PuMHEG1uLOGTPNAfewDOLQe/eVryfyBODQtZRpJB1EF1lK G1vxxN/bsoWzHbDUU7eA0VCX8gWhls3pLgIFWW+DZCfvBKUHJrYO5sNoOIl/XkG4 +o4LvutR/QVE1hI6bFYO+5rgz71RUI1lPtY7mPOc4TMa6paam4HDEWFq0UjqDsFp x/vCC+01qL4U4EPO8kjvtL7lSKdsgDwO3F8vtaXwNXhQLS7flZPqV6CNPzqI8lZw DEUiZIOJlGh8oBxdiXQv =WOiD -----END PGP SIGNATURE----- --=-=-=--