linux-kernel - Re: [PATCH v6] i2c: virtio: add a virtio i2c frontend driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAK8P3a04u9Xv15K06zrsOtzZF18+1wDpJbBHUU3wYwU--Hdz5A@mail.gmail.com>
Date:   Wed, 10 Mar 2021 09:27:39 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Jason Wang <jasowang@...hat.com>
Cc:     Jie Deng <jie.deng@...el.com>,
        Linux I2C <linux-i2c@...r.kernel.org>,
        virtualization@...ts.linux-foundation.org,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Michael S. Tsirkin" <mst@...hat.com>,
        Wolfram Sang <wsa@...nel.org>,
        Wolfram Sang <wsa+renesas@...g-engineering.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        conghui.chen@...el.com, kblaiech@...lanox.com,
        jarkko.nikula@...ux.intel.com,
        Sergey Semin <Sergey.Semin@...kalelectronics.ru>,
        Mike Rapoport <rppt@...nel.org>, loic.poulain@...aro.org,
        Tali Perry <tali.perry1@...il.com>,
        Uwe Kleine-König 
        <u.kleine-koenig@...gutronix.de>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        yu1.wang@...el.com, shuo.a.liu@...el.com,
        Viresh Kumar <viresh.kumar@...aro.org>,
        Stefan Hajnoczi <stefanha@...hat.com>,
        Paolo Bonzini <pbonzini@...hat.com>
Subject: Re: [PATCH v6] i2c: virtio: add a virtio i2c frontend driver

On Wed, Mar 10, 2021 at 4:59 AM Jason Wang <jasowang@...hat.com> wrote:
> On 2021/3/10 10:22 上午, Jie Deng wrote:
> > On 2021/3/4 17:15, Jason Wang wrote:
> >>
> >>
> >>> +        }
> >>> +
> >>> +        if (msgs[i].flags & I2C_M_RD)
> >>> +            memcpy(msgs[i].buf, req->buf, msgs[i].len);
> >>
> >>
> >> Sorry if I had asked this before but any rason not to use msg[i].buf
> >> directly?
> >>
> >>
> > The msg[i].buf is passed by the I2C core. I just noticed that these
> > bufs are not
> > always allocated by kmalloc. They may come from the stack, which may
> > cause
> > the check "sg_init_one -> sg_set_buf -> virt_addr_valid"  to fail.
> > Therefore the
> > msg[i].buf is not suitable for direct use here.
>
> Right, stack is virtually mapped.

Maybe there is (or should be) a way to let the i2c core code handle
the bounce buffering in this case. This is surely not a problem that
is unique to this driver, and I'm sure it has come up many times in
the past.

I see that there is a i2c_get_dma_safe_msg_buf() helper for this
purpose, but it has to be called by the driver rather than the core,
so the driver still needs to keep track of each address when it
sends multiple i2c_msg at once, but maybe it can all be done
inside the sg_table instead of yet another structure.

At least this one avoids copying data that is marked with the
I2C_M_DMA_SAFE flag.

       Arnd