On Mon, Feb 24, 2020 at 06:16:18PM +0100, Borislav Petkov wrote: > On Mon, Feb 24, 2020 at 11:41:29AM -0500, Arvind Sankar wrote: > > Hi Boris, apologies for the confusion and unnecessary work I've created, > > but I think the preference is to merge the 2-patch series I posted > > yesterday [1] instead of this. > > > > [1] https://lore.kernel.org/lkml/20200223193715.83729-1-nivedita@xxxxxxxxxxxx/ > > What guarantees this would work and we won't hit some corner case or > toolchain configuration this hasn't been tested on? > > If that happens, I need to have a state to revert back to, i.e., this > patch, discarding .eh_frame explicitly. > > So I'll pick up [1] too, but give people a couple of days - a chance to > complain about. :) > > -- > Regards/Gruss, > Boris. > > SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG Nürnberg Ok, note that the 2-patch series assumed that it would replace this one, so it doesn't contain a revert of discarding .eh_frame explicitly for the compressed kernel. The first patch of that series at least should be safe enough, it will stop generating .eh_frame sections in most cases, and shouldn't make any edge cases worse than before. The second one might be a regression if we do have some case that still creates them though.
|