From: David Miller <davem@davemloft.net>
To: mchan@broadcom.com
Cc: sergei.shtylyov@cogentembedded.com, natg@google.com,
nsujir@broadcom.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] net-tg3: Initialize REG_BASE_ADDR at PCI config offset 120 to 0
Date: Tue, 10 Dec 2013 22:23:13 -0500 (EST) [thread overview]
Message-ID: <20131210.222313.694303616856894486.davem@davemloft.net> (raw)
In-Reply-To: <1386701379.1752.26.camel@LTIRV-MCHAN1.corp.ad.broadcom.com>
From: Michael Chan <mchan@broadcom.com>
Date: Tue, 10 Dec 2013 10:49:39 -0800
> On Tue, 2013-12-10 at 13:43 -0500, David Miller wrote:
>
>> What if the kernel is booted via kexec, and the driver in the kernel
>> we are kexec'ing from left indirect access enabled in MISC_HOST_CTRL?
>
> That should be ok. The driver will only use valid register offsets in
> indirect mode during run time, so register 0x78 should point to a valid
> register. If indirect mode is never used by the driver, it will point
> to zero with this patch. So register 0x78 will be valid (or zero) in
> the kexec'ed kernel.
Ok, that may be true, but I'd like to consider the much larger issue
at hand.
If the indirect mechanism is enabled, some of the offsets that may be
in there might be value, but would be entirely undesirable to be read
because the read has side effects.
What if the interrupt status register is what gets read if the user
scans config space at just the wrong moment, and therefore an
interrupt gets lost?
I understand that the patch we are discussing is a serious improvement
from the current situation, so I will apply it and queue it up for
-stable.
However I think we need to do something reasonable to prevent the
kinds of situations I described above.
Thanks.
next prev parent reply other threads:[~2013-12-11 3:23 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-09 18:43 Nat Gurumoorthy
2013-12-09 19:00 ` Michael Chan
2013-12-09 19:22 ` Natarajan Gurumoorthy
2013-12-09 21:18 ` Sergei Shtylyov
2013-12-09 21:07 ` Michael Chan
2013-12-10 6:58 ` Michael Chan
2013-12-10 15:01 ` Natarajan Gurumoorthy
2013-12-10 18:40 ` Michael Chan
2013-12-10 18:43 ` David Miller
2013-12-10 18:49 ` Michael Chan
2013-12-11 3:23 ` David Miller [this message]
2013-12-11 23:21 ` Michael Chan
2013-12-12 0:35 ` David Miller
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=20131210.222313.694303616856894486.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
--cc=mchan@broadcom.com \
--cc=natg@google.com \
--cc=netdev@vger.kernel.org \
--cc=nsujir@broadcom.com \
--cc=sergei.shtylyov@cogentembedded.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®