From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753664AbcEYB0A (ORCPT ); Tue, 24 May 2016 21:26:00 -0400 Received: from mail-bn1bn0103.outbound.protection.outlook.com ([157.56.110.103]:28593 "EHLO na01-bn1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752299AbcEYBZ6 (ORCPT ); Tue, 24 May 2016 21:25:58 -0400 Authentication-Results: hpe.com; dkim=none (message not signed) header.d=none;hpe.com; dmarc=none action=none header.from=hpe.com; Message-ID: <5744FF1A.8050804@hpe.com> Date: Tue, 24 May 2016 21:25:46 -0400 From: Waiman Long User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130109 Thunderbird/10.0.12 MIME-Version: 1.0 To: Jason Low CC: Peter Hurley , , Davidlohr Bueso , Peter Zijlstra , Ingo Molnar , , Dave Chinner , "Paul E. McKenney" , Scott J Norton , Douglas Hatch Subject: Re: [PATCH v4 2/5] locking/rwsem: Protect all writes to owner by WRITE_ONCE References: <1463534783-38814-1-git-send-email-Waiman.Long@hpe.com> <1463534783-38814-3-git-send-email-Waiman.Long@hpe.com> <20160518140436.GA6273@linux-uzut.site> <1463592095.3369.10.camel@j-VirtualBox> <573CB496.4010707@hpe.com> <1463601515.2587.24.camel@j-VirtualBox> <574086FE.6080807@hurleysoftware.com> <1464029181.2479.21.camel@j-VirtualBox> In-Reply-To: <1464029181.2479.21.camel@j-VirtualBox> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [71.168.64.112] X-ClientProxiedBy: CY1PR18CA0039.namprd18.prod.outlook.com (10.163.31.49) To AT5PR84MB0306.NAMPRD84.PROD.OUTLOOK.COM (10.162.138.28) X-MS-Office365-Filtering-Correlation-Id: c5bb1ffa-8c86-471b-0b45-08d3843b8463 X-Microsoft-Exchange-Diagnostics: 1;AT5PR84MB0306;2:NSnFa1K1BFBDWdvUGfP6ECcLUrLvLJ4SouePKMypPDNlnIxNpa2pGn63fBWRqHWFYxdpEH0lhN74Uuz3P/Qz6MyP4lKWisFpe3sZULAuZCjA1Vr2RnkvgfsuPLiyVO74CtUgd3lDsgCn174pGxPmRBcQO6CJ+1cMv0tEHjaUfpvX0rVKZJNsTsLVLBRCMm93;3:djLyKiRjiSCbBoFXPcxGVka6ZkLvgNVIs5iS2/dLP+8jPkyghmrQQcG/LtBxmLn9/uvE+JvIHbJshuZz5vvuEhXtXK3PRh5QPAi+SN59Wqi8O/Th7HziA710YD5a6ZJ5;25:SSCvk/yJ4UwQHH22FUARuOIETTM7eajqg/aDiV87WNGNEzPuSRvZF3J2J6LvcgQvTMdNzib5SfWXHlTmZfMC9OjcOaD+ryeUNQ3usDUpPvq11t78kfTB8kjTv/tkNbPGA6TNqH4mPDwMVfkb9x1U0cv0upJUoNeE1PuOCbjb6kQ3fZN94Sk/OO1EnMs3h+Sm+s0/HftCHoy1obyhQfg08jQKYBEO5Z7JoFUeILPpCOx9CtV+CJUsn37YKaHwx0F2aItHYuZizHQq3CNFrfkYz3LlWRKSWNBLtmfEXUblhE5bDMHMh0OntQuE8Gv4KJgEtZna4W8NthrN006KS2WBXagHqAqYDdUzteqvSHasoqgch8g+JFLMJsjm2cNmJ5u4XrRJioDQVI6C8OLJRPsbGSUdpWjFAP+H2kf0vgmBfXw= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AT5PR84MB0306; X-LD-Processed: 105b2061-b669-4b31-92ac-24d304d195dc,ExtAddr X-Microsoft-Exchange-Diagnostics: 1;AT5PR84MB0306;20:2aXlPxEPG8o3uwt8DRtabhJxVlSJVNrX3Qs9n4LJLP1CNAeYIw5oFmKWTYRVUZ3XpE+02kuPs3qd85GVJfO+rr6Khr2idOPREJoOnD0YD/lN/B8v0lEkP6uqGhMw7C6G++715gUXQHPvrhNAmLhNGyPwGZ7mYrYGV9epFbN+xeED2+lRHS661KDaAHN1mfgBI/KGBG8RC5z3lpIVtLNDO2bKLhZXktz08eFRiDZ3avVyPAW8ZznlpaB9o45vPhBCqm0lU5OBIisU2duSGlhirfwHiWn8uahNARmBNmgimiROgurrTDWN3MxJGfZ1ShrgCEIs0oN8dLB4jq9xuqzOZQ==;4:GfbPxeZ7adNsucBQ49xYA3yS08wq3vtSu6fohDFbVQmgac/iAG9WB7+LhsByBB/ouZw7K8TVfp+LJPMqemiruezLInAR4tigm0hZIaoYHgD34KxWUwFY0xBwuaCkyQ9FsVF3jvc0CqsV66RbwHkVL1j5RiKnJhw+j1iq4VEm8aGDSUs+mgWZbdDF5kmui0uNRwRGzJ81H1e6K2UWlE0HqRdbZ1E3Iju6KWNtViZ5ReJx28xW3Qu+2p5Byx8e0IIA3VCuR1pk2jXpgETHyMOujYdFIFMDHYfbpYv9AGpg7S7nf5zFfOWaiokZwixSqNGNonDzB9CP9wjr3VVIiNzXMNEZ2sSEyFfWWYGu2utZ/E+O9i9ZtiNlDK/xwXcEVpuu X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001);SRVR:AT5PR84MB0306;BCL:0;PCL:0;RULEID:;SRVR:AT5PR84MB0306; X-Forefront-PRVS: 09538D3531 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(4630300001)(6049001)(6009001)(377454003)(377424004)(24454002)(64126003)(50986999)(54356999)(76176999)(81166006)(4001350100001)(2906002)(2950100001)(4326007)(230700001)(65816999)(586003)(189998001)(36756003)(42186005)(86362001)(33656002)(6116002)(92566002)(3846002)(23676002)(93886004)(110136002)(5004730100002)(77096005)(47776003)(50466002)(5008740100001)(117156001)(66066001)(65956001)(65806001)(8676002)(8666003)(83506001)(7059030);DIR:OUT;SFP:1102;SCL:1;SRVR:AT5PR84MB0306;H:[192.168.142.138];FPR:;SPF:None;MLV:sfv;LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBVDVQUjg0TUIwMzA2OzIzOmt4VDFYaENKUWZEQk9WOG5KbU8rTHpJUDNp?= =?utf-8?B?bHUwR2MyMTF5Y20rRHpHNXVDR2NQanBtVTVSVTNCZXZsWGpzOFB4NWJ0UkZO?= =?utf-8?B?UWF6SjRuTVpBMEZDR2xGVW9qbjA2NTVxWm5kTmtLbm10SXA5WTlUWkxaaFo4?= =?utf-8?B?cnROVCtmc3B3OFJ5LytVWU1UcllRcVB3Wk1qaGhDbjd0WUZNZjAva2hoT1dH?= =?utf-8?B?U2o2dC9LL0V0SWxmYjJ3MmlJWkJ4azBRb0V6ZkQxekdHV1h5cEhNZUN4YitF?= =?utf-8?B?RkNmTzN6VEVFVDJmOVpodDZoNDU1YysxeTBqUHVNQUF4L056Z0pVLzZUNzEv?= =?utf-8?B?UUVGWGN0OVlIL0VQOHZsa3VhV3A3cVlJbjAzTTRjSk16QmE5TWx6L2lnM2sx?= =?utf-8?B?cXFoSUt6T0FiNjFTQzdSbDgyUjh4Y3FzQldIMzR1K2hER2hEVjhoYzd3Y2Nq?= =?utf-8?B?bHpSZHhpaWZyQXFCQ3J0Q3FiWVNRY0tlM3hLV1RwTjZIZERYaXZLMFFxcDNv?= =?utf-8?B?Y1AvbFJ3WVNiZ3RGTWo5Q1VRd2lFS2YwdUtwMGNxRVNvdGZ6cFUvTGRyVzBx?= =?utf-8?B?eHl0WGNQL0gzekpjRWlzRHNkcmhaMk45bkk3QjdVNnBUNldjRHVUMHNhSEtR?= =?utf-8?B?VFRoMWpwRjRrYnM0T3hFV0J5cklrMmRQaERaZkdhZlZFKzJab0hjcXBjRjZG?= =?utf-8?B?ZHFXTVdlVGVwMjl3UzU5NnJkZ3pOekpDVkwwZUcvenRLNi9JcWFzdEtnSU9t?= =?utf-8?B?VDFoTGdwemt5RU1oSnJLL2U1VklGSTl6RnhiV0NWdkwzbGlkTk05QnNuV2JV?= =?utf-8?B?R3hueHdYYVJyaitKZkVVUFViYnY2UExJcnJBZ3p0NG5nUktvOVBUMHVIaWxT?= =?utf-8?B?Y0VvSjliZFdQZnRKUnZiM1lSVS9NVjU3NE1aZlQzTjl1Z1NXTS9IdEh4THVr?= =?utf-8?B?QUprQzRTY0xIM0JGb0ZpMkNxeHU3TlRUeGpKc0JkaTUrOUVaRHozSS9UTzNW?= =?utf-8?B?TzYvRGNoNjBjTzN0OXRBMFVOOWpKZUdBTnZvQmZxc0swQmRBdTY5dVl4RGZK?= =?utf-8?B?SW02L2JUMmNSTTd3aWw1QUx3ei9WeERvUGdZSTIvSWV4Y1FmWG5CMGwwUFRQ?= =?utf-8?B?L2pzd1lHUkRQQkZESnk1TWZQeHBLazJwUWdQbVhST0VKZXFuZit3eGtFekMz?= =?utf-8?B?NVVyZWpCamllWXBYQlEzRHE0SURjOG1tMTEzZmdkYWhKVDBmOTErUzRHRkpq?= =?utf-8?B?a05STDFPRGVXVzhJODdLdGp5ZHEySVhUUzBCT3dwcWZxWmVpd012eHR4Si9B?= =?utf-8?B?NFRZZGc4UFlLOHdtd2g1Rys0SFltRnlQNXhHVnNEeHdTcFZad1pOV0tCWHFv?= =?utf-8?B?L2lDWE9VM2JBK2VFenZtcUJKeENnemN4aVhjMnlvcE9aeTVxb3pFVDlrakpY?= =?utf-8?B?aGV2c2d2Uy9TNUovNTJCeGlPQXpqbE15NmtpMk1nY1lWMTljOEVMa1ZQSVhE?= =?utf-8?B?bnlSQT09?= X-Microsoft-Exchange-Diagnostics: 1;AT5PR84MB0306;5:DZ5f7bsL8CBCqEo6slUiObY+qK0Qk1xiNejfr8vx89iP7t/MvbWFZrNkE0mCI8PEn/8Q6ELt8njMA3BfpB76G/TIMwtRC9DxAyAV4IZ5FWDxG4dsPvPDk5Kqys3yvoea9BqfVkmk3YfReCSZYaIwDQ==;24:HHgVg7qIfsaeHG92lSs0s2QyOFNyYL9g/86MyzhhSG8pPkkejbH2SgXiJtXFIF94osqbZcJf8qfz06tOFkQBdqC3ZUfI2I8enVUCt2WYd8w=;7:jaU6aHPYvY9V3U50jVwP6iNg0Wdi7y3sxEdH7U/4x8TZi6At+Jg3h0bZ434iW9Hc3UIVjT8I7VvuOBmjQoXrQ/jp1jX+EvDo7ieBPoe2JLOvSdwSt49Wc7aREsiEb8Ps1ZJ+GEMzpZPn6dcu/AxGAq/kUDsSZYPwxx+LA3hDKCBomFz2VmpjZ2w2dRP97jMx SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: hpe.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 May 2016 01:25:53.1401 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AT5PR84MB0306 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/23/2016 02:46 PM, Jason Low wrote: > On Sat, 2016-05-21 at 09:04 -0700, Peter Hurley wrote: >> On 05/18/2016 12:58 PM, Jason Low wrote: >>> It should be fine to use the standard READ_ONCE here, even if it's just >>> for documentation, as it's probably not going to cost anything in >>> practice. It would be better to avoid adding any special macros for this >>> which may just add more complexity. >> See, I don't understand this line of reasoning at all. >> >> I read this as "it's ok to be non-optimal here where were spinning CPU >> time but not ok to be non-optimal generally elsewhere where it's >> way less important like at init time". > So I think there is a difference between using it during init time and > using it here where we're spinning. During init time, initializing the > owner field locklessly is normal. No other thread should be concurrently > be writing to the field, since the structure is just getting > initialized, so there are no surprises there. > > Our access of the owner field in this function is special in that we're > using a bit of "lockless magic" to read and write to a field that gets > concurrently accessed without any serialization. Since we're not taking > the wait_lock in a scenario where we'd normally would take a lock, it > would be good to have this documented. > >> And by the way, it's not just "here" but _everywhere_. >> What about reading ->on_cpu locklessly? > Sure, we could also use READ_ONCE when reading ->on_cpu :) > As on_cpu is just a boolean, load tearing isn't really a problem. You either see the bit 0 set or not, but not something in between (not a qbit) :-) Cheers, Longman