Re: Race: data race between shmem_getpage() and mapping_set_gfp_mask()

["Gong, Sishuai" <sishuai@xxxxxxxxxx>]

Thanks for your feedback. We are sorry that we didn’t send detailed reports as expected and the trouble we caused. We will try to provide more analysis for the ones we reported and to be reported in the next.

Our analysis shows this data race didn’t have explicit harmful impact in this case and we want to report our experience with the experiment.

------------------------------------------
Interleaving
We observed two interleavings of the two racy instructions. As shown below, the reader can see an inconsistent value but it is not used in both interleavings.
We are wondering if the xa_is_value() condition could be true. Possibly the inconsistent value will be passed to shmem_swapin_page() and cause some error.

Interleaving 1
Writer							Reader
m->gfp_mask = mask;
// write value = 0x100c0a
								return shmem_getpage_gfp(inode, index, pagep, sgp, mapping_gfp_mask(inode->i_mapping), NULL, NULL, NULL);
								// read value = 0x100c0a
								…
								// in function shmem_getpage_gfp()
								if (xa_is_value(page)) {
								// condition is false, skip
									error = shmem_swapin_page(inode, index, &page, sgp, gfp, vma, fault_type);


Interleaving 2
Writer							Reader
								return shmem_getpage_gfp(inode, index, pagep, sgp, mapping_gfp_mask(inode->i_mapping), NULL, NULL, NULL);
								// read value = 0x100caa

m->gfp_mask = mask;
// write value = 0x100c0a
								…
								// in function shmem_getpage_gfp()
								if (xa_is_value(page)) {
								// condition is false, skip
								       error = shmem_swapin_page(inode, index, &page, sgp, gfp, vma, fault_type);


Thanks,
Sishuai

> On Nov 30, 2020, at 1:16 PM, Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote:
> 
> On Mon, Nov 30, 2020 at 06:14:29PM +0000, Gong, Sishuai wrote:
>> Hi,
>> 
>> We found a data race in linux kernel 5.3.11 that we are able to reproduce in x86 under specific interleavings. Currently, we are not sure about the consequence of this race so we would like to confirm with the community if this can be a harmful bug.
> 
> Are you going to be sending a lot of these?  There's no shortage of
> actual bugs hit with syzcaller.  What we're short on is people to review,
> analyse and fix bugs.