linux-kernel - Re: [PATCH] mmc: block: ioctl: Poll for TRAN if possible

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-next>] [day] [month] [year] [list]

Date:   Wed, 9 Jun 2021 11:31:39 +0000
From:   Christian Löhle <CLoehle@...erstone.com>
To:     Avri Altman <Avri.Altman@....com>,
        "linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "ulf.hansson@...aro.org" <ulf.hansson@...aro.org>,
        Adrian Hunter <adrian.hunter@...el.com>,
        "shawn.lin@...k-chips.com" <shawn.lin@...k-chips.com>
Subject: Re: [PATCH] mmc: block: ioctl: Poll for TRAN if possible

>> +        */
>> +       return !(cmd->opcode == MMC_SEND_CID
>> +                       || cmd->opcode == MMC_ALL_SEND_CID
>> +                       || cmd->opcode == MMC_SEND_CSD
>> +                       || cmd->opcode == MMC_SEND_STATUS
>> +                       || cmd->opcode == MMC_SELECT_CARD
>> +                       || cmd->opcode == MMC_APP_CMD
>> +                       || cmd->opcode == MMC_GO_INACTIVE_STATE
>> +                       || cmd->opcode == MMC_GO_IDLE_STATE);
>> +
>Aren’t you only interested in cmds that move to tran state from other state?
>According to the Device state transitions (table 61 in eMMC5.1) it only concern
>cmd7 (stby->tran), cmd12 (data->tran), and cmd14 (btst->tran).
>
>Thanks,
>Avri

No, I'd poll for any command where this is possible, so I only exclude the
ones not ending up in TRAN.
The TRAN->RCV->PRG->TRAN commands are the ones that need polling
to be race condition free.
Technically CMD16, 23  and so on (TRAN->TRAN directly) don't need the
CMD13 polling but it does not hurt either, especially because the cmd->opcode
itself overlaps for general and sd commands.
Tracking whether CMD55 was the last command would have been awkward and
CMD13 polling wherever possible seems the more sane option.
If adding a flag to disable any inter-CMD13 polling of none-R1b commands is
desired, I can add that, but I did not see a good reason for that right now.

Regards,
Christian
Hyperstone GmbH | Line-Eid-Strasse 3 | 78467 Konstanz
Managing Directors: Dr. Jan Peter Berns.
Commercial register of local courts: Freiburg HRB381782