From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751809AbcEUSro (ORCPT ); Sat, 21 May 2016 14:47:44 -0400 Received: from mail-wm0-f54.google.com ([74.125.82.54]:38142 "EHLO mail-wm0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751086AbcEUSrm (ORCPT ); Sat, 21 May 2016 14:47:42 -0400 From: Michal Nazarewicz To: Felipe Balbi , "Du, Changbin" Cc: Greg Kroah-Hartman , Al Viro , rui.silva@linaro.org, k.opasiak@samsung.com, lars@metafoo.de, linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org Subject: [PATCH 0/2] f_fs: better handle excess data on read Date: Sat, 21 May 2016 20:47:33 +0200 Message-Id: <1463856455-18160-1-git-send-email-mina86@mina86.com> X-Mailer: git-send-email 2.8.0.rc3.226.g39d4020 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Between this set and Du, Changbin’s patch, we now have implementation for the following three possibilities to choose from: 1. Buffer excess data (this whole patch set). 2. Fail the transfer (Du, Changbin’s patch). 3. Drop excess data (the first patch from this set). As per earlier comments, I think 3. is the correct, i.e. the second patch should not be ocmmited because: * it complicates the code, * doesn’t handle AIO anyway, * introduces weird behaviours when partial read happens just before endpoint is disabled (we may end up silently dropping excess data anyway), * goes beyond what UDC does and * breaks one read -> one request model which has been true so far. Michal Nazarewicz (2): usb: gadget: f_fs: printk error when excess data is dropped on read usb: gadget: f_fs: buffer data from ‘oversized’ OUT requests drivers/usb/gadget/function/f_fs.c | 179 ++++++++++++++++++++++++++++++------- 1 file changed, 145 insertions(+), 34 deletions(-) -- Best regards ミハウ “𝓶𝓲𝓷𝓪86” ナザレヴイツ «If at first you don’t succeed, give up skydiving»