Quoting Timur Tabi (2018-06-22 08:41:11) > On 6/22/18 10:38 AM, Stanimir Varbanov wrote: > > Before entering into the read function we already hold a mutex which > > serializes data reading so I cannot imagine how below sequence could > > happen. Can you explain how to reproduce this race? > > > >> 1. Core 1 reads status register, shows data is available. > >> 2. Core 2 also reads status register, same result > >> 3. Core 2 reads data register, depleting all entropy > >> 4. Core 1 reads data register, which returns 0 > > I have a test which spawns 100 copies of rngtest on a 48-core machine. > Without the spinlock, the driver returns no data much more often. > > If there really is a mutex that serializes data reads across all cores, > then I don't have an explanation. > Perhaps it's because you implemented the 'wait' functionality in this driver? Before the patch there wasn't any sort of wait check so we would bail out if there wasn't any data even if the caller requested that we wait for randomness to be available. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
