[PATCH v3 02/13] futex: Rename futex_pi_state to futex_state

The futex_pi_state structure will be overloaded in later patches to store state information about non-PI futexes. So the structure name itself is no longer a good description of its purpose. So its name is changed to futex_state, a more generic name. Some of the functions that process the futex

[PATCH v3 05/13] futex: Add a new futex type field into futex_state

As the futex_state structure will be overloaded in later patches to be used by non-PI futexes, it is necessary to add a type field to distinguish among different types of futexes. Signed-off-by: Waiman Long --- kernel/futex.c | 14 ++ 1 files changed, 10

[PATCH v3 09/13] futex: Implement lock handoff for TP futexes to prevent lock starvation

The current TP futexes has no guarantee that the top waiter (serialization mutex owner) can get the lock within a finite time. As a result, lock starvation can happen. A lock handoff mechanism is added to the TP futexes to prevent lock starvation from happening. The idea is that the top waiter

[PATCH v3 08/13] futex: Enable robust handling of TP futexes

The TP futexes don't have code to handle the death of futex owners. There are 2 different cases that need to be considered. As top waiter gets a reference to the task structure of the futex owner, the task structure will never go away even if the owner dies. When the futex owner died while the

[PATCH v3 04/13] futex: Consolidate pure pi_state_list add & delete codes to helpers

Two new helper functions (task_pi_list_add & task_pi_list_del) are created to consolidate all the pure pi_state_list addition and insertion codes. The set_owner argument in task_pi_list_add() will be needed in a later patch. Signed-off-by: Waiman Long --- kernel/futex.c |

[PATCH v3 03/13] futex: Add helpers to get & cmpxchg futex value without lock

Two new helper functions cmpxchg_futex_value() and get_futex_value() are added to access and change the futex value without the hash bucket lock. As a result, page fault is enabled and the page will be faulted in if not present yet. Signed-off-by: Waiman Long ---

[PATCH v3 10/13] futex: Inform FUTEX_LOCK callers on how the lock is acquired

As there are three different ways for a TP futex waiter in the kernel to acquire the lock. It may be useful to pass this information out so that user space has a better view of what is happening in the kernel. With this change, different non-negative values will now be returned depending on how

[PATCH v3 00/13] futex: Introducing throughput-optimized futexes

v2->v3: - Use the abbreviation TP for the new futexes instead of TO. - Make a number of changes accordingly to review comments from ThomasG, PeterZ and MikeG. - Breaks the main futex patch into smaller pieces to make them easier to review. - Integrate the microbenchmark into the

[PATCH v3 13/13] perf bench: New microbenchmark for userspace mutex performance

This microbenchmark simulates how the use of different futex types can affect the actual performanace of userspace mutex locks. The usage is: perf bench futex mutex Three sets of simple mutex lock and unlock functions are implemented using the wait-wake, PI and TP futexes respectively.

[PATCH v3 06/13] futex: Allow direct attachment of futex_state objects to hash bucket

Currently, the futex state objects can only be located indirectly as hash bucket => futex_q => futex state Actually it can be beneficial in some cases to locate the futex state object directly from the hash bucket without the futex_q middleman. Therefore, a new list head to link the

[PATCH v3 01/13] futex: Consolidate duplicated timer setup code

A new futex_setup_timer() helper function is added to consolidate all the hrtimer_sleeper setup code. Signed-off-by: Waiman Long --- kernel/futex.c | 67 +++- 1 files changed, 37 insertions(+), 30 deletions(-) diff

Re: [PATCH 0/2] Moving runnable code from Documentation (last 2 patches)

On 09/26/2016 12:40 PM, Shuah Khan wrote: > This patch series contains the last 2 patches to complete moving runnable > code from Documentation to selftests, samples, and tools. > > The first patch moves blackfin gptimers-example to samples and removes > CONFIG_BUILD_DOCSRC. > > The second one

Re: [PATCH] doc: convert 80211 DocBook to RST

Off-commit comment: this is a line-by-line, title-by-title, section-by-section, comment-by-comment conversion of the DocBook 80211.tmpl file to RST. The 80211.tmpl file has also been deleted, and removed from the DocBook/Makefile list -- I'm not sure this should be done. I'm sure that

[PATCH] doc: convert 80211 DocBook to RST

