linux-kernel - Re: [PATCH v6 2/6] mailbox: sun6i-msgbox: Add a new mailbox 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: <CABb+yY3T1cL+E6Y1tGb5cuKLSY5m_zi=VOx4AJzuX40TMOSQTw@mail.gmail.com>
Date:   Fri, 14 Feb 2020 22:47:28 -0600
From:   Jassi Brar <jassisinghbrar@...il.com>
To:     Samuel Holland <samuel@...lland.org>
Cc:     Maxime Ripard <mripard@...nel.org>, Chen-Yu Tsai <wens@...e.org>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        Ondrej Jirman <megous@...ous.com>,
        Vasily Khoruzhick <anarsoul@...il.com>,
        Devicetree List <devicetree@...r.kernel.org>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-sunxi@...glegroups.com
Subject: Re: [PATCH v6 2/6] mailbox: sun6i-msgbox: Add a new mailbox driver

On Fri, Feb 14, 2020 at 9:48 PM Samuel Holland <samuel@...lland.org> wrote:
>
> On 2/12/20 8:18 PM, Samuel Holland wrote:
> > Jassi,
> >
> > On 2/12/20 8:02 PM, Jassi Brar wrote:
> >> On Sun, Jan 12, 2020 at 11:18 PM Samuel Holland <samuel@...lland.org> wrote:
> >>>
> >>> +static int sun6i_msgbox_send_data(struct mbox_chan *chan, void *data)
> >>> +{
> >>> +       struct sun6i_msgbox *mbox = to_sun6i_msgbox(chan);
> >>> +       int n = channel_number(chan);
> >>> +       uint32_t msg = *(uint32_t *)data;
> >>> +
> >>> +       /* Using a channel backwards gets the hardware into a bad state. */
> >>> +       if (WARN_ON_ONCE(!(readl(mbox->regs + CTRL_REG(n)) & CTRL_TX(n))))
> >>> +               return 0;
> >>> +
> >>> +       /* We cannot post a new message if the FIFO is full. */
> >>> +       if (readl(mbox->regs + FIFO_STAT_REG(n)) & FIFO_STAT_MASK) {
> >>> +               mbox_dbg(mbox, "Channel %d busy sending 0x%08x\n", n, msg);
> >>> +               return -EBUSY;
> >>> +       }
> >>> +
> >> This check should go into sun6i_msgbox_last_tx_done().
> >> send_data() assumes all is clear to send next packet.
> >
> > sun6i_msgbox_last_tx_done() already checks that the FIFO is completely empty (as
> > the big comment explains). So this error could only be hit in the knows_txdone
> > == true case, if the client pipelines multiple messages by calling
> > mbox_client_txdone() before the message is actually removed from the FIFO.
> >
> > From the comments in mailbox_controller.h, this kind of usage looks to be
> > unsupported. In that case, I could remove the check entirely. Does that sound right?
>
> After more thought, I would prefer to keep the check. It is fast/simple, and it
> keeps the hardware from getting into an inconsistent state. Silently dropping
> messages sounds like a poor quality of implementation.
>
If the FIFO becomes full after calling send_data(),  then
last_tx_done() should not only check remote's irq status but also
check that the data has been consumed from the FIFO locally (hence the
check becomes redundant in send_data). Otherwise the last_tx_done is
incomplete.  And you actually end up writing more code (error handling
and resubmission instead of the api managing it all transparently)

> send_data() is documented in mailbox_controller.h as returning EBUSY,
>
error is usually returned for s/w check (like mssg too big for fifo),
not h/w events.

> and I see multiple other mailbox controllers implementing the same or a similar check.
>
That it encourages next developer to repeat, is another reason to do
it right this time. Otherwise, I can live with that check in
send_data.

> If
> that is not the way you intend for the API to work, then please update the
> comments in mailbox_controller.h.
>
Mailbox implementations follow no spec. There may be prudent need to
return from send_data, but practically I haven't come across any(?)
platform that can't do without the check in send_data.

Cheers!