linux-kernel - Re: [PATCH v2 2/2] staging: panel: fix lcd type in module parameters

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150324232559.GA23298@1wt.eu>
Date:	Wed, 25 Mar 2015 00:25:59 +0100
From:	Willy Tarreau <w@....eu>
To:	Sudip Mukherjee <sudipm.mukherjee@...il.com>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	devel@...verdev.osuosl.org, linux-kernel@...r.kernel.org,
	stable@...r.kernel.org
Subject: Re: [PATCH v2 2/2] staging: panel: fix lcd type in module parameters

On Tue, Mar 24, 2015 at 02:56:33PM +0530, Sudip Mukherjee wrote:
> with reference to the previous patch of the series, fixed the
> lcd type in module parameters.

Sudip, it's better to avoid fragmenting patches like you did, because
it will result in a kernel state where there is an inconsistency between
the parameters actually used by the kernel and those reported by modinfo.
This can happen for example if someone does a bisect and ends up on patch
1/2 applied only. Obviously in this case there is very little harm, but
you get the idea : each patch should be a functional change, address one
thing and do it consistently. So if you change the #defines or enums or
whatever, all the locations where their old values were referenced must
be changed in the same patch, simply because in fact they are duplicate
entries. Another point is that someone who notices your patch v1 and
does not notice patch v2 could pick v1 for his kernel and end up with
something inconsistent. For this reason it would be better to merge your
patches into a single one here.

> might not apply properly to old versions, some reordering was done
> in commit <98e0e762e>

Appreciated, thanks for checking this!

Best regards,
Willy

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/