Signed-off-by: Florian Margaine --- .../actions-and-configuration.rst | 9 + .../80211/cfg80211-subsystem/data-path-helpers.rst | 9 + .../cfg80211-subsystem/device-registration.rst | 9 + Documentation/80211/cfg80211-subsystem/index.rst | 14

Re: md/dm-crypt: Rename a jump label in crypt_message() ?

> If you continue discussing after that point, I guess that such a condition is not needed. > then you make a clear statement that it isn't an accident. I hope that most of my software development activities are not "an accident". Is the intent for any update suggestion (like the renaming of a

Re: utime accounting regression since 4.6 (was: Re: [PACTH v2 0/3] Implement /proc//totmaps)

On Fri, 2016-09-30 at 11:49 +0200, Michal Hocko wrote: > [CC Mike and Mel as they have seen some accounting oddities >  when doing performance testing. They can share details but >  essentially the system time just gets too high] > > For your reference the email thread started >

Re: md/dm-crypt: Rename a jump label in crypt_message() ?

> I don't like out labels, but that's my opinion. Thanks for this acknowledgement that you have still got a special opinion about such an identifier. > There is nothing in CodingStyle which says you can't do it. Does the terse description there try to suggest also to choose better identifiers

Re: md/dm-crypt: Rename a jump label in crypt_message() ?

SF Markus Elfring writes: >> When someone tells you that you are wasting their time, > > This information can be useful to some degree Yes. If you continue discussing after that point, then you make a clear statement that it isn't an accident. You are

Re: md/dm-crypt: Rename a jump label in crypt_message() ?

On Fri, Sep 30, 2016 at 01:32:23PM +0200, SF Markus Elfring wrote: > > I specifically did not say that "out:" or "error:" labels are bad names. > > Did you inform me once that you had also a special opinion about an identifier > like "out"? I don't like out labels, but that's my opinion. There

Re: md/dm-crypt: Rename a jump label in crypt_message() ?

> When someone tells you that you are wasting their time, This information can be useful to some degree > then that is not a subject for further discussion. I got an other impression. I guess that there are constraints for such a response which can become interesting for further

Re: md/dm-crypt: Rename a jump label in crypt_message() ?

SF Markus Elfring writes: >> go around bothering everyone with waste of time cleanup patches. > > I find it still debatable if the shown software development efforts > are really "wasted". When someone tells you that you are wasting their time, then that is not a

Re: md/dm-crypt: Rename a jump label in crypt_message() ?

> Again, I wrote the paragraph in CodingStyle. This is obvious from the corresponding commit "add some more error handling guidelines" (ea04036032edda6f771c1381d03832d2ed0f6c31 on 2014-12-02). > I just said that it's a good idea to think about label names I agree also to such a desire. >

Re: utime accounting regression since 4.6 (was: Re: [PACTH v2 0/3] Implement /proc//totmaps)

[CC Mike and Mel as they have seen some accounting oddities when doing performance testing. They can share details but essentially the system time just gets too high] For your reference the email thread started http://lkml.kernel.org/r/20160823143330.gl23...@dhcp22.suse.cz I suspect this is

Re: [PATCH v8 0/8] thunderbolt: Introducing Thunderbolt(TM) Networking

On Fri, Sep 30, 2016 at 08:37:36AM +, Levy, Amir (Jer) wrote: > On Fri, Sep 30 2016, 09:40 AM, David Miller wrote: > > From: Greg KH > > Date: Fri, 30 Sep 2016 08:30:05 +0200 > > > > > On Fri, Sep 30, 2016 at 01:55:55AM -0400, David Miller wrote: > > >> From: Amir

RE: [PATCH v8 0/8] thunderbolt: Introducing Thunderbolt(TM) Networking

On Fri, Sep 30 2016, 09:40 AM, David Miller wrote: > From: Greg KH > Date: Fri, 30 Sep 2016 08:30:05 +0200 > > > On Fri, Sep 30, 2016 at 01:55:55AM -0400, David Miller wrote: > >> From: Amir Levy > >> Date: Wed, 28 Sep 2016 17:44:22 +0300 >

Re: [PATCH v8 0/8] thunderbolt: Introducing Thunderbolt(TM) Networking

On Fri, Sep 30, 2016 at 01:55:55AM -0400, David Miller wrote: > From: Amir Levy > Date: Wed, 28 Sep 2016 17:44:22 +0300 > > > This driver enables Thunderbolt Networking on non-Apple platforms > > running Linux. > > Greg, any idea where this should get merged once fully