linux-kernel - Re: linux-next: build failure after merge of the v9fs tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Sat, 10 Dec 2022 06:24:26 +0900
From:   Dominique Martinet <asmadeus@...ewreck.org>
To:     Christian Schoenebeck <linux_oss@...debyte.com>
Cc:     Stephen Rothwell <sfr@...b.auug.org.au>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Next Mailing List <linux-next@...r.kernel.org>
Subject: Re: linux-next: build failure after merge of the v9fs tree

Christian Schoenebeck wrote on Fri, Dec 09, 2022 at 03:40:06PM +0100:
> > > You remember updating the 1st patch as well, right? :)
> > 
> > It looks up to date to me, e.g. zc is added at the end of the p9_fcall
> > structure.
> > (and these are the only two patches you sent, right? :D)
> 
> Mmm, that's the queued patch I see:
> https://github.com/martinetd/linux/commit/298468c26c14682a5be80a6ec1b4880c8eb3b261
> 
> Which is v1 ('zc' is not at the end of the structure, and in v1 there were
> multiple assignment in the same line like:
> 
>   req->tc.zc = req->rc.zc = false;
> 
> which caused code style checker to bark (as well as on the commit log which it
> found too short). So in v2 it is:
> 
>   req->tc.zc = false;
>   req->rc.zc = false;
> 
> And yes, only two patches. :)

Ah. . . what did I just say about applying patches in my local branch
for testing later, they correct one is just sitting there but wasn't
tested/pushed yet :/

(if you care, I'm using my 9p-test branch for that, but it's not sent
sent to -next obviously)


> Well, workflows are quite different. Personally I always manually reply to
> mailed patches once I queued them, so that people can verify and correct me in
> case I queued the wrong ones. I never had the feeling to script that part.

Yes I usually do write a note about it when I take the patch locally,
but in this case I think I just applied the patches for checkpatch
(indentation looked off without being sure it'd complain) and didn't
intend to queue it; then came back later and "oh they're here, thanks
past me!" (incorrectly)

I guess at this point the problem comes back down to not running
tests/pushing to next immediately; if I finish automating that part I
think this kind of errors wouldn't happen as non-pushed patches wouldn't
make sense...
Well, it's been rare enough but still worth thinking about safeguards
imo, there's usually a reason for v2 patchs so getting the v1 in even
occasionally is bad :-D

-- 
Dominique