Investment Interest & Offer

[Seydou Thieba]

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v15 00/13] mux controller abstraction and iio/i2c muxes

[Luc Van Oostenryck]

On Sat, Jun 3, 2017 at 11:29 PM, Peter Rosin  wrote:
> On 2017-06-03 22:26, Luc Van Oostenryck wrote:
>> On Sat, Jun 3, 2017 at 9:34 PM, Greg Kroah-Hartman
>>  wrote:
>>> On Sat, Jun 03, 2017 at 08:37:21PM +0200, Luc Van Oostenryck wrote:
 On Sat, Jun 3, 2017 at 12:26 PM, Greg Kroah-Hartman
  wrote:
> On Sun, May 14, 2017 at 09:51:03PM +0200, Peter Rosin wrote:
>> From: Peter Rosin 
>>
>> Hi Greg,
>>
>> Philipp found problems in v14 with using a mutex for locking that was
>> the outcome of the review for v13, so I'm now using a semaphore instead
>> of the rwsem that was in v13. That at least got rid of the scary call
>> to downgrade_write. However, I'm still unsure about what you actually
>> meant with your comment about lack of sparse markings [1]. I did add
>> __must_check to the funcs that selects the mux, but I've got this
>> feeling that this is not what you meant?
>
> I thought there was a way to mark a function as requiring a lock be held
> when it is being called.  Does sparse not support that anymore?

 sparse still support these annotations, of course.
 In this case, I suppose you're talking about '__must_hold()' which
 *must* be used instead of a pair of '__releases()' + '__acquires()'
 when the lock is help on function entry and exit.
>>>
>>> Ah, yes, that's what I was thinking of.  I don't know if sparse can
>>> track things like this across an exported symbol, so I doubt it really
>>> will help here.  Sorry for the noise.
>>
>> No problem, I'm glad to help for sparse related things.
>>
>> I didn't saw the code in question because the lkml.org link Peter
>> gave didn't work for me and I don't know much about exported symbols
>> (but I think the sole effect is to add some data in some symbol table).
>> But these annotations just work based on the declarations, very much
>> like type checking. So if you have something in scope like the following:
>>
>> void do_stuff_locked(struct s *ptr) __must_hold(*ptr);
>>
>> ...
>>
>> void do_stuff_unlocked(struct s *ptr)
>> {
>> ...
>> do_stuff_locked(ptr);// will warn
>> ...
>> }
>>
>> You will have a warning from sparse unless the code preceding and following
>> the call to do_stuff_locked() lock & then unlock 'ptr', generaly
>> indirectly by a pair
>> of functions, the one before with an '__acquires()' in its declaration
>> the one after
>> with a '__releases()' in its declaration:
>>
>> void lock_stuff(struct s *ptr) __acquires(*ptr);
>> void unlock_stuff(struct s *ptr) __releases(*ptr);
>>
>> void do_stuff_unlocked(struct s *ptr)
>> {
>> lock_stuff(ptr);
>> do_stuff_locked(ptr);// won't warn
>> unlock_stuff(ptr);
>> }
>
> Ok, thanks for the explanation! The above was what I gathered when I
> looked around, and since it didn't really fit the usage pattern of the
> mux api I was stomped. When comparing the mux code with the above,
> mux_control_select would be an __acquires (albeit a conditional one,
> but let's not muddy the waters unnecessarily) and mux_control_deselect
> would be a __releases.
>
> But for long time mux consumers, like the video mux, it must be OK to
> only acquire the mux, and not release it right away in the same context,
> which I assume will be very hard for sparse to handle sanely? E.g. I
> think sparse also complains if there are unbalanced __acquires and
> __releases in some context, no?

Yes, there are some limitations.

You can do conditional locks, it's what spin_trylock() and
{read,write}_trylock()
do. something like the following will be OK:

void do_stuff_unlocked(struct s *ptr)
{
 if (trylock_stuff(ptr)) {
  do_stuff_locked(ptr);// won't warn
  unlock_stuff(ptr);
 }
}

sparse won't complain because everything is correct within each block.
But something that sparse will complain about would be:

void foobar(struct s *ptr)
{
 if (some condition)
  lock_stuff(ptr);
   // will warn
 ... some code ...

 if (same condition) {
  do_stuff_locked(ptr);
  unlock_stuff(ptr);
 }
}

While correct from the point of view of locking, sparse won't be able
to take into account
that indeed, the two ifs are fro the same condition. sparse will only
see that after the first
if there will be one path where the lock will be held and another one
where it won't and
will this issue a 'different lock contexts for basic block' warning.

For this mux code, for example, the function mux_control_select() will
have a problem
because depending on the return value of __mux_control_select() you will want to
take back the lock or not, so the exit state of this function is not
well defined regarding
locking. It's the same for 

Re: [PATCH v15 00/13] mux controller abstraction and iio/i2c muxes

[Peter Rosin]

On 2017-06-03 12:31, Greg Kroah-Hartman wrote:
> On Sat, Jun 03, 2017 at 07:26:27PM +0900, Greg Kroah-Hartman wrote:
>> On Sun, May 14, 2017 at 09:51:03PM +0200, Peter Rosin wrote:
>>> From: Peter Rosin 
>>>
>>> Hi Greg,
>>>
>>> Philipp found problems in v14 with using a mutex for locking that was
>>> the outcome of the review for v13, so I'm now using a semaphore instead
>>> of the rwsem that was in v13. That at least got rid of the scary call
>>> to downgrade_write. However, I'm still unsure about what you actually
>>> meant with your comment about lack of sparse markings [1]. I did add
>>> __must_check to the funcs that selects the mux, but I've got this
>>> feeling that this is not what you meant?
>>
>> I thought there was a way to mark a function as requiring a lock be held
>> when it is being called.  Does sparse not support that anymore?
> 
> Anyway, not a big deal.  I still worry about the calls blocking when
> people are not expecting them to, but it is just the nature of th api I
> guess.

Yeah, first come first serve. I don't know what else I can do, except maybe
follow up with a timed version of mux_control_select()...

> All now queued up, nice work, thanks for sticking with this.

*big sigh of relief*

I was getting pretty fed up with the series to be honest :-), so thanks
a bunch for taking it!

