On Tue, Nov 10, 2020 at 1:19 PM Marc Zyngier wrote:
> > Why? I thought we were trying to kill nVHE off now that newer CPUs
> > provide the saner virtualization extensions?
>
> We can't kill nVHE at all, because that is the only game in town.
> You can't even buy a decent machine with VHE, no mat
On Wed, Oct 16, 2019 at 6:35 PM James Bottomley
wrote:
> > The documentation says that krng is suitable for key generation.
> > Should the documentation changed to state that it is unsuitable?
>
> How do you get that from the argument above? The krng is about the
> best we have in terms of unpre
On Wed, Oct 16, 2019 at 1:41 PM Jarkko Sakkinen
wrote:
> > > get_random_bytes(). TPM could have a bug (making results predicatable),
> > > backdoor or even an inteposer in the bus. Salting gives protections
> > > against these concerns.
> >
> > The current issue in the randomness from my point o
On Tue, Oct 15, 2019 at 3:50 PM Jarkko Sakkinen
wrote:
>
> Salt the result that comes from the TPM RNG with random bytes from the
> kernel RNG. This will allow to use tpm_get_random() as a substitute for
> get_random_bytes(). TPM could have a bug (making results predicatable),
> backdoor or even
Hi,
Okay my bad, proper __initconst declarations would do the trick, cool stuff.
--
Janne
On Thu, Jan 31, 2019 at 1:09 PM Janne Karhunen wrote:
>
> Hi,
>
> Never mind, not enough coffee for the morning. Looks good addressing
> wise, but something goes haywire with the
7; compiled
user mode blob sits in between those symbols correctly. Hummm ?
--
Janne
On Thu, Jan 31, 2019 at 12:48 PM Janne Karhunen
wrote:
>
> Hi,
>
> Hmm, does this approach work if the code is not in a kernel module? I
> tried to use it as part of the kernel image and looks to
Hi,
Hmm, does this approach work if the code is not in a kernel module? I
tried to use it as part of the kernel image and looks to me the
bounding symbols _start and _end are not correctly relocated?
--
Janne
On Fri, Jun 15, 2018 at 3:48 AM Alexei Starovoitov
wrote:
>
> On Thu, Jun 14, 2018 at
On Tue, Aug 16, 2016 at 11:59 AM, Richard Weinberger wrote:
>> For saving some precious boot-up time (my systems run without initrd)
>> and to unify the solutions. If kernel does this bootloaders and
>> initrds don't have to care.
>
> Features - collect them all? ;-)
Well if every vendor ends up
On Tue, Aug 16, 2016 at 10:04 AM, Richard Weinberger
wrote:
> Why are you moving this feature into the kernel?
> To support such advanced features we have the initramfs.
>
> dracut has already rootfallback=.
For saving some precious boot-up time (my systems run without initrd)
and to unify the s
Recovery option can be used to define a secondary rootfs
in case mounting of the primary root fails. This allows
the kernel to automatically switch to a recovery
filesystem without the initrd or the bootloader support
for the switch.
Signed-off-by: Janne Karhunen
---
Documentation/kernel
On Sat, Nov 2, 2013 at 8:06 AM, Gao feng wrote:
> And another question, it looks like if we don't have proc/sys fs mounted,
> then proc/sys will be failed to be mounted?
I have been wondering the same. Was quite some illogical surprise that
we have to be doing overlay mounts. This is the exact o
On Fri, Oct 18, 2013 at 5:11 PM, Michael Opdenacker
wrote:
> Credits to Geert Uytterhoeven and Janne Karhunen for their improvement
> suggestions.
>
> Signed-off-by: Michael Opdenacker
Worksforme
Tested-by: Janne Karhunen
--
Janne
--
To unsubscribe from this list: s
On Fri, Oct 18, 2013 at 11:47 AM, Michael Opdenacker
wrote:
> This patch proposes to make init failures more explicit.
>
> Before this, the "No init found" message didn't help much.
> It could sometimes be misleading and actually mean
> "No *working* init found".
Heh, I was just looking at simil
On Tue, Oct 15, 2013 at 10:41 AM, Janne Karhunen
wrote:
>> call_timer_fn 0x73/0x160 <--- EIP hits 0
>
> Use after free.. with CONFIG_DEBUG_PAGEALLOC &&
> CONFIG_DEBUG_OBJECTS_TIMERS we get :
>
> call_timer_fn 0x73/0x160
> destroy_timer_on_stack 0x20/0x20
>
> call_timer_fn 0x73/0x160 <--- EIP hits 0
Use after free.. with CONFIG_DEBUG_PAGEALLOC &&
CONFIG_DEBUG_OBJECTS_TIMERS we get :
call_timer_fn 0x73/0x160
destroy_timer_on_stack 0x20/0x20
ftrace_raw_event_hrtimer_expire_entry 0x3b/0xc0
run_timer_softirq 0x1f2/0x230
--
Janne
--
To unsubscribe fro
Hi,
Attached config seems to yield following crash ~5 seconds from kernel
init on Lenovo X201. Any pointers? Sorry for horrible output, its
manually copied from console.
call_timer_fn 0x73/0x160 <--- EIP hits 0
usleep_range 0x40/0x40
run_timer_softirq 0x1d5/0x220
..
call_timer_fn:
..
0xc1060
On Mon, Jul 15, 2013 at 9:17 PM, Linus Torvalds
wrote:
>
> Google "management by perkele".
Actually, not even our former president mr. Kekkonen never went quite
as far using this method. I think something along the lines of
legendary 'saatanan tunarit' would suffice next time :)
--
Janne
--
To
On 8/28/07, Neil Brown <[EMAIL PROTECTED]> wrote:
> > Brief question about NFSv3 lock recovery to those who might
> > know - does Linux implementation (or NLM/NSM protocol)
> > properly support the case in which client and server state
> > change simultaneously?
>
> If both crash, there is nothing
Hi,
Brief question about NFSv3 lock recovery to those who might
know - does Linux implementation (or NLM/NSM protocol)
properly support the case in which client and server state
change simultaneously?
Reason I'm asking is that this very case is occasionally giving
me stale locks. Given that NFSv3
On Monday 04 December 2006 22:03, Jan Engelhardt wrote:
> >> 2) NFS provides persistent storage.
> >
> >To me this sounds like a chicken and an egg problem. It
> >both depends and provides this at the same time :/. But
> >hey, if it's supposed to work then OK.
>
> Way 1:
>
> mount -nt tmpfs none /
On Monday 04 December 2006 20:21, Trond Myklebust wrote:
> > > 2) NFS provides persistent storage.
> >
> > To me this sounds like a chicken and an egg problem. It
> > both depends and provides this at the same time :/. But
> > hey, if it's supposed to work then OK.
>
> ??? Locking depends on persi
On Monday 04 December 2006 17:29, Trond Myklebust wrote:
> > > I have been trying to make FC5's kernel do a boot
> > > with an NFS root file system. I see the support is in the
> > > kernel(?).
> >
> > Is this really properly possible (with read/write access and
> > locking in place)? AFAIK NFS
On 12/2/06, William Estrada <[EMAIL PROTECTED]> wrote:
Hi guys,
I have been trying to make FC5's kernel do a boot
with an NFS root file system. I see the support is in the
kernel(?).
Is this really properly possible (with read/write access and
locking in place)? AFAIK NFS client lock state
23 matches
Mail list logo
