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

See all merge proposals.

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 as soon as possible.

Last successful import was .

Import started on juju-98ee42-prod-launchpad-codeimport-5 and finished taking 1 minute — see the log
Import started on juju-98ee42-prod-launchpad-codeimport-2 and finished taking 50 seconds — see the log
Import started on juju-98ee42-prod-launchpad-codeimport-1 and finished taking 30 seconds — see the log
Import started on juju-98ee42-prod-launchpad-codeimport-3 and finished taking 30 seconds — see the log
Import started on juju-98ee42-prod-launchpad-codeimport-3 and finished taking 30 seconds — see the log
Import started on juju-98ee42-prod-launchpad-codeimport-4 and finished taking 25 seconds — see the log
Import started on juju-98ee42-prod-launchpad-codeimport-3 and finished taking 25 seconds — see the log
Import started on juju-98ee42-prod-launchpad-codeimport-2 and finished taking 30 seconds — see the log
Import started on juju-98ee42-prod-launchpad-codeimport-4 and finished taking 30 seconds — see the log
Import started on juju-98ee42-prod-launchpad-codeimport-4 and finished taking 30 seconds — see the log

Branches

Name Last Modified Last Commit
stable-2.13 2024-09-28 14:55:07 UTC
Version 2.13.15

Author: Mathieu Desnoyers
Author Date: 2024-09-28 14:55:07 UTC

Version 2.13.15

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

master 2024-07-29 15:22:01 UTC
Fix: scsi: sd: Atomic write support added in 6.11-rc1

Author: Kienan Stewart
Author Date: 2024-07-29 14:23:02 UTC

Fix: scsi: sd: Atomic write support added in 6.11-rc1

See upstream commit:

    commit bf4ae8f2e6407a779c0368eb0f3e047a8333be17
    Author: John Garry <john.g.garry@oracle.com>
    Date: Thu Jun 20 12:53:57 2024 +0000

        scsi: sd: Atomic write support

        Support is divided into two main areas:
        - reading VPD pages and setting sdev request_queue limits
        - support WRITE ATOMIC (16) command and tracing

        The relevant block limits VPD page need to be read to allow the block layer
        request_queue atomic write limits to be set. These VPD page limits are
        described in sbc4r22 section 6.6.4 - Block limits VPD page.

        There are five limits of interest:
        - MAXIMUM ATOMIC TRANSFER LENGTH
        - ATOMIC ALIGNMENT
        - ATOMIC TRANSFER LENGTH GRANULARITY
        - MAXIMUM ATOMIC TRANSFER LENGTH WITH BOUNDARY
        - MAXIMUM ATOMIC BOUNDARY SIZE

        MAXIMUM ATOMIC TRANSFER LENGTH is the maximum length for a WRITE ATOMIC
        (16) command. It will not be greater than the device MAXIMUM TRANSFER
        LENGTH.

        ATOMIC ALIGNMENT and ATOMIC TRANSFER LENGTH GRANULARITY are the minimum
        alignment and length values for an atomic write in terms of logical blocks.

        Unlike NVMe, SCSI does not specify an LBA space boundary, but does specify
        a per-IO boundary granularity. The maximum boundary size is specified in
        MAXIMUM ATOMIC BOUNDARY SIZE. When used, this boundary value is set in the
        WRITE ATOMIC (16) ATOMIC BOUNDARY field - layout for the WRITE_ATOMIC_16
        command can be found in sbc4r22 section 5.48. This boundary value is the
        granularity size at which the device may atomically write the data. A value
        of zero in WRITE ATOMIC (16) ATOMIC BOUNDARY field means that all data must
        be atomically written together.

        MAXIMUM ATOMIC TRANSFER LENGTH WITH BOUNDARY is the maximum atomic write
        length if a non-zero boundary value is set.

        For atomic write support, the WRITE ATOMIC (16) boundary is not of much
        interest, as the block layer expects each request submitted to be executed
        be atomically written together.

        MAXIMUM ATOMIC TRANSFER LENGTH WITH BOUNDARY is the maximum atomic write
        length if a non-zero boundary value is set.

        For atomic write support, the WRITE ATOMIC (16) boundary is not of much
        interest, as the block layer expects each request submitted to be executed
        atomically. However, the SCSI spec does leave itself open to a quirky
        scenario where MAXIMUM ATOMIC TRANSFER LENGTH is zero, yet MAXIMUM ATOMIC
        TRANSFER LENGTH WITH BOUNDARY and MAXIMUM ATOMIC BOUNDARY SIZE are both
        non-zero. This case will be supported.

        To set the block layer request_queue atomic write capabilities, sanitize
        the VPD page limits and set limits as follows:
        - atomic_write_unit_min is derived from granularity and alignment values.
          If no granularity value is not set, use physical block size
        - atomic_write_unit_max is derived from MAXIMUM ATOMIC TRANSFER LENGTH. In
          the scenario where MAXIMUM ATOMIC TRANSFER LENGTH is zero and boundary
          limits are non-zero, use MAXIMUM ATOMIC BOUNDARY SIZE for
          atomic_write_unit_max. New flag scsi_disk.use_atomic_write_boundary is
          set for this scenario.
        - atomic_write_boundary_bytes is set to zero always

        SCSI also supports a WRITE ATOMIC (32) command, which is for type 2
        protection enabled. This is not going to be supported now, so check for
        T10_PI_TYPE2_PROTECTION when setting any request_queue limits.

        To handle an atomic write request, add support for WRITE ATOMIC (16)
        command in handler sd_setup_atomic_cmnd(). Flag use_atomic_write_boundary
        is checked here for encoding ATOMIC BOUNDARY field.

        Trace info is also added for WRITE_ATOMIC_16 command.

Change-Id: Ie072002fe2184615c72531ac081a324ef18cfb03
Signed-off-by: Kienan Stewart <kstewart@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

stable-2.12 2024-07-18 17:22:29 UTC
Version 2.12.18

Author: Mathieu Desnoyers
Author Date: 2024-07-18 17:22:29 UTC

Version 2.12.18

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

stable-2.11 2021-11-13 19:46:38 UTC
Document last supported kernel version for stable-2.11 branch

Author: Michael Jeanson
Author Date: 2021-10-13 17:47:23 UTC

Document last supported kernel version for stable-2.11 branch

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

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 2024-09-28
lp:~lttng/lttng-modules/+git/packaging 2024-01-23
12 of 2 results
You can't create new repositories for lttng-modules.