Cheers,
peda

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v15 00/13] mux controller abstraction and iio/i2c muxes

[Peter Rosin]

On 2017-06-03 22:26, Luc Van Oostenryck wrote:
> On Sat, Jun 3, 2017 at 9:34 PM, Greg Kroah-Hartman
>  wrote:
>> On Sat, Jun 03, 2017 at 08:37:21PM +0200, Luc Van Oostenryck wrote:
>>> On Sat, Jun 3, 2017 at 12:26 PM, Greg Kroah-Hartman
>>>  wrote:
 On Sun, May 14, 2017 at 09:51:03PM +0200, Peter Rosin wrote:
> From: Peter Rosin 
>
> Hi Greg,
>
> Philipp found problems in v14 with using a mutex for locking that was
> the outcome of the review for v13, so I'm now using a semaphore instead
> of the rwsem that was in v13. That at least got rid of the scary call
> to downgrade_write. However, I'm still unsure about what you actually
> meant with your comment about lack of sparse markings [1]. I did add
> __must_check to the funcs that selects the mux, but I've got this
> feeling that this is not what you meant?

 I thought there was a way to mark a function as requiring a lock be held
 when it is being called.  Does sparse not support that anymore?
>>>
>>> sparse still support these annotations, of course.
>>> In this case, I suppose you're talking about '__must_hold()' which
>>> *must* be used instead of a pair of '__releases()' + '__acquires()'
>>> when the lock is help on function entry and exit.
>>
>> Ah, yes, that's what I was thinking of.  I don't know if sparse can
>> track things like this across an exported symbol, so I doubt it really
>> will help here.  Sorry for the noise.
> 
> No problem, I'm glad to help for sparse related things.
> 
> I didn't saw the code in question because the lkml.org link Peter
> gave didn't work for me and I don't know much about exported symbols
> (but I think the sole effect is to add some data in some symbol table).
> But these annotations just work based on the declarations, very much
> like type checking. So if you have something in scope like the following:
> 
> void do_stuff_locked(struct s *ptr) __must_hold(*ptr);
> 
> ...
> 
> void do_stuff_unlocked(struct s *ptr)
> {
> ...
> do_stuff_locked(ptr);// will warn
> ...
> }
> 
> You will have a warning from sparse unless the code preceding and following
> the call to do_stuff_locked() lock & then unlock 'ptr', generaly
> indirectly by a pair
> of functions, the one before with an '__acquires()' in its declaration
> the one after
> with a '__releases()' in its declaration:
> 
> void lock_stuff(struct s *ptr) __acquires(*ptr);
> void unlock_stuff(struct s *ptr) __releases(*ptr);
> 
> void do_stuff_unlocked(struct s *ptr)
> {
> lock_stuff(ptr);
> do_stuff_locked(ptr);// won't warn
> unlock_stuff(ptr);
> }

