From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexey Brodkin Subject: Re: arc_usr_cmpxchg and preemption Date: Wed, 14 Mar 2018 20:38:53 +0000 Message-ID: <1521059931.11552.51.camel@synopsys.com> References: <1521045375.11552.27.camel@synopsys.com> <20180314175352.GP4064@hirez.programming.kicks-ass.net> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <20180314175352.GP4064@hirez.programming.kicks-ass.net> Content-Language: en-US Content-ID: Sender: linux-kernel-owner@vger.kernel.org To: "Vineet.Gupta1@synopsys.com" , "peterz@infradead.org" Cc: "linux-kernel@vger.kernel.org" , "linux-arch@vger.kernel.org" , "linux-snps-arc@lists.infradead.org" List-Id: linux-arch.vger.kernel.org SGkgUGV0ZXIsIFZpbmVldCwNCg0KT24gV2VkLCAyMDE4LTAzLTE0IGF0IDE4OjUzICswMTAwLCBQ ZXRlciBaaWpsc3RyYSB3cm90ZToNCj4gT24gV2VkLCBNYXIgMTQsIDIwMTggYXQgMDk6NTg6MTlB TSAtMDcwMCwgVmluZWV0IEd1cHRhIHdyb3RlOg0KPiANCj4gPiBXZWxsIGl0IGlzIGJyb2tlbiB3 cnQgdGhlIHNlbWFudGljcyB0aGUgc3lzY2FsbCBpcyBzdXBwb3NlZCB0byBwcm92aWRlLg0KPiA+ IFByZWVtcHRpb24gZGlzYWJsaW5nIGlzIHdoYXQgcHJldmVudHMgYSBjb25jdXJyZW50IHRocmVh ZCBmcm9tIGNvbWluZyBpbiBhbmQNCj4gPiBtb2RpZnlpbmcgdGhlIHNhbWUgbG9jYXRpb24gKElt YWdpbmUgYSB2YXJpYWJsZSB3aGljaCBpcyBiZWluZyBjbXB4Y2hnDQo+ID4gY29uY3VycmVudGx5 IGJ5IDIgdGhyZWFkcykuDQo+ID4gDQo+ID4gT25lIGFwcHJvYWNoIGlzIHRvIGRvIGl0IHRoZSBN SVBTIHdheSwgZW11bGF0ZSB0aGUgbGxzYyBmbGFnIC0gc2V0IGl0IHVuZGVyDQo+ID4gcHJlZW1w dGlvbiBkaXNhYmxlZCBzZWN0aW9uIGFuZCBjbGVhciBpdCBpbiBzd2l0Y2hfdG8NCj4gDQo+ICpz aHVkZGVyKi4uLiBqdXN0IGNhdGNoIHRoZSAtRUZBVUxULCBmb3JjZSB0aGUgd3JpdGUgZmF1bHQg YW5kIHJldHJ5Lg0KPiANCj4gU29tZXRoaW5nIGxpa2U6DQo+IA0KPiBpbnQgc3lzX2NtcHhjaGco dTMyIF9fdXNlciAqdXNlcl9wdHIsIHUzMiBvbGQsIHUzMiBuZXcpDQo+IHsNCj4gCXUzMiB2YWw7 DQo+IAlpbnQgcmV0Ow0KPiANCj4gYWdhaW46DQo+IAlyZXQgPSAwOw0KPiANCj4gCXByZWVtcHRf ZGlzYWJsZSgpOw0KPiAJdmFsID0gZ2V0X3VzZXIodXNlcl9wdHIpOw0KPiAJaWYgKHZhbCA9PSBv bGQpDQo+IAkJcmV0ID0gcHV0X3VzZXIobmV3LCB1c2VyX3B0cik7DQo+IAlwcmVlbXB0X2VuYWJs ZSgpOw0KPiANCj4gCWlmIChyZXQgPT0gLUVGQVVMVCkgew0KPiAJCXN0cnVjdCBwYWdlICpwYWdl Ow0KPiAJCXJldCA9IGdldF91c2VyX3BhZ2VzX2Zhc3QoKHVuc2lnbmVkIGxvbmcpdXNlcl9wdHIs IDEsIDEsICZwYWdlKTsNCj4gCQlpZiAocmV0IDwgMCkNCj4gCQkJcmV0dXJuIHJldDsNCj4gCQlw dXRfcGFnZShwYWdlKTsNCj4gCQlnb3RvIGFnYWluOw0KDQpJIGd1ZXNzIHRoaXMganVtcCB3ZSBu ZWVkIHRvIGRvIG9ubHkgb25jZSwgcmlnaHQ/DQpJZiBmb3Igd2hhdGV2ZXIgcmVhc29uIGdldF91 c2VyX3BhZ2VzX2Zhc3QoKSBmYWlscyB3ZSByZXR1cm4gaW1tZWRpYXRlbHkNCmFuZCBpZiBpdCBz dWNjZWVkcyB0aGVyZSdzIG5vIHJlYXNvbiBmb3IgcHV0X3VzZXIoKSB0byBub3Qgc3VjY2VlZCBh cw0KcmVxdWlyZWQgcGFnZSBpcyBzdXBwb3NlZCB0byBiZSBwcmVwYXJlZCBmb3Igd3JpdGUuDQoN Ck90aGVyd2lzZSBpZiBzb21ldGhpbmcgZ29lcyB3YXkgdG9vIGJhZCB3ZSBtYXkgZW5kLXVwIGlu IGFuIGluZmluaXRlIGxvb3ANCndoaWNoIHdlJ2QgYmV0dGVyIHByZXZlbnQuDQoNCj4gCX0NCj4g DQo+IAlyZXR1cm4gcmV0Ow0KPiB9DQoNCkBWaW5lZXQsIGFyZSB5b3UgT0sgd2l0aCBwcm9wb3Nl ZCBpbXBsZW1lbnRhdGlvbj8NCg0KLUFsZXhleQ0K From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexey.Brodkin@synopsys.com (Alexey Brodkin) Date: Wed, 14 Mar 2018 20:38:53 +0000 Subject: arc_usr_cmpxchg and preemption In-Reply-To: <20180314175352.GP4064@hirez.programming.kicks-ass.net> References: <1521045375.11552.27.camel@synopsys.com> <20180314175352.GP4064@hirez.programming.kicks-ass.net> List-ID: Message-ID: <1521059931.11552.51.camel@synopsys.com> To: linux-snps-arc@lists.infradead.org Hi Peter, Vineet, On Wed, 2018-03-14@18:53 +0100, Peter Zijlstra wrote: > On Wed, Mar 14, 2018@09:58:19AM -0700, Vineet Gupta wrote: > > > Well it is broken wrt the semantics the syscall is supposed to provide. > > Preemption disabling is what prevents a concurrent thread from coming in and > > modifying the same location (Imagine a variable which is being cmpxchg > > concurrently by 2 threads). > > > > One approach is to do it the MIPS way, emulate the llsc flag - set it under > > preemption disabled section and clear it in switch_to > > *shudder*... just catch the -EFAULT, force the write fault and retry. > > Something like: > > int sys_cmpxchg(u32 __user *user_ptr, u32 old, u32 new) > { > u32 val; > int ret; > > again: > ret = 0; > > preempt_disable(); > val = get_user(user_ptr); > if (val == old) > ret = put_user(new, user_ptr); > preempt_enable(); > > if (ret == -EFAULT) { > struct page *page; > ret = get_user_pages_fast((unsigned long)user_ptr, 1, 1, &page); > if (ret < 0) > return ret; > put_page(page); > goto again; I guess this jump we need to do only once, right? If for whatever reason get_user_pages_fast() fails we return immediately and if it succeeds there's no reason for put_user() to not succeed as required page is supposed to be prepared for write. Otherwise if something goes way too bad we may end-up in an infinite loop which we'd better prevent. > } > > return ret; > } @Vineet, are you OK with proposed implementation? -Alexey