Return-path: Received: from mail-wr1-f41.google.com ([209.85.221.41]:40037 "EHLO mail-wr1-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731198AbeHITHH (ORCPT ); Thu, 9 Aug 2018 15:07:07 -0400 Received: by mail-wr1-f41.google.com with SMTP id h15-v6so5698763wrs.7 for ; Thu, 09 Aug 2018 09:41:25 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <87mutvzfc5.fsf@kamboji.qca.qualcomm.com> References: <20180731211404.2eac1bb0@wiggum> <87lg9f1rw8.fsf@kamboji.qca.qualcomm.com> <87mutvzfc5.fsf@kamboji.qca.qualcomm.com> From: Jonas Gorski Date: Thu, 9 Aug 2018 18:41:04 +0200 Message-ID: (sfid-20180809_184153_120873_55C107D1) Subject: Re: b43/leds: Ensure NUL-termination of LED name string To: Kalle Valo Cc: =?UTF-8?Q?Michael_B=C3=BCsch?= , Larry Finger , =?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= , linux-wireless , b43-dev Content-Type: text/plain; charset="UTF-8" Sender: linux-wireless-owner@vger.kernel.org List-ID: On 9 August 2018 at 18:15, Kalle Valo wrote: > Jonas Gorski writes: > >> On 9 August 2018 at 17:28, Kalle Valo wrote: >>> Michael B=C3=BCsch writes: >>> >>>> strncpy might not NUL-terminate the string, if the name equals the buf= fer size. >>>> Use strlcpy instead. >>>> >>>> Signed-off-by: Michael Buesch >>>> Cc: stable@vger.kernel.org >>> >>> This is weird, with all the patches you submitted last week I get this >>> if I download the patch from patchwork: >>> >>> $ git am -s 1.mbox >>> Patch is empty. Was it split wrong? >>> >>> But if I download the patch directly from my IMAP folder I have no >>> problems: >>> >>> $ git am -s 1.mbox >>> Applying: b43/leds: Ensure NUL-termination of LED name string >>> >>> This happens even without my custom patchwork script so this has >>> something to do with the patchwork server, but it's not obvious to me >>> what triggers it. IIRC I have not seen anything like this before. It >>> seems that you didn't use git-send-email, I strongly suggest to use tha= t >>> just to avoid problems like this. >> >> Looks like patchwork mishandles the pgp signature, the patchwork mbox ha= s >> >>> Content-Type: multipart/signed; micalg=3Dpgp-sha512; >>> boundary=3D"Sig_/EN90ciRq4eWXDUcnZABQ0Ak"; protocol=3D"application/pgp= -signature" >> >> as the only content-type (and the boundary is nowhere to be found), >> while the one in my inbox has >> >>> Content-Type: multipart/signed; micalg=3Dpgp-sha512; >>> boundary=3D"Sig_/EN90ciRq4eWXDUcnZABQ0Ak"; >>> protocol=3D"application/pgp-signature" >>> >>> --Sig_/EN90ciRq4eWXDUcnZABQ0Ak >>> Content-Type: text/plain; charset=3DUS-ASCII >>> Content-Transfer-Encoding: quoted-printable >> >> When I remove the Content-Type: line(s) from the mbox from patchwork, >> git recognises it again as a patch. I guess git am ignores everything >> until the boundary, which got dropped by patchwork, so it never finds >> the actual patch. > > Awesome, thanks for debugging this! It would be great if someone could > report this to the patchwork maintainers, I don't have the time right > now. Silly question, but who *are* the maintainers? I just spend several minutes on https://patchwork.kernel.org/ and google, and failed to find any contact information. Regards Jonas