Ok, thanks for the explanation! The above was what I gathered when I
looked around, and since it didn't really fit the usage pattern of the
mux api I was stomped. When comparing the mux code with the above,
mux_control_select would be an __acquires (albeit a conditional one,
but let's not muddy the waters unnecessarily) and mux_control_deselect
would be a __releases.

But for long time mux consumers, like the video mux, it must be OK to
only acquire the mux, and not release it right away in the same context,
which I assume will be very hard for sparse to handle sanely? E.g. I
think sparse also complains if there are unbalanced __acquires and
__releases in some context, no?

Cheers,
peda

BTW, the core mux code is at the below link if the lkml link continues
to fail:
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/commit/?h=char-misc-testing=a3b02a9c6591ce154cd44e2383406390a45b530c
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v15 00/13] mux controller abstraction and iio/i2c muxes

[Luc Van Oostenryck]

On Sat, Jun 3, 2017 at 9:34 PM, Greg Kroah-Hartman
 wrote:
> On Sat, Jun 03, 2017 at 08:37:21PM +0200, Luc Van Oostenryck wrote:
>> On Sat, Jun 3, 2017 at 12:26 PM, Greg Kroah-Hartman
>>  wrote:
>> > On Sun, May 14, 2017 at 09:51:03PM +0200, Peter Rosin wrote:
>> >> From: Peter Rosin 
>> >>
>> >> Hi Greg,
>> >>
>> >> Philipp found problems in v14 with using a mutex for locking that was
>> >> the outcome of the review for v13, so I'm now using a semaphore instead
>> >> of the rwsem that was in v13. That at least got rid of the scary call
>> >> to downgrade_write. However, I'm still unsure about what you actually
>> >> meant with your comment about lack of sparse markings [1]. I did add
>> >> __must_check to the funcs that selects the mux, but I've got this
>> >> feeling that this is not what you meant?
>> >
>> > I thought there was a way to mark a function as requiring a lock be held
>> > when it is being called.  Does sparse not support that anymore?
>>
>> sparse still support these annotations, of course.
>> In this case, I suppose you're talking about '__must_hold()' which
>> *must* be used instead of a pair of '__releases()' + '__acquires()'
>> when the lock is help on function entry and exit.
>
> Ah, yes, that's what I was thinking of.  I don't know if sparse can
> track things like this across an exported symbol, so I doubt it really
> will help here.  Sorry for the noise.

No problem, I'm glad to help for sparse related things.

I didn't saw the code in question because the lkml.org link Peter
gave didn't work for me and I don't know much about exported symbols
(but I think the sole effect is to add some data in some symbol table).
But these annotations just work based on the declarations, very much
like type checking. So if you have something in scope like the following:

void do_stuff_locked(struct s *ptr) __must_hold(*ptr);

...

void do_stuff_unlocked(struct s *ptr)
{
...
do_stuff_locked(ptr);// will warn
...
}

