From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from devils.ext.ti.com ([198.47.26.153]:46120 "EHLO devils.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752230AbbI3QIs (ORCPT ); Wed, 30 Sep 2015 12:08:48 -0400 Date: Wed, 30 Sep 2015 11:08:43 -0500 From: Felipe Balbi To: Krzysztof Opasiak CC: , Robert Baldyga , , , , Subject: Re: [PATCH v3 1/2] usb: gadget: loopback: fix: Don't share qlen and buflen between instances Message-ID: <20150930160843.GF32625@saruman.tx.rr.com> Reply-To: References: <1442947223-13277-1-git-send-email-k.opasiak@samsung.com> <56041470.70306@samsung.com> <20150924165136.GF14151@saruman.tx.rr.com> <56042E9D.5040408@samsung.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CXFpZVxO6m2Ol4tQ" Content-Disposition: inline In-Reply-To: <56042E9D.5040408@samsung.com> Sender: stable-owner@vger.kernel.org List-ID: --CXFpZVxO6m2Ol4tQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 24, 2015 at 07:10:53PM +0200, Krzysztof Opasiak wrote: >=20 >=20 > On 09/24/2015 06:51 PM, Felipe Balbi wrote: > >On Thu, Sep 24, 2015 at 05:19:12PM +0200, Robert Baldyga wrote: > >>On 09/22/2015 08:40 PM, Krzysztof Opasiak wrote: > >>>Each instance of loopback function may have different qlen > >>>and buflen attributes values. When linking function to > >>>configuration those values had been assigned to global > >>>variables. Linking other instance to config overwrites those > >>>values. > >>> > >>>This commit moves those values to f_loopback structure > >>>to avoid overwriting. Now each function has its own instance > >>>of those values. > >>> > >>>Cc: # 3.10+ > >>>Signed-off-by: Krzysztof Opasiak > >> > >>Reviewed-by: Robert Baldyga > > > >doesn't seem to fit stable IMO. Care to explain why you think we need > >to backport this to v3.10+ ? > > >=20 > Let's consider following set of commands: >=20 > cd $CFS_ROOT/usb_gadget > mkdir g1 > cd g1 > mkdir functions/SourceSink.1 > mkdir functions/SourceSink.2 > echo 1024 > functions/SourceSink.1/buflen > echo 512 > functions/SourceSink.2/buflen > mkdir configs/c.1 > ln -s functions/SourceSink.1 configs/c.1/ > ln -s functions/SourceSink.2 configs/c.1/ > echo $UDC > UDC >=20 > You assume that after executing this script you will get two instances of > SourceSink functions and one of them will alloc requests buffers which has > 1024 and second one which has only 512. >=20 > Unfortunately due to using global variables both of them are going to all= oc > only 512 bytes for each request. The same situation is with qlen. All > instances are going to use attributes values from the last one in the > system, even if they are in multiple gadgets. that's all fine and dandy, but it's still a new requirement. It fits easily into "has never worked before" category. If it was something which really regressed, IOW we used to support it but some other commit broke it, then I'd agree. > In my opinion second patch in this series is much more important as it ma= kes > loopback function working again after almost year of being only /dev/null > and /dev/zero. But that one should to go only to 3.18. ok --=20 balbi --CXFpZVxO6m2Ol4tQ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJWDAkLAAoJEIaOsuA1yqREngIP/j1gSGbVmsrnr8tFlUPIZafH ah+2P15sUTlLSJ8f/FugKYBKmMWtTjXSNK5KGm7E4B+3b+sWzh5PiBqE7fz6vFum 6jThwI7ZHYCuuTkRiutRsn0NonfFD1xEUIQOxk5ok7XPhY4QRJa8a7Z2w4NCtKeh m5TmPqI9hO2Gx+gxir+wCPfuV95vQgjEcFGOhSiqEFTj2HtEDeOjWybl1LJfi1eb vO0cZjdCEEnO+4w86SUMTioYINDqn+wMMIU27whpRRnnbFkJ0vlgGblmTdI/0JGw 4lMaFF78FMHXIvWmFTBheViTOMgO2M6h3mC/n+yJG3OECo/y5Agaxm8GOQGg3rpT EsMFFip5LJvo5IcXfMENVTUGnMKoHDqKnMXzopdFwL1e+AuhQLez7nQlW4oTZXPv j3Z9YiKN+FaQdc7YShqZPxZZ0M9vP4baXzk0BAFh3DV/01fL/Ob8dYIFhnJz/Fu6 2oDepA1n2nHvRSg3QWgT4khxtI7bM5LNB1e2dh8MWgqI2ZAbLree07AjXIzkUVbT WCF6MpTzTJQOPZcWcEkW3OlURFD3WkuMm+2ILqDlEcAZ5KU7qEbTd1BYCdonJt44 sd6fBsJTubEOCqDlDN7ztT/Nsd4/JQfY1YfRjeEu2+rd18JeaSVye/z1fTlnYWGj NjE7OQEh9DdEvDHWFeuK =6Td/ -----END PGP SIGNATURE----- --CXFpZVxO6m2Ol4tQ--