From: Alexander Holler <holler@ahsoftware.de>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] initramfs: print error and shell out for unsupported content
Date: Sat, 22 Mar 2014 10:53:07 +0100 [thread overview]
Message-ID: <532D5D83.4000101@ahsoftware.de> (raw)
In-Reply-To: <532CC625.7020509@ahsoftware.de>
Am 22.03.2014 00:07, schrieb Alexander Holler:
> Am 21.03.2014 23:55, schrieb Andrew Morton:
>> Should we check for \t and \n as well?
>
> Hmm, maybe. But usually there aren't filenames wich do contain those
> characters, and if you want to break (or exploit) the kernel build
> process, there are easier ways. But colons and spaces are more widely
> used, e.g. the colons in my initramfs were generated by bluez (look at
> /var/lib/bluetooth).
>
> I think the current process is good enough for most stuff one wants to
> put into an initramfs, and it has the great feature of the uid/guid
> translation.
> So just a quick check to avoid the most basic problems should be ok. And
> I don't really see a need to check for \t and \n too, because nobody
> sane uses them in filenames. But ok, that just would be a few chars more
> in the regex for find. ;)
>
> I leave that up to you.
Sorry for that answer, but I dislike the process which turns patch
posters into remote keyboards quiet a lot.
When I post a patch I usually already have spend time to discover,
investigate, describe, fix the problem (as good as I can or I'm
willing), write a checkpatch conforming patch, and test that patch,
which most of the time sums up to several hours (I didn't want to spend
at all).
And then all kind of comments are arriving to change this and that and
fix that typo or remove that space and the patch ping pong starts until
an arbitrary maintainer or reviewer is happy.
I think the process should be more like that:
- patch posted
(- comments from maintainer)
- original patch commited
- patch from maintainer or reviewer on top of the original patch commited
That would give credits to both, the original patch poster and the
maintainer or reviewer (for his changes).
Of course, that isn't an ideal solution, but I would like it a lot, if
such a process would at least be seen as a possible and reasonable way,
even if it means that two patches instead of one do end up in the
repository.
To keep things together, maybe the second patch could be marked as
[maintainer patch] or [reviewer patch], that would make it clear that
both patches tie together and should be reverted both, if needed.
Anyway, I'm drifting offtopic, but that was something I always wanted to
suggest.
But the real reason why I've started to write this mail, is that it
might make sense to delete usr/.initramfs_data.cpio.d with a make
(dist)clean. That file is the reason why the bug with colons might drive
people crazy, because not even a make distclean (or git clean -df) will
make make working again after a broken usr/.initramfs_data.cpio.d was
build (with colons in filenames).
Maybe I will post a patch for that too, if I'm willing to do and test it
(together with a v3 of the patch which checks for \t \n and \r too).
Regards,
Alexander Holler
next prev parent reply other threads:[~2014-03-22 9:53 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-20 21:35 [PATCH] initramfs: print error and shell out for unsupported content Alexander Holler
2014-03-20 21:43 ` Levente Kurusa
2014-03-20 22:00 ` [PATCH v2] " Alexander Holler
2014-03-20 22:25 ` Alexander Holler
2014-03-21 21:03 ` Andrew Morton
2014-03-21 22:49 ` Alexander Holler
2014-03-21 22:55 ` Andrew Morton
2014-03-21 23:07 ` Alexander Holler
2014-03-22 9:53 ` Alexander Holler [this message]
2014-03-22 12:29 ` [PATCH 1/2] initramfs: don't include filenames from the initramfs for make goals (dist)clean Alexander Holler
2014-03-22 12:29 ` [PATCH 2/2 v3] initramfs: print error and shell out for unsupported content Alexander Holler
2014-03-22 18:22 ` Alexander Holler
2014-03-31 20:31 ` Michal Marek
2014-04-01 11:23 ` Alexander Holler
2014-04-01 12:23 ` Michal Marek
2014-04-01 17:52 ` Alexander Holler
2014-10-19 7:18 ` [PATCH 1/2 v4] initramfs: don't include filenames from the initramfs for make goals (dist)clean Alexander Holler
2014-10-19 7:18 ` [PATCH 2/2 v4] initramfs: print error and shell out for unsupported content Alexander Holler
2014-03-26 21:16 ` [PATCH v2] " Alexander Holler
2014-03-26 21:38 ` Levente Kurusa
2014-03-26 21:55 ` Alexander Holler
2014-03-26 22:37 ` Alexander Holler
2014-03-27 8:25 ` Alexander Holler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=532D5D83.4000101@ahsoftware.de \
--to=holler@ahsoftware.de \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.