You will have a warning from sparse unless the code preceding and following
the call to do_stuff_locked() lock & then unlock 'ptr', generaly
indirectly by a pair
of functions, the one before with an '__acquires()' in its declaration
the one after
with a '__releases()' in its declaration:

void lock_stuff(struct s *ptr) __acquires(*ptr);
void unlock_stuff(struct s *ptr) __releases(*ptr);

void do_stuff_unlocked(struct s *ptr)
{
lock_stuff(ptr);
do_stuff_locked(ptr);// won't warn
unlock_stuff(ptr);
}


Regards,
-- Luc
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v15 00/13] mux controller abstraction and iio/i2c muxes

[Greg Kroah-Hartman]

On Sat, Jun 03, 2017 at 08:37:21PM +0200, Luc Van Oostenryck wrote:
> On Sat, Jun 3, 2017 at 12:26 PM, Greg Kroah-Hartman
>  wrote:
> > On Sun, May 14, 2017 at 09:51:03PM +0200, Peter Rosin wrote:
> >> From: Peter Rosin 
> >>
> >> Hi Greg,
> >>
> >> Philipp found problems in v14 with using a mutex for locking that was
> >> the outcome of the review for v13, so I'm now using a semaphore instead
> >> of the rwsem that was in v13. That at least got rid of the scary call
> >> to downgrade_write. However, I'm still unsure about what you actually
> >> meant with your comment about lack of sparse markings [1]. I did add
> >> __must_check to the funcs that selects the mux, but I've got this
> >> feeling that this is not what you meant?
> >
> > I thought there was a way to mark a function as requiring a lock be held
> > when it is being called.  Does sparse not support that anymore?
> 
> sparse still support these annotations, of course.
> In this case, I suppose you're talking about '__must_hold()' which
> *must* be used instead of a pair of '__releases()' + '__acquires()'
> when the lock is help on function entry and exit.

Ah, yes, that's what I was thinking of.  I don't know if sparse can
track things like this across an exported symbol, so I doubt it really
will help here.  Sorry for the noise.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v15 00/13] mux controller abstraction and iio/i2c muxes

[Luc Van Oostenryck]

On Sat, Jun 3, 2017 at 12:26 PM, Greg Kroah-Hartman
 wrote:
> On Sun, May 14, 2017 at 09:51:03PM +0200, Peter Rosin wrote:
>> From: Peter Rosin 
>>
>> Hi Greg,
>>
>> Philipp found problems in v14 with using a mutex for locking that was
>> the outcome of the review for v13, so I'm now using a semaphore instead
>> of the rwsem that was in v13. That at least got rid of the scary call
>> to downgrade_write. However, I'm still unsure about what you actually
>> meant with your comment about lack of sparse markings [1]. I did add
>> __must_check to the funcs that selects the mux, but I've got this
>> feeling that this is not what you meant?
>
> I thought there was a way to mark a function as requiring a lock be held
> when it is being called.  Does sparse not support that anymore?

sparse still support these annotations, of course.
In this case, I suppose you're talking about '__must_hold()' which
*must* be used instead of a pair of '__releases()' + '__acquires()'
when the lock is help on function entry and exit.

Cheers,
-- Luc Van Oostenryck
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v15 00/13] mux controller abstraction and iio/i2c muxes

[Greg Kroah-Hartman]

On Sat, Jun 03, 2017 at 07:26:27PM +0900, Greg Kroah-Hartman wrote:
> On Sun, May 14, 2017 at 09:51:03PM +0200, Peter Rosin wrote:
> > From: Peter Rosin 
> > 
> > Hi Greg,
> > 
> > Philipp found problems in v14 with using a mutex for locking that was
> > the outcome of the review for v13, so I'm now using a semaphore instead
> > of the rwsem that was in v13. That at least got rid of the scary call
> > to downgrade_write. However, I'm still unsure about what you actually
> > meant with your comment about lack of sparse markings [1]. I did add
> > __must_check to the funcs that selects the mux, but I've got this
> > feeling that this is not what you meant?
> 
> I thought there was a way to mark a function as requiring a lock be held
> when it is being called.  Does sparse not support that anymore?

