View Bazaar branches
Get this repository:
git clone https://git.launchpad.net/lttng-modules

Import details

Import Status: Reviewed

This repository is an import of the Git repository at https://git.lttng.org/lttng-modules.git.

The next import is scheduled to run .

Last successful import was .

Import started on juju-1e3bde-prod-lp-code-import-12 and finished taking 25 seconds — see the log
Import started on juju-1e3bde-prod-lp-code-import-15 and finished taking 40 seconds — see the log
Import started on juju-1e3bde-prod-lp-code-import-14 and finished taking 15 seconds — see the log
Import started on juju-1e3bde-prod-lp-code-import-12 and finished taking 15 seconds — see the log
Import started on juju-1e3bde-prod-lp-code-import-15 and finished taking 15 seconds — see the log
Import started on juju-1e3bde-prod-lp-code-import-12 and finished taking 15 seconds — see the log
Import started on juju-1e3bde-prod-lp-code-import-15 and finished taking 15 seconds — see the log
Import started on juju-1e3bde-prod-lp-code-import-15 and finished taking 25 seconds — see the log
Import started on juju-1e3bde-prod-lp-code-import-14 and finished taking 15 seconds — see the log
Import started on juju-1e3bde-prod-lp-code-import-15 and finished taking 15 seconds — see the log

Branches

Name Last Modified Last Commit
stable-2.12 2021-09-14 18:38:21 UTC
fix: Revert "Makefile: Enable -Wimplicit-fallthrough for Clang" (v5.15)

Author: Michael Jeanson
Author Date: 2021-09-13 18:16:22 UTC

fix: Revert "Makefile: Enable -Wimplicit-fallthrough for Clang" (v5.15)

Starting with v5.15, "-Wimplicit-fallthrough=5" was added to the build
flags which requires the use of "__attribute__((__fallthrough__))" to
annotate fallthrough case statements.

