On Nov 19, 2020 / 13:01, Peter Zijlstra wrote:
> On Thu, Nov 19, 2020 at 11:51:00AM +, Shinichiro Kawasaki wrote:
> > I tried Peter's patch in my test system and result looks good. The warning
> > is
> > still observed with 5.10-rc4. With the patch on top of 5.10-rc4, the warning
> >
On 19.11.20 13:01, Peter Zijlstra wrote:
On Thu, Nov 19, 2020 at 11:51:00AM +, Shinichiro Kawasaki wrote:
I tried Peter's patch in my test system and result looks good. The warning is
still observed with 5.10-rc4. With the patch on top of 5.10-rc4, the warning
disappeared.
The patch on
On Thu, Nov 19, 2020 at 11:51:00AM +, Shinichiro Kawasaki wrote:
> I tried Peter's patch in my test system and result looks good. The warning is
> still observed with 5.10-rc4. With the patch on top of 5.10-rc4, the warning
> disappeared.
The patch on its own is not sufficient to fix things;
On Nov 18, 2020 / 09:22, Peter Zijlstra wrote:
> On Wed, Nov 18, 2020 at 07:47:36AM +0100, Jürgen Groß wrote:
> > On 16.11.20 14:04, Peter Zijlstra wrote:
> > > On Mon, Nov 16, 2020 at 12:56:32PM +0100, Jürgen Groß wrote:
> > > > > > > > > > static inline notrace unsigned long
> > > > > > > > > >
On Wed, Nov 18, 2020 at 07:47:36AM +0100, Jürgen Groß wrote:
> On 16.11.20 14:04, Peter Zijlstra wrote:
> > On Mon, Nov 16, 2020 at 12:56:32PM +0100, Jürgen Groß wrote:
> > > > > > > > > static inline notrace unsigned long
> > > > > > > > > arch_local_save_flags(void)
> > > > > > > > > {
> > > >
On 16.11.20 14:04, Peter Zijlstra wrote:
On Mon, Nov 16, 2020 at 12:56:32PM +0100, Jürgen Groß wrote:
static inline notrace unsigned long arch_local_save_flags(void)
{
PVOP_CALL_ARGS;
PVOP_TEST_NULL(irq.save_fl);
asm_inline volatile(ALTERNATIVE(paravirt_alt(PARAVIRT_CALL),
On Mon, Nov 16, 2020 at 12:56:32PM +0100, Jürgen Groß wrote:
> > > > > > > static inline notrace unsigned long arch_local_save_flags(void)
> > > > > > > {
> > > > > > > PVOP_CALL_ARGS;
> > > > > > > PVOP_TEST_NULL(irq.save_fl);
> > > > > > > asm_inline
On 13.11.20 18:34, Andy Lutomirski wrote:
On Wed, Nov 11, 2020 at 12:25 PM Andrew Cooper
wrote:
On 11/11/2020 20:15, Josh Poimboeuf wrote:
On Wed, Nov 11, 2020 at 09:07:30PM +0100, Peter Zijlstra wrote:
On Wed, Nov 11, 2020 at 01:59:00PM -0600, Josh Poimboeuf wrote:
On Wed, Nov 11, 2020 at
On 15.11.20 17:05, Andy Lutomirski wrote:
On Nov 14, 2020, at 10:33 PM, Jürgen Groß wrote:
On 14.11.20 19:10, Andy Lutomirski wrote:
On Sat, Nov 14, 2020 at 1:16 AM Jürgen Groß wrote:
On 13.11.20 18:34, Andy Lutomirski wrote:
On Wed, Nov 11, 2020 at 12:25 PM Andrew Cooper
wrote:
So I
> On Nov 14, 2020, at 10:33 PM, Jürgen Groß wrote:
>
> On 14.11.20 19:10, Andy Lutomirski wrote:
>>> On Sat, Nov 14, 2020 at 1:16 AM Jürgen Groß wrote:
>>>
>>> On 13.11.20 18:34, Andy Lutomirski wrote:
On Wed, Nov 11, 2020 at 12:25 PM Andrew Cooper
wrote:
So I think
On 14.11.20 19:10, Andy Lutomirski wrote:
On Sat, Nov 14, 2020 at 1:16 AM Jürgen Groß wrote:
On 13.11.20 18:34, Andy Lutomirski wrote:
On Wed, Nov 11, 2020 at 12:25 PM Andrew Cooper
wrote:
So I think there is at most one of these that wants anything more
complicated than a plain
On Sat, Nov 14, 2020 at 1:16 AM Jürgen Groß wrote:
>
> On 13.11.20 18:34, Andy Lutomirski wrote:
> > On Wed, Nov 11, 2020 at 12:25 PM Andrew Cooper
> > wrote:
> >
> > So I think there is at most one of these that wants anything more
> > complicated than a plain ALTERNATIVE. Any volunteers to
On 13.11.20 18:34, Andy Lutomirski wrote:
On Wed, Nov 11, 2020 at 12:25 PM Andrew Cooper
wrote:
On 11/11/2020 20:15, Josh Poimboeuf wrote:
On Wed, Nov 11, 2020 at 09:07:30PM +0100, Peter Zijlstra wrote:
On Wed, Nov 11, 2020 at 01:59:00PM -0600, Josh Poimboeuf wrote:
On Wed, Nov 11, 2020 at
On Wed, Nov 11, 2020 at 12:25 PM Andrew Cooper
wrote:
>
> On 11/11/2020 20:15, Josh Poimboeuf wrote:
> > On Wed, Nov 11, 2020 at 09:07:30PM +0100, Peter Zijlstra wrote:
> >> On Wed, Nov 11, 2020 at 01:59:00PM -0600, Josh Poimboeuf wrote:
> >>> On Wed, Nov 11, 2020 at 08:42:06PM +0100, Peter
On Wed, Nov 11, 2020 at 12:13:28PM -0600, Josh Poimboeuf wrote:
> On Wed, Nov 11, 2020 at 06:47:36PM +0100, Peter Zijlstra wrote:
> > Yeah, so it's all a giant can of worms that; also see:
> >
> > https://lkml.kernel.org/r/20200821084738.508092...@infradead.org
> >
> > The basic idea is to
On Wed, Nov 11, 2020 at 08:25:36PM +, Andrew Cooper wrote:
> > Right, it makes objtool's job a _little_ easier, since it already knows
> > how to read alternatives. But it still has to learn to deal with the
> > conflicting stack layouts.
>
> I suppose the needed abstraction is "these
On Wed, Nov 11, 2020 at 02:15:06PM -0600, Josh Poimboeuf wrote:
> On Wed, Nov 11, 2020 at 09:07:30PM +0100, Peter Zijlstra wrote:
> > Possible, we just need to be _really_ careful to not allow changing
> > those static_call()s. So maybe we need DEFINE_STATIC_CALL_RO() which
> > does a
On 11/11/2020 20:15, Josh Poimboeuf wrote:
> On Wed, Nov 11, 2020 at 09:07:30PM +0100, Peter Zijlstra wrote:
>> On Wed, Nov 11, 2020 at 01:59:00PM -0600, Josh Poimboeuf wrote:
>>> On Wed, Nov 11, 2020 at 08:42:06PM +0100, Peter Zijlstra wrote:
> Would objtool have an easier time coping if this
On Wed, Nov 11, 2020 at 09:07:30PM +0100, Peter Zijlstra wrote:
> On Wed, Nov 11, 2020 at 01:59:00PM -0600, Josh Poimboeuf wrote:
> > On Wed, Nov 11, 2020 at 08:42:06PM +0100, Peter Zijlstra wrote:
> > > > Would objtool have an easier time coping if this were implemented in
> > > > terms of a
On Wed, Nov 11, 2020 at 01:59:00PM -0600, Josh Poimboeuf wrote:
> On Wed, Nov 11, 2020 at 08:42:06PM +0100, Peter Zijlstra wrote:
> > > Would objtool have an easier time coping if this were implemented in
> > > terms of a static call?
> >
> > I doubt it, the big problem is that there is no
On Wed, Nov 11, 2020 at 08:42:06PM +0100, Peter Zijlstra wrote:
> > Would objtool have an easier time coping if this were implemented in
> > terms of a static call?
>
> I doubt it, the big problem is that there is no visibility into the
> actual alternative text. Runtime patching fragments into
On Wed, Nov 11, 2020 at 06:46:37PM +, Andrew Cooper wrote:
> Well...
>
> static_calls are a newer, and more generic, form of pvops. Most of the
> magic is to do with inlining small fragments, but static calls can do
> that now too, IIRC?
If you're referring to this glorious hack:
On 11/11/2020 18:13, Josh Poimboeuf wrote:
> On Wed, Nov 11, 2020 at 06:47:36PM +0100, Peter Zijlstra wrote:
>> This is PARAVIRT_XXL only, which is a Xen special. My preference, as
>> always, is to kill it... Sadly the Xen people have a different opinion.
> That would be s nice... then we
On Wed, Nov 11, 2020 at 06:47:36PM +0100, Peter Zijlstra wrote:
> This is PARAVIRT_XXL only, which is a Xen special. My preference, as
> always, is to kill it... Sadly the Xen people have a different opinion.
That would be s nice... then we could get rid of paravirt patching
altogether and
On Wed, Nov 11, 2020 at 11:05:36AM -0600, Josh Poimboeuf wrote:
> On Fri, Nov 06, 2020 at 06:04:15AM +, Shinichiro Kawasaki wrote:
> > Greetings,
> >
> > I observe "WARNING: can't access registers at
> > asm_common_interrupt+0x1e/0x40"
> >
On Fri, Nov 06, 2020 at 06:04:15AM +, Shinichiro Kawasaki wrote:
> Greetings,
>
> I observe "WARNING: can't access registers at asm_common_interrupt+0x1e/0x40"
> in my kernel test system repeatedly, which is printed by unwind_next_frame()
> in
> "arch/x86/ker
gt; > attachment file to LKML. In case it does not reach to you, please let me
> > know.
>
> Got it, thanks. Unfortunately I'm still confused.
>
> Can you test with the following patch, and boot with 'unwind_debug'?
> That should hopefully dump a lot of useful data along with
On Mon, Nov 09, 2020 at 09:10:38AM +, Shinichiro Kawasaki wrote:
> On Nov 06, 2020 / 12:06, Josh Poimboeuf wrote:
> > On Fri, Nov 06, 2020 at 06:04:15AM +, Shinichiro Kawasaki wrote:
> > > Greetings,
> > >
> > > I observe "WARNING: can't access
On Nov 06, 2020 / 12:06, Josh Poimboeuf wrote:
> On Fri, Nov 06, 2020 at 06:04:15AM +, Shinichiro Kawasaki wrote:
> > Greetings,
> >
> > I observe "WARNING: can't access registers at
> > asm_common_interrupt+0x1e/0x40"
> > in my kern
On Fri, Nov 06, 2020 at 06:04:15AM +, Shinichiro Kawasaki wrote:
> Greetings,
>
> I observe "WARNING: can't access registers at asm_common_interrupt+0x1e/0x40"
> in my kernel test system repeatedly, which is printed by unwind_next_frame()
> in
> "arch/x86/ker
Greetings,
I observe "WARNING: can't access registers at asm_common_interrupt+0x1e/0x40"
in my kernel test system repeatedly, which is printed by unwind_next_frame() in
"arch/x86/kernel/unwind_orc.c". Syzbot already reported that [1]. Similar
warning was reported and discusse
...@syzkaller.appspotmail.com
WARNING: can't access registers at asm_common_interrupt+0x1e/0x40
arch/x86/include/asm/idtentry.h:572
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal
32 matches
Mail list logo
