[rulkc] [PATCH net-next v4] vsock/virtio: rewrite MSG_ZEROCOPY flag handling

[rulkc] [PATCH net-next v4] vsock/virtio: rewrite MSG_ZEROCOPY flag handling

[avkrasnov]

Logically it was based on TCP implementation, so to make further support
easier, rewrite it in the TCP way (like in 'tcp_sendmsg_locked()'). By
this way, patch also adds handling case when 'msg_ubuf' is already set.

Signed-off-by: Arseniy Krasnov <avkrasnov at rulkc.org>
---
 Changelog v1->v2:
 * Rebase on last 'net-next'. Don't need 'skb_zcopy_set()' now - it was
   already added.
 Changelog v2->v3:
 * Update commit message.
 * Remove one empty line.
 Changelog v3->v4:
 * Update commit message.

 net/vmw_vsock/virtio_transport_common.c | 47 ++++++++++++-------------
 1 file changed, 22 insertions(+), 25 deletions(-)

diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c
index 09475007165b..41c2a0b82a8e 100644
--- a/net/vmw_vsock/virtio_transport_common.c
+++ b/net/vmw_vsock/virtio_transport_common.c
@@ -328,38 +328,35 @@ static int virtio_transport_send_pkt_info(struct vsock_sock *vsk,
 	if (pkt_len == 0 && info->op == VIRTIO_VSOCK_OP_RW)
 		return pkt_len;
 
-	if (info->msg) {
-		/* If zerocopy is not enabled by 'setsockopt()', we behave as
-		 * there is no MSG_ZEROCOPY flag set.
+	if (info->msg && (info->msg->msg_flags & MSG_ZEROCOPY)) {
+		/* If 'info->msg' is not NULL, this is only VIRTIO_VSOCK_OP_RW.
+		 * 'MSG_ZEROCOPY' flag handling here is based on the same flag
+		 * handling from 'tcp_sendmsg_locked()'.
 		 */
-		if (!sock_flag(sk_vsock(vsk), SOCK_ZEROCOPY))
-			info->msg->msg_flags &= ~MSG_ZEROCOPY;
+		if (info->msg->msg_ubuf) {
+			uarg = info->msg->msg_ubuf;
+			can_zcopy = virtio_transport_can_zcopy(t_ops, info, pkt_len);
+		} else if (sock_flag(sk_vsock(vsk), SOCK_ZEROCOPY)) {
+			uarg = msg_zerocopy_realloc(sk_vsock(vsk), pkt_len,
+						    NULL, false);
+			if (!uarg) {
+				virtio_transport_put_credit(vvs, pkt_len);
+				return -ENOMEM;
+			}
 
-		if (info->msg->msg_flags & MSG_ZEROCOPY)
 			can_zcopy = virtio_transport_can_zcopy(t_ops, info, pkt_len);
+			if (!can_zcopy)
+				uarg_to_msgzc(uarg)->zerocopy = 0;
 
+			have_uref = true;
+		}
+
+		/* 'can_zcopy' means that this transmission will be
+		 * in zerocopy way (e.g. using 'frags' array).
+		 */
 		if (can_zcopy)
 			max_skb_len = min_t(u32, VIRTIO_VSOCK_MAX_PKT_BUF_SIZE,
 					    (MAX_SKB_FRAGS * PAGE_SIZE));
-
-		if (info->msg->msg_flags & MSG_ZEROCOPY &&
-		    info->op == VIRTIO_VSOCK_OP_RW) {
-			uarg = info->msg->msg_ubuf;
-
-			if (!uarg) {
-				uarg = msg_zerocopy_realloc(sk_vsock(vsk),
-							    pkt_len, NULL, false);
-				if (!uarg) {
-					virtio_transport_put_credit(vvs, pkt_len);
-					return -ENOMEM;
-				}
-
-				if (!can_zcopy)
-					uarg_to_msgzc(uarg)->zerocopy = 0;
-
-				have_uref = true;
-			}
-		}
 	}
 
 	rest_len = pkt_len;
-- 
2.25.1

[rulkc] [PATCH net-next v4] vsock/virtio: rewrite MSG_ZEROCOPY flag handling

[mst]

On Sun, Jun 28, 2026 at 09:20:52PM +0300, Arseniy Krasnov wrote:
> Logically it was based on TCP implementation, so to make further support
> easier, rewrite it in the TCP way (like in 'tcp_sendmsg_locked()'). By
> this way, patch also adds handling case when 'msg_ubuf' is already set.
> 
> Signed-off-by: Arseniy Krasnov <avkrasnov at rulkc.org>

Acked-by: Michael S. Tsirkin <mst at redhat.com>

> ---
>  Changelog v1->v2:
>  * Rebase on last 'net-next'. Don't need 'skb_zcopy_set()' now - it was
>    already added.
>  Changelog v2->v3:
>  * Update commit message.
>  * Remove one empty line.
>  Changelog v3->v4:
>  * Update commit message.
> 
>  net/vmw_vsock/virtio_transport_common.c | 47 ++++++++++++-------------
>  1 file changed, 22 insertions(+), 25 deletions(-)
> 
> diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c
> index 09475007165b..41c2a0b82a8e 100644
> --- a/net/vmw_vsock/virtio_transport_common.c
> +++ b/net/vmw_vsock/virtio_transport_common.c
> @@ -328,38 +328,35 @@ static int virtio_transport_send_pkt_info(struct vsock_sock *vsk,
>  	if (pkt_len == 0 && info->op == VIRTIO_VSOCK_OP_RW)
>  		return pkt_len;
>  
> -	if (info->msg) {
> -		/* If zerocopy is not enabled by 'setsockopt()', we behave as
> -		 * there is no MSG_ZEROCOPY flag set.
> +	if (info->msg && (info->msg->msg_flags & MSG_ZEROCOPY)) {
> +		/* If 'info->msg' is not NULL, this is only VIRTIO_VSOCK_OP_RW.
> +		 * 'MSG_ZEROCOPY' flag handling here is based on the same flag
> +		 * handling from 'tcp_sendmsg_locked()'.
>  		 */
> -		if (!sock_flag(sk_vsock(vsk), SOCK_ZEROCOPY))
> -			info->msg->msg_flags &= ~MSG_ZEROCOPY;
> +		if (info->msg->msg_ubuf) {
> +			uarg = info->msg->msg_ubuf;
> +			can_zcopy = virtio_transport_can_zcopy(t_ops, info, pkt_len);
> +		} else if (sock_flag(sk_vsock(vsk), SOCK_ZEROCOPY)) {
> +			uarg = msg_zerocopy_realloc(sk_vsock(vsk), pkt_len,
> +						    NULL, false);
> +			if (!uarg) {
> +				virtio_transport_put_credit(vvs, pkt_len);
> +				return -ENOMEM;
> +			}
>  
> -		if (info->msg->msg_flags & MSG_ZEROCOPY)
>  			can_zcopy = virtio_transport_can_zcopy(t_ops, info, pkt_len);
> +			if (!can_zcopy)
> +				uarg_to_msgzc(uarg)->zerocopy = 0;
>  
> +			have_uref = true;
> +		}
> +
> +		/* 'can_zcopy' means that this transmission will be
> +		 * in zerocopy way (e.g. using 'frags' array).
> +		 */
>  		if (can_zcopy)
>  			max_skb_len = min_t(u32, VIRTIO_VSOCK_MAX_PKT_BUF_SIZE,
>  					    (MAX_SKB_FRAGS * PAGE_SIZE));
> -
> -		if (info->msg->msg_flags & MSG_ZEROCOPY &&
> -		    info->op == VIRTIO_VSOCK_OP_RW) {
> -			uarg = info->msg->msg_ubuf;
> -
> -			if (!uarg) {
> -				uarg = msg_zerocopy_realloc(sk_vsock(vsk),
> -							    pkt_len, NULL, false);
> -				if (!uarg) {
> -					virtio_transport_put_credit(vvs, pkt_len);
> -					return -ENOMEM;
> -				}
> -
> -				if (!can_zcopy)
> -					uarg_to_msgzc(uarg)->zerocopy = 0;
> -
> -				have_uref = true;
> -			}
> -		}
>  	}
>  
>  	rest_len = pkt_len;
> -- 
> 2.25.1

[rulkc] [PATCH net-next v4] vsock/virtio: rewrite MSG_ZEROCOPY flag handling

[sgarzare]

On Sun, Jun 28, 2026 at 09:20:52PM +0300, Arseniy Krasnov wrote:
>Logically it was based on TCP implementation, so to make further support
>easier, rewrite it in the TCP way (like in 'tcp_sendmsg_locked()'). By
>this way, patch also adds handling case when 'msg_ubuf' is already set.

Thanks for this!

IIUC the result will be similar of commit eb315a7d1396 ("tcp: support 
externally provided ubufs") for tcp. Maybe I would have added it to the 
commit description, anyway the patch LGTM:

Reviewed-by: Stefano Garzarella <sgarzare at redhat.com>

>
>Signed-off-by: Arseniy Krasnov <avkrasnov at rulkc.org>
>---
> Changelog v1->v2:
> * Rebase on last 'net-next'. Don't need 'skb_zcopy_set()' now - it was
>   already added.
> Changelog v2->v3:
> * Update commit message.
> * Remove one empty line.
> Changelog v3->v4:
> * Update commit message.
>
> net/vmw_vsock/virtio_transport_common.c | 47 ++++++++++++-------------
> 1 file changed, 22 insertions(+), 25 deletions(-)
>
>diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c
>index 09475007165b..41c2a0b82a8e 100644
>--- a/net/vmw_vsock/virtio_transport_common.c
>+++ b/net/vmw_vsock/virtio_transport_common.c
>@@ -328,38 +328,35 @@ static int virtio_transport_send_pkt_info(struct vsock_sock *vsk,
> 	if (pkt_len == 0 && info->op == VIRTIO_VSOCK_OP_RW)
> 		return pkt_len;
>
>-	if (info->msg) {
>-		/* If zerocopy is not enabled by 'setsockopt()', we behave as
>-		 * there is no MSG_ZEROCOPY flag set.
>+	if (info->msg && (info->msg->msg_flags & MSG_ZEROCOPY)) {
>+		/* If 'info->msg' is not NULL, this is only VIRTIO_VSOCK_OP_RW.
>+		 * 'MSG_ZEROCOPY' flag handling here is based on the same flag
>+		 * handling from 'tcp_sendmsg_locked()'.
> 		 */
>-		if (!sock_flag(sk_vsock(vsk), SOCK_ZEROCOPY))
>-			info->msg->msg_flags &= ~MSG_ZEROCOPY;
>+		if (info->msg->msg_ubuf) {
>+			uarg = info->msg->msg_ubuf;
>+			can_zcopy = virtio_transport_can_zcopy(t_ops, info, pkt_len);
>+		} else if (sock_flag(sk_vsock(vsk), SOCK_ZEROCOPY)) {
>+			uarg = msg_zerocopy_realloc(sk_vsock(vsk), pkt_len,
>+						    NULL, false);
>+			if (!uarg) {
>+				virtio_transport_put_credit(vvs, pkt_len);
>+				return -ENOMEM;
>+			}
>
>-		if (info->msg->msg_flags & MSG_ZEROCOPY)
> 			can_zcopy = virtio_transport_can_zcopy(t_ops, info, pkt_len);
>+			if (!can_zcopy)
>+				uarg_to_msgzc(uarg)->zerocopy = 0;
>
>+			have_uref = true;
>+		}
>+
>+		/* 'can_zcopy' means that this transmission will be
>+		 * in zerocopy way (e.g. using 'frags' array).
>+		 */
> 		if (can_zcopy)
> 			max_skb_len = min_t(u32, VIRTIO_VSOCK_MAX_PKT_BUF_SIZE,
> 					    (MAX_SKB_FRAGS * PAGE_SIZE));
>-
>-		if (info->msg->msg_flags & MSG_ZEROCOPY &&
>-		    info->op == VIRTIO_VSOCK_OP_RW) {
>-			uarg = info->msg->msg_ubuf;
>-
>-			if (!uarg) {
>-				uarg = msg_zerocopy_realloc(sk_vsock(vsk),
>-							    pkt_len, NULL, false);
>-				if (!uarg) {
>-					virtio_transport_put_credit(vvs, pkt_len);
>-					return -ENOMEM;
>-				}
>-
>-				if (!can_zcopy)
>-					uarg_to_msgzc(uarg)->zerocopy = 0;
>-
>-				have_uref = true;
>-			}
>-		}
> 	}
>
> 	rest_len = pkt_len;
>-- 
>2.25.1
>

[rulkc] [RESEND PATCH v1 4/4] Add LANDAU Linux project overview and maintenance documentation

[pabeni]

Introduce the LANDAU Linux subproject under the LANDAU umbrella:
- Add landau-linux/index.md with project description, goals, and
  key documents navigation
- Add landau-linux/maintenance.md with the comprehensive maintenance
  manifest covering:
  * Versioning scheme (VERSION.PATCHLEVEL.SUBLEVEL.lXYZ)
  * Branching strategy (landau-next, landau-V.P.y)
  * Release cycle and schedule
  * RC testing process
  * LTS support policy
  * Maintainer responsibilities
  * GPG signing requirements
  * Squash policy with Co-developed-by attribution

These documents formalize the LANDAU Linux maintenance process and
establish the project as an upstream-first fork tracking mainline
and stable kernels.

Signed-off-by: Dmitry Rokosov <rockosov at rulkc.org>
---
 landau-linux/index.md       |  27 +++
 landau-linux/maintenance.md | 325 ++++++++++++++++++++++++++++++++++++
 2 files changed, 352 insertions(+)
 create mode 100644 landau-linux/index.md
 create mode 100644 landau-linux/maintenance.md

diff --git a/landau-linux/index.md b/landau-linux/index.md
new file mode 100644
index 000000000000..2891de83267a
--- /dev/null
+++ b/landau-linux/index.md
@@ -0,0 +1,27 @@
+# ⚛️ LANDAU Linux
+
+---
+
+## 🎯 О проекте
+
+Мы видим LANDAU Linux как **upstream-first форк**, улучшающий mainline/stable ветки*:
+
+*   🔄 **Регулярное обновление:** Следование за актуальными версиями mainline/stable (раз в 1–2 месяца).
+*   📦 **Приём патчей:** Включение полезных наработок, которые по разным причинам не попали в upstream (драйверы, архитектурные доработки).
+*   🖥️ **Поддержка российского железа:** Создание единой ветки ядра как основы BSP для процессоров различных архитектур (ARM, MIPS, RISC-V, Эльбрус), аппаратных платформ и consumer электроники, разрабатываемой в России.
+*   👁️ **Прозрачность:** Открытый процесс ревью, современный CI и совместное тестирование.
+
+Проект призван решать как текущие задачи индустрии (сохранение и развитие кода, снижение фрагментации), так и готовить основу для будущего — появления собственных IP- и Core-вендоров, ODM-производителей устройств на отечественных чипах.
+
+---
+
+## 📄 Ключевые документы
+
+| Документ | Описание |
+|----------|----------|
+| 📋 **[LANDAU Linux Maintenance](./maintenance.md)** | Официальный процесс maintenance LANDAU Linux |
+
+---
+
+[⬅️ Вернуться на главную LANDAU](../index.md)
+
diff --git a/landau-linux/maintenance.md b/landau-linux/maintenance.md
new file mode 100644
index 000000000000..906c625ee06f
--- /dev/null
+++ b/landau-linux/maintenance.md
@@ -0,0 +1,325 @@
+title: "📋 Манифест сопровождения LANDAU"
+description: "Официальный процесс maintenance LANDAU Linux — версионирование, ветки, релизы и LTS"
+published: true
+---
+
+# 📋 Манифест процесса сопровождения LANDAU
+
+> **LANDAU** — форк ядра Linux с собственной схемой версионирования и предсказуемым циклом релизов.  
+> Этот документ описывает формальный процесс сопровождения (maintenance) проекта.
+
+---
+
+## 🧭 1. Обзор
+
+### 🎯 Цель
+
+Обеспечить стабильный, предсказуемый и документированный процесс выпуска LANDAU-релизов с отслеживанием апстрим-ядра Linux.
+
+### Глоссарий
+V - VERSION - major версия ядра Linux
+P - PATCHLEVEL - middle версия ядра Linux
+S - SUBLEVEL - minor версия ядра Linux
+E - EXTRAVERSION - поле в версии ядра Linux, в которое мы встраиваем версию LANDAU (ядром Linux обычно используется для -rc релизов (testing фазы))
+RMW - Rebase & Merge Window - временной отрезок, в рамках которого мейнтейнеры LANDAU ребейзят свой changelog на новую базовую версию ядра.
+Bundle - в общем случае это changelog LANDAU Linux, который отличается от upstream (группа патч серий). Есть общий LANDAU Bundle, а есть Bundle-ы мейнтейнеров в их форках.
+
+### 📁 Структура репозитория
+
+| Сущность | Назначение |
+|----------|-------------|
+| `landau-next` | Ветка для следующего релиза LANDAU, куда мейтейнеры отсылают свои MR |
+| `landau-V.P.y` | Текущая ветка для релиза LANDAU на базе ядра с версией V.P |
+
+`landau-next` - это ветка для работы всех мейтейнеров вместе. В ней разрешаются конфликты и собираются все MR вместе для создания ветки `landau-V.P.y`.
+`landau-next` - это force-push ветка, которая меняется при каждом старте нового RMW
+
+### 🪞 Апстрим-зеркала
+
+На сервере `https://git.rulkc.org` поддерживаются постоянно обновляемые зеркала:
+
+- 🔷 `torvalds/linux` — основная ветка ядра
+- 🔷 `stable/linux` — стабильные релизы
+- 🔷 `linux-next` — интеграционное дерево linux-next
+
+---
+
+## 🏷️ 2. Схема версионирования
+
+### 📐 Формат версии LANDAU
+
+```
+VERSION.PATCHLEVEL.SUBLEVEL.lXYZ
+```
+
+| Компонент | Пример | Описание |
+|-----------|--------|----------|
+| `VERSION` | `7` | Мажорная версия ядра |
+| `PATCHLEVEL` | `0` | Минорная версия |
+| `SUBLEVEL` | `12` | Номер стабильного обновления апстрима |
+| `lXYZ` | `l0`, `l1` | Сборочный номер LANDAU |
+
+
+### 🏷️ Git-теги
+
+Используются **аннотированные теги** в формате:
+
+```
+v7.0.lXYZ
+```
+
+Пример: `v7.0.l0`, `v7.0.l5`
+
+---
+
+## 🌿 3. Веточная стратегия
+
+### 📌 Основные ветки
+
+| Ветка | Назначение |
+|-------|-------------|
+| `landau-next` | Ветка для следующего релиза LANDAU, куда мейтейнеры отсылают свои MR |
+| `landau-V.P.y` | Текущая ветка для релиза LANDAU на базе ядра с версией V.P |
+
+### ⏳ Жизненный цикл ветки
+
+```mermaid
+graph LR
+    A[Создание ветки<br>landau-7.0.y] --> B[Активная разработка<br>и выпуск релизов]
+    B --> C{Тип поддержки?}
+    C -->|Обычное ядро| D[EOL апстрима →<br>ветка архивируется]
+    C -->|LTS ядро| E[Поддержка до EOL апстрима<br>только исправления]
+```
+
+| Стадия | Действие |
+|--------|----------|
+| 🆕 Создание | От тега апстрим-релиза |
+| 🔧 Разработка | Ветка `landau-7.0.y` |
+| 🛑 Окончание поддержки | Апстрим достигает EOL |
+| 🐢 LTS | Только исправления (без новых фич) |
+
+---
+
+## 📅 4. График релизов
+
+### ⏱️ Апстрим-график
+
+| Фаза | ⏰ Длительность | 📝 Описание |
+|------|----------------|-------------|
+| Разработка | 9-10 недель | Подготовка к новому релизу |
+| Rebase & Merge Window | 2 недели | Приём новых Merge Requests от мейнтейнеров |
+| RC-тестирование | 7-8 недель | Тестирование кандидатов на релиз |
+| Финальный релиз | — | Публикация стабильного ядра |
+
+> ℹ️ **Важно**: Релизы LANDAU отстают от апстрима на **1 patchlevel (SUBLEVEL)**.
+
+---
+
+## 🔄 5. Процесс выпуска LANDAU
+
+### 📊 Полный цикл релиза
+
+```mermaid
+flowchart TD
+    A[📦 Выход нового апстрим-релиза mainline] --> B[🔓 Открытие RMW LANDAU<br>2 недели]
+    B --> C[🏷️ Создание тега v7.0.l-rc1]
+    C --> D[🧪 Фаза RC-тестирования<br>1 неделя на RC]
+    D --> E{Все тесты пройдены?}
+    E -->|Нет| F[🔧 Исправление ошибок]
+    F --> D
+    E -->|Да| G[✅ Релиз v7.0.l]
+    G --> H[🔄 Интеграция SUBLEVEL<br>апстрима]
+    H --> I[📈 Повышение версии<br>v7.0.1.l1]
+```
+
+### 5.1 🆕 Новый релиз mainline
+
+| Шаг | Действие |
+|-----|----------|
+| 1 | Создать ветку `landau-7.0.y` от тега апстрим-релиза |
+| 2 | Применить LANDAU-специфичные патчи |
+| 3 | Установить `VERSION`, `PATCHLEVEL`, `SUBLEVEL` по апстриму |
+| 4 | Оставить `EXTRAVERSION` пустым (используется `.lX` формат) |
+| 5 | Создать тег `v7.0.l-rc1` |
+
+### 5.2 🧪 RC-тестирование
+
+| Параметр | Значение |
+|----------|----------|
+| ⏱️ Длительность | **1 неделя** на каждый RC |
+| 🏷️ Кандидаты | `rc1`, `rc2`, `rc3` ... |
+| 🎯 Фокус | Регрессионное тестирование, стабильность, валидация фич |
+| 🔧 Исправления | Применяются непосредственно в ветку релиза |
+
+### 5.3 ✅ Финальный релиз
+
+1. Убедиться, что все критические проблемы решены
+2. Создать финальный аннотированный тег `v7.0.l`
+3. Опубликовать релиз
+
+### 5.4 🔄 Интеграция апстрим-обновлений SUBLEVEL
+
+| Шаг | Действие | Пример |
+|-----|----------|--------|
+| 1 | Определить новый `SUBLEVEL` из апстрим-тега | `v7.0.1` |
+| 2 | Смержить апстрим-изменения | `git merge v7.0.1` |
+| 3 | Повысить LANDAU-версию | `l` → `l1` |
+| 4 | Обновить версию | `v7.0.1.l1` |
+| 5 | Выпустить релиз | Публикация тега |
+
+---
+
+## 🐢 6. Политика в отношении LTS
+
+Мейнтейнеры LANDAU приняли решение **нативно поддерживать LTS-версии** апстрим-ядра.
+
+### ⚠️ Ограничения LTS-поддержки
+
+| ✅ Разрешено | ❌ Запрещено |
+|--------------|--------------|
+| Исправления безопасности | Бэкпорт новых фич |
+| Критические багфиксы | Новые драйверы |
+| Стабилизирующие патчи | Изменения подсистем |
+| Документация | Любые не-багфиксы |
+
+> 📌 **Принцип**: Поддерживается тот Changelog, который был на момент отвода LTS основного ядра.
+
+### 🛑 Окончание поддержки
+
+| Тип ядра | Условие окончания поддержки |
+|----------|------------------------------|
+| Обычное | Апстрим достигает EOL |
+| LTS | Поддержка продолжается до EOL апстрима (без добавления новых фич) |
+
+Гарантировано LANDAU Owners поддерживают одно последнее LTS ядро. Про остальные LTS ядра думаем при наличии ресурсов.
+
+---
+
+## 👤 7. Обязанности мейнтейнера
+
+| Область | Ответственность |
+|---------|------------------|
+| 👁️ Мониторинг апстрима | Отслеживание новых релизов и RC-циклов |
+| 📦 Применение патчей | Интеграция LANDAU-специфичных изменений |
+| 🏷️ Управление тегами | Создание аннотированных тегов в формате `vX.Y.lZ` |
+| 🧪 Координация RC | Организация тестирования кандидатов на релиз |
+| 🔒 Безопасность | Мониторинг и применение апстрим-исправлений безопасности |
+| 📝 Документирование | Ведение changelog для каждого LANDAU-релиза |
+
+---
+
+## 📖 8. Пример полного цикла релиза
+
+### Исходные данные
+
+Апстрим выпускает ядро **`6.12.0`**
+
+### 📍 Пошаговый пример
+
+#### 👁️ Схема
+
+| Этап | Действие | Результат | Версия сборки |
+|------|----------|-----------|---------------|
+| 1 | Force push ветки `landau-next` на `v7.0` | `landau-next` | — |
+| 2 | Старт RMW | `landau-next` | `N/A` |
+| 3 | Создание RC1 | `v7.0.l-rc1` | `7.0.l-rc1` |
+| 4 | Создание RC2 | `v7.0.l-rc2` | `7.0.l-rc2` |
+| 5 | Создание RC3 | `v7.0.l-rc3` | `7.0.l-rc3` |
+| 6 | **Финальный релиз** и **отвод ветки** | `v7.0.l`<br>`landau-7.0.y` | `7.0.l` |
+| 7 | Апстрим выпускает `7.0.1` | Слияние изменений в `landau-7.0.y` | — |
+| 8 | Обновление версии | `v7.0.1.l1` | `7.0.1.l1` |
+| 9 | Апстрим объявляет EOL для `7.0` | Ветка `landau-7.0.y` архивируется | — |
+
+#### 🔄 Детальное описание процесса
+
+1. **Выход нового стабильного релиза upstream kernel** (например, `v7.0` по результатам 7 недель стабилизации)
+2. **Открытие RMW LANDAU** — берём 2 недели на свой релиз LANDAU:
+   - Затаскиваем патч-серии (MR) в ветку `landau-next`, на основе `v7.0`
+   - Там же происходит решение всех конфликтов
+   - Формируются первые общие сборки ядра
+3. **Выпуск RC-версий** (например, `v7.0.l-rc1`) — RC-релизы делаются в ветке `landau-next`
+4. **Тестирование** — длится до 7 недель (может быть меньше):
+   - Выпускаются RC-версии: `rc1`, `rc2`, `rc3` и т.д.
+5. **Финальный релиз и отвод стабильной ветки**:
+   - Выпускаем релиз `v7.0.l`
+   - Отводим стабильную ветку **`landau-7.0.y`** от финального релиза
+   - Вся дальнейшая поддержка этой версии ведётся в `landau-7.0.y`
+6. **Завершение цикла `landau-next`**:
+   - Ветка `landau-next` останавливает свой рост на первом релизе `v7.0.l`
+   - Переключается на шаг 1, когда в upstream выходит новый стабильный релиз (например, `v7.1`)
+7. **Интеграция SUBLEVEL из upstream**:
+   - Если в upstream меняется SUBLEVEL (например, `7.0.1`), мы интегрируем данный релиз в **`landau-7.0.y`**
+   - Повышаем свою версию: `v7.0.1.l1`
+   - То есть повышается версия LANDAU, а SUBLEVEL становится равным upstream SUBLEVEL
+8. **Развитие стабильной версии**:
+   - Стабильная версия LANDAU `v7.0` ведётся в ветке `landau-7.0.y`
+9. **Окончание поддержки релиза**:
+   - Поддержка релиза LANDAU-ветки заканчивается, когда версия основного ядра больше не тегируется как stable на kernel.org (например, `7.0` достигла EOL)
+10. **LTS-поддержка**:
+    - Если основное ядро уходит в LTS, LANDAU поддерживает LTS до конца
+    - Приносятся только фиксы LANDAU (без новых фич) и новые SUBLEVEL
+11. **Гарантии поддержки**:
+    - LANDAU Owners гарантированно поддерживают **одно последнее LTS ядро**
+    - Про поддержку более старых LTS ядер думаем при наличии ресурсов
+
+#### 📊 Визуализация цикла
+
+```mermaid
+flowchart TD
+    A[Выход нового<br>stable релиза upstream<br>например, v7.0] --> B[Открытие RMW LANDAU<br>2 недели]
+    B --> C[Приём MR в landau-next<br>на основе v7.0]
+    C --> D[Выпуск RC1, RC2, RC3...<br>до 7 недель]
+    D --> E{Тестирование пройдено?}
+    E -->|Нет| D
+    E -->|Да| F[Релиз v7.0.l<br><br>⚡ Отвод ветки<br><b>landau-7.0.y</b>]
+    F --> G[Ожидание нового<br>stable upstream]
+    G --> H[Апстрим выпускает<br>новый SUBLEVEL,<br>например, 7.0.1]
+    H --> I[Интеграция в landau-7.0.y:<br>v7.0.1.l1]
+    I --> J{Апстрим EOL?}
+    J -->|Нет| H
+    J -->|Да| K[Архивация ветки<br>landau-7.0.y]
+```
+
+#### 🏷️ Пример полной цепочки тегов
+
+Для ядра `7.0.x` в LANDAU:
+
+```
+v7.0.l-rc1  →  v7.0.l-rc2  →  v7.0.l-rc3  →  v7.0.l
+                                                  ↓
+                                          отвод landau-7.0.y
+                                                  ↓
+                                          v7.0.1.l1  →  v7.0.2.l2  →  ...
+```
+
+---
+
+### Требования к патчам
+
+TODO
+
+### Pull requests
+
+TODO
+
+### Maintainers B4 usage
+
+TODO
+
+---
+
+## 📚 9. Ссылки и ресурсы
+
+| Ресурс | URL |
+|--------|-----|
+| 📦 Репозиторий LANDAU | `https://git.rulkc.org/pub/scm/landau` |
+| 🪞 Зеркала апстрима | `https://git.rulkc.org` |
+| 🔗 Апстрим-ядро | `https://kernel.org` |
+
+---
+
+> 📌 **Актуальная версия документа**: 1.0  
+> ✍️ **Поддерживается**: LANDAU Maintainers
+> 📅 **Последнее обновление**: 2026
+
+[⬅️ Вернуться на страницу LANDAU Linux](./index.md)
-- 
2.48.1

[rulkc] [PATCH net-next v4] vsock/virtio: rewrite MSG_ZEROCOPY flag handling

[patchwork-bot+netdevbpf]

Hello:

This patch was applied to netdev/net-next.git (main)
by Paolo Abeni <pabeni at redhat.com>:

On Sun, 28 Jun 2026 21:20:52 +0300 you wrote:
> Logically it was based on TCP implementation, so to make further support
> easier, rewrite it in the TCP way (like in 'tcp_sendmsg_locked()'). By
> this way, patch also adds handling case when 'msg_ubuf' is already set.
> 
> Signed-off-by: Arseniy Krasnov <avkrasnov at rulkc.org>
> ---
>  Changelog v1->v2:
>  * Rebase on last 'net-next'. Don't need 'skb_zcopy_set()' now - it was
>    already added.
>  Changelog v2->v3:
>  * Update commit message.
>  * Remove one empty line.
>  Changelog v3->v4:
>  * Update commit message.
> 
> [...]

Here is the summary with links:
  - [net-next,v4] vsock/virtio: rewrite MSG_ZEROCOPY flag handling
    https://git.kernel.org/netdev/net-next/c/f456c1922c49

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html