linux-kernel - Re: [PATCH] sound: max98090: Remove executable bit

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: <20130321203709.GJ15926@opensource.wolfsonmicro.com>
Date:	Thu, 21 Mar 2013 21:37:09 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Joe Perches <joe@...ches.com>
Cc:	Liam Girdwood <lgirdwood@...il.com>,
	Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.de>,
	alsa-devel@...a-project.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] sound: max98090: Remove executable bit

On Thu, Mar 21, 2013 at 12:16:45PM -0700, Joe Perches wrote:

> The commit isn't in -next so I have no idea what
> you actually applied. (nor do I really care btw)

The fact that you don't care is kind of the problem here, aside from
the extra effort involved the active resistance to change isn't good
especially given that you are keen on things like get_maintainers and
so on.

> Did you try it?

> It commits:

> ASoC: sound: max98080: Remove executable bit

Which clearly neither makes sense (think about what that means...) nor
is consistent with other commits to either the driver or the subsystem.

> If you're really anal about it and you want
> sound: for sound/soc removed,

Yes, of course.

> perl -p -i -e 's/^(?:ASoC:\s*)?(?:sound:\s*)?(.*)$/ASoC: $1/g if 1 .. 1' ${1+"$@"}

So that'll work for this particular error but then will fail if someone
mistakenly uses any other prefix and won't do anything about the driver
specific prefix.  

In any case this is not useful as even if you concoct something that
fixes every possible error it still doesn't help with the incoming patch
queue since searches don't match, the rewrite would need to be done on
incoming mail and that's not a good idea.

> This is a "your taste" issue only, and do keep in mind
> mountains vs molehills.

The reason I'm complaining here is that you routinely send very trivial
patches which don't apply cleanly - sometimes they don't apply at all
since you send them against inappropriate trees as well as requiring
hand editing.  This isn't a good pattern, it should be changed - people
who submit many patches ought to be examples of how to work smoothly.

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)