On 29.03.20 18:46, Linus Torvalds wrote: > Please, David H - whatever you do with email is WRONG. > > Fix your completely broken email client. Stop doing this. I'm really sorry this happened again - but I am afraid it's not my email client that's broken :( I've been using bare "git format-patch" + "git send-email" to send out patches for years now, so I don't see what's wrong about that. Now, I took a look at what arrived in my mail box (via cc) without doing round trips through the RH mailing infrastructure and what arrived via the mailing list: What I received via CC (without anybody messing with my mail content): Message-Id: <20200128093542.6908-1-david@xxxxxxxxxx> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 [...] And none of that "=" MIME crap. What I received via the mailing list (e.g., linux-mm@xxxxxxxxx) Message-Id: <20200128093542.6908-1-david@xxxxxxxxxx> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@xxxxxxxxx Precedence: bulk X-Loop: owner-majordomo@xxxxxxxxx List-ID: <linux-mm.kvack.org> [...] X-Mimecast-Spam-Score: 1 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 [...] And a lot of this MIME crap. I have no idea if such a conversion is expected to be done. > > On Sat, Mar 28, 2020 at 7:17 PM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: >> >> From: David Hildenbrand <david@xxxxxxxxxx> >> [...] >> According to Nathan Fontenot, DLPAR on powerpc is nowadays no longer >> driven from userspace via the drmgr command (powerpc-utils). Nowadays >> it's managed in the kernel - including onlining/offlining of memory >> blocks - triggered by drmgr writing to /sys/kernel/dlpar. So the >> affected legacy userspace handling is only active on old kernels. Only ve= >> ry >> old versions of drmgr on a new kernel (unlikely) might execute slower - >> totally acceptable. >> >> With CONFIG_MEMORY_HOTREMOVE, always indicating "removable" should not >> break any user space tool. We implement a very bad heuristic now. Withou= >> t >> CONFIG_MEMORY_HOTREMOVE we cannot offline anything, so report >> "not removable" as before. > > Notice the bogus MIME line continuation left-overs? > > [...] Only ve= > ry > > and > > [...] Withou= > t > > is just completely wrong. Yes, absolutely broken. > You either have a completely broken email client that doesn't handle > MIME at all - get rid of it - or you're then dealing with raw mbox > data in a completely broken manner without handling MIME wrapping. Again, just using git send-email :/ > > I can't figure out _what_ you're doing wrong, but the pattern is clear > by now: it's not Andrew (although Andrew should check explanations > better!), since it _only_ happens with patches from David Hildenbrand. > > Fix your workflow. Because it's broken. Let's have a look at some stuff I sent out during the last weeks: https://lkml.kernel.org/r/20200319131221.14044-1-david@xxxxxxxxxx Already the cover letter looks horrible: https://lore.kernel.org/linux-hyperv/20200319131221.14044-1-david@xxxxxxxxxx/raw And *again* does not match at all what I received directly via cc in my mail box (== what I expect was sent via "git send-email"). Even the patch content has been partially converted https://lore.kernel.org/linux-hyperv/20200319131221.14044-2-david@xxxxxxxxxx/raw Unless I am missing something important, the issue is not in mail client setup, but there is something in the mailing infrastructure horribly messing with my mails. Red Hat has recently switched to Mimecast and there have been plenty of issues, maybe this is one of these. I guess the only thing I can do is sending mails via a different mail server / different email address? I'll double check if any other patches still queued in -next are similarly broken. I guess so. -- Thanks, David / dhildenb
