All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: "xuqiang (M)" <xuqiang36@huawei.com>
Cc: tglx@linutronix.de, linux-kernel@vger.kernel.org, rui.xiang@huawei.com
Subject: Re: [PATCH -next] irq-chip/gic-v3-its: Fixed an issue where the ITS executes the residual commands in the queue again when the ITS wakes up from sleep mode.
Date: Thu, 05 Nov 2020 13:12:02 +0000	[thread overview]
Message-ID: <11f4143b4ef55739ff1441e848c1f66f@kernel.org> (raw)
In-Reply-To: <8395dfbb-a90e-6903-abe9-cd6f7c48f441@huawei.com>

Please don't top-post.

On 2020-11-05 11:54, xuqiang (M) wrote:
> The kernel sends three commands in the following sequence:
> 
> 1.mapd(deviceA, ITT_addr1, valid:1)
> 
> 2.mapti(deviceA):ITS write ITT_addr1 memory;
> 
> 3.mapd(deviceA, ITT_addr1, valid:0) and kfree(ITT_addr1);
> 
> 4.mapd(deviceA, ITT_addr2, valid:1);
> 
> 5.mapti(deviceA):ITS write ITT_addr2 memory;
> 
> In this case, the processor enters the sleep mode. After the kernel
> performs the suspend operation, the firmware performs the store
> operation and saves GITS_CBASER and GITS_CWRITER registers.
> 
> Then, the processor is woken up, and the firmware restores GITS_CBASER
> and GITS_CWRITER registers. Because GITS_CWRITER register is not 0,
> ITS will read the above command sequence execution from the command
> queue, causing ITT_addr1 memory to be trampled.

This cannot work. By doing a memset on the command queue, you are
only feeding crap to the ITS (command 0 simply does not exist).
Consider yourself lucky that it doesn't just lock-up.

What needs to happen is the restore sequence that is already in the
driver, so that the command queue is in a sane state before re-enabling
the ITS.

         M.
-- 
Jazz is not dead. It just smells funny...

  reply	other threads:[~2020-11-05 13:12 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-03  8:11 [PATCH -next] irq-chip/gic-v3-its: Fixed an issue where the ITS executes the residual commands in the queue again when the ITS wakes up from sleep mode Xu Qiang
2020-11-03 18:19 ` Marc Zyngier
2020-11-05 11:54   ` xuqiang (M)
2020-11-05 13:12     ` Marc Zyngier [this message]
2020-11-05 14:06       ` xuqiang (M)
2020-11-05 14:24         ` Marc Zyngier
2020-11-06 10:05           ` xuqiang (M)
  -- strict thread matches above, loose matches on Subject: below --
2020-11-07 10:42 Xu Qiang
2020-11-07 16:54 ` Marc Zyngier
2020-11-09  3:05   ` xuqiang (M)
2020-11-09 10:43     ` Marc Zyngier
2020-11-10  9:09       ` xuqiang (M)
2020-11-17 13:37         ` xuqiang (M)
2020-11-22 12:47 ` Marc Zyngier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=11f4143b4ef55739ff1441e848c1f66f@kernel.org \
    --to=maz@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rui.xiang@huawei.com \
    --cc=tglx@linutronix.de \
    --cc=xuqiang36@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.