Anyway, not a big deal.  I still worry about the calls blocking when
people are not expecting them to, but it is just the nature of th api I
guess.

All now queued up, nice work, thanks for sticking with this.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v15 00/13] mux controller abstraction and iio/i2c muxes

[Greg Kroah-Hartman]

On Sun, May 14, 2017 at 09:51:03PM +0200, Peter Rosin wrote:
> From: Peter Rosin 
> 
> Hi Greg,
> 
> Philipp found problems in v14 with using a mutex for locking that was
> the outcome of the review for v13, so I'm now using a semaphore instead
> of the rwsem that was in v13. That at least got rid of the scary call
> to downgrade_write. However, I'm still unsure about what you actually
> meant with your comment about lack of sparse markings [1]. I did add
> __must_check to the funcs that selects the mux, but I've got this
> feeling that this is not what you meant?

I thought there was a way to mark a function as requiring a lock be held
when it is being called.  Does sparse not support that anymore?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] net: Update TCP congestion control documentation

[Anmol Sarma]

Update tcp.txt to fix mandatory congestion control ops and default
CCA selection. Also, fix comment in tcp.h for undo_cwnd.

Signed-off-by: Anmol Sarma 
---
 Documentation/networking/tcp.txt | 31 +--
 include/net/tcp.h|  2 +-
 2 files changed, 14 insertions(+), 19 deletions(-)

diff --git a/Documentation/networking/tcp.txt b/Documentation/networking/tcp.txt
index bdc4c0d..9c7139d 100644
--- a/Documentation/networking/tcp.txt
+++ b/Documentation/networking/tcp.txt
@@ -1,7 +1,7 @@
 TCP protocol
 
 
-Last updated: 9 February 2008
+Last updated: 3 June 2017
 
 Contents
 
@@ -29,18 +29,19 @@ As of 2.6.13, Linux supports pluggable congestion control 
algorithms.
 A congestion control mechanism can be registered through functions in
 tcp_cong.c. The functions used by the congestion control mechanism are
 registered via passing a tcp_congestion_ops struct to
-tcp_register_congestion_control. As a minimum name, ssthresh,
-cong_avoid must be valid.
+tcp_register_congestion_control. As a minimum, the congestion control
+mechanism must provide a valid name and must implement either ssthresh,
+cong_avoid and undo_cwnd hooks or the "omnipotent" cong_control hook.
 
 Private data for a congestion control mechanism is stored in tp->ca_priv.
 tcp_ca(tp) returns a pointer to this space.  This is preallocated space - it
 is important to check the size of your private data will fit this space, or
-alternatively space could be allocated elsewhere and a pointer to it could
+alternatively, space could be allocated elsewhere and a pointer to it could
 be stored here.
 
 There are three kinds of congestion control algorithms currently: The
 simplest ones are derived from TCP reno (highspeed, scalable) and just
-provide an alternative the congestion window calculation. More complex
+provide an alternative congestion window calculation. More complex
 ones like BIC try to look at other events to provide better
 heuristics.  There are also round trip time based algorithms like
 Vegas and Westwood+.
@@ -49,21 +50,15 @@ Good TCP congestion control is a complex problem because 
the algorithm
 needs to maintain fairness and performance. Please review current
 research and RFC's before developing new modules.
 
-The method that is used to determine which congestion control mechanism is
-determined by the setting of the sysctl net.ipv4.tcp_congestion_control.
-The default congestion control will be the last one registered (LIFO);
-so if you built everything as modules, the default will be reno. If you
-build with the defaults from Kconfig, then CUBIC will be builtin (not a
-module) and it will end up the default.
+The default congestion control mechanism is chosen based on the
+DEFAULT_TCP_CONG Kconfig parameter. If you really want a particular default
+value then you can set it using sysctl net.ipv4.tcp_congestion_control. The
+module will be autoloaded if needed and you will get the expected protocol. If
+you ask for an unknown congestion method, then the sysctl attempt will fail.
 
