On Mon, Apr 04, 2016 at 02:31:46PM -0700, Andy Lutomirski wrote:
> Could you do it by moving just the earlyprintk stuff a la
> fpu__init_parse_early_param()?
Yeah, something like that. I'll play with this more tomorrow. Btw, no
need to make any of this part of your patchset - I'd like early change
On Mon, Apr 4, 2016 at 12:38 PM, Borislav Petkov wrote:
> On Mon, Apr 04, 2016 at 06:00:42PM +0200, Peter Zijlstra wrote:
>> On Mon, Apr 04, 2016 at 08:32:21AM -0700, Andy Lutomirski wrote:
>>
>> > Adding locking would be easy enough, wouldn't it?
>>
>> See patch in this thread..
>>
>> > But do an
On Mon, Apr 04, 2016 at 06:00:42PM +0200, Peter Zijlstra wrote:
> On Mon, Apr 04, 2016 at 08:32:21AM -0700, Andy Lutomirski wrote:
>
> > Adding locking would be easy enough, wouldn't it?
>
> See patch in this thread..
>
> > But do any platforms really boot a second CPU before switching to real
>
On Mon, Apr 04, 2016 at 08:32:21AM -0700, Andy Lutomirski wrote:
> Adding locking would be easy enough, wouldn't it?
See patch in this thread..
> But do any platforms really boot a second CPU before switching to real
> printk?
I _only_ use early_printk() as printk() is a quagmire of fail :-)
On 4/4/2016 8:32 AM, Andy Lutomirski wrote:
Adding locking would be easy enough, wouldn't it?
But do any platforms really boot a second CPU before switching to real
printk? Given that I see all the smpboot stuff in dmesg, I guess real
printk happens first. I admit I haven't actually checked.
On Apr 4, 2016 4:51 AM, "Jan Kara" wrote:
>
> On Sat 02-04-16 13:58:19, Andy Lutomirski wrote:
> > [cc Jan Kara]
> >
> > On Sat, Apr 2, 2016 at 1:47 PM, Borislav Petkov wrote:
> > > On Sat, Apr 02, 2016 at 01:13:37PM -0700, Andy Lutomirski wrote:
> > >> Given that I this isn't really a regression
On Mon, Apr 04, 2016 at 01:52:06PM +0200, Jan Kara wrote:
> Sounds like a good idea to me. I've also consulted this with Petr Mladek
> (added to CC) who is using printk_func per-cpu variable in his
> printk-from-NMI patches and he also doesn't see a problem with this.
There's a few printk() varian
On Sat 02-04-16 13:58:19, Andy Lutomirski wrote:
> [cc Jan Kara]
>
> On Sat, Apr 2, 2016 at 1:47 PM, Borislav Petkov wrote:
> > On Sat, Apr 02, 2016 at 01:13:37PM -0700, Andy Lutomirski wrote:
> >> Given that I this isn't really a regression with my patches (it
> >> probably never worked much bet
[cc Jan Kara]
On Sat, Apr 2, 2016 at 1:47 PM, Borislav Petkov wrote:
> On Sat, Apr 02, 2016 at 01:13:37PM -0700, Andy Lutomirski wrote:
>> Given that I this isn't really a regression with my patches (it
>> probably never worked much better on 32-bit and the regs never would
>> have shown at all o
On Sat, Apr 02, 2016 at 01:13:37PM -0700, Andy Lutomirski wrote:
> Given that I this isn't really a regression with my patches (it
> probably never worked much better on 32-bit and the regs never would
> have shown at all on 64-bit),
You're right. That thing calls printk *and* early_printk, WTF:
On Sat, Apr 2, 2016 at 11:39 AM, Borislav Petkov wrote:
> On Sat, Apr 02, 2016 at 07:01:34AM -0700, Andy Lutomirski wrote:
>> This removes a bunch of assembly and adds some C code instead. It
>> changes the actual printouts on both 32-bit and 64-bit kernels, but
>> they still seem okay.
>>
>> Sig
On Sat, Apr 02, 2016 at 07:01:34AM -0700, Andy Lutomirski wrote:
> This removes a bunch of assembly and adds some C code instead. It
> changes the actual printouts on both 32-bit and 64-bit kernels, but
> they still seem okay.
>
> Signed-off-by: Andy Lutomirski
> ---
> arch/x86/include/asm/uacc
This removes a bunch of assembly and adds some C code instead. It
changes the actual printouts on both 32-bit and 64-bit kernels, but
they still seem okay.
Signed-off-by: Andy Lutomirski
---
arch/x86/include/asm/uaccess.h | 2 +-
arch/x86/kernel/head_32.S | 49 +---
13 matches
Mail list logo