Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Thu, 9 Aug 2018 12:52:13 -0700
From:   Brian Norris <briannorris@chromium.org>
To:     Stephen Boyd <swboyd@chromium.org>
Cc:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        linux-kernel@vger.kernel.org,
        Wei-Ning Huang <wnhuang@chromium.org>,
        Julius Werner <jwerner@chromium.org>,
        Samuel Holland <samuel@sholland.org>
Subject: Re: [PATCH v3 2/7] firmware: coreboot: Unmap ioregion on failure
Message-ID: <20180809195211.GA137192@ban.mtv.corp.google.com>
References: <20180809171722.144325-1-swboyd@chromium.org>
 <20180809171722.144325-3-swboyd@chromium.org>
 <20180809174936.GC129285@ban.mtv.corp.google.com>
 <153384363124.220756.3747855789935101539@swboyd.mtv.corp.google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <153384363124.220756.3747855789935101539@swboyd.mtv.corp.google.com>
User-Agent: Mutt/1.10.1+48 (1f3a9df87d11) (2018-07-22)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi,

On Thu, Aug 09, 2018 at 12:40:31PM -0700, Stephen Boyd wrote:
> Quoting Brian Norris (2018-08-09 10:49:38)
> > On Thu, Aug 09, 2018 at 10:17:17AM -0700, Stephen Boyd wrote:
> > > Both callers of coreboot_table_init() ioremap the pointer that comes in
> > > but they don't unmap the memory on failure. Both of them also fail probe
> > > immediately with the return value of coreboot_table_init(), leaking a
> > > mapping when it fails. Plug the leak so the mapping isn't left unused.
> > > 
> > > Cc: Wei-Ning Huang <wnhuang@chromium.org>
> > > Cc: Julius Werner <jwerner@chromium.org>
> > > Cc: Brian Norris <briannorris@chromium.org>
> > > Cc: Samuel Holland <samuel@sholland.org>
> > > Fixes: 570d30c2823f ("firmware: coreboot: Expose the coreboot table as a bus")
> > 
> > I suppose this is fair, since that commit introduced error paths and
> > didn't clean them up. But one warning below:
> > 
> > > Signed-off-by: Stephen Boyd <swboyd@chromium.org>
> > > ---
> > >  drivers/firmware/google/coreboot_table.c | 3 +++
> > >  1 file changed, 3 insertions(+)
> > > 
> > > diff --git a/drivers/firmware/google/coreboot_table.c b/drivers/firmware/google/coreboot_table.c
> > > index 19db5709ae28..0d3e140444ae 100644
> > > --- a/drivers/firmware/google/coreboot_table.c
> > > +++ b/drivers/firmware/google/coreboot_table.c
> > > @@ -138,6 +138,9 @@ int coreboot_table_init(struct device *dev, void __iomem *ptr)
> > >               ptr_entry += entry.size;
> > >       }
> > >  
> > > +     if (ret)
> > > +             iounmap(ptr);
> > 
> > This works because no sub-driver is using this mapping any more (i.e.,
> > because we killed coreboot_table_find()). Otherwise, we'd need to
> > explicitly kill all the sub-devices first. IOW, if this gets backported
> > to older kernels, it would need to go along with this and its other
> > dependencies:
> 
> The memory is copied out of the table. So do the devices actually use
> the memory that we remap here? I don't see how it's a problem if we
> unmap the table after we populate devices.

No, the memory is (or was) copied each time. See:

int coreboot_table_find(int tag, void *data, size_t data_size)
{
...
	memcpy_fromio(&header, ptr_header, sizeof(header));
...

(where ptr_header is an alias for 'ptr')

So before commit b616cf53aa7a and friends, this patch is a bad idea.

Just to reiterate/clarify: none of this is a criticism of this patch as
applied to mainline. It's just a criticism of what might happen with the
'Fixes' tag if we aren't careful.

Brian


> > b616cf53aa7a firmware: coreboot: Remove unused coreboot_table_find