-If you really want a particular default value then you will need
-to set it with the sysctl.  If you use a sysctl, the module will be autoloaded
-if needed and you will get the expected protocol. If you ask for an
-unknown congestion method, then the sysctl attempt will fail.
-
-If you remove a tcp congestion control module, then you will get the next
+If you remove a TCP congestion control module, then you will get the next
 available one. Since reno cannot be built as a module, and cannot be
-deleted, it will always be available.
+removed, it will always be available.
 
 How the new TCP output machine [nyi] works.
 ===
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 82462db..28b577a 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -969,7 +969,7 @@ struct tcp_congestion_ops {
void (*cwnd_event)(struct sock *sk, enum tcp_ca_event ev);
/* call when ack arrives (optional) */
void (*in_ack_event)(struct sock *sk, u32 flags);
-   /* new value of cwnd after loss (optional) */
+   /* new value of cwnd after loss (required) */
u32  (*undo_cwnd)(struct sock *sk);
/* hook for packet ack accounting (optional) */
void (*pkts_acked)(struct sock *sk, const struct ack_sample *sample);
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 7/7] Documentation/dev-tools: Add kselftest_harness documentation

[Mickaël Salaün]

On 02/06/2017 22:02, Shuah Khan wrote:
> Hi Mickaël,
> 
> On 05/26/2017 12:44 PM, Mickaël Salaün wrote:
>> Add ReST metadata to kselftest_harness.h to be able to include the
>> comments in the Sphinx documentation.
>>
> 
> These don't belong the change log. These types of changes are for
> reviewers benefit and should be added between the sign-of block
> and the start of diff.

OK, I didn't know this rule, which seems different from one maintainer
to another. I'll take this into account the next time.

> 
> I had to fix a few patches in this series before commit.
> 
>> Changes since v4:
>> * exclude the TEST_API() changes (requested by Kees Cook)
>>
>> Changes since v3:
>> * document macros as actual functions (suggested by Jonathan Corbet)
>> * remove the TEST_API() wrapper to expose the underlying macro arguments
>>   to the documentation tools
>> * move and cleanup comments
>>
>> Changes since v2:
>> * add reference to the full documentation in the header file (suggested
>>   by Kees Cook)
> 
>>
>> Signed-off-by: Mickaël Salaün 
>> Cc: Andy Lutomirski 
>> Cc: Jonathan Corbet 
>> Cc: Kees Cook 
>> Cc: Shuah Khan 
>> Cc: Will Drewry 
> 
> git am isn't happy:
> 
> Applying: Documentation/dev-tools: Add kselftest_harness documentation
> .git/rebase-apply/patch:47: new blank line at EOF.
> +
> warning: 1 line adds whitespace errors.
> 
> Please fix and resend.

I didn't try to apply the series with "git am" since neither "git
format-patch" nor scripts/checkpatch.pl output a warning.

This "git am" warning is about the last line of the ReST file which end
with an empty line. I will fix it if needed.

