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 for Android: free password hash cracker in your pocket

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

Message-ID: <20150325050732.GA4004@sudip-PC>
Date:	Wed, 25 Mar 2015 10:37:32 +0530
From:	Sudip Mukherjee <sudipm.mukherjee@...il.com>
To:	Willy Tarreau <w@....eu>
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 Wed, Mar 25, 2015 at 12:25:59AM +0100, Willy Tarreau wrote:
> 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.
explained very well. thanks. i was wondering why Dan asked me to merge
them into one.

regards
sudip

> 
> > 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/