See upstream commit by the man himself:

  commit d936eb23874433caa3e3d841cfa16f5434b85dcf
  Author: Linus Torvalds <torvalds@linux-foundation.org>
  Date: Thu Jul 15 18:05:31 2021 -0700

    Revert "Makefile: Enable -Wimplicit-fallthrough for Clang"

    This reverts commit b7eb335e26a9c7f258c96b3962c283c379d3ede0.

    It turns out that the problem with the clang -Wimplicit-fallthrough
    warning is not about the kernel source code, but about clang itself, and
    that the warning is unusable until clang fixes its broken ways.

    In particular, when you enable this warning for clang, you not only get
    warnings about implicit fallthroughs. You also get this:

       warning: fallthrough annotation in unreachable code [-Wimplicit-fallthrough]

    which is completely broken becasue it

     (a) doesn't even tell you where the problem is (seriously: no line
         numbers, no filename, no nothing).

     (b) is fundamentally broken anyway, because there are perfectly valid
         reasons to have a fallthrough statement even if it turns out that
         it can perhaps not be reached.

    In the kernel, an example of that second case is code in the scheduler:

                    switch (state) {
                    case cpuset:
                            if (IS_ENABLED(CONFIG_CPUSETS)) {
                                    cpuset_cpus_allowed_fallback(p);
                                    state = possible;
                                    break;
                            }
                            fallthrough;
                    case possible:

    where if CONFIG_CPUSETS is enabled you actually never hit the
    fallthrough case at all. But that in no way makes the fallthrough
    wrong.

    So the warning is completely broken, and enabling it for clang is a very
    bad idea.

    In the meantime, we can keep the gcc option enabled, and make the gcc
    build use

        -Wimplicit-fallthrough=5

    which means that we will at least continue to require a proper
    fallthrough statement, and that gcc won't silently accept the magic
    comment versions. Because gcc does this all correctly, and while the odd
    "=5" part is kind of obscure, it's documented in [1]:

      "-Wimplicit-fallthrough=5 doesn’t recognize any comments as
       fallthrough comments, only attributes disable the warning"

    so if clang ever fixes its bad behavior we can try enabling it there again.

Change-Id: Iea69849592fb69ac04fb9bb28efcd6b8dce8ba88
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

stable-2.13 2021-09-14 17:43:31 UTC
fix: Revert "Makefile: Enable -Wimplicit-fallthrough for Clang" (v5.15)

Author: Michael Jeanson
Author Date: 2021-09-13 18:16:22 UTC

fix: Revert "Makefile: Enable -Wimplicit-fallthrough for Clang" (v5.15)

Starting with v5.15, "-Wimplicit-fallthrough=5" was added to the build
flags which requires the use of "__attribute__((__fallthrough__))" to
annotate fallthrough case statements.

See upstream commit by the man himself:

  commit d936eb23874433caa3e3d841cfa16f5434b85dcf
  Author: Linus Torvalds <torvalds@linux-foundation.org>
  Date: Thu Jul 15 18:05:31 2021 -0700

    Revert "Makefile: Enable -Wimplicit-fallthrough for Clang"

    This reverts commit b7eb335e26a9c7f258c96b3962c283c379d3ede0.

    It turns out that the problem with the clang -Wimplicit-fallthrough
    warning is not about the kernel source code, but about clang itself, and
    that the warning is unusable until clang fixes its broken ways.

    In particular, when you enable this warning for clang, you not only get
    warnings about implicit fallthroughs. You also get this:

       warning: fallthrough annotation in unreachable code [-Wimplicit-fallthrough]

    which is completely broken becasue it

     (a) doesn't even tell you where the problem is (seriously: no line
         numbers, no filename, no nothing).

     (b) is fundamentally broken anyway, because there are perfectly valid
         reasons to have a fallthrough statement even if it turns out that
         it can perhaps not be reached.

    In the kernel, an example of that second case is code in the scheduler:

                    switch (state) {
                    case cpuset:
                            if (IS_ENABLED(CONFIG_CPUSETS)) {
                                    cpuset_cpus_allowed_fallback(p);
                                    state = possible;
                                    break;
                            }
                            fallthrough;
                    case possible:

    where if CONFIG_CPUSETS is enabled you actually never hit the
    fallthrough case at all. But that in no way makes the fallthrough
    wrong.

    So the warning is completely broken, and enabling it for clang is a very
    bad idea.

    In the meantime, we can keep the gcc option enabled, and make the gcc
    build use

        -Wimplicit-fallthrough=5

    which means that we will at least continue to require a proper
    fallthrough statement, and that gcc won't silently accept the magic
    comment versions. Because gcc does this all correctly, and while the odd
    "=5" part is kind of obscure, it's documented in [1]:

      "-Wimplicit-fallthrough=5 doesn’t recognize any comments as
       fallthrough comments, only attributes disable the warning"

    so if clang ever fixes its bad behavior we can try enabling it there again.

Change-Id: Iea69849592fb69ac04fb9bb28efcd6b8dce8ba88
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

master 2021-09-14 17:42:00 UTC
fix: Revert "Makefile: Enable -Wimplicit-fallthrough for Clang" (v5.15)

Author: Michael Jeanson
Author Date: 2021-09-13 18:16:22 UTC

fix: Revert "Makefile: Enable -Wimplicit-fallthrough for Clang" (v5.15)

Starting with v5.15, "-Wimplicit-fallthrough=5" was added to the build
flags which requires the use of "__attribute__((__fallthrough__))" to
annotate fallthrough case statements.

See upstream commit by the man himself:

  commit d936eb23874433caa3e3d841cfa16f5434b85dcf
  Author: Linus Torvalds <torvalds@linux-foundation.org>
  Date: Thu Jul 15 18:05:31 2021 -0700

    Revert "Makefile: Enable -Wimplicit-fallthrough for Clang"

    This reverts commit b7eb335e26a9c7f258c96b3962c283c379d3ede0.

    It turns out that the problem with the clang -Wimplicit-fallthrough
    warning is not about the kernel source code, but about clang itself, and
    that the warning is unusable until clang fixes its broken ways.

    In particular, when you enable this warning for clang, you not only get
    warnings about implicit fallthroughs. You also get this:

       warning: fallthrough annotation in unreachable code [-Wimplicit-fallthrough]

    which is completely broken becasue it

     (a) doesn't even tell you where the problem is (seriously: no line
         numbers, no filename, no nothing).

     (b) is fundamentally broken anyway, because there are perfectly valid
         reasons to have a fallthrough statement even if it turns out that
         it can perhaps not be reached.

    In the kernel, an example of that second case is code in the scheduler:

                    switch (state) {
                    case cpuset:
                            if (IS_ENABLED(CONFIG_CPUSETS)) {
                                    cpuset_cpus_allowed_fallback(p);
                                    state = possible;
                                    break;
                            }
                            fallthrough;
                    case possible:

    where if CONFIG_CPUSETS is enabled you actually never hit the
    fallthrough case at all. But that in no way makes the fallthrough
    wrong.

    So the warning is completely broken, and enabling it for clang is a very
    bad idea.

    In the meantime, we can keep the gcc option enabled, and make the gcc
    build use

        -Wimplicit-fallthrough=5

    which means that we will at least continue to require a proper
    fallthrough statement, and that gcc won't silently accept the magic
    comment versions. Because gcc does this all correctly, and while the odd
    "=5" part is kind of obscure, it's documented in [1]:

      "-Wimplicit-fallthrough=5 doesn’t recognize any comments as
       fallthrough comments, only attributes disable the warning"

    so if clang ever fixes its bad behavior we can try enabling it there again.

Change-Id: Iea69849592fb69ac04fb9bb28efcd6b8dce8ba88
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

stable-2.11 2021-07-13 19:34:24 UTC
Fix: Include correct header in backport of "fix: sched: Change task_struct::s...

Author: Mathieu Desnoyers
Author Date: 2021-07-13 19:34:24 UTC

Fix: Include correct header in backport of "fix: sched: Change task_struct::state (v5.14)"

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I1dad8c9f057886ef8b18c0a6b3407e2fd595473c

stable-2.10 2021-02-16 18:49:34 UTC
Document last supported kernel version for stable-2.10 branch

Author: Mathieu Desnoyers
Author Date: 2021-02-16 18:49:00 UTC

Document last supported kernel version for stable-2.10 branch

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: Ie554bb04840f799c34b0f28657cf982969991797

stable-2.9 2019-10-17 19:14:20 UTC
Version 2.9.15

Author: Mathieu Desnoyers
Author Date: 2019-10-17 19:14:20 UTC

Version 2.9.15

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

stable-2.8 2017-08-02 16:38:43 UTC
Version 2.8.7

Author: Mathieu Desnoyers
Author Date: 2017-08-02 16:38:43 UTC

Version 2.8.7

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

stable-2.7 2016-10-13 14:12:32 UTC
Version 2.7.7

Author: Mathieu Desnoyers
Author Date: 2016-10-13 14:12:32 UTC

Version 2.7.7

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

stable-2.6 2016-05-20 21:50:22 UTC
Version 2.6.6

Author: Mathieu Desnoyers
Author Date: 2016-05-20 21:50:22 UTC

Version 2.6.6

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

stable-2.5 2015-09-09 20:38:21 UTC
Version 2.5.6

Author: Mathieu Desnoyers
Author Date: 2015-09-09 20:38:21 UTC

Version 2.5.6

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

stable-2.4 2015-01-26 20:21:45 UTC
Version 2.4.4

Author: Mathieu Desnoyers
Author Date: 2015-01-26 20:21:45 UTC

Version 2.4.4

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

stable-2.3 2014-03-15 18:20:00 UTC
Fix file permissions for lttng-statedump-impl.c

Author: Mathieu Desnoyers
Author Date: 2014-03-15 18:19:18 UTC

Fix file permissions for lttng-statedump-impl.c

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

stable-2.2 2014-02-28 17:33:30 UTC
Version 2.2.4

Author: Mathieu Desnoyers
Author Date: 2014-02-28 17:33:30 UTC

Version 2.2.4

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

stable-2.1 2013-07-11 20:30:31 UTC
Version 2.1.3

Author: Mathieu Desnoyers
Author Date: 2013-07-11 20:30:31 UTC

Version 2.1.3

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

stable-2.0 2013-07-11 20:26:34 UTC
Version 2.0.8

Author: Mathieu Desnoyers
Author Date: 2013-07-11 20:26:34 UTC

Version 2.0.8

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

v0.19-stable 2011-11-25 21:59:56 UTC
lttng-modules v0.19-stable: setup_trace_write: Fix recursive locking

Author: Juha Niskanen
Author Date: 2011-11-25 21:59:56 UTC

lttng-modules v0.19-stable: setup_trace_write: Fix recursive locking

lttng-modules: ltt_trace_destroy calls ltt_lock_traces internally so
this non-recursive mutex must be first unlocked when executing error
handling code.

Signed-off-by: Juha Niskanen <juha_niskanen@mentor.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

116 of 16 results

Other repositories

Name Last Modified
lp:lttng-modules 2021-09-14
lp:~lttng/lttng-modules/+git/packaging 2021-02-16
12 of 2 results
You can't create new repositories for lttng-modules.