> 
> -- Shuah
> 
>> ---
>>  Documentation/dev-tools/kselftest.rst   |  34 +++
>>  tools/testing/selftests/kselftest_harness.h | 415 
>> ++--
>>  2 files changed, 364 insertions(+), 85 deletions(-)
>>
>> diff --git a/Documentation/dev-tools/kselftest.rst 
>> b/Documentation/dev-tools/kselftest.rst
>> index 9232ce94612c..a92fa181b6cf 100644
>> --- a/Documentation/dev-tools/kselftest.rst
>> +++ b/Documentation/dev-tools/kselftest.rst
>> @@ -120,3 +120,37 @@ Contributing new tests (details)
>> executable which is not tested by default.
>> TEST_FILES, TEST_GEN_FILES mean it is the file which is used by
>> test.
>> +
>> +Test Harness
>> +
>> +
>> +The kselftest_harness.h file contains useful helpers to build tests.  The 
>> tests
>> +from tools/testing/selftests/seccomp/seccomp_bpf.c can be used as example.
>> +
>> +Example
>> +---
>> +
>> +.. kernel-doc:: tools/testing/selftests/kselftest_harness.h
>> +:doc: example
>> +
>> +
>> +Helpers
>> +---
>> +
>> +.. kernel-doc:: tools/testing/selftests/kselftest_harness.h
>> +:functions: TH_LOG TEST TEST_SIGNAL FIXTURE FIXTURE_DATA FIXTURE_SETUP
>> +FIXTURE_TEARDOWN TEST_F TEST_HARNESS_MAIN
>> +
>> +Operators
>> +-
>> +
>> +.. kernel-doc:: tools/testing/selftests/kselftest_harness.h
>> +:doc: operators
>> +
>> +.. kernel-doc:: tools/testing/selftests/kselftest_harness.h
>> +:functions: ASSERT_EQ ASSERT_NE ASSERT_LT ASSERT_LE ASSERT_GT ASSERT_GE
>> +ASSERT_NULL ASSERT_TRUE ASSERT_NULL ASSERT_TRUE ASSERT_FALSE
>> +ASSERT_STREQ ASSERT_STRNE EXPECT_EQ EXPECT_NE EXPECT_LT
>> +EXPECT_LE EXPECT_GT EXPECT_GE EXPECT_NULL EXPECT_TRUE
>> +EXPECT_FALSE EXPECT_STREQ EXPECT_STRNE
>> +
>> diff --git a/tools/testing/selftests/kselftest_harness.h 
>> b/tools/testing/selftests/kselftest_harness.h
>> index 45f807ce37e1..c56f72e07cd7 100644
>> --- a/tools/testing/selftests/kselftest_harness.h
>> +++ b/tools/testing/selftests/kselftest_harness.h
>> @@ -4,41 +4,49 @@
>>   *
>>   * kselftest_harness.h: simple C unit test helper.
>>   *
>> - * Usage:
>> - *   #include "../kselftest_harness.h"
>> - *   TEST(standalone_test) {
>> - * do_some_stuff;
>> - * EXPECT_GT(10, stuff) {
>> - *stuff_state_t state;
>> - *enumerate_stuff_state();
>> - *TH_LOG("expectation failed with state: %s", state.msg);
>> - * }
>> - * more_stuff;
>> - * ASSERT_NE(some_stuff, NULL) TH_LOG("how did it happen?!");
>> - * last_stuff;
>> - * EXPECT_EQ(0, last_stuff);
>> - *   }
>> - *
>> - *   FIXTURE(my_fixture) {
>> - * mytype_t *data;
>> - * int awesomeness_level;
>> - *   };
>> - *   FIXTURE_SETUP(my_fixture) {
>> - * self->data = mytype_new();
>> - * ASSERT_NE(NULL, self->data);
>> - *   }
>> - *   FIXTURE_TEARDOWN(my_fixture) {
>> - * mytype_free(self->data);
>> - *   }
>> - *   TEST_F(my_fixture, data_is_good) {
>> - * EXPECT_EQ(1, is_my_data_good(self->data));
>> - *   }
>> - *
>> - *   TEST_HARNESS_MAIN
>> + * See documentation in Documentation/dev-tools/kselftest.rst
>>   *
>>   * API inspired by code.google.com/p/googletest
>>   */
>>  
>> +/**
>> + * DOC: example
>> + 

Re: [PATCH v5 3/7] selftests/seccomp: Force rebuild according to dependencies

[Mickaël Salaün]

Hi Shuah,

On 02/06/2017 21:31, Shuah Khan wrote:
> Hi Mickaël,
> 
> On 05/26/2017 12:43 PM, Mickaël Salaün wrote:
>> Rebuild the seccomp tests when kselftest_harness.h is updated.
>>
>> Signed-off-by: Mickaël Salaün 
>> Acked-by: Kees Cook 
>> Cc: Andy Lutomirski 
>> Cc: Shuah Khan 
>> Cc: Will Drewry 
>> ---
>>  tools/testing/selftests/seccomp/Makefile | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/tools/testing/selftests/seccomp/Makefile 
>> b/tools/testing/selftests/seccomp/Makefile
>> index 5fa6fd2246b1..aeb0c805f3ca 100644
>> --- a/tools/testing/selftests/seccomp/Makefile
>> +++ b/tools/testing/selftests/seccomp/Makefile
>> @@ -4,3 +4,5 @@ LDFLAGS += -lpthread
>>  
>>  include ../lib.mk
>>  
>> +$(TEST_GEN_PROGS): seccomp_bpf.c ../kselftest_harness.h
>> +$(CC) $(CFLAGS) $(LDFLAGS) $< -o $@
>>
> 
> This change breaks seccomp build:
> 
> make -C tools/testing/selftests/seccomp/
> make: Entering directory 
> '/mnt/data/lkml/linux_4.12/tools/testing/selftests/seccomp'
> make: *** No rule to make target '../kselftest_harness.h', needed by 
> '/mnt/data/lkml/linux_4.12/tools/testing/selftests/seccomp/seccomp_bpf'.  
> Stop.
> make: Leaving directory 
> '/mnt/data/lkml/linux_4.12/tools/testing/selftests/seccomp'
> shuah@mazurka:/mnt/data/lkml/linux_4.12$ cd tools/testing/selftests/seccomp/
> shuah@mazurka:/mnt/data/lkml/linux_4.12/tools/testing/selftests/seccomp$ make
> make: *** No rule to make target '../kselftest_harness.h', needed by 
> '/mnt/data/lkml/linux_4.12/tools/testing/selftests/seccomp/seccomp_bpf'.  
> Stop.
> 
> 
> Did you happen to try building with this change?

Yes I did, and it builds fine for me (with the same command and
patches). There is only one warning from GCC with
../kselftest_harness.h:368 because of the trick from OPTIONAL_HANDLER(),
which is intentional (and not modified by my patches).

I don't get why your "make" said that there is "No rule to make target"
../kselftest_harness.h . This file exists (patch 1/7) so there is no
need to create it…
gen_kselftest_tar.sh works fine too.

Thanks,
 Mickaël



signature.asc
Description: OpenPGP digital signature

Re: [RFC PATCH v2 11/17] cgroup: Implement new thread mode semantics

[Tejun Heo]

Hello,

On Fri, Jun 02, 2017 at 04:36:22PM -0400, Waiman Long wrote:
> I wouldn't argue further on that if you insist. However, I still want to

Oh, please don't get me wrong.  I'm not trying to shut down the
discussion or anything.  It's just that whole-scope discussions can
get very meandering and time-consuming when these two issues can be
decoupled from each other without compromising on either.  Let's
approach these issues separately.

> relax the constraint somewhat by abandoning the no internal process
> constraint  when only threaded controllers (non-resource domains) are
> enabled even when thread mode has not been explicitly enabled. It is a
> modified version my second alternative. Now the question is which
> controllers are considered to be resource domains. I think memory and
> blkio are in the list. What else do you think should be considered
> resource domains?

And we're now a bit into repeating ourselves but for controlling of
any significant resources (mostly cpu, memory, io), there gotta be
significant portion of resource consumption which isn't tied to
spcific processes or threads that should be accounted for.  Both
memory and io already do this to a certain extent, but not completely.
cpu doesn't do it at all yet but we usually can't / shouldn't declare
a resource category to be domain-free.

There are exceptions - controllers which are only used for membership
identification (perf and the old net controllers), pids which is
explicitly tied to tasks (note that CPU cycles aren't), cpuset which
is an attribute propagating / restricting controller.

Out of those, the identification uses already aren't affected by the
constraint as they're now all either direct membership test against
the hierarchy or implicit controllers which aren't subject to the
constraint.  That leaves pids and cpuset.  We can exempt them from the
constraint but I'm not quite sure what that buys us given that neither
is affected by requiring explicit leaf nodes.  It'd just make the
rules more complicated without actual benefits.

That said, we can exempt those two.  I don't see much point in it but
we can definitely discuss the pros and cons, and it's likely that it's
not gonna make much difference wichever way we choose.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html