INFO: task can't die in task_thread

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:d01f2f7e Add linux-next specific files for 20210226
git tree:   linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=17a449cad0
kernel config:  https://syzkaller.appspot.com/x/.config?x=a1746d2802a82a05
dashboard link: https://syzkaller.appspot.com/bug?extid=424fd30c996924e270a9

Unfortunately, I don't have any reproducer for this issue yet.

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+424fd30c996924e27...@syzkaller.appspotmail.com

INFO: task iou-wrk-14642:14654 can't die for more than 143 seconds.
task:iou-wrk-14642   state:R  running task stack:29768 pid:14654 ppid:  
8579 flags:0x4006
Call Trace:
 context_switch kernel/sched/core.c:4324 [inline]
 __schedule+0x90c/0x21a0 kernel/sched/core.c:5075
 schedule+0xcf/0x270 kernel/sched/core.c:5154
 schedule_timeout+0x14a/0x250 kernel/time/timer.c:1892
 io_wqe_worker fs/io-wq.c:512 [inline]
 task_thread.isra.0+0x8d0/0x1380 fs/io-wq.c:602
 task_thread_bound+0x18/0x20 fs/io-wq.c:608
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294
INFO: task iou-wrk-14642:14655 can't die for more than 144 seconds.
task:iou-wrk-14642   state:R  running task stack:29704 pid:14655 ppid:  
8579 flags:0x4006
Call Trace:
 context_switch kernel/sched/core.c:4324 [inline]
 __schedule+0x90c/0x21a0 kernel/sched/core.c:5075
 schedule+0xcf/0x270 kernel/sched/core.c:5154
 schedule_timeout+0x14a/0x250 kernel/time/timer.c:1892
 io_wqe_worker fs/io-wq.c:512 [inline]
 task_thread.isra.0+0x8d0/0x1380 fs/io-wq.c:602
 task_thread_unbound+0x1b/0x20 fs/io-wq.c:613
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294
INFO: task iou-wrk-14642:14656 can't die for more than 144 seconds.
task:iou-wrk-14642   state:R  running task stack:29480 pid:14656 ppid:  
8579 flags:0x4006
Call Trace:
 context_switch kernel/sched/core.c:4324 [inline]
 __schedule+0x90c/0x21a0 kernel/sched/core.c:5075
 schedule+0xcf/0x270 kernel/sched/core.c:5154
INFO: task iou-wrk-14642:14657 can't die for more than 145 seconds.
task:iou-wrk-14642   state:R  running task stack:29512 pid:14657 ppid:  
8579 flags:0x4006
Call Trace:
 context_switch kernel/sched/core.c:4324 [inline]
 __schedule+0x90c/0x21a0 kernel/sched/core.c:5075
 schedule+0xcf/0x270 kernel/sched/core.c:5154
 schedule_timeout+0x14a/0x250 kernel/time/timer.c:1892
 io_wqe_worker fs/io-wq.c:512 [inline]
 task_thread.isra.0+0x8d0/0x1380 fs/io-wq.c:602
 task_thread_unbound+0x1b/0x20 fs/io-wq.c:613
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294
INFO: task iou-wrk-14642:14659 can't die for more than 146 seconds.
task:iou-wrk-14642   state:R  running task stack:29768 pid:14659 ppid:  
8579 flags:0x4006
Call Trace:
 context_switch kernel/sched/core.c:4324 [inline]
 __schedule+0x90c/0x21a0 kernel/sched/core.c:5075
 schedule+0xcf/0x270 kernel/sched/core.c:5154
 schedule_timeout+0x14a/0x250 kernel/time/timer.c:1892
 io_wqe_worker fs/io-wq.c:512 [inline]
 task_thread.isra.0+0x8d0/0x1380 fs/io-wq.c:602
 task_thread_unbound+0x1b/0x20 fs/io-wq.c:613
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294
INFO: task iou-wrk-14642:14661 can't die for more than 147 seconds.
task:iou-wrk-14642   state:R  running task stack:29768 pid:14661 ppid:  
8579 flags:0x4006
Call Trace:
 context_switch kernel/sched/core.c:4324 [inline]
 __schedule+0x90c/0x21a0 kernel/sched/core.c:5075
 schedule+0xcf/0x270 kernel/sched/core.c:5154
 schedule_timeout+0x14a/0x250 kernel/time/timer.c:1892
 io_wqe_worker fs/io-wq.c:512 [inline]
 task_thread.isra.0+0x8d0/0x1380 fs/io-wq.c:602
 task_thread_bound+0x18/0x20 fs/io-wq.c:608
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294
INFO: task iou-wrk-14642:14665 can't die for more than 147 seconds.
task:iou-wrk-14642   state:R  running task stack:29328 pid:14665 ppid:  
8579 flags:0x4006
Call Trace:
 context_switch kernel/sched/core.c:4324 [inline]
 __schedule+0x90c/0x21a0 kernel/sched/core.c:5075
 schedule+0xcf/0x270 kernel/sched/core.c:5154
 schedule_timeout+0x14a/0x250 kernel/time/timer.c:1892
 io_wqe_worker fs/io-wq.c:512 [inline]
 task_thread.isra.0+0x8d0/0x1380 fs/io-wq.c:602
 task_thread_bound+0x18/0x20 fs/io-wq.c:608
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294
INFO: task iou-wrk-14642:14666 can't die for more than 148 seconds.
task:iou-wrk-14642   state:R  running task stack:29552 pid:14666 ppid:  
8579 flags:0x4006
Call Trace:
 context_switch kernel/sched/core.c:4324 [inline]
 __schedule+0x90c/0x21a0 kernel/sched/core.c:5075
 schedule+0xcf/0x270 kernel/sched/core.c:5154
 schedule_timeout+0x14a/0x250 kernel/time/timer.c:1892
 io_wqe_worker fs/io-wq.c:512 [inline]
 task_thread.isra.0+0x8d0/0x1380 fs/io-wq.c:602
 task_thread_unbound+0x1b/0x20 fs/io-wq.c:613
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294
INFO: task iou-wrk-14642:14668 can't die for more than 149 seconds.
task:iou-wrk-14642   state:R  running task stack:29704 p

Re: [PATCH] rtc: tps65910: include linux/property.h

[Dmitry Osipenko]

25.02.2021 16:42, Arnd Bergmann пишет:
> From: Arnd Bergmann 
> 
> The added device_property_present() call causes a build
> failure in some configurations because of the missing header:
> 
> drivers/rtc/rtc-tps65910.c:422:7: error: implicit declaration of function 
> 'device_property_present' [-Werror,-Wimplicit-function-declaration]
> 
> Fixes: 454ba154a62c ("rtc: tps65910: Support wakeup-source property")
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/rtc/rtc-tps65910.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/rtc/rtc-tps65910.c b/drivers/rtc/rtc-tps65910.c
> index 288abb1abdb8..bc89c62ccb9b 100644
> --- a/drivers/rtc/rtc-tps65910.c
> +++ b/drivers/rtc/rtc-tps65910.c
> @@ -18,6 +18,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> 

Reviewed-by: Dmitry Osipenko 

Re: [PATCH v2] bus: mhi: core: Add unique qrtr node id support

[gokulsri]

 Hi
On 2021-02-26 23:01, Bhaumik Bhatt wrote:

On 2021-02-26 06:52 AM, Manivannan Sadhasivam wrote:
On Fri, Feb 26, 2021 at 04:12:49PM +0530, Gokul Sriram Palanisamy 
wrote:

On platforms with two or more identical mhi
devices, qmi service will run with identical
qrtr-node-id. Because of this identical ID,
host qrtr-lookup cannot register more than one
qmi service with identical node ID. Ultimately,
only one qmi service will be avilable for the
underlying drivers to communicate with.

On QCN9000, it implements a unique qrtr-node-id
and qmi instance ID using a unique instance ID
written to a debug register from host driver
soon after SBL is loaded.

This change generates a unique instance ID from
PCIe domain number and bus number, writes to the
given debug register just after SBL is loaded so
that it is available for FW when the QMI service
is spawned.

sample:
root@OpenWrt:/# qrtr-lookup
  Service Version Instance Node  Port
   15   108 1 Test service
   69   188 2 ATH10k WLAN firmware service
   15   10   24 1 Test service
   69   1   24   24 2 ATH10k WLAN firmware service

Here 8 and 24 on column 3 (QMI Instance ID)
and 4 (QRTR Node ID) are the node IDs that
is unique per mhi device.

Signed-off-by: Gokul Sriram Palanisamy 
---
 drivers/bus/mhi/core/boot.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/bus/mhi/core/boot.c 
b/drivers/bus/mhi/core/boot.c

index c2546bf..5e5dad5 100644
--- a/drivers/bus/mhi/core/boot.c
+++ b/drivers/bus/mhi/core/boot.c
@@ -16,8 +16,12 @@
 #include 
 #include 
 #include 
+#include 
 #include "internal.h"

+#define QRTR_INSTANCE_MASK 0x00FF
+#define QRTR_INSTANCE_SHIFT0
+
 /* Setup RDDM vector table for RDDM transfer and program RXVEC */
 void mhi_rddm_prepare(struct mhi_controller *mhi_cntrl,
  struct image_info *img_info)
@@ -391,6 +395,9 @@ void mhi_fw_load_handler(struct mhi_controller 
*mhi_cntrl)

const struct firmware *firmware = NULL;
struct image_info *image_info;
struct device *dev = &mhi_cntrl->mhi_dev->dev;
+   struct pci_dev *pci_dev = to_pci_dev(mhi_cntrl->cntrl_dev);
+   struct pci_bus *bus = pci_dev->bus;
+   uint32_t instance;
const char *fw_name;
void *buf;
dma_addr_t dma_addr;
@@ -466,6 +473,13 @@ void mhi_fw_load_handler(struct mhi_controller 
*mhi_cntrl)

return;
}

+   instance = ((pci_domain_nr(bus) & 0xF) << 4) | (bus->number & 0xF);
+   instance &= QRTR_INSTANCE_MASK;
+
+   mhi_write_reg_field(mhi_cntrl, mhi_cntrl->bhi,
+   BHI_ERRDBG2, QRTR_INSTANCE_MASK,
+   QRTR_INSTANCE_SHIFT, instance);


You cannot not do this in MHI stack. Why can't you do this in the MHI 
controller

specific to QCN9000? And btw, is QCN9000 supported in mainline?

Thanks,
Mani


+
write_lock_irq(&mhi_cntrl->pm_lock);
mhi_cntrl->dev_state = MHI_STATE_RESET;
write_unlock_irq(&mhi_cntrl->pm_lock);
--
2.7.4



As others have stated, please refrain from adding protocol specific
code (such as PCIe)
in the MHI core driver. Please have this change in your controller.

If there is access to BHI registers required prior to power up from
MHI core, it is not
exposed right now. We can talk about how you can  achieve that, so you
can do this write
in your controller after mhi_prepare_for_power_up().

Thanks,
Bhaumik
---
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum,

a Linux Foundation Collaborative Project

 Thank you Jeffrey, Manivannan and Bhaumik.
 Adding Bjorn for his review and suggestions.

 Thanks,
 Gokul

[PATCH v6 1/9] uapi: virtio_ids: add a sound device type ID from OASIS spec

[Anton Yakovlev]

The OASIS virtio spec defines a sound device type ID that is not
present in the header yet.

Signed-off-by: Anton Yakovlev 
---
 include/uapi/linux/virtio_ids.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/uapi/linux/virtio_ids.h b/include/uapi/linux/virtio_ids.h
index bc1c0621f5ed..029a2e07a7f9 100644
--- a/include/uapi/linux/virtio_ids.h
+++ b/include/uapi/linux/virtio_ids.h
@@ -51,6 +51,7 @@
 #define VIRTIO_ID_PSTORE   22 /* virtio pstore device */
 #define VIRTIO_ID_IOMMU23 /* virtio IOMMU */
 #define VIRTIO_ID_MEM  24 /* virtio mem */
+#define VIRTIO_ID_SOUND25 /* virtio sound */
 #define VIRTIO_ID_FS   26 /* virtio filesystem */
 #define VIRTIO_ID_PMEM 27 /* virtio pmem */
 #define VIRTIO_ID_MAC80211_HWSIM   29 /* virtio mac80211-hwsim */
-- 
2.30.1

[PATCH v6 2/9] ALSA: virtio: add virtio sound driver

[Anton Yakovlev]

Introduce skeleton of the virtio sound driver. The driver implements
the virtio sound device specification, which has become part of the
virtio standard.

Initial initialization of the device, virtqueues and creation of an
empty ALSA sound device.

Signed-off-by: Anton Yakovlev 
---
 MAINTAINERS |   9 +
 include/uapi/linux/virtio_snd.h | 334 
 sound/Kconfig   |   2 +
 sound/Makefile  |   3 +-
 sound/virtio/Kconfig|  10 +
 sound/virtio/Makefile   |   7 +
 sound/virtio/virtio_card.c  | 289 +++
 sound/virtio/virtio_card.h  |  65 +++
 8 files changed, 718 insertions(+), 1 deletion(-)
 create mode 100644 include/uapi/linux/virtio_snd.h
 create mode 100644 sound/virtio/Kconfig
 create mode 100644 sound/virtio/Makefile
 create mode 100644 sound/virtio/virtio_card.c
 create mode 100644 sound/virtio/virtio_card.h

diff --git a/MAINTAINERS b/MAINTAINERS
index c71664ca8bfd..4369946434ad 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -19049,6 +19049,15 @@ W: https://virtio-mem.gitlab.io/
 F: drivers/virtio/virtio_mem.c
 F: include/uapi/linux/virtio_mem.h
 
+VIRTIO SOUND DRIVER
+M: Anton Yakovlev 
+M: "Michael S. Tsirkin" 
+L: virtualizat...@lists.linux-foundation.org
+L: alsa-de...@alsa-project.org (moderated for non-subscribers)
+S: Maintained
+F: include/uapi/linux/virtio_snd.h
+F: sound/virtio/*
+
 VIRTUAL BOX GUEST DEVICE DRIVER
 M: Hans de Goede 
 M: Arnd Bergmann 
diff --git a/include/uapi/linux/virtio_snd.h b/include/uapi/linux/virtio_snd.h
new file mode 100644
index ..dfe49547a7b0
--- /dev/null
+++ b/include/uapi/linux/virtio_snd.h
@@ -0,0 +1,334 @@
+/* SPDX-License-Identifier: BSD-3-Clause */
+/*
+ * Copyright (C) 2021 OpenSynergy GmbH
+ */
+#ifndef VIRTIO_SND_IF_H
+#define VIRTIO_SND_IF_H
+
+#include 
+
+/***
+ * CONFIGURATION SPACE
+ */
+struct virtio_snd_config {
+   /* # of available physical jacks */
+   __le32 jacks;
+   /* # of available PCM streams */
+   __le32 streams;
+   /* # of available channel maps */
+   __le32 chmaps;
+};
+
+enum {
+   /* device virtqueue indexes */
+   VIRTIO_SND_VQ_CONTROL = 0,
+   VIRTIO_SND_VQ_EVENT,
+   VIRTIO_SND_VQ_TX,
+   VIRTIO_SND_VQ_RX,
+   /* # of device virtqueues */
+   VIRTIO_SND_VQ_MAX
+};
+
+/***
+ * COMMON DEFINITIONS
+ */
+
+/* supported dataflow directions */
+enum {
+   VIRTIO_SND_D_OUTPUT = 0,
+   VIRTIO_SND_D_INPUT
+};
+
+enum {
+   /* jack control request types */
+   VIRTIO_SND_R_JACK_INFO = 1,
+   VIRTIO_SND_R_JACK_REMAP,
+
+   /* PCM control request types */
+   VIRTIO_SND_R_PCM_INFO = 0x0100,
+   VIRTIO_SND_R_PCM_SET_PARAMS,
+   VIRTIO_SND_R_PCM_PREPARE,
+   VIRTIO_SND_R_PCM_RELEASE,
+   VIRTIO_SND_R_PCM_START,
+   VIRTIO_SND_R_PCM_STOP,
+
+   /* channel map control request types */
+   VIRTIO_SND_R_CHMAP_INFO = 0x0200,
+
+   /* jack event types */
+   VIRTIO_SND_EVT_JACK_CONNECTED = 0x1000,
+   VIRTIO_SND_EVT_JACK_DISCONNECTED,
+
+   /* PCM event types */
+   VIRTIO_SND_EVT_PCM_PERIOD_ELAPSED = 0x1100,
+   VIRTIO_SND_EVT_PCM_XRUN,
+
+   /* common status codes */
+   VIRTIO_SND_S_OK = 0x8000,
+   VIRTIO_SND_S_BAD_MSG,
+   VIRTIO_SND_S_NOT_SUPP,
+   VIRTIO_SND_S_IO_ERR
+};
+
+/* common header */
+struct virtio_snd_hdr {
+   __le32 code;
+};
+
+/* event notification */
+struct virtio_snd_event {
+   /* VIRTIO_SND_EVT_XXX */
+   struct virtio_snd_hdr hdr;
+   /* optional event data */
+   __le32 data;
+};
+
+/* common control request to query an item information */
+struct virtio_snd_query_info {
+   /* VIRTIO_SND_R_XXX_INFO */
+   struct virtio_snd_hdr hdr;
+   /* item start identifier */
+   __le32 start_id;
+   /* item count to query */
+   __le32 count;
+   /* item information size in bytes */
+   __le32 size;
+};
+
+/* common item information header */
+struct virtio_snd_info {
+   /* function group node id (High Definition Audio Specification 7.1.2) */
+   __le32 hda_fn_nid;
+};
+
+/***
+ * JACK CONTROL MESSAGES
+ */
+struct virtio_snd_jack_hdr {
+   /* VIRTIO_SND_R_JACK_XXX */
+   struct virtio_snd_hdr hdr;
+   /* 0 ... virtio_snd_config::jacks - 1 */
+   __le32 jack_id;
+};
+
+/* supported jack features */
+enum {
+   VIRTIO_SND_JACK_F_REMAP = 0
+};
+
+struct virtio_snd_jack_info {
+   /* common header */
+   struct virtio_snd_info hdr;
+   /* supported feature bit map (1 << VIRTIO_SND_JACK_F_XXX) */
+   __le32 features;
+   /* pin configuration (High Definition Audio Specifica

[PATCH v6 5/9] ALSA: virtio: handling control and I/O messages for the PCM device

[Anton Yakovlev]

The driver implements a message-based transport for I/O substream
operations. Before the start of the substream, the hardware buffer is
sliced into I/O messages, the number of which is equal to the current
number of periods. The size of each message is equal to the current
size of one period.

I/O messages are organized in an ordered queue. The completion of the
I/O message indicates an elapsed period (the only exception is the end
of the stream for the capture substream). Upon completion, the message
is automatically re-added to the end of the queue.

Signed-off-by: Anton Yakovlev 
---
 sound/virtio/Makefile |   3 +-
 sound/virtio/virtio_card.c|  18 +-
 sound/virtio/virtio_card.h|   9 +
 sound/virtio/virtio_pcm.c |  32 +++
 sound/virtio/virtio_pcm.h |  40 
 sound/virtio/virtio_pcm_msg.c | 417 ++
 6 files changed, 516 insertions(+), 3 deletions(-)
 create mode 100644 sound/virtio/virtio_pcm_msg.c

diff --git a/sound/virtio/Makefile b/sound/virtio/Makefile
index 69162a545a41..626af3cc3ed7 100644
--- a/sound/virtio/Makefile
+++ b/sound/virtio/Makefile
@@ -5,5 +5,6 @@ obj-$(CONFIG_SND_VIRTIO) += virtio_snd.o
 virtio_snd-objs := \
virtio_card.o \
virtio_ctl_msg.o \
-   virtio_pcm.o
+   virtio_pcm.o \
+   virtio_pcm_msg.o
 
diff --git a/sound/virtio/virtio_card.c b/sound/virtio/virtio_card.c
index c5e9ceaaa8a0..9f74261b234c 100644
--- a/sound/virtio/virtio_card.c
+++ b/sound/virtio/virtio_card.c
@@ -65,8 +65,16 @@ static void virtsnd_event_notify_cb(struct virtqueue *vqueue)
spin_lock_irqsave(&queue->lock, flags);
do {
virtqueue_disable_cb(vqueue);
-   while ((event = virtqueue_get_buf(vqueue, &length)))
+   while ((event = virtqueue_get_buf(vqueue, &length))) {
+   switch (le32_to_cpu(event->hdr.code)) {
+   case VIRTIO_SND_EVT_PCM_PERIOD_ELAPSED:
+   case VIRTIO_SND_EVT_PCM_XRUN:
+   virtsnd_pcm_event(snd, event);
+   break;
+   }
+
virtsnd_event_send(vqueue, event, true, GFP_ATOMIC);
+   }
if (unlikely(virtqueue_is_broken(vqueue)))
break;
} while (!virtqueue_enable_cb(vqueue));
@@ -87,7 +95,9 @@ static int virtsnd_find_vqs(struct virtio_snd *snd)
struct virtio_device *vdev = snd->vdev;
static vq_callback_t *callbacks[VIRTIO_SND_VQ_MAX] = {
[VIRTIO_SND_VQ_CONTROL] = virtsnd_ctl_notify_cb,
-   [VIRTIO_SND_VQ_EVENT] = virtsnd_event_notify_cb
+   [VIRTIO_SND_VQ_EVENT] = virtsnd_event_notify_cb,
+   [VIRTIO_SND_VQ_TX] = virtsnd_pcm_tx_notify_cb,
+   [VIRTIO_SND_VQ_RX] = virtsnd_pcm_rx_notify_cb
};
static const char *names[VIRTIO_SND_VQ_MAX] = {
[VIRTIO_SND_VQ_CONTROL] = "virtsnd-ctl",
@@ -273,6 +283,7 @@ static int virtsnd_probe(struct virtio_device *vdev)
 static void virtsnd_remove(struct virtio_device *vdev)
 {
struct virtio_snd *snd = vdev->priv;
+   unsigned int i;
 
virtsnd_ctl_msg_cancel_all(snd);
 
@@ -282,6 +293,9 @@ static void virtsnd_remove(struct virtio_device *vdev)
vdev->config->del_vqs(vdev);
vdev->config->reset(vdev);
 
+   for (i = 0; snd->substreams && i < snd->nsubstreams; ++i)
+   virtsnd_pcm_msg_free(&snd->substreams[i]);
+
kfree(snd->event_msgs);
 }
 
diff --git a/sound/virtio/virtio_card.h b/sound/virtio/virtio_card.h
index 4431cc8f0445..7e50f3835ab1 100644
--- a/sound/virtio/virtio_card.h
+++ b/sound/virtio/virtio_card.h
@@ -79,4 +79,13 @@ virtsnd_rx_queue(struct virtio_snd *snd)
return &snd->queues[VIRTIO_SND_VQ_RX];
 }
 
+static inline struct virtio_snd_queue *
+virtsnd_pcm_queue(struct virtio_pcm_substream *vss)
+{
+   if (vss->direction == SNDRV_PCM_STREAM_PLAYBACK)
+   return virtsnd_tx_queue(vss->snd);
+   else
+   return virtsnd_rx_queue(vss->snd);
+}
+
 #endif /* VIRTIO_SND_CARD_H */
diff --git a/sound/virtio/virtio_pcm.c b/sound/virtio/virtio_pcm.c
index 4348ead63c14..3cfd3520a9c0 100644
--- a/sound/virtio/virtio_pcm.c
+++ b/sound/virtio/virtio_pcm.c
@@ -337,6 +337,8 @@ int virtsnd_pcm_parse_cfg(struct virtio_snd *snd)
 
vss->snd = snd;
vss->sid = i;
+   init_waitqueue_head(&vss->msg_empty);
+   spin_lock_init(&vss->lock);
 
rc = virtsnd_pcm_build_hw(vss, &info[i]);
if (rc)
@@ -461,3 +463,33 @@ int virtsnd_pcm_build_devs(struct virtio_snd *snd)
 
return 0;
 }
+
+/**
+ * virtsnd_pcm_event() - Handle the PCM device event notification.
+ * @snd: VirtIO sound device.
+ * @event: VirtIO sound event.
+ *
+ * Context: Interrupt context.
+ */
+void virtsnd_pcm_event(struct virtio_snd *snd, struct virtio_snd_event *event)
+{
+   

[PATCH v6 4/9] ALSA: virtio: build PCM devices and substream hardware descriptors

[Anton Yakovlev]

Like the HDA specification, the virtio sound device specification links
PCM substreams, jacks and PCM channel maps into functional groups. For
each discovered group, a PCM device is created, the number of which
coincides with the group number.

Introduce the module parameters for setting the hardware buffer
parameters:
  pcm_buffer_ms [=160]
  pcm_periods_min [=2]
  pcm_periods_max [=16]
  pcm_period_ms_min [=10]
  pcm_period_ms_max [=80]

Signed-off-by: Anton Yakovlev 
---
 sound/virtio/Makefile  |   3 +-
 sound/virtio/virtio_card.c |  14 ++
 sound/virtio/virtio_card.h |  10 +
 sound/virtio/virtio_pcm.c  | 463 +
 sound/virtio/virtio_pcm.h  |  70 ++
 5 files changed, 559 insertions(+), 1 deletion(-)
 create mode 100644 sound/virtio/virtio_pcm.c
 create mode 100644 sound/virtio/virtio_pcm.h

diff --git a/sound/virtio/Makefile b/sound/virtio/Makefile
index dc551e637441..69162a545a41 100644
--- a/sound/virtio/Makefile
+++ b/sound/virtio/Makefile
@@ -4,5 +4,6 @@ obj-$(CONFIG_SND_VIRTIO) += virtio_snd.o
 
 virtio_snd-objs := \
virtio_card.o \
-   virtio_ctl_msg.o
+   virtio_ctl_msg.o \
+   virtio_pcm.o
 
diff --git a/sound/virtio/virtio_card.c b/sound/virtio/virtio_card.c
index 196cb97087b0..c5e9ceaaa8a0 100644
--- a/sound/virtio/virtio_card.c
+++ b/sound/virtio/virtio_card.c
@@ -175,6 +175,16 @@ static int virtsnd_build_devs(struct virtio_snd *snd)
 VIRTIO_SND_CARD_NAME " at %s/%s",
 dev_name(dev->parent), dev_name(dev));
 
+   rc = virtsnd_pcm_parse_cfg(snd);
+   if (rc)
+   return rc;
+
+   if (snd->nsubstreams) {
+   rc = virtsnd_pcm_build_devs(snd);
+   if (rc)
+   return rc;
+   }
+
return snd_card_register(snd->card);
 }
 
@@ -203,6 +213,9 @@ static int virtsnd_validate(struct virtio_device *vdev)
return -EINVAL;
}
 
+   if (virtsnd_pcm_validate(vdev))
+   return -EINVAL;
+
return 0;
 }
 
@@ -225,6 +238,7 @@ static int virtsnd_probe(struct virtio_device *vdev)
 
snd->vdev = vdev;
INIT_LIST_HEAD(&snd->ctl_msgs);
+   INIT_LIST_HEAD(&snd->pcm_list);
 
vdev->priv = snd;
 
diff --git a/sound/virtio/virtio_card.h b/sound/virtio/virtio_card.h
index 349311a30199..4431cc8f0445 100644
--- a/sound/virtio/virtio_card.h
+++ b/sound/virtio/virtio_card.h
@@ -12,9 +12,13 @@
 #include 
 
 #include "virtio_ctl_msg.h"
+#include "virtio_pcm.h"
 
 #define VIRTIO_SND_CARD_DRIVER "virtio-snd"
 #define VIRTIO_SND_CARD_NAME   "VirtIO SoundCard"
+#define VIRTIO_SND_PCM_NAME"VirtIO PCM"
+
+struct virtio_pcm_substream;
 
 /**
  * struct virtio_snd_queue - Virtqueue wrapper structure.
@@ -33,6 +37,9 @@ struct virtio_snd_queue {
  * @card: ALSA sound card.
  * @ctl_msgs: Pending control request list.
  * @event_msgs: Device events.
+ * @pcm_list: VirtIO PCM device list.
+ * @substreams: VirtIO PCM substreams.
+ * @nsubstreams: Number of PCM substreams.
  */
 struct virtio_snd {
struct virtio_device *vdev;
@@ -40,6 +47,9 @@ struct virtio_snd {
struct snd_card *card;
struct list_head ctl_msgs;
struct virtio_snd_event *event_msgs;
+   struct list_head pcm_list;
+   struct virtio_pcm_substream *substreams;
+   u32 nsubstreams;
 };
 
 /* Message completion timeout in milliseconds (module parameter). */
diff --git a/sound/virtio/virtio_pcm.c b/sound/virtio/virtio_pcm.c
new file mode 100644
index ..4348ead63c14
--- /dev/null
+++ b/sound/virtio/virtio_pcm.c
@@ -0,0 +1,463 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * virtio-snd: Virtio sound device
+ * Copyright (C) 2021 OpenSynergy GmbH
+ */
+#include 
+#include 
+
+#include "virtio_card.h"
+
+static unsigned int pcm_buffer_ms = 160;
+module_param(pcm_buffer_ms, uint, 0644);
+MODULE_PARM_DESC(pcm_buffer_ms, "PCM substream buffer time in milliseconds");
+
+static unsigned int pcm_periods_min = 2;
+module_param(pcm_periods_min, uint, 0644);
+MODULE_PARM_DESC(pcm_periods_min, "Minimum number of PCM periods");
+
+static unsigned int pcm_periods_max = 16;
+module_param(pcm_periods_max, uint, 0644);
+MODULE_PARM_DESC(pcm_periods_max, "Maximum number of PCM periods");
+
+static unsigned int pcm_period_ms_min = 10;
+module_param(pcm_period_ms_min, uint, 0644);
+MODULE_PARM_DESC(pcm_period_ms_min, "Minimum PCM period time in milliseconds");
+
+static unsigned int pcm_period_ms_max = 80;
+module_param(pcm_period_ms_max, uint, 0644);
+MODULE_PARM_DESC(pcm_period_ms_max, "Maximum PCM period time in milliseconds");
+
+/* Map for converting VirtIO format to ALSA format. */
+static const snd_pcm_format_t g_v2a_format_map[] = {
+   [VIRTIO_SND_PCM_FMT_IMA_ADPCM] = SNDRV_PCM_FORMAT_IMA_ADPCM,
+   [VIRTIO_SND_PCM_FMT_MU_LAW] = SNDRV_PCM_FORMAT_MU_LAW,
+   [VIRTIO_SND_PCM_FMT_A_LAW] = SNDRV_PCM_FORMAT_A_LAW,
+   [VIRTIO_SND_PCM_FMT_S8] = SNDRV_PCM_FORMAT_S8,
+   [V

[PATCH v6 3/9] ALSA: virtio: handling control messages

[Anton Yakovlev]

The control queue can be used by different parts of the driver to send
commands to the device. Control messages can be either synchronous or
asynchronous. The lifetime of a message is controlled by a reference
count.

Introduce a module parameter to set the message completion timeout:
  msg_timeout_ms [=1000]

Signed-off-by: Anton Yakovlev 
---
 sound/virtio/Makefile |   3 +-
 sound/virtio/virtio_card.c|  13 ++
 sound/virtio/virtio_card.h|   7 +
 sound/virtio/virtio_ctl_msg.c | 310 ++
 sound/virtio/virtio_ctl_msg.h |  78 +
 5 files changed, 410 insertions(+), 1 deletion(-)
 create mode 100644 sound/virtio/virtio_ctl_msg.c
 create mode 100644 sound/virtio/virtio_ctl_msg.h

diff --git a/sound/virtio/Makefile b/sound/virtio/Makefile
index 8c87ebb9982b..dc551e637441 100644
--- a/sound/virtio/Makefile
+++ b/sound/virtio/Makefile
@@ -3,5 +3,6 @@
 obj-$(CONFIG_SND_VIRTIO) += virtio_snd.o
 
 virtio_snd-objs := \
-   virtio_card.o
+   virtio_card.o \
+   virtio_ctl_msg.o
 
diff --git a/sound/virtio/virtio_card.c b/sound/virtio/virtio_card.c
index 697cb5f16e4d..196cb97087b0 100644
--- a/sound/virtio/virtio_card.c
+++ b/sound/virtio/virtio_card.c
@@ -11,6 +11,10 @@
 
 #include "virtio_card.h"
 
+int msg_timeout_ms = MSEC_PER_SEC;
+module_param(msg_timeout_ms, int, 0644);
+MODULE_PARM_DESC(msg_timeout_ms, "Message completion timeout in milliseconds");
+
 static void virtsnd_remove(struct virtio_device *vdev);
 
 /**
@@ -82,6 +86,7 @@ static int virtsnd_find_vqs(struct virtio_snd *snd)
 {
struct virtio_device *vdev = snd->vdev;
static vq_callback_t *callbacks[VIRTIO_SND_VQ_MAX] = {
+   [VIRTIO_SND_VQ_CONTROL] = virtsnd_ctl_notify_cb,
[VIRTIO_SND_VQ_EVENT] = virtsnd_event_notify_cb
};
static const char *names[VIRTIO_SND_VQ_MAX] = {
@@ -193,6 +198,11 @@ static int virtsnd_validate(struct virtio_device *vdev)
return -EINVAL;
}
 
+   if (!msg_timeout_ms) {
+   dev_err(&vdev->dev, "msg_timeout_ms value cannot be zero\n");
+   return -EINVAL;
+   }
+
return 0;
 }
 
@@ -214,6 +224,7 @@ static int virtsnd_probe(struct virtio_device *vdev)
return -ENOMEM;
 
snd->vdev = vdev;
+   INIT_LIST_HEAD(&snd->ctl_msgs);
 
vdev->priv = snd;
 
@@ -249,6 +260,8 @@ static void virtsnd_remove(struct virtio_device *vdev)
 {
struct virtio_snd *snd = vdev->priv;
 
+   virtsnd_ctl_msg_cancel_all(snd);
+
if (snd->card)
snd_card_free(snd->card);
 
diff --git a/sound/virtio/virtio_card.h b/sound/virtio/virtio_card.h
index b903b1b12e90..349311a30199 100644
--- a/sound/virtio/virtio_card.h
+++ b/sound/virtio/virtio_card.h
@@ -11,6 +11,8 @@
 #include 
 #include 
 
+#include "virtio_ctl_msg.h"
+
 #define VIRTIO_SND_CARD_DRIVER "virtio-snd"
 #define VIRTIO_SND_CARD_NAME   "VirtIO SoundCard"
 
@@ -29,15 +31,20 @@ struct virtio_snd_queue {
  * @vdev: Underlying virtio device.
  * @queues: Virtqueue wrappers.
  * @card: ALSA sound card.
+ * @ctl_msgs: Pending control request list.
  * @event_msgs: Device events.
  */
 struct virtio_snd {
struct virtio_device *vdev;
struct virtio_snd_queue queues[VIRTIO_SND_VQ_MAX];
struct snd_card *card;
+   struct list_head ctl_msgs;
struct virtio_snd_event *event_msgs;
 };
 
+/* Message completion timeout in milliseconds (module parameter). */
+extern int msg_timeout_ms;
+
 static inline struct virtio_snd_queue *
 virtsnd_control_queue(struct virtio_snd *snd)
 {
diff --git a/sound/virtio/virtio_ctl_msg.c b/sound/virtio/virtio_ctl_msg.c
new file mode 100644
index ..67a5a0301ba3
--- /dev/null
+++ b/sound/virtio/virtio_ctl_msg.c
@@ -0,0 +1,310 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * virtio-snd: Virtio sound device
+ * Copyright (C) 2021 OpenSynergy GmbH
+ */
+#include 
+#include 
+
+#include "virtio_card.h"
+
+/**
+ * struct virtio_snd_msg - Control message.
+ * @sg_request: Scattergather list containing a device request (header).
+ * @sg_response: Scattergather list containing a device response (status).
+ * @list: Pending message list entry.
+ * @notify: Request completed notification.
+ * @ref_count: Reference count used to manage a message lifetime.
+ */
+struct virtio_snd_msg {
+   struct scatterlist sg_request;
+   struct scatterlist sg_response;
+   struct list_head list;
+   struct completion notify;
+   refcount_t ref_count;
+};
+
+/**
+ * virtsnd_ctl_msg_ref() - Increment reference counter for the message.
+ * @msg: Control message.
+ *
+ * Context: Any context.
+ */
+void virtsnd_ctl_msg_ref(struct virtio_snd_msg *msg)
+{
+   refcount_inc(&msg->ref_count);
+}
+
+/**
+ * virtsnd_ctl_msg_unref() - Decrement reference counter for the message.
+ * @msg: Control message.
+ *
+ * The message will be freed when the ref_count value is 0.
+ *
+ * Context: Any context.
+ */
+void virts

Re: [RFC PATCH v5 11/19] virtio/vsock: dequeue callback for SOCK_SEQPACKET

[Arseny Krasnov]

On 24.02.2021 09:41, Michael S. Tsirkin wrote:
> On Wed, Feb 24, 2021 at 08:07:48AM +0300, Arseny Krasnov wrote:
>> On 23.02.2021 17:17, Michael S. Tsirkin wrote:
>>> On Thu, Feb 18, 2021 at 08:39:37AM +0300, Arseny Krasnov wrote:
 This adds transport callback and it's logic for SEQPACKET dequeue.
 Callback fetches RW packets from rx queue of socket until whole record
 is copied(if user's buffer is full, user is not woken up). This is done
 to not stall sender, because if we wake up user and it leaves syscall,
 nobody will send credit update for rest of record, and sender will wait
 for next enter of read syscall at receiver's side. So if user buffer is
 full, we just send credit update and drop data. If during copy SEQ_BEGIN
 was found(and not all data was copied), copying is restarted by reset
 user's iov iterator(previous unfinished data is dropped).

 Signed-off-by: Arseny Krasnov 
 ---
  include/linux/virtio_vsock.h|  10 +++
  include/uapi/linux/virtio_vsock.h   |  16 
  net/vmw_vsock/virtio_transport_common.c | 114 
  3 files changed, 140 insertions(+)

 diff --git a/include/linux/virtio_vsock.h b/include/linux/virtio_vsock.h
 index dc636b727179..003d06ae4a85 100644
 --- a/include/linux/virtio_vsock.h
 +++ b/include/linux/virtio_vsock.h
 @@ -36,6 +36,11 @@ struct virtio_vsock_sock {
u32 rx_bytes;
u32 buf_alloc;
struct list_head rx_queue;
 +
 +  /* For SOCK_SEQPACKET */
 +  u32 user_read_seq_len;
 +  u32 user_read_copied;
 +  u32 curr_rx_msg_cnt;
>>> wrap these in a struct to make it's clearer they
>>> are related?
>> Ack
  };
  
  struct virtio_vsock_pkt {
 @@ -80,6 +85,11 @@ virtio_transport_dgram_dequeue(struct vsock_sock *vsk,
   struct msghdr *msg,
   size_t len, int flags);
  
 +int
 +virtio_transport_seqpacket_dequeue(struct vsock_sock *vsk,
 + struct msghdr *msg,
 + int flags,
 + bool *msg_ready);
  s64 virtio_transport_stream_has_data(struct vsock_sock *vsk);
  s64 virtio_transport_stream_has_space(struct vsock_sock *vsk);
  
 diff --git a/include/uapi/linux/virtio_vsock.h 
 b/include/uapi/linux/virtio_vsock.h
 index 1d57ed3d84d2..cf9c165e5cca 100644
 --- a/include/uapi/linux/virtio_vsock.h
 +++ b/include/uapi/linux/virtio_vsock.h
 @@ -63,8 +63,14 @@ struct virtio_vsock_hdr {
__le32  fwd_cnt;
  } __attribute__((packed));
  
 +struct virtio_vsock_seq_hdr {
 +  __le32  msg_cnt;
 +  __le32  msg_len;
 +} __attribute__((packed));
 +
  enum virtio_vsock_type {
VIRTIO_VSOCK_TYPE_STREAM = 1,
 +  VIRTIO_VSOCK_TYPE_SEQPACKET = 2,
  };
  
  enum virtio_vsock_op {
 @@ -83,6 +89,11 @@ enum virtio_vsock_op {
VIRTIO_VSOCK_OP_CREDIT_UPDATE = 6,
/* Request the peer to send the credit info to us */
VIRTIO_VSOCK_OP_CREDIT_REQUEST = 7,
 +
 +  /* Record begin for SOCK_SEQPACKET */
 +  VIRTIO_VSOCK_OP_SEQ_BEGIN = 8,
 +  /* Record end for SOCK_SEQPACKET */
 +  VIRTIO_VSOCK_OP_SEQ_END = 9,
  };
  
  /* VIRTIO_VSOCK_OP_SHUTDOWN flags values */
 @@ -91,4 +102,9 @@ enum virtio_vsock_shutdown {
VIRTIO_VSOCK_SHUTDOWN_SEND = 2,
  };
  
 +/* VIRTIO_VSOCK_OP_RW flags values */
 +enum virtio_vsock_rw {
 +  VIRTIO_VSOCK_RW_EOR = 1,
 +};
 +
  #endif /* _UAPI_LINUX_VIRTIO_VSOCK_H */
>>> Probably a good idea to also have a feature bit gating
>>> this functionality.
>> IIUC this also requires some qemu patch, because in current
>>
>> implementation of vsock device in qemu, there is no 'set_features'
>>
>> callback for such device. This callback will handle guest's write
>>
>> to feature register, by calling vhost kernel backend, where this
>>
>> bit will be processed by host.
> Well patching userspace to make use of a kernel feature
> is par for the course, isn't it?
>
>> IMHO I'm not sure that SEQPACKET support needs feature
>>
>> bit - it is just two new ops for virtio vsock protocol, and from point
>>
>> of view of virtio device it is same as STREAM. May be it is needed
>>
>> for cases when client tries to connect to server which doesn't support
>>
>> SEQPACKET, so without bit result will be "Connection reset by peer",
>>
>> and with such bit client will know that server doesn't support it and
>>
>> 'socket(SOCK_SEQPACKET)' will return error?
> Yes, a better error handling would be one reason to do it like this.

May be it will be better to add special flag to OP_RST. When someone

tries to connect to server which doesn't support such socket type(seqpacket

or dgram), connection reset is sent. This reset carries special flag which

indicates, that such socket type is not supp

[PATCH v6 6/9] ALSA: virtio: PCM substream operators

[Anton Yakovlev]

Introduce the operators required for the operation of substreams.

Signed-off-by: Anton Yakovlev 
---
 sound/virtio/Makefile |   3 +-
 sound/virtio/virtio_pcm.c |   2 +
 sound/virtio/virtio_pcm.h |   4 +
 sound/virtio/virtio_pcm_ops.c | 453 ++
 4 files changed, 461 insertions(+), 1 deletion(-)
 create mode 100644 sound/virtio/virtio_pcm_ops.c

diff --git a/sound/virtio/Makefile b/sound/virtio/Makefile
index 626af3cc3ed7..34493226793f 100644
--- a/sound/virtio/Makefile
+++ b/sound/virtio/Makefile
@@ -6,5 +6,6 @@ virtio_snd-objs := \
virtio_card.o \
virtio_ctl_msg.o \
virtio_pcm.o \
-   virtio_pcm_msg.o
+   virtio_pcm_msg.o \
+   virtio_pcm_ops.o
 
diff --git a/sound/virtio/virtio_pcm.c b/sound/virtio/virtio_pcm.c
index 3cfd3520a9c0..3605151860f2 100644
--- a/sound/virtio/virtio_pcm.c
+++ b/sound/virtio/virtio_pcm.c
@@ -454,6 +454,8 @@ int virtsnd_pcm_build_devs(struct virtio_snd *snd)
 
for (kss = ks->substream; kss; kss = kss->next)
vs->substreams[kss->number]->substream = kss;
+
+   snd_pcm_set_ops(vpcm->pcm, i, &virtsnd_pcm_ops);
}
 
snd_pcm_set_managed_buffer_all(vpcm->pcm,
diff --git a/sound/virtio/virtio_pcm.h b/sound/virtio/virtio_pcm.h
index 7af41cad4e8f..55dfb19d14b3 100644
--- a/sound/virtio/virtio_pcm.h
+++ b/sound/virtio/virtio_pcm.h
@@ -28,6 +28,7 @@ struct virtio_pcm_msg;
  * @hw_ptr: Substream hardware pointer value in bytes [0 ... buffer_bytes).
  * @xfer_enabled: Data transfer state (0 - off, 1 - on).
  * @xfer_xrun: Data underflow/overflow state (0 - no xrun, 1 - xrun).
+ * @release: True if the substream must be released on the device side.
  * @msgs: Allocated I/O messages.
  * @nmsgs: Number of allocated I/O messages.
  * @msg_last_enqueued: Index of the last I/O message added to the virtqueue.
@@ -47,6 +48,7 @@ struct virtio_pcm_substream {
size_t hw_ptr;
bool xfer_enabled;
bool xfer_xrun;
+   bool release;
struct virtio_pcm_msg **msgs;
unsigned int nmsgs;
int msg_last_enqueued;
@@ -78,6 +80,8 @@ struct virtio_pcm {
struct virtio_pcm_stream streams[SNDRV_PCM_STREAM_LAST + 1];
 };
 
+extern const struct snd_pcm_ops virtsnd_pcm_ops;
+
 int virtsnd_pcm_validate(struct virtio_device *vdev);
 
 int virtsnd_pcm_parse_cfg(struct virtio_snd *snd);
diff --git a/sound/virtio/virtio_pcm_ops.c b/sound/virtio/virtio_pcm_ops.c
new file mode 100644
index ..d02d79bd94f3
--- /dev/null
+++ b/sound/virtio/virtio_pcm_ops.c
@@ -0,0 +1,453 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * virtio-snd: Virtio sound device
+ * Copyright (C) 2021 OpenSynergy GmbH
+ */
+#include 
+
+#include "virtio_card.h"
+
+/*
+ * I/O messages lifetime
+ * -
+ *
+ * Allocation:
+ *   Messages are initially allocated in the ops->hw_params() after the size 
and
+ *   number of periods have been successfully negotiated.
+ *
+ * Freeing:
+ *   Messages can be safely freed after the queue has been successfully flushed
+ *   (RELEASE command in the ops->sync_stop()) and the ops->hw_free() has been
+ *   called.
+ *
+ *   When the substream stops, the ops->sync_stop() waits until the device has
+ *   completed all pending messages. This wait can be interrupted either by a
+ *   signal or due to a timeout. In this case, the device can still access
+ *   messages even after calling ops->hw_free(). It can also issue an 
interrupt,
+ *   and the interrupt handler will also try to access message structures.
+ *
+ *   Therefore, freeing of already allocated messages occurs:
+ *
+ *   - in ops->hw_params(), if this operator was called several times in a row,
+ * or if ops->hw_free() failed to free messages previously;
+ *
+ *   - in ops->hw_free(), if the queue has been successfully flushed;
+ *
+ *   - in dev->release().
+ */
+
+/* Map for converting ALSA format to VirtIO format. */
+struct virtsnd_a2v_format {
+   snd_pcm_format_t alsa_bit;
+   unsigned int vio_bit;
+};
+
+static const struct virtsnd_a2v_format g_a2v_format_map[] = {
+   { SNDRV_PCM_FORMAT_IMA_ADPCM, VIRTIO_SND_PCM_FMT_IMA_ADPCM },
+   { SNDRV_PCM_FORMAT_MU_LAW, VIRTIO_SND_PCM_FMT_MU_LAW },
+   { SNDRV_PCM_FORMAT_A_LAW, VIRTIO_SND_PCM_FMT_A_LAW },
+   { SNDRV_PCM_FORMAT_S8, VIRTIO_SND_PCM_FMT_S8 },
+   { SNDRV_PCM_FORMAT_U8, VIRTIO_SND_PCM_FMT_U8 },
+   { SNDRV_PCM_FORMAT_S16_LE, VIRTIO_SND_PCM_FMT_S16 },
+   { SNDRV_PCM_FORMAT_U16_LE, VIRTIO_SND_PCM_FMT_U16 },
+   { SNDRV_PCM_FORMAT_S18_3LE, VIRTIO_SND_PCM_FMT_S18_3 },
+   { SNDRV_PCM_FORMAT_U18_3LE, VIRTIO_SND_PCM_FMT_U18_3 },
+   { SNDRV_PCM_FORMAT_S20_3LE, VIRTIO_SND_PCM_FMT_S20_3 },
+   { SNDRV_PCM_FORMAT_U20_3LE, VIRTIO_SND_PCM_FMT_U20_3 },
+   { SNDRV_PCM_FORMAT_S24_3LE, VIRTIO_SND_PCM_FMT_S24_3 },
+   { SNDRV_PCM_FORMAT_U24_3LE, VIRTIO_SND_PCM_FMT_U24_3 },
+   { SNDRV_

[PATCH v6 7/9] ALSA: virtio: introduce jack support

[Anton Yakovlev]

Enumerate all available jacks and create ALSA controls.

At the moment jacks have a simple implementation and can only be used
to receive notifications about a plugged in/out device.

Signed-off-by: Anton Yakovlev 
---
 sound/virtio/Makefile  |   1 +
 sound/virtio/virtio_card.c |  14 +++
 sound/virtio/virtio_card.h |  12 ++
 sound/virtio/virtio_jack.c | 233 +
 4 files changed, 260 insertions(+)
 create mode 100644 sound/virtio/virtio_jack.c

diff --git a/sound/virtio/Makefile b/sound/virtio/Makefile
index 34493226793f..09f485291285 100644
--- a/sound/virtio/Makefile
+++ b/sound/virtio/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_SND_VIRTIO) += virtio_snd.o
 virtio_snd-objs := \
virtio_card.o \
virtio_ctl_msg.o \
+   virtio_jack.o \
virtio_pcm.o \
virtio_pcm_msg.o \
virtio_pcm_ops.o
diff --git a/sound/virtio/virtio_card.c b/sound/virtio/virtio_card.c
index 9f74261b234c..c852afda5712 100644
--- a/sound/virtio/virtio_card.c
+++ b/sound/virtio/virtio_card.c
@@ -67,6 +67,10 @@ static void virtsnd_event_notify_cb(struct virtqueue *vqueue)
virtqueue_disable_cb(vqueue);
while ((event = virtqueue_get_buf(vqueue, &length))) {
switch (le32_to_cpu(event->hdr.code)) {
+   case VIRTIO_SND_EVT_JACK_CONNECTED:
+   case VIRTIO_SND_EVT_JACK_DISCONNECTED:
+   virtsnd_jack_event(snd, event);
+   break;
case VIRTIO_SND_EVT_PCM_PERIOD_ELAPSED:
case VIRTIO_SND_EVT_PCM_XRUN:
virtsnd_pcm_event(snd, event);
@@ -185,10 +189,20 @@ static int virtsnd_build_devs(struct virtio_snd *snd)
 VIRTIO_SND_CARD_NAME " at %s/%s",
 dev_name(dev->parent), dev_name(dev));
 
+   rc = virtsnd_jack_parse_cfg(snd);
+   if (rc)
+   return rc;
+
rc = virtsnd_pcm_parse_cfg(snd);
if (rc)
return rc;
 
+   if (snd->njacks) {
+   rc = virtsnd_jack_build_devs(snd);
+   if (rc)
+   return rc;
+   }
+
if (snd->nsubstreams) {
rc = virtsnd_pcm_build_devs(snd);
if (rc)
diff --git a/sound/virtio/virtio_card.h b/sound/virtio/virtio_card.h
index 7e50f3835ab1..2092da297a9d 100644
--- a/sound/virtio/virtio_card.h
+++ b/sound/virtio/virtio_card.h
@@ -18,6 +18,7 @@
 #define VIRTIO_SND_CARD_NAME   "VirtIO SoundCard"
 #define VIRTIO_SND_PCM_NAME"VirtIO PCM"
 
+struct virtio_jack;
 struct virtio_pcm_substream;
 
 /**
@@ -38,6 +39,8 @@ struct virtio_snd_queue {
  * @ctl_msgs: Pending control request list.
  * @event_msgs: Device events.
  * @pcm_list: VirtIO PCM device list.
+ * @jacks: VirtIO jacks.
+ * @njacks: Number of jacks.
  * @substreams: VirtIO PCM substreams.
  * @nsubstreams: Number of PCM substreams.
  */
@@ -48,6 +51,8 @@ struct virtio_snd {
struct list_head ctl_msgs;
struct virtio_snd_event *event_msgs;
struct list_head pcm_list;
+   struct virtio_jack *jacks;
+   u32 njacks;
struct virtio_pcm_substream *substreams;
u32 nsubstreams;
 };
@@ -88,4 +93,11 @@ virtsnd_pcm_queue(struct virtio_pcm_substream *vss)
return virtsnd_rx_queue(vss->snd);
 }
 
+int virtsnd_jack_parse_cfg(struct virtio_snd *snd);
+
+int virtsnd_jack_build_devs(struct virtio_snd *snd);
+
+void virtsnd_jack_event(struct virtio_snd *snd,
+   struct virtio_snd_event *event);
+
 #endif /* VIRTIO_SND_CARD_H */
diff --git a/sound/virtio/virtio_jack.c b/sound/virtio/virtio_jack.c
new file mode 100644
index ..c69f1dcdcc84
--- /dev/null
+++ b/sound/virtio/virtio_jack.c
@@ -0,0 +1,233 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * virtio-snd: Virtio sound device
+ * Copyright (C) 2021 OpenSynergy GmbH
+ */
+#include 
+#include 
+#include 
+
+#include "virtio_card.h"
+
+/**
+ * DOC: Implementation Status
+ *
+ * At the moment jacks have a simple implementation and can only be used to
+ * receive notifications about a plugged in/out device.
+ *
+ * VIRTIO_SND_R_JACK_REMAP
+ *   is not supported
+ */
+
+/**
+ * struct virtio_jack - VirtIO jack.
+ * @jack: Kernel jack control.
+ * @nid: Functional group node identifier.
+ * @features: Jack virtio feature bit map (1 << VIRTIO_SND_JACK_F_XXX).
+ * @defconf: Pin default configuration value.
+ * @caps: Pin capabilities value.
+ * @connected: Current jack connection status.
+ * @type: Kernel jack type (SND_JACK_XXX).
+ */
+struct virtio_jack {
+   struct snd_jack *jack;
+   u32 nid;
+   u32 features;
+   u32 defconf;
+   u32 caps;
+   bool connected;
+   int type;
+};
+
+/**
+ * virtsnd_jack_get_label() - Get the name string for the jack.
+ * @vjack: VirtIO jack.
+ *
+ * Returns the jack name based on the default pin configuration value (see HDA

[PATCH v6 9/9] ALSA: virtio: introduce device suspend/resume support

[Anton Yakovlev]

All running PCM substreams are stopped on device suspend and restarted
on device resume.

Signed-off-by: Anton Yakovlev 
---
 sound/virtio/virtio_card.c| 56 +++
 sound/virtio/virtio_pcm.c |  1 +
 sound/virtio/virtio_pcm_ops.c | 41 -
 3 files changed, 90 insertions(+), 8 deletions(-)

diff --git a/sound/virtio/virtio_card.c b/sound/virtio/virtio_card.c
index 59455a562018..c7ae8801991d 100644
--- a/sound/virtio/virtio_card.c
+++ b/sound/virtio/virtio_card.c
@@ -323,6 +323,58 @@ static void virtsnd_remove(struct virtio_device *vdev)
kfree(snd->event_msgs);
 }
 
+#ifdef CONFIG_PM_SLEEP
+/**
+ * virtsnd_freeze() - Suspend device.
+ * @vdev: VirtIO parent device.
+ *
+ * Context: Any context.
+ * Return: 0 on success, -errno on failure.
+ */
+static int virtsnd_freeze(struct virtio_device *vdev)
+{
+   struct virtio_snd *snd = vdev->priv;
+
+   virtsnd_ctl_msg_cancel_all(snd);
+
+   vdev->config->del_vqs(vdev);
+   vdev->config->reset(vdev);
+
+   kfree(snd->event_msgs);
+
+   /*
+* If the virtsnd_restore() fails before re-allocating events, then we
+* get a dangling pointer here.
+*/
+   snd->event_msgs = NULL;
+
+   return 0;
+}
+
+/**
+ * virtsnd_restore() - Resume device.
+ * @vdev: VirtIO parent device.
+ *
+ * Context: Any context.
+ * Return: 0 on success, -errno on failure.
+ */
+static int virtsnd_restore(struct virtio_device *vdev)
+{
+   struct virtio_snd *snd = vdev->priv;
+   int rc;
+
+   rc = virtsnd_find_vqs(snd);
+   if (rc)
+   return rc;
+
+   virtio_device_ready(vdev);
+
+   virtsnd_enable_event_vq(snd);
+
+   return 0;
+}
+#endif /* CONFIG_PM_SLEEP */
+
 static const struct virtio_device_id id_table[] = {
{ VIRTIO_ID_SOUND, VIRTIO_DEV_ANY_ID },
{ 0 },
@@ -335,6 +387,10 @@ static struct virtio_driver virtsnd_driver = {
.validate = virtsnd_validate,
.probe = virtsnd_probe,
.remove = virtsnd_remove,
+#ifdef CONFIG_PM_SLEEP
+   .freeze = virtsnd_freeze,
+   .restore = virtsnd_restore,
+#endif
 };
 
 static int __init init(void)
diff --git a/sound/virtio/virtio_pcm.c b/sound/virtio/virtio_pcm.c
index 3605151860f2..4a4a6583b002 100644
--- a/sound/virtio/virtio_pcm.c
+++ b/sound/virtio/virtio_pcm.c
@@ -109,6 +109,7 @@ static int virtsnd_pcm_build_hw(struct virtio_pcm_substream 
*vss,
SNDRV_PCM_INFO_BATCH |
SNDRV_PCM_INFO_BLOCK_TRANSFER |
SNDRV_PCM_INFO_INTERLEAVED |
+   SNDRV_PCM_INFO_RESUME |
SNDRV_PCM_INFO_PAUSE;
 
if (!info->channels_min || info->channels_min > info->channels_max) {
diff --git a/sound/virtio/virtio_pcm_ops.c b/sound/virtio/virtio_pcm_ops.c
index d02d79bd94f3..03a7e2666cfb 100644
--- a/sound/virtio/virtio_pcm_ops.c
+++ b/sound/virtio/virtio_pcm_ops.c
@@ -167,7 +167,8 @@ static int virtsnd_pcm_hw_params(struct snd_pcm_substream 
*substream,
int vrate = -1;
int rc;
 
-   if (virtsnd_pcm_msg_pending_num(vss)) {
+   if (runtime->status->state != SNDRV_PCM_STATE_SUSPENDED &&
+   virtsnd_pcm_msg_pending_num(vss)) {
dev_err(&vdev->dev, "SID %u: invalid I/O queue state\n",
vss->sid);
return -EBADFD;
@@ -231,6 +232,10 @@ static int virtsnd_pcm_hw_params(struct snd_pcm_substream 
*substream,
if (rc)
return rc;
 
+   /* If messages have already been allocated before, do nothing. */
+   if (runtime->status->state == SNDRV_PCM_STATE_SUSPENDED)
+   return 0;
+
/* Free previously allocated messages (if any). */
virtsnd_pcm_msg_free(vss);
 
@@ -267,20 +272,24 @@ static int virtsnd_pcm_hw_free(struct snd_pcm_substream 
*substream)
  */
 static int virtsnd_pcm_prepare(struct snd_pcm_substream *substream)
 {
+   struct snd_pcm_runtime *runtime = substream->runtime;
struct virtio_pcm_substream *vss = snd_pcm_substream_chip(substream);
struct virtio_device *vdev = vss->snd->vdev;
struct virtio_snd_msg *msg;
 
-   if (virtsnd_pcm_msg_pending_num(vss)) {
-   dev_err(&vdev->dev, "SID %u: invalid I/O queue state\n",
-   vss->sid);
-   return -EBADFD;
+   if (runtime->status->state != SNDRV_PCM_STATE_SUSPENDED) {
+   if (virtsnd_pcm_msg_pending_num(vss)) {
+   dev_err(&vdev->dev, "SID %u: invalid I/O queue state\n",
+   vss->sid);
+   return -EBADFD;
+   }
+
+   vss->buffer_bytes = snd_pcm_lib_buffer_bytes(substream);
+   vss->hw_ptr = 0;
+   vss->msg_last_enqueued = -1;
}
 
-   vss->buffer_bytes = snd_pcm_lib_buffer_bytes(substream);
-   vss->hw_ptr = 0;
vss->xfer_xrun = false;
-   vss->msg_last_enqueued = -1;
vss->msg_count 

[PATCH v6 8/9] ALSA: virtio: introduce PCM channel map support

[Anton Yakovlev]

Enumerate all available PCM channel maps and create ALSA controls.

Signed-off-by: Anton Yakovlev 
---
 sound/virtio/Makefile   |   1 +
 sound/virtio/virtio_card.c  |  10 ++
 sound/virtio/virtio_card.h  |   8 ++
 sound/virtio/virtio_chmap.c | 219 
 sound/virtio/virtio_pcm.h   |   4 +
 5 files changed, 242 insertions(+)
 create mode 100644 sound/virtio/virtio_chmap.c

diff --git a/sound/virtio/Makefile b/sound/virtio/Makefile
index 09f485291285..2742bddb8874 100644
--- a/sound/virtio/Makefile
+++ b/sound/virtio/Makefile
@@ -4,6 +4,7 @@ obj-$(CONFIG_SND_VIRTIO) += virtio_snd.o
 
 virtio_snd-objs := \
virtio_card.o \
+   virtio_chmap.o \
virtio_ctl_msg.o \
virtio_jack.o \
virtio_pcm.o \
diff --git a/sound/virtio/virtio_card.c b/sound/virtio/virtio_card.c
index c852afda5712..59455a562018 100644
--- a/sound/virtio/virtio_card.c
+++ b/sound/virtio/virtio_card.c
@@ -197,6 +197,10 @@ static int virtsnd_build_devs(struct virtio_snd *snd)
if (rc)
return rc;
 
+   rc = virtsnd_chmap_parse_cfg(snd);
+   if (rc)
+   return rc;
+
if (snd->njacks) {
rc = virtsnd_jack_build_devs(snd);
if (rc)
@@ -209,6 +213,12 @@ static int virtsnd_build_devs(struct virtio_snd *snd)
return rc;
}
 
+   if (snd->nchmaps) {
+   rc = virtsnd_chmap_build_devs(snd);
+   if (rc)
+   return rc;
+   }
+
return snd_card_register(snd->card);
 }
 
diff --git a/sound/virtio/virtio_card.h b/sound/virtio/virtio_card.h
index 2092da297a9d..6af3d4816f57 100644
--- a/sound/virtio/virtio_card.h
+++ b/sound/virtio/virtio_card.h
@@ -43,6 +43,8 @@ struct virtio_snd_queue {
  * @njacks: Number of jacks.
  * @substreams: VirtIO PCM substreams.
  * @nsubstreams: Number of PCM substreams.
+ * @chmaps: VirtIO channel maps.
+ * @nchmaps: Number of channel maps.
  */
 struct virtio_snd {
struct virtio_device *vdev;
@@ -55,6 +57,8 @@ struct virtio_snd {
u32 njacks;
struct virtio_pcm_substream *substreams;
u32 nsubstreams;
+   struct virtio_snd_chmap_info *chmaps;
+   u32 nchmaps;
 };
 
 /* Message completion timeout in milliseconds (module parameter). */
@@ -100,4 +104,8 @@ int virtsnd_jack_build_devs(struct virtio_snd *snd);
 void virtsnd_jack_event(struct virtio_snd *snd,
struct virtio_snd_event *event);
 
+int virtsnd_chmap_parse_cfg(struct virtio_snd *snd);
+
+int virtsnd_chmap_build_devs(struct virtio_snd *snd);
+
 #endif /* VIRTIO_SND_CARD_H */
diff --git a/sound/virtio/virtio_chmap.c b/sound/virtio/virtio_chmap.c
new file mode 100644
index ..5bc924933a59
--- /dev/null
+++ b/sound/virtio/virtio_chmap.c
@@ -0,0 +1,219 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * virtio-snd: Virtio sound device
+ * Copyright (C) 2021 OpenSynergy GmbH
+ */
+#include 
+
+#include "virtio_card.h"
+
+/* VirtIO->ALSA channel position map */
+static const u8 g_v2a_position_map[] = {
+   [VIRTIO_SND_CHMAP_NONE] = SNDRV_CHMAP_UNKNOWN,
+   [VIRTIO_SND_CHMAP_NA] = SNDRV_CHMAP_NA,
+   [VIRTIO_SND_CHMAP_MONO] = SNDRV_CHMAP_MONO,
+   [VIRTIO_SND_CHMAP_FL] = SNDRV_CHMAP_FL,
+   [VIRTIO_SND_CHMAP_FR] = SNDRV_CHMAP_FR,
+   [VIRTIO_SND_CHMAP_RL] = SNDRV_CHMAP_RL,
+   [VIRTIO_SND_CHMAP_RR] = SNDRV_CHMAP_RR,
+   [VIRTIO_SND_CHMAP_FC] = SNDRV_CHMAP_FC,
+   [VIRTIO_SND_CHMAP_LFE] = SNDRV_CHMAP_LFE,
+   [VIRTIO_SND_CHMAP_SL] = SNDRV_CHMAP_SL,
+   [VIRTIO_SND_CHMAP_SR] = SNDRV_CHMAP_SR,
+   [VIRTIO_SND_CHMAP_RC] = SNDRV_CHMAP_RC,
+   [VIRTIO_SND_CHMAP_FLC] = SNDRV_CHMAP_FLC,
+   [VIRTIO_SND_CHMAP_FRC] = SNDRV_CHMAP_FRC,
+   [VIRTIO_SND_CHMAP_RLC] = SNDRV_CHMAP_RLC,
+   [VIRTIO_SND_CHMAP_RRC] = SNDRV_CHMAP_RRC,
+   [VIRTIO_SND_CHMAP_FLW] = SNDRV_CHMAP_FLW,
+   [VIRTIO_SND_CHMAP_FRW] = SNDRV_CHMAP_FRW,
+   [VIRTIO_SND_CHMAP_FLH] = SNDRV_CHMAP_FLH,
+   [VIRTIO_SND_CHMAP_FCH] = SNDRV_CHMAP_FCH,
+   [VIRTIO_SND_CHMAP_FRH] = SNDRV_CHMAP_FRH,
+   [VIRTIO_SND_CHMAP_TC] = SNDRV_CHMAP_TC,
+   [VIRTIO_SND_CHMAP_TFL] = SNDRV_CHMAP_TFL,
+   [VIRTIO_SND_CHMAP_TFR] = SNDRV_CHMAP_TFR,
+   [VIRTIO_SND_CHMAP_TFC] = SNDRV_CHMAP_TFC,
+   [VIRTIO_SND_CHMAP_TRL] = SNDRV_CHMAP_TRL,
+   [VIRTIO_SND_CHMAP_TRR] = SNDRV_CHMAP_TRR,
+   [VIRTIO_SND_CHMAP_TRC] = SNDRV_CHMAP_TRC,
+   [VIRTIO_SND_CHMAP_TFLC] = SNDRV_CHMAP_TFLC,
+   [VIRTIO_SND_CHMAP_TFRC] = SNDRV_CHMAP_TFRC,
+   [VIRTIO_SND_CHMAP_TSL] = SNDRV_CHMAP_TSL,
+   [VIRTIO_SND_CHMAP_TSR] = SNDRV_CHMAP_TSR,
+   [VIRTIO_SND_CHMAP_LLFE] = SNDRV_CHMAP_LLFE,
+   [VIRTIO_SND_CHMAP_RLFE] = SNDRV_CHMAP_RLFE,
+   [VIRTIO_SND_CHMAP_BC] = SNDRV_CHMAP_BC,
+   [VIRTIO_SND_CHMAP_BLC] = SNDRV_CHMAP_BLC,
+   [VIRTIO_SND_CHMAP_BRC] = SNDRV_CHMAP_BRC
+};
+
+/**
+ * virtsnd_chmap_parse_cfg() - Parse the channel map configura

Re: [PATCH 1/2] list: Add list_is_null() to check if a list_head has been initialized

[Sergei Shtylyov]

Hello!

On 27.02.2021 1:49, Laurent Pinchart wrote:


From: Laurent Pinchart 

The new function checks if the list_head prev and next pointers are
NULL, in order to see if a list_head that has been zeroed when allocated
has been initialized with INIT_LIST_HEAD() or added to a list.


   So zeroed or initialized/added? :-)


This can be used in cleanup functions that want to support being safely
called when an object has not been initialized, to return immediately.
In most cases other fields of the object can be checked for this
purpose, but in some cases a list_head field is the only option.

Signed-off-by: Laurent Pinchart 
---
  include/linux/list.h | 13 +
  1 file changed, 13 insertions(+)

diff --git a/include/linux/list.h b/include/linux/list.h
index 85c92555e31f..e4fc6954de3b 100644
--- a/include/linux/list.h
+++ b/include/linux/list.h
@@ -29,6 +29,19 @@ static inline void INIT_LIST_HEAD(struct list_head *list)
list->prev = list;
  }
  
+/**

+ * list_is_null - check if a list_head has been initialized
+ * @list: the list
+ *
+ * Check if the list_head prev and next pointers are NULL. This is useful to
+ * see if a list_head that has been zeroed when allocated has been initialized
+ * with INIT_LIST_HEAD() or added to a list.


   So zeroed or initialized/added? :-)


+ */
+static inline bool list_is_null(struct list_head *list)
+{
+   return list->prev == NULL && list->next == NULL;


   Maybe instead:

return !list->prev && !list->next;

[...]

MBR, Sergei

[PATCH 4.4.y] arm: kprobes: Allow to handle reentered kprobe on single-stepping

[huangshaobo]

From: Masami Hiramatsu 

commit f3fbd7ec62dec1528fb8044034e2885f2b257941 upstream

This is arm port of commit 6a5022a56ac3 ("kprobes/x86: Allow to
handle reentered kprobe on single-stepping")

Since the FIQ handlers can interrupt in the single stepping
(or preparing the single stepping, do_debug etc.), we should
consider a kprobe is hit in the NMI handler. Even in that
case, the kprobe is allowed to be reentered as same as the
kprobes hit in kprobe handlers
(KPROBE_HIT_ACTIVE or KPROBE_HIT_SSDONE).

The real issue will happen when a kprobe hit while another
reentered kprobe is processing (KPROBE_REENTER), because
we already consumed a saved-area for the previous kprobe.

Signed-off-by: Masami Hiramatsu 
Signed-off-by: Jon Medhurst 
Fixes: 24ba613c9d6c ("ARM kprobes: core code")
Cc: sta...@vger.kernel.org #v2.6.25~v4.11
Signed-off-by: huangshaobo 
---
 arch/arm/probes/kprobes/core.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/probes/kprobes/core.c b/arch/arm/probes/kprobes/core.c
index 3eb018fa1a1f..c3362ddd6c4c 100644
--- a/arch/arm/probes/kprobes/core.c
+++ b/arch/arm/probes/kprobes/core.c
@@ -270,6 +270,7 @@ void __kprobes kprobe_handler(struct pt_regs *regs)
switch (kcb->kprobe_status) {
case KPROBE_HIT_ACTIVE:
case KPROBE_HIT_SSDONE:
+   case KPROBE_HIT_SS:
/* A pre- or post-handler probe got us here. */
kprobes_inc_nmissed_count(p);
save_previous_kprobe(kcb);
@@ -278,6 +279,11 @@ void __kprobes kprobe_handler(struct pt_regs *regs)
singlestep(p, regs, kcb);
restore_previous_kprobe(kcb);
break;
+   case KPROBE_REENTER:
+   /* A nested probe was hit in FIQ, it is a BUG */
+   pr_warn("Unrecoverable kprobe detected at 
%p.\n",
+   p->addr);
+   /* fall through */
default:
/* impossible cases */
BUG();
-- 
2.12.3

Re: [Linuxarm] [PATCH v1] drm/nouveau/device: append a NUL-terminated character for the string which filled by strncpy()

[luojiaxing]

On 2021/2/26 9:01, Song Bao Hua (Barry Song) wrote:



-Original Message-
From: Luo Jiaxing [mailto:luojiax...@huawei.com]
Sent: Friday, February 26, 2021 12:39 AM
To: nouv...@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
bske...@redhat.com
Cc: linux-kernel@vger.kernel.org; linux...@openeuler.org; luojiaxing

Subject: [Linuxarm] [PATCH v1] drm/nouveau/device: append a NUL-terminated
character for the string which filled by strncpy()

Following warning is found when using W=1 to build kernel:

In function ‘nvkm_udevice_info’,
 inlined from ‘nvkm_udevice_mthd’ at
drivers/gpu/drm/nouveau/nvkm/engine/device/user.c:195:10:
drivers/gpu/drm/nouveau/nvkm/engine/device/user.c:164:2: warning: ‘strncpy’
specified bound 16 equals destination size [-Wstringop-truncation]
   164 |  strncpy(args->v0.chip, device->chip->name, sizeof(args->v0.chip));
drivers/gpu/drm/nouveau/nvkm/engine/device/user.c:165:2: warning: ‘strncpy’
specified bound 64 equals destination size [-Wstringop-truncation]
   165 |  strncpy(args->v0.name, device->name, sizeof(args->v0.name));

The reason of this warning is strncpy() does not guarantee that the
destination buffer will be NUL terminated. If the length of source string
is bigger than number we set by third input parameter, only first [number]
of characters is copied to the destination, and no NUL-terminated is
automatically added. There are some potential risks.

Signed-off-by: Luo Jiaxing 
---
  drivers/gpu/drm/nouveau/nvkm/engine/device/user.c | 6 --
  1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/user.c
b/drivers/gpu/drm/nouveau/nvkm/engine/device/user.c
index fea9d8f..2a32fe0 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/device/user.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/user.c
@@ -161,8 +161,10 @@ nvkm_udevice_info(struct nvkm_udevice *udev, void *data,
u32 size)
if (imem && args->v0.ram_size > 0)
args->v0.ram_user = args->v0.ram_user - imem->reserved;

-   strncpy(args->v0.chip, device->chip->name, sizeof(args->v0.chip));
-   strncpy(args->v0.name, device->name, sizeof(args->v0.name));
+   strncpy(args->v0.chip, device->chip->name, sizeof(args->v0.chip) - 1);
+   args->v0.chip[sizeof(args->v0.chip) - 1] = '\0';
+   strncpy(args->v0.name, device->name, sizeof(args->v0.name) - 1);
+   args->v0.name[sizeof(args->v0.name) - 1] = '\0';


Isn't it better to use snprintf()?



yes, you are right,  snprintf() is better. Most of drivers use 
snprintf() to format a string,


but still some examples in kernel that use it for copy.


I modify to code to the follow and I think it's the same with strncpy 
but more safety


diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/user.c 
b/drivers/gpu/drm/nouveau/nvkm/engine/device/user.c

index fea9d8f..4bf65bb 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/device/user.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/user.c
@@ -161,8 +161,8 @@ nvkm_udevice_info(struct nvkm_udevice *udev, void 
*data, u32 size)

    if (imem && args->v0.ram_size > 0)
    args->v0.ram_user = args->v0.ram_user - imem->reserved;

-   strncpy(args->v0.chip, device->chip->name, sizeof(args->v0.chip));
-   strncpy(args->v0.name, device->name, sizeof(args->v0.name));
+   snprintf(args->v0.chip, sizeof(args->v0.chip), "%s", 
device->chip->name);

+   snprintf(args->v0.name, sizeof(args->v0.name), "%s", device->name);

Thanks

Jiaxing





return 0;
  }


Thanks
Barry

drivers/pinctrl/qcom/pinctrl-lpass-lpi.c:458 lpi_config_set() error: uninitialized symbol 'strength'.

[Dan Carpenter]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   2c87f7a38f930ef6f6a7bdd04aeb82ce3971b54b
commit: 6e261d1090d6db0e9dd22978b6f38a2c58558a3f pinctrl: qcom: Add sm8250 
lpass lpi pinctrl driver
config: arm64-randconfig-m031-20210226 (attached as .config)
compiler: aarch64-linux-gcc (GCC) 9.3.0

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 
Reported-by: Dan Carpenter 

New smatch warnings:
drivers/pinctrl/qcom/pinctrl-lpass-lpi.c:458 lpi_config_set() error: 
uninitialized symbol 'strength'.

Old smatch warnings:
drivers/pinctrl/qcom/pinctrl-lpass-lpi.c:457 lpi_config_set() error: 
uninitialized symbol 'pullup'.

vim +/strength +458 drivers/pinctrl/qcom/pinctrl-lpass-lpi.c

6e261d1090d6db Srinivas Kandagatla 2020-12-02  391  static int 
lpi_config_set(struct pinctrl_dev *pctldev, unsigned int group,
6e261d1090d6db Srinivas Kandagatla 2020-12-02  392
unsigned long *configs, unsigned int nconfs)
6e261d1090d6db Srinivas Kandagatla 2020-12-02  393  {
6e261d1090d6db Srinivas Kandagatla 2020-12-02  394  struct lpi_pinctrl 
*pctrl = dev_get_drvdata(pctldev->dev);
6e261d1090d6db Srinivas Kandagatla 2020-12-02  395  unsigned int param, 
arg, pullup, strength;

 

6e261d1090d6db Srinivas Kandagatla 2020-12-02  396  bool value, 
output_enabled = false;
6e261d1090d6db Srinivas Kandagatla 2020-12-02  397  const struct 
lpi_pingroup *g;
6e261d1090d6db Srinivas Kandagatla 2020-12-02  398  unsigned long sval;
6e261d1090d6db Srinivas Kandagatla 2020-12-02  399  int i, slew_offset;
6e261d1090d6db Srinivas Kandagatla 2020-12-02  400  u32 val;
6e261d1090d6db Srinivas Kandagatla 2020-12-02  401  
6e261d1090d6db Srinivas Kandagatla 2020-12-02  402  g = 
&pctrl->data->groups[group];
6e261d1090d6db Srinivas Kandagatla 2020-12-02  403  for (i = 0; i < nconfs; 
i++) {
6e261d1090d6db Srinivas Kandagatla 2020-12-02  404  param = 
pinconf_to_config_param(configs[i]);
6e261d1090d6db Srinivas Kandagatla 2020-12-02  405  arg = 
pinconf_to_config_argument(configs[i]);
6e261d1090d6db Srinivas Kandagatla 2020-12-02  406  
6e261d1090d6db Srinivas Kandagatla 2020-12-02  407  switch (param) {
6e261d1090d6db Srinivas Kandagatla 2020-12-02  408  case 
PIN_CONFIG_BIAS_DISABLE:
6e261d1090d6db Srinivas Kandagatla 2020-12-02  409  pullup 
= LPI_GPIO_BIAS_DISABLE;
6e261d1090d6db Srinivas Kandagatla 2020-12-02  410  break;
6e261d1090d6db Srinivas Kandagatla 2020-12-02  411  case 
PIN_CONFIG_BIAS_PULL_DOWN:
6e261d1090d6db Srinivas Kandagatla 2020-12-02  412  pullup 
= LPI_GPIO_PULL_DOWN;
6e261d1090d6db Srinivas Kandagatla 2020-12-02  413  break;
6e261d1090d6db Srinivas Kandagatla 2020-12-02  414  case 
PIN_CONFIG_BIAS_BUS_HOLD:
6e261d1090d6db Srinivas Kandagatla 2020-12-02  415  pullup 
= LPI_GPIO_KEEPER;
6e261d1090d6db Srinivas Kandagatla 2020-12-02  416  break;
6e261d1090d6db Srinivas Kandagatla 2020-12-02  417  case 
PIN_CONFIG_BIAS_PULL_UP:
6e261d1090d6db Srinivas Kandagatla 2020-12-02  418  pullup 
= LPI_GPIO_PULL_UP;
6e261d1090d6db Srinivas Kandagatla 2020-12-02  419  break;
6e261d1090d6db Srinivas Kandagatla 2020-12-02  420  case 
PIN_CONFIG_INPUT_ENABLE:
6e261d1090d6db Srinivas Kandagatla 2020-12-02  421  
output_enabled = false;
6e261d1090d6db Srinivas Kandagatla 2020-12-02  422  break;
6e261d1090d6db Srinivas Kandagatla 2020-12-02  423  case 
PIN_CONFIG_OUTPUT:
6e261d1090d6db Srinivas Kandagatla 2020-12-02  424  
output_enabled = true;
6e261d1090d6db Srinivas Kandagatla 2020-12-02  425  value = 
arg;
6e261d1090d6db Srinivas Kandagatla 2020-12-02  426  break;
6e261d1090d6db Srinivas Kandagatla 2020-12-02  427  case 
PIN_CONFIG_DRIVE_STRENGTH:
6e261d1090d6db Srinivas Kandagatla 2020-12-02  428  
strength = arg;

^^^
Only initialized here.

6e261d1090d6db Srinivas Kandagatla 2020-12-02  429  break;
6e261d1090d6db Srinivas Kandagatla 2020-12-02  430  case 
PIN_CONFIG_SLEW_RATE:
6e261d1090d6db Srinivas Kandagatla 2020-12-02  431  if (arg 
> LPI_SLEW_RATE_MAX) {
6e261d1090d6db Srinivas Kandagatla 2020-12-02  432  
dev_err(pctldev->dev, "invalid slew rate %u for pin: %d\n",
6e261d1090d6db Srinivas Kandagatla 2020-12-02  433  
arg, group);
6e261d1090d6db Srinivas Kandagatla 2020-12-02  434  
return

drivers/cpufreq/qcom-cpufreq-hw.c:377 qcom_cpufreq_hw_cpu_init() error: we previously assumed 'data' could be null (see line 327)

[Dan Carpenter]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   8b83369ddcb3fb9cab5c1088987ce477565bb630
commit: 67fc209b527d023db4d087c68e44e9790aa089ef cpufreq: qcom-hw: drop 
devm_xxx() calls from init/exit hooks
config: arm64-randconfig-m031-20210226 (attached as .config)
compiler: aarch64-linux-gcc (GCC) 9.3.0

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 
Reported-by: Dan Carpenter 

smatch warnings:
drivers/cpufreq/qcom-cpufreq-hw.c:377 qcom_cpufreq_hw_cpu_init() error: we 
previously assumed 'data' could be null (see line 327)
drivers/cpufreq/qcom-cpufreq-hw.c:377 qcom_cpufreq_hw_cpu_init() error: 
dereferencing freed memory 'data'

vim +/data +377 drivers/cpufreq/qcom-cpufreq-hw.c

2849dd8bc72b62 Taniya Das2018-12-14  277  static int 
qcom_cpufreq_hw_cpu_init(struct cpufreq_policy *policy)
2849dd8bc72b62 Taniya Das2018-12-14  278  {
bd74e286b35413 Manivannan Sadhasivam 2020-09-08  279struct platform_device 
*pdev = cpufreq_get_driver_data();
bd74e286b35413 Manivannan Sadhasivam 2020-09-08  280struct device *dev = 
&pdev->dev;
2849dd8bc72b62 Taniya Das2018-12-14  281struct of_phandle_args 
args;
2849dd8bc72b62 Taniya Das2018-12-14  282struct device_node 
*cpu_np;
55538fbc79e926 Taniya Das2019-01-31  283struct device *cpu_dev;
67fc209b527d02 Shawn Guo 2021-01-19  284struct resource *res;
2849dd8bc72b62 Taniya Das2018-12-14  285void __iomem *base;
dcd1fd724c19fe Manivannan Sadhasivam 2020-09-15  286struct 
qcom_cpufreq_data *data;
2849dd8bc72b62 Taniya Das2018-12-14  287int ret, index;
2849dd8bc72b62 Taniya Das2018-12-14  288  
55538fbc79e926 Taniya Das2019-01-31  289cpu_dev = 
get_cpu_device(policy->cpu);
55538fbc79e926 Taniya Das2019-01-31  290if (!cpu_dev) {
55538fbc79e926 Taniya Das2019-01-31  291pr_err("%s: 
failed to get cpu%d device\n", __func__,
55538fbc79e926 Taniya Das2019-01-31  292   
policy->cpu);
55538fbc79e926 Taniya Das2019-01-31  293return -ENODEV;
55538fbc79e926 Taniya Das2019-01-31  294}
55538fbc79e926 Taniya Das2019-01-31  295  
2849dd8bc72b62 Taniya Das2018-12-14  296cpu_np = 
of_cpu_device_node_get(policy->cpu);
2849dd8bc72b62 Taniya Das2018-12-14  297if (!cpu_np)
2849dd8bc72b62 Taniya Das2018-12-14  298return -EINVAL;
2849dd8bc72b62 Taniya Das2018-12-14  299  
2849dd8bc72b62 Taniya Das2018-12-14  300ret = 
of_parse_phandle_with_args(cpu_np, "qcom,freq-domain",
2849dd8bc72b62 Taniya Das2018-12-14  301
 "#freq-domain-cells", 0, &args);
2849dd8bc72b62 Taniya Das2018-12-14  302of_node_put(cpu_np);
2849dd8bc72b62 Taniya Das2018-12-14  303if (ret)
2849dd8bc72b62 Taniya Das2018-12-14  304return ret;
2849dd8bc72b62 Taniya Das2018-12-14  305  
2849dd8bc72b62 Taniya Das2018-12-14  306index = args.args[0];
2849dd8bc72b62 Taniya Das2018-12-14  307  
67fc209b527d02 Shawn Guo 2021-01-19  308res = 
platform_get_resource(pdev, IORESOURCE_MEM, index);
67fc209b527d02 Shawn Guo 2021-01-19  309if (!res) {
67fc209b527d02 Shawn Guo 2021-01-19  310dev_err(dev, 
"failed to get mem resource %d\n", index);
67fc209b527d02 Shawn Guo 2021-01-19  311return -ENODEV;
67fc209b527d02 Shawn Guo 2021-01-19  312}
67fc209b527d02 Shawn Guo 2021-01-19  313  
67fc209b527d02 Shawn Guo 2021-01-19  314if 
(!request_mem_region(res->start, resource_size(res), res->name)) {
67fc209b527d02 Shawn Guo 2021-01-19  315dev_err(dev, 
"failed to request resource %pR\n", res);
67fc209b527d02 Shawn Guo 2021-01-19  316return -EBUSY;
67fc209b527d02 Shawn Guo 2021-01-19  317}
2849dd8bc72b62 Taniya Das2018-12-14  318  
67fc209b527d02 Shawn Guo 2021-01-19  319base = 
ioremap(res->start, resource_size(res));
67fc209b527d02 Shawn Guo 2021-01-19  320if (IS_ERR(base)) {
67fc209b527d02 Shawn Guo 2021-01-19  321dev_err(dev, 
"failed to map resource %pR\n", res);
67fc209b527d02 Shawn Guo 2021-01-19  322ret = 
PTR_ERR(base);
67fc209b527d02 Shawn Guo 2021-01-19  323goto 
release_region;
67fc209b527d02 Shawn Guo 2021-01-19  324}
67fc209b527d02 Shawn Guo 2021-01-19  325  
67fc209b527d02 Shawn Guo 2021-01-19  326data = 
kzalloc(sizeof(*data), GFP_KERNEL);
dcd1fd724c19fe Manivannan Sadhasivam 2020-09-15 @327if (!data) {
dcd1fd724c19fe

arch/powerpc/sysdev/xive/common.c:279 xmon_xive_get_irq_config() warn: variable dereferenced before check 'd' (see line 261)

[Dan Carpenter]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   8b83369ddcb3fb9cab5c1088987ce477565bb630
commit: 97ef275077932c65b1b8ec5022abd737a9fbf3e0 powerpc/xive: Fix xmon support 
on the PowerNV platform
config: powerpc64-randconfig-m031-20210226 (attached as .config)
compiler: powerpc64-linux-gcc (GCC) 9.3.0

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 
Reported-by: Dan Carpenter 

smatch warnings:
arch/powerpc/sysdev/xive/common.c:279 xmon_xive_get_irq_config() warn: variable 
dereferenced before check 'd' (see line 261)

vim +/d +279 arch/powerpc/sysdev/xive/common.c

5896163f7f91c05 Cédric Le Goater 2019-09-10  259  int 
xmon_xive_get_irq_config(u32 hw_irq, struct irq_data *d)
b4868ff55d082bc Cédric Le Goater 2019-08-14  260  {
97ef275077932c6 Cédric Le Goater 2020-03-06 @261struct irq_chip *chip = 
irq_data_get_irq_chip(d);

  ^
Dereferenced inside function

5896163f7f91c05 Cédric Le Goater 2019-09-10  262int rc;
5896163f7f91c05 Cédric Le Goater 2019-09-10  263u32 target;
5896163f7f91c05 Cédric Le Goater 2019-09-10  264u8 prio;
5896163f7f91c05 Cédric Le Goater 2019-09-10  265u32 lirq;
5896163f7f91c05 Cédric Le Goater 2019-09-10  266  
97ef275077932c6 Cédric Le Goater 2020-03-06  267if (!is_xive_irq(chip))
97ef275077932c6 Cédric Le Goater 2020-03-06  268return -EINVAL;
97ef275077932c6 Cédric Le Goater 2020-03-06  269  
5896163f7f91c05 Cédric Le Goater 2019-09-10  270rc = 
xive_ops->get_irq_config(hw_irq, &target, &prio, &lirq);
5896163f7f91c05 Cédric Le Goater 2019-09-10  271if (rc) {
5896163f7f91c05 Cédric Le Goater 2019-09-10  272
xmon_printf("IRQ 0x%08x : no config rc=%d\n", hw_irq, rc);
5896163f7f91c05 Cédric Le Goater 2019-09-10  273return rc;
5896163f7f91c05 Cédric Le Goater 2019-09-10  274}
5896163f7f91c05 Cédric Le Goater 2019-09-10  275  
5896163f7f91c05 Cédric Le Goater 2019-09-10  276xmon_printf("IRQ 0x%08x 
: target=0x%x prio=%02x lirq=0x%x ",
5896163f7f91c05 Cédric Le Goater 2019-09-10  277hw_irq, 
target, prio, lirq);
5896163f7f91c05 Cédric Le Goater 2019-09-10  278  
5896163f7f91c05 Cédric Le Goater 2019-09-10 @279if (d) {
^^
Checked too late

5896163f7f91c05 Cédric Le Goater 2019-09-10  280struct 
xive_irq_data *xd = irq_data_get_irq_handler_data(d);
5896163f7f91c05 Cédric Le Goater 2019-09-10  281u64 val = 
xive_esb_read(xd, XIVE_ESB_GET);
5896163f7f91c05 Cédric Le Goater 2019-09-10  282  
5896163f7f91c05 Cédric Le Goater 2019-09-10  283
xmon_printf("PQ=%c%c",
5896163f7f91c05 Cédric Le Goater 2019-09-10  284val 
& XIVE_ESB_VAL_P ? 'P' : '-',
5896163f7f91c05 Cédric Le Goater 2019-09-10  285val 
& XIVE_ESB_VAL_Q ? 'Q' : '-');
5896163f7f91c05 Cédric Le Goater 2019-09-10  286}
5896163f7f91c05 Cédric Le Goater 2019-09-10  287  
5896163f7f91c05 Cédric Le Goater 2019-09-10  288xmon_printf("\n");
5896163f7f91c05 Cédric Le Goater 2019-09-10  289return 0;
b4868ff55d082bc Cédric Le Goater 2019-08-14  290  }

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip

Re: [PATCH v7 0/3] Update to zstd-1.4.6

[Oleksandr Natalenko]

Hi.

On Thu, Dec 03, 2020 at 12:51:11PM -0800, Nick Terrell wrote:
> From: Nick Terrell 
> 
> Please pull from
> 
>   g...@github.com:terrelln/linux.git tags/v7-zstd-1.4.6
> 
> to get these changes. Alternatively the patchset is included.
> 
> This patchset upgrades the zstd library to the latest upstream release. The
> current zstd version in the kernel is a modified version of upstream 
> zstd-1.3.1.
> At the time it was integrated, zstd wasn't ready to be used in the kernel 
> as-is.
> But, it is now possible to use upstream zstd directly in the kernel.
> 
> I have not yet released zstd-1.4.6 upstream. I want the zstd version in the
> kernel to match up with a known upstream release, so we know exactly what code
> is running. Whenever this patchset is ready for merge, I will cut a release at
> the upstream commit that gets merged. This should not be necessary for future
> releases.
> 
> The kernel zstd library is automatically generated from upstream zstd. A 
> script
> makes the necessary changes and imports it into the kernel. The changes are:
> 
> 1. Replace all libc dependencies with kernel replacements and rewrite 
> includes.
> 2. Remove unncessary portability macros like: #if defined(_MSC_VER).
> 3. Use the kernel xxhash instead of bundling it.
> 
> This automation gets tested every commit by upstream's continuous integration.
> When we cut a new zstd release, we will submit a patch to the kernel to update
> the zstd version in the kernel.
> 
> I've updated zstd to upstream with one big patch because every commit must 
> build,
> so that precludes partial updates. Since the commit is 100% generated, I hope 
> the
> review burden is lightened. I considered replaying upstream commits, but that 
> is
> not possible because there have been ~3500 upstream commits since the last 
> zstd
> import, and the commits don't all build individually. The bulk update 
> preserves
> bisectablity because bugs can be bisected to the zstd version update. At that
> point the update can be reverted, and we can work with upstream to find and 
> fix
> the bug. After this big switch in how the kernel consumes zstd, future patches
> will be smaller, because they will only have one upstream release worth of
> changes each.
> 
> This patchset adds a new kernel-style wrapper around zstd. This wrapper API is
> functionally equivalent to the subset of the current zstd API that is 
> currently
> used. The wrapper API changes to be kernel style so that the symbols don't
> collide with zstd's symbols. The update to zstd-1.4.6 maintains the same API
> and preserves the semantics, so that none of the callers need to be updated.
> 
> This patchset comes in 2 parts:
> 1. The first 2 patches prepare for the zstd upgrade. The first patch adds the
>new kernel style API so zstd can be upgraded without modifying any callers.
>The second patch adds an indirection for the lib/decompress_unzstd.c
>including of all decompression source files.
> 2. Import zstd-1.4.6. This patch is completely generated from upstream using
>automated tooling.
> 
> I tested every caller of zstd on x86_64. I tested both after the 1.4.6 upgrade
> using the compatibility wrapper, and after the final patch in this series. 
> 
> I tested kernel and initramfs decompression in i386 and arm.
> 
> I ran benchmarks to compare the current zstd in the kernel with zstd-1.4.6.
> I benchmarked on x86_64 using QEMU with KVM enabled on an Intel i9-9900k.
> I found:
> * BtrFS zstd compression at levels 1 and 3 is 5% faster
> * BtrFS zstd decompression+read is 15% faster
> * SquashFS zstd decompression+read is 15% faster
> * F2FS zstd compression+write at level 3 is 8% faster
> * F2FS zstd decompression+read is 20% faster
> * ZRAM decompression+read is 30% faster
> * Kernel zstd decompression is 35% faster
> * Initramfs zstd decompression+build is 5% faster
> 
> The latest zstd also offers bug fixes and a 1 KB reduction in stack uage 
> during
> compression. For example the recent problem with large kernel decompression 
> has
> been fixed upstream for over 2 years https://lkml.org/lkml/2020/9/29/27.
> 
> Please let me know if there is anything that I can do to ease the way for 
> these
> patches. I think it is important because it gets large performance 
> improvements,
> contains bug fixes, and is switching to a more maintainable model of consuming
> upstream zstd directly, making it easy to keep up to date.
> 
> Best,
> Nick Terrell
> 
> v1 -> v2:
> * Successfully tested F2FS with help from Chao Yu to fix my test.
> * (1/9) Fix ZSTD_initCStream() wrapper to handle pledged_src_size=0 means 
> unknown.
>   This fixes F2FS with the zstd-1.4.6 compatibility wrapper, exposed by the 
> test.
> 
> v2 -> v3:
> * (3/9) Silence warnings by Kernel Test Robot:
>   https://github.com/facebook/zstd/pull/2324
>   Stack size warnings remain, but these aren't new, and the functions it 
> warns on
>   are either unused or not in the maximum stack path. This patchset reduces 
> zst

[PATCH] hwmon: corsair-psu: update calculation of LINEAR11 values

[Wilken Gottwalt]

Changes the way how LINEAR11 values are calculated. The new method
increases the precision of 2-3 digits.

old method:
corsairpsu-hid-3-1
Adapter: HID adapter
v_in:230.00 V
v_out +12v:   12.00 V
v_out +5v: 5.00 V
v_out +3.3v:   3.00 V
psu fan:0 RPM
vrm temp: +44.0°C
case temp:+37.0°C
power total: 152.00 W
power +12v:  112.00 W
power +5v:38.00 W
power +3.3v:   5.00 W
curr in:  N/A
curr +12v: 9.00 A
curr +5v:  7.00 A
curr +3.3v:  1000.00 mA

new method:
corsairpsu-hid-3-1
Adapter: HID adapter
v_in:230.00 V
v_out +12v:   12.16 V
v_out +5v: 5.01 V
v_out +3.3v:   3.30 V
psu fan:0 RPM
vrm temp: +44.5°C
case temp:+37.8°C
power total: 148.00 W
power +12v:  108.00 W
power +5v:37.00 W
power +3.3v:   4.50 W
curr in:  N/A
curr +12v: 9.25 A
curr +5v:  7.50 A
curr +3.3v:1.50 A

Co-developed-by: Jack Doan 
Signed-off-by: Jack Doan 
Signed-off-by: Wilken Gottwalt 
---
 drivers/hwmon/corsair-psu.c | 30 --
 1 file changed, 8 insertions(+), 22 deletions(-)

diff --git a/drivers/hwmon/corsair-psu.c b/drivers/hwmon/corsair-psu.c
index 99494056f4bd..b0953eeeb2d3 100644
--- a/drivers/hwmon/corsair-psu.c
+++ b/drivers/hwmon/corsair-psu.c
@@ -119,27 +119,13 @@ struct corsairpsu_data {
 };
 
 /* some values are SMBus LINEAR11 data which need a conversion */
-static int corsairpsu_linear11_to_int(const int val)
+static int corsairpsu_linear11_to_int(const u16 val, const int scale)
 {
-   int exp = (val & 0x) >> 0x0B;
-   int mant = val & 0x7FF;
-   int i;
-
-   if (exp > 0x0F)
-   exp -= 0x20;
-   if (mant > 0x3FF)
-   mant -= 0x800;
-   if ((mant & 0x01) == 1)
-   ++mant;
-   if (exp < 0) {
-   for (i = 0; i < -exp; ++i)
-   mant /= 2;
-   } else {
-   for (i = 0; i < exp; ++i)
-   mant *= 2;
-   }
+   const int exp = ((s16)val) >> 11;
+   const int mant = (((s16)(val & 0x7ff)) << 5) >> 5;
+   const int result = mant * scale;
 
-   return mant;
+   return (exp >= 0) ? (result << exp) : (result >> -exp);
 }
 
 static int corsairpsu_usb_cmd(struct corsairpsu_data *priv, u8 p0, u8 p1, u8 
p2, void *data)
@@ -249,14 +235,14 @@ static int corsairpsu_get_value(struct corsairpsu_data 
*priv, u8 cmd, u8 rail, l
case PSU_CMD_RAIL_AMPS:
case PSU_CMD_TEMP0:
case PSU_CMD_TEMP1:
-   *val = corsairpsu_linear11_to_int(tmp & 0x) * 1000;
+   *val = corsairpsu_linear11_to_int(tmp & 0x, 1000);
break;
case PSU_CMD_FAN:
-   *val = corsairpsu_linear11_to_int(tmp & 0x);
+   *val = corsairpsu_linear11_to_int(tmp & 0x, 1);
break;
case PSU_CMD_RAIL_WATTS:
case PSU_CMD_TOTAL_WATTS:
-   *val = corsairpsu_linear11_to_int(tmp & 0x) * 100;
+   *val = corsairpsu_linear11_to_int(tmp & 0x, 100);
break;
case PSU_CMD_TOTAL_UPTIME:
case PSU_CMD_UPTIME:
-- 
2.30.1

Re: [PATCH] dma-buf: heaps: Set VM_PFNMAP in mmap for system and cma heaps

[Christoph Hellwig]

On Fri, Feb 26, 2021 at 08:36:55AM +0100, Daniel Vetter wrote:
> Also given that both deal with struct page there's a ton of divergence
> between these two that doesn't make much sense. Maybe could even share
> the code fully, aside from how you allocate the struct pages.

I've been saying that since the code was first submitted.  Once pages
are allocated from CMA they should be treated not different from normal
pages.

Please take a look at how the DMA contigous allocator manages to share
all code for handling CMA vs alloc_pages pages.

Re: [PATCH] [RFC] arm64: enable HAVE_LD_DEAD_CODE_DATA_ELIMINATION

[Arnd Bergmann]

On Fri, Feb 26, 2021 at 10:13 PM 'Fangrui Song' via Clang Built Linux
 wrote:
>
> For folks who are interested in --gc-sections on metadata sections,
> I want to bring you awareness of the implication of __start_/__stop_ symbols 
> and C identifier name sections.
> You can see https://github.com/ClangBuiltLinux/linux/issues/1307 for a 
> summary.
> (Its linked blog article has some examples.)
>
> In the kernel linker scripts, most C identifier name sections begin with 
> double-underscore __.
> Some are surrounded by `KEEP(...)`, some are not.
>
> * A `KEEP` keyword has GC root semantics and makes ld --gc-sections 
> ineffectful.
> * Without `KEEP`, __start_/__stop_ references from a live input section
>can unnecessarily retain all the associated C identifier name input
>sections. The new ld.lld option `-z start-stop-gc` can defeat this rule.
>
> As an example, a __start___jump_table reference from a live section
> causes all `__jump_table` input section to be retained, even if you
> change `KEEP(__jump_table)` to `(__jump_table)`.
> (If you change the symbol name from `__start_${section}` to something
> else (e.g. `__start${section}`), the rule will not apply.)

I suspect the __start_* symbols are cargo-culted by many developers
copying stuff around between kernel linker scripts, that's certainly how I
approach making changes to it normally without a deeper understanding
of how the linker actually works or what the different bits of syntax mean
there.

I see the original vmlinux.lds linker script showed up in linux-2.1.23, and
it contained

+  . = ALIGN(16);   /* Exception table */
+  __start___ex_table = .;
+  __ex_table : { *(__ex_table) }
+  __stop___ex_table = .;
+
+  __start___ksymtab = .;   /* Kernel symbol table */
+  __ksymtab : { *(__ksymtab) }
+  __stop___ksymtab = .;

originally for arch/sparc, and shortly afterwards for i386. The magic
__ex_table section was first used in linux-2.1.7 without a linker
script. It's probably a good idea to try cleaning these up by using
non-magic start/stop symbols for all sections, and relying on KEEP()
instead where needed.

> There are a lot of KEEP usage. Perhaps some can be dropped to facilitate
> ld --gc-sections.

I see a lot of these were added by Nick Piggin (added to Cc) in this commit:

commit 266ff2a8f51f02b429a987d87634697eb0d01d6a
Author: Nicholas Piggin 
Date:   Wed May 9 22:59:58 2018 +1000

kbuild: Fix asm-generic/vmlinux.lds.h for LD_DEAD_CODE_DATA_ELIMINATION

KEEP more tables, and add the function/data section wildcard to more
section selections.

This is a little ad-hoc at the moment, but kernel code should be moved
to consistently use .text..x (note: double dots) for explicit sections
and all references to it in the linker script can be made with
TEXT_MAIN, and similarly for other sections.

For now, let's see if major architectures move to enabling this option
then we can do some refactoring passes. Otherwise if it remains unused
or superseded by LTO, this may not be required.

Signed-off-by: Nicholas Piggin 
Signed-off-by: Masahiro Yamada 

which apparently was intentionally cautious.

Unlike what Nick expected in his submission, I now think the annotations
will be needed for LTO just like they are for --gc-sections.

  Arnd

[PATCH] x86/tools/relocs: add __printf attribute to die()

[Greg Kroah-Hartman]

There are a number of printf "mismatches" in the use of die() in
x86/tools/relocs.c.  Fix them up and add the printf attribute to the
reloc.h header file to prevent them from ever coming back.

Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Borislav Petkov 
Cc: "H. Peter Anvin" 
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman 
---
 arch/x86/tools/relocs.c | 21 +++--
 arch/x86/tools/relocs.h |  1 +
 2 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/arch/x86/tools/relocs.c b/arch/x86/tools/relocs.c
index ce7188cbdae5..c3105a8c6cde 100644
--- a/arch/x86/tools/relocs.c
+++ b/arch/x86/tools/relocs.c
@@ -389,7 +389,8 @@ static void read_ehdr(FILE *fp)
Elf_Shdr shdr;
 
if (fseek(fp, ehdr.e_shoff, SEEK_SET) < 0)
-   die("Seek to %d failed: %s\n", ehdr.e_shoff, 
strerror(errno));
+   die("Seek to %d failed: %s\n",
+   (int)ehdr.e_shoff, strerror(errno));
 
if (fread(&shdr, sizeof(shdr), 1, fp) != 1)
die("Cannot read initial ELF section header: %s\n", 
strerror(errno));
@@ -412,17 +413,17 @@ static void read_shdrs(FILE *fp)
 
secs = calloc(shnum, sizeof(struct section));
if (!secs) {
-   die("Unable to allocate %d section headers\n",
+   die("Unable to allocate %ld section headers\n",
shnum);
}
if (fseek(fp, ehdr.e_shoff, SEEK_SET) < 0) {
die("Seek to %d failed: %s\n",
-   ehdr.e_shoff, strerror(errno));
+   (int)ehdr.e_shoff, strerror(errno));
}
for (i = 0; i < shnum; i++) {
struct section *sec = &secs[i];
if (fread(&shdr, sizeof(shdr), 1, fp) != 1)
-   die("Cannot read ELF section headers %d/%d: %s\n",
+   die("Cannot read ELF section headers %d/%ld: %s\n",
i, shnum, strerror(errno));
sec->shdr.sh_name  = elf_word_to_cpu(shdr.sh_name);
sec->shdr.sh_type  = elf_word_to_cpu(shdr.sh_type);
@@ -451,11 +452,11 @@ static void read_strtabs(FILE *fp)
sec->strtab = malloc(sec->shdr.sh_size);
if (!sec->strtab) {
die("malloc of %d bytes for strtab failed\n",
-   sec->shdr.sh_size);
+   (int)sec->shdr.sh_size);
}
if (fseek(fp, sec->shdr.sh_offset, SEEK_SET) < 0) {
die("Seek to %d failed: %s\n",
-   sec->shdr.sh_offset, strerror(errno));
+   (int)sec->shdr.sh_offset, strerror(errno));
}
if (fread(sec->strtab, 1, sec->shdr.sh_size, fp)
!= sec->shdr.sh_size) {
@@ -476,11 +477,11 @@ static void read_symtabs(FILE *fp)
sec->symtab = malloc(sec->shdr.sh_size);
if (!sec->symtab) {
die("malloc of %d bytes for symtab failed\n",
-   sec->shdr.sh_size);
+   (int)sec->shdr.sh_size);
}
if (fseek(fp, sec->shdr.sh_offset, SEEK_SET) < 0) {
die("Seek to %d failed: %s\n",
-   sec->shdr.sh_offset, strerror(errno));
+   (int)sec->shdr.sh_offset, strerror(errno));
}
if (fread(sec->symtab, 1, sec->shdr.sh_size, fp)
!= sec->shdr.sh_size) {
@@ -509,11 +510,11 @@ static void read_relocs(FILE *fp)
sec->reltab = malloc(sec->shdr.sh_size);
if (!sec->reltab) {
die("malloc of %d bytes for relocs failed\n",
-   sec->shdr.sh_size);
+   (int)sec->shdr.sh_size);
}
if (fseek(fp, sec->shdr.sh_offset, SEEK_SET) < 0) {
die("Seek to %d failed: %s\n",
-   sec->shdr.sh_offset, strerror(errno));
+   (int)sec->shdr.sh_offset, strerror(errno));
}
if (fread(sec->reltab, 1, sec->shdr.sh_size, fp)
!= sec->shdr.sh_size) {
diff --git a/arch/x86/tools/relocs.h b/arch/x86/tools/relocs.h
index 43c83c0fd22c..4c49c82446eb 100644
--- a/arch/x86/tools/relocs.h
+++ b/arch/x86/tools/relocs.h
@@ -17,6 +17,7 @@
 #include 
 #include 
 
+__attribute__((__format__(printf, 1, 2)))
 void die(char *fmt, ...) __attribute__((noreturn));
 
 #define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
-- 
2.30.1

Re: arch/arm/boot/compressed/fdt_check_mem_start.c:62:10: warning: no previous prototype for function 'fdt_check_mem_start'

[Geert Uytterhoeven]

Hi Kernel Test Robot,

On Sat, Feb 27, 2021 at 3:47 AM kernel test robot  wrote:
> FYI, the error/warning still remains.

My response in
https://lore.kernel.org/linux-arm-kernel/CAMuHMdVmMLvvJ4mAa+y8JCJ2+5Bwu2W=psgn3toC1msTghn=x...@mail.gmail.com/
is still valid.

>
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
> master
> head:   3fb6d0e00efc958d01c2f109c8453033a2d96796
> commit: 0673cb38951215060d7993b43ad3c45cd413c2c3 ARM: 9045/1: uncompress: 
> Validate start of physical memory against passed DTB
> date:   4 weeks ago
> config: arm-randconfig-r003-20210226 (attached as .config)
> compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 
> b889ef4214bc6dc8880fdd4badc0dcd9a3197753)
> reproduce (this is a W=1 build):
> wget 
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # install arm cross compiling tool for clang build
> # apt-get install binutils-arm-linux-gnueabi
> # 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0673cb38951215060d7993b43ad3c45cd413c2c3
> git remote add linus 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> git fetch --no-tags linus master
> git checkout 0673cb38951215060d7993b43ad3c45cd413c2c3
> # save the attached .config to linux build tree
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot 
>
> All warnings (new ones prefixed by >>):
>
> >> arch/arm/boot/compressed/fdt_check_mem_start.c:62:10: warning: no previous 
> >> prototype for function 'fdt_check_mem_start' [-Wmissing-prototypes]
>uint32_t fdt_check_mem_start(uint32_t mem_start, const void *fdt)
> ^
>arch/arm/boot/compressed/fdt_check_mem_start.c:62:1: note: declare 
> 'static' if the function is not intended to be used outside of this 
> translation unit
>uint32_t fdt_check_mem_start(uint32_t mem_start, const void *fdt)
>^
>static
>1 warning generated.
>
>
> vim +/fdt_check_mem_start +62 arch/arm/boot/compressed/fdt_check_mem_start.c
>
> 46
> 47  /*
> 48   * Check the start of physical memory
> 49   *
> 50   * Traditionally, the start address of physical memory is obtained by 
> masking
> 51   * the program counter.  However, this does require that this address 
> is a
> 52   * multiple of 128 MiB, precluding booting Linux on platforms where 
> this
> 53   * requirement is not fulfilled.
> 54   * Hence validate the calculated address against the memory 
> information in the
> 55   * DTB, and, if out-of-range, replace it by the real start address.
> 56   * To preserve backwards compatibility (systems reserving a block of 
> memory
> 57   * at the start of physical memory, kdump, ...), the traditional 
> method is
> 58   * always used if it yields a valid address.
> 59   *
> 60   * Return value: start address of physical memory to use
> 61   */
>   > 62  uint32_t fdt_check_mem_start(uint32_t mem_start, const void *fdt)
>
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org



-- 
Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

[PATCH] e1000e: use proper #include guard name in hw.h

[Greg Kroah-Hartman]

The include guard for the e1000e and e1000 hw.h files are the same, so
add the proper "E" term to the hw.h file for the e1000e driver.

This resolves some static analyzer warnings, like the one found by the
"lgtm.com" tool.

Cc: Jesse Brandeburg 
Cc: Tony Nguyen 
Cc: "David S. Miller" 
Cc: Jakub Kicinski 
Cc: intel-wired-...@lists.osuosl.org
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/net/ethernet/intel/e1000e/hw.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/intel/e1000e/hw.h 
b/drivers/net/ethernet/intel/e1000e/hw.h
index 69a2329ea463..f7954cadd979 100644
--- a/drivers/net/ethernet/intel/e1000e/hw.h
+++ b/drivers/net/ethernet/intel/e1000e/hw.h
@@ -1,8 +1,8 @@
 /* SPDX-License-Identifier: GPL-2.0 */
 /* Copyright(c) 1999 - 2018 Intel Corporation. */
 
-#ifndef _E1000_HW_H_
-#define _E1000_HW_H_
+#ifndef _E1000E_HW_H_
+#define _E1000E_HW_H_
 
 #include "regs.h"
 #include "defines.h"
-- 
2.30.1

Re: [PATCH] i2c/busses: fix spellint typo

[Jean Delvare]

Hi zuoqilin,

There's an obvious typo in the subject. Which is kind of ironical
considering the point of your patch.

Also, your patch is driver-specific, so "i2c/busses:" isn't an
appropriate prefix. According to the standard practice for the i2c
subsystem, the proper prefix for the subject would be: "i2c: sis630:".

On Thu, 25 Feb 2021 19:53:38 +0800, zuoqil...@163.com wrote:
> From: zuoqilin 
> 
> change 'adress' to 'address'

Please start your sentences with a capital and end them with a dot.

> 
> Signed-off-by: zuoqilin 
> ---
>  drivers/i2c/busses/i2c-sis630.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/i2c/busses/i2c-sis630.c b/drivers/i2c/busses/i2c-sis630.c
> index cfb8e04..87d5625 100644
> --- a/drivers/i2c/busses/i2c-sis630.c
> +++ b/drivers/i2c/busses/i2c-sis630.c
> @@ -97,7 +97,7 @@
>  module_param(force, bool, 0);
>  MODULE_PARM_DESC(force, "Forcibly enable the SIS630. DANGEROUS!");
>  
> -/* SMBus base adress */
> +/* SMBus base address */
>  static unsigned short smbus_base;
>  
>  /* supported chips */

Other than that, the change looks OK, thanks.

-- 
Jean Delvare
SUSE L3 Support

Re: [PATCH] iommu/tegra-smmu: Fix mc errors on tegra124-nyan

[Dmitry Osipenko]

25.02.2021 09:27, Nicolin Chen пишет:
...
>> The partially revert should be okay, but it's not clear to me what makes
>> difference for T124 since I don't see that problem on T30, which also
>> has active display at a boot time.
> 
> Hmm..do you see ->attach_dev() is called from host1x_client_iommu_attach
> or from of_dma_configure_id/arch_setup_dma_ops?
> 

I applied yours debug-patch, please see dmesg.txt attached to the email.
Seems probe-defer of the tegra-dc driver prevents the implicit
tegra_smmu_attach_dev, so it happens to work by accident.
[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 5.11.0-next-20210226-3-g89069e0f4a28 
(dima@dimapc) (armv7a-hardfloat-linux-gnueabi-gcc (Gentoo 9.3.0-r2 p4) 9.3.0, 
GNU ld (Gentoo 2.26.1 p1.0) 2.26.1) #7012 SMP PREEMPT Sat Feb 27 11:49:27 MSK 
2021
[0.00] CPU: ARMv7 Processor [412fc099] revision 9 (ARMv7), cr=50c5387d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
instruction cache
[0.00] OF: fdt: Machine model: ASUS Google Nexus 7 (Project Bach / 
ME370TG) E1565
[0.00] Memory policy: Data cache writealloc
[0.00] Reserved memory: created CMA memory pool at 0xa000, size 256 
MiB
[0.00] OF: reserved mem: initialized node linux,cma@8000, 
compatible id shared-dma-pool
[0.00] Zone ranges:
[0.00]   Normal   [mem 0x-0x9f7f]
[0.00]   HighMem  [mem 0x9f80-0xbfdf]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x8000-0xbfdf]
[0.00] Initmem setup node 0 [mem 0x8000-0xbfdf]
[0.00] On node 0 totalpages: 261632
[0.00]   Normal zone: 1134 pages used for memmap
[0.00]   Normal zone: 0 pages reserved
[0.00]   Normal zone: 129024 pages, LIFO batch:31
[0.00]   HighMem zone: 132608 pages, LIFO batch:31
[0.00] percpu: Embedded 21 pages/cpu s53324 r8192 d24500 u86016
[0.00] pcpu-alloc: s53324 r8192 d24500 u86016 alloc=21*4096
[0.00] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
[0.00] Built 1 zonelists, mobility grouping on.  Total pages: 260498
[0.00] Kernel command line: tegraid=30.1.3.0.0 mem=1022M@2048M 
android.commchip=0 vmalloc=512M androidboot.serialno=015d3f18c9081210 
video=tegrafb no_console_suspend=1 console=none debug_uartport=hsport 
usbcore.old_scheme_first=1 lp0_vec=8192@0xbddf9000 
tegra_fbmem=8195200@0xabe01000 core_edp_mv=0 audio_codec=rt5640 
board_info=f41:a00:1:44:2 root=/dev/sda1 rw rootwait tegraboot=sdmmc gpt 
gpt_sector=61079551 androidboot.bootloader=4.23 
androidboot.baseband=1231_0.18.0_0409 init=/usr/lib/systemd/systemd 
root=/dev/nfs nfsroot=192.168.3.100:/nfs/root,v3,tcp rw 
ip=192.168.3.101::192.168.3.100:255.255.255.0::usb0 no_console_suspend gpt 
gpt_sector=61079551 console=tty1 no_console_suspend
[0.00] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes, 
linear)
[0.00] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes, 
linear)
[0.00] mem auto-init: stack:off, heap alloc:off, heap free:off
[0.00] Memory: 754680K/1046528K available (10240K kernel code, 1579K 
rwdata, 5404K rodata, 1024K init, 418K bss, 29704K reserved, 262144K 
cma-reserved, 268224K highmem)
[0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[0.00] ftrace: allocating 46557 entries in 91 pages
[0.00] [ cut here ]
[0.00] WARNING: CPU: 0 PID: 0 at arch/arm/kernel/insn.c:15 
__arm_gen_branch+0x7f/0x84
[0.00] Modules linked in:
[0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 
5.11.0-next-20210226-3-g89069e0f4a28 #7012
[0.00] Hardware name: NVIDIA Tegra SoC (Flattened Device Tree)
[0.00] [] (unwind_backtrace) from [] 
(show_stack+0x11/0x14)
[0.00] [] (show_stack) from [] 
(dump_stack+0x8d/0x9a)
[0.00] [] (dump_stack) from [] (__warn+0xb7/0xc8)
[0.00] [] (__warn) from [] 
(warn_slowpath_fmt+0x45/0x78)
[0.00] [] (warn_slowpath_fmt) from [] 
(__arm_gen_branch+0x7f/0x84)
[0.00] [] (__arm_gen_branch) from [] 
(ftrace_make_nop+0xf/0x20)
[0.00] [] (ftrace_make_nop) from [] 
(ftrace_process_locs+0x211/0x320)
[0.00] [] (ftrace_process_locs) from [] 
(ftrace_init+0x6f/0xbe)
[0.00] [] (ftrace_init) from [] 
(start_kernel+0x42d/0x662)
[0.00] [] (start_kernel) from [<>] (0x0)
[0.00] random: get_random_bytes called from 
print_oops_end_marker+0x25/0x64 with crng_init=0
[0.00] ---[ end trace  ]---
[0.00] [ ftrace bug ]
[0.00] ftrace failed to modify
[0.00] [] crash_notes_memory_init+0x4/0x34
[0.00]  actual:   23:f0:9c:ec
[0.00] Initializing ftrace call sites
[0.00] ftrace record flags: 0

Re: [PATCH 0/2] irqchip: add support for BCM6345 interrupt controller

[Marc Zyngier]

Alvaro,

On Sat, 27 Feb 2021 08:49:25 +,
Álvaro Fernández Rojas  wrote:
> 
> Hi Andy,
> 
> That wasn’t top-posting,

If that isn't top-posting, I wonder what is. With HTML on top, to make
sure it breaks every established rule.

> I was just asking why it was changed to Not Applicable instead of
> leaving it as New until the merge window closes...

I have no idea why, and I don't really care. I don't use patchwork for
anything I maintain, and the sole reference is the state of my Inbox.

> I have the feeling that if the patch is changed to Not Applicable
> it’s going to be forgotten after the merge window closes...

If you haven't received any feedback on your patches within a few
*weeks*, feel free to point them again to the relevant people (me, at
least).

Documentation/process/submitting-patches.rst describes the process I
(and most other kernel people) use. Feel free to refer to it.

Thanks,

M.

-- 
Without deviation from the norm, progress is not possible.

Re: [PATCH] perf buildid-cache: Add test for PE executable

[Jiri Olsa]

On Fri, Feb 26, 2021 at 08:47:36PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Thu, Feb 25, 2021 at 09:35:04PM +0100, Jiri Olsa escreveu:
> > On Wed, Feb 24, 2021 at 02:59:16PM -0500, Nicholas Fraser wrote:
> > > From 9fd0b3889f00ad13662879767d833309d8a035b6 Mon Sep 17 00:00:00 2001
> > > From: Nicholas Fraser 
> > > Date: Thu, 18 Feb 2021 13:24:03 -0500
> > > Subject: [PATCH] perf buildid-cache: Add test for PE executable
> > > 
> > > This builds on the previous changes to tests/shell/buildid.sh, adding
> > > tests for a PE file. It adds it to the build-id cache manually and, if
> > > Wine is available, runs it under "perf record" and verifies that it was
> > > added automatically.
> > > 
> > > If wine is not installed, only warnings are printed; the test can still
> > > exit 0.
> > > 
> > > Signed-off-by: Nicholas Fraser 
> > 
> > works nicely now, thanks
> > 
> > Acked-by: Jiri Olsa 
> 
> Thanks for checking it, but if you did a review, i.e. if you looked at
> the code, made suggestions, the submitter acted upon those changes, you
> looked again, etc, shouldn't this be a more appropriate:
> 
> Reviewed-by: Jiri Olsa 
> 
> ?
> 
> I think we need to make these tags reflect more what really happened,
> i.e. if you just glanced over and thought, quickly, that it seems
> okayish, then Acked-by is what we should use, but if you gone thru the
> trouble of actually _looking hard_ at it, sometimes multiple times, then
> we should really use Reviewed-by and not take that lightly.

ah right, I slipped to using ack regardles the effort ;-)
I'll try to kick myself to use reviewed where appropriate

for this one:

Reviewed-by: Jiri Olsa 

thanks,
jirka

Re: [PATCH] media: i2c: adp1653: fix error handling from a call to adp1653_get_fault

[Dan Carpenter]

On Fri, Feb 26, 2021 at 11:22:29PM +, Colin King wrote:
> From: Colin Ian King 
> 
> The error check on rval from the call to adp1653_get_fault currently
> returns if rval is non-zero. This appears to be incorrect as the
> following if statement checks for various bit settings in rval so
> clearly rval is expected to be non-zero at that point. Coverity
> flagged the if statement up as deadcode.  Fix this so the error
> return path only occurs when rval is negative.
> 
> Addresses-Coverity: ("Logically dead code")
> Fixes: 287980e49ffc ("remove lots of IS_ERR_VALUE abuses")
> Signed-off-by: Colin Ian King 
> ---
>  drivers/media/i2c/adp1653.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/media/i2c/adp1653.c b/drivers/media/i2c/adp1653.c
> index 522a0b10e415..1a4878385394 100644
> --- a/drivers/media/i2c/adp1653.c
> +++ b/drivers/media/i2c/adp1653.c
> @@ -170,7 +170,7 @@ static int adp1653_set_ctrl(struct v4l2_ctrl *ctrl)
>   int rval;
>  
>   rval = adp1653_get_fault(flash);
> - if (rval)
> + if (rval < 0)
>   return rval;

This is good, but all the other callers need to fixed as well:


   140  static int adp1653_get_ctrl(struct v4l2_ctrl *ctrl)
   141  {
   142  struct adp1653_flash *flash =
   143  container_of(ctrl->handler, struct adp1653_flash, 
ctrls);
   144  int rval;
   145  
   146  rval = adp1653_get_fault(flash);
   147  if (rval)
   148  return rval;
   149  
   150  ctrl->cur.val = 0;
   151  
   152  if (flash->fault & ADP1653_REG_FAULT_FLT_SCP)

flash->fault is the equivalent of "rval" for non-negative returns so
this condition can never be true.  We should never be returning these
weird firmware ADP1653_REG_FAULT_FLT_SCP fault codes to the v4l2 layers.

   153  ctrl->cur.val |= V4L2_FLASH_FAULT_SHORT_CIRCUIT;
   154  if (flash->fault & ADP1653_REG_FAULT_FLT_OT)
   155  ctrl->cur.val |= V4L2_FLASH_FAULT_OVER_TEMPERATURE;
   156  if (flash->fault & ADP1653_REG_FAULT_FLT_TMR)
   157  ctrl->cur.val |= V4L2_FLASH_FAULT_TIMEOUT;
   158  if (flash->fault & ADP1653_REG_FAULT_FLT_OV)
   159  ctrl->cur.val |= V4L2_FLASH_FAULT_OVER_VOLTAGE;
   160  
   161  flash->fault = 0;
   162  
   163  return 0;
   164  }

regards,
dan carpenter

[PATCH] WMI: asus: Reduce G14 and G15 match to min product name

[Luke D Jones]

This patch reduces the product match for GA401 series laptops to
the minimum string required.

The GA401 series of laptops has a lengthy list of product
variations in the 2020 series and the 2021 series refresh
is using the same base product ID of GA401.

The same is also true for the GA502 series, and the new GA503
series which is added in this patch as a variant of the G15.

Signed-off-by: Luke D Jones 
---
 drivers/platform/x86/asus-nb-wmi.c | 57 --
 1 file changed, 6 insertions(+), 51 deletions(-)

diff --git a/drivers/platform/x86/asus-nb-wmi.c 
b/drivers/platform/x86/asus-nb-wmi.c
index d41d7ad14be0..f4db67c3eba2 100644
--- a/drivers/platform/x86/asus-nb-wmi.c
+++ b/drivers/platform/x86/asus-nb-wmi.c
@@ -427,73 +427,28 @@ static const struct dmi_system_id asus_quirks[] = {
},
{
.callback = dmi_matched,
-   .ident = "ASUSTeK COMPUTER INC. GA401IH",
+   .ident = "ASUSTeK COMPUTER INC. GA401",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
-   DMI_MATCH(DMI_PRODUCT_NAME, "GA401IH"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "GA401"),
},
.driver_data = &quirk_asus_vendor_backlight,
},
{
.callback = dmi_matched,
-   .ident = "ASUSTeK COMPUTER INC. GA401II",
+   .ident = "ASUSTeK COMPUTER INC. GA502",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
-   DMI_MATCH(DMI_PRODUCT_NAME, "GA401II"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "GA502"),
},
.driver_data = &quirk_asus_vendor_backlight,
},
{
.callback = dmi_matched,
-   .ident = "ASUSTeK COMPUTER INC. GA401IU",
+   .ident = "ASUSTeK COMPUTER INC. GA503",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
-   DMI_MATCH(DMI_PRODUCT_NAME, "GA401IU"),
-   },
-   .driver_data = &quirk_asus_vendor_backlight,
-   },
-   {
-   .callback = dmi_matched,
-   .ident = "ASUSTeK COMPUTER INC. GA401IV",
-   .matches = {
-   DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
-   DMI_MATCH(DMI_PRODUCT_NAME, "GA401IV"),
-   },
-   .driver_data = &quirk_asus_vendor_backlight,
-   },
-   {
-   .callback = dmi_matched,
-   .ident = "ASUSTeK COMPUTER INC. GA401IVC",
-   .matches = {
-   DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
-   DMI_MATCH(DMI_PRODUCT_NAME, "GA401IVC"),
-   },
-   .driver_data = &quirk_asus_vendor_backlight,
-   },
-   {
-   .callback = dmi_matched,
-   .ident = "ASUSTeK COMPUTER INC. GA502II",
-   .matches = {
-   DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
-   DMI_MATCH(DMI_PRODUCT_NAME, "GA502II"),
-   },
-   .driver_data = &quirk_asus_vendor_backlight,
-   },
-   {
-   .callback = dmi_matched,
-   .ident = "ASUSTeK COMPUTER INC. GA502IU",
-   .matches = {
-   DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
-   DMI_MATCH(DMI_PRODUCT_NAME, "GA502IU"),
-   },
-   .driver_data = &quirk_asus_vendor_backlight,
-   },
-   {
-   .callback = dmi_matched,
-   .ident = "ASUSTeK COMPUTER INC. GA502IV",
-   .matches = {
-   DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
-   DMI_MATCH(DMI_PRODUCT_NAME, "GA502IV"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "GA503"),
},
.driver_data = &quirk_asus_vendor_backlight,
},
-- 
2.30.1

Re: [drm/i915/gt] 8c3b1ba0e7: perf-sanity-tests.Parse_event_definition_strings.fail

[Jiri Olsa]

On Fri, Feb 26, 2021 at 08:41:26AM +0800, Jin, Yao wrote:

SNIP

> > +   SET_SYMBOL(prefix, PMU_EVENT_SYMBOL);
> > len++;
> > }
> > }
> > }
> > +
> > +   /* unlikely, but still.. */
> > +   if (!len)
> > +   goto err;
> > +   perf_pmu_events_list_num = len;
> > +
> > qsort(perf_pmu_events_list, len,
> > sizeof(struct perf_pmu_event_symbol), comp_pmu);
> > 
> 
> Thanks so much for the patch! It works with my tests.
> 
> # ./perf test 6
>  6: Parse event definition strings  : Ok
> 
> # ./perf stat -e software/r1a/ -a -- sleep 1
> 
>  Performance counter stats for 'system wide':
> 
>  software/r1a/
> 
>1.000940433 seconds time elapsed
> 
> In theory, do we also need to check suffix as well? I think returning
> PMU_EVENT_SYMBOL_SUFFIX may also confuse the parser. But yes, we don't have
> this case now.

yep, let's wait for use case ;-) you can't have suffix
without prefix, and that's the one failing, so I think
we are fine

thanks,
jirka

mmu.c:undefined reference to `patch__hash_page_A0'

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   3fb6d0e00efc958d01c2f109c8453033a2d96796
commit: 259149cf7c3c6195e6199e045ca988c31d081cab powerpc/32s: Only build hash 
code when CONFIG_PPC_BOOK3S_604 is selected
date:   4 weeks ago
config: powerpc64-randconfig-r013-20210227 (attached as .config)
compiler: powerpc-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=259149cf7c3c6195e6199e045ca988c31d081cab
git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 259149cf7c3c6195e6199e045ca988c31d081cab
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=powerpc64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All errors (new ones prefixed by >>):

   powerpc-linux-ld: arch/powerpc/mm/book3s32/mmu.o: in function 
`MMU_init_hw_patch':
>> mmu.c:(.init.text+0x75e): undefined reference to `patch__hash_page_A0'
>> powerpc-linux-ld: mmu.c:(.init.text+0x76a): undefined reference to 
>> `patch__hash_page_A0'
>> powerpc-linux-ld: mmu.c:(.init.text+0x776): undefined reference to 
>> `patch__hash_page_A1'
   powerpc-linux-ld: mmu.c:(.init.text+0x782): undefined reference to 
`patch__hash_page_A1'
>> powerpc-linux-ld: mmu.c:(.init.text+0x78e): undefined reference to 
>> `patch__hash_page_A2'
   powerpc-linux-ld: mmu.c:(.init.text+0x79a): undefined reference to 
`patch__hash_page_A2'
>> powerpc-linux-ld: mmu.c:(.init.text+0x7aa): undefined reference to 
>> `patch__hash_page_B'
   powerpc-linux-ld: mmu.c:(.init.text+0x7b6): undefined reference to 
`patch__hash_page_B'
>> powerpc-linux-ld: mmu.c:(.init.text+0x7c2): undefined reference to 
>> `patch__hash_page_C'
   powerpc-linux-ld: mmu.c:(.init.text+0x7ce): undefined reference to 
`patch__hash_page_C'
>> powerpc-linux-ld: mmu.c:(.init.text+0x7da): undefined reference to 
>> `patch__flush_hash_A0'
   powerpc-linux-ld: mmu.c:(.init.text+0x7e6): undefined reference to 
`patch__flush_hash_A0'
>> powerpc-linux-ld: mmu.c:(.init.text+0x7f2): undefined reference to 
>> `patch__flush_hash_A1'
   powerpc-linux-ld: mmu.c:(.init.text+0x7fe): undefined reference to 
`patch__flush_hash_A1'
>> powerpc-linux-ld: mmu.c:(.init.text+0x80a): undefined reference to 
>> `patch__flush_hash_A2'
   powerpc-linux-ld: mmu.c:(.init.text+0x816): undefined reference to 
`patch__flush_hash_A2'
>> powerpc-linux-ld: mmu.c:(.init.text+0x83e): undefined reference to 
>> `patch__flush_hash_B'
   powerpc-linux-ld: mmu.c:(.init.text+0x84e): undefined reference to 
`patch__flush_hash_B'
   powerpc-linux-ld: arch/powerpc/mm/book3s32/mmu.o: in function 
`update_mmu_cache':
>> mmu.c:(.text.update_mmu_cache+0xa0): undefined reference to `add_hash_page'

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip

Re: [PATCH] powerpc/bug: Remove specific powerpc BUG_ON()

[Christophe Leroy]

Le 11/02/2021 à 15:30, Segher Boessenkool a écrit :

On Thu, Feb 11, 2021 at 03:09:43PM +0100, Christophe Leroy wrote:

Le 11/02/2021 à 12:49, Segher Boessenkool a écrit :

On Thu, Feb 11, 2021 at 07:41:52AM +, Christophe Leroy wrote:

powerpc BUG_ON() is based on using twnei or tdnei instruction,
which obliges gcc to format the condition into a 0 or 1 value
in a register.


Huh?  Why is that?

Will it work better if this used __builtin_trap?  Or does the kernel only
detect very specific forms of trap instructions?


We already made a try with __builtin_trap() 1,5 year ago, see
https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20510ce03cc9463f1c9e743c1d93b939de501b53.1566219503.git.christophe.le...@c-s.fr/

The main problems encountered are:
- It is only possible to use it for BUG_ON, not for WARN_ON because GCC
considers it as noreturn. Is there any workaround ?


A trap is noreturn by definition:

  -- Built-in Function: void __builtin_trap (void)
  This function causes the program to exit abnormally.


- The kernel (With CONFIG_DEBUG_BUGVERBOSE) needs to be able to identify
the source file and line corresponding to the trap. How can that be done
with __builtin_trap() ?


The DWARF debug info should be sufficient.  Perhaps you can post-process
some way?

You can create a trap that falls through yourself (by having a trap-on
condition with a condition that is always true, but make the compiler
not see that).  This isn't efficient though.

Could you file a feature request (in bugzilla)?  It is probably useful
for generic code as well, but we could implement this for powerpc only
if needed.



https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99299

Christophe

drivers/gpu/drm/amd/amdgpu/../display/dc/irq/dcn21/irq_service_dcn21.c:242:39: warning: initialized field overwritten

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   3fb6d0e00efc958d01c2f109c8453033a2d96796
commit: 688f97ed3f5e339c0c2c09d9ee7ff23d5807b0a7 drm/amd/display: Add 
vupdate_no_lock interrupts for DCN2.1
date:   4 days ago
config: i386-randconfig-r002-20210227 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce (this is a W=1 build):
# 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=688f97ed3f5e339c0c2c09d9ee7ff23d5807b0a7
git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 688f97ed3f5e339c0c2c09d9ee7ff23d5807b0a7
# save the attached .config to linux build tree
make W=1 ARCH=i386 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>):

   
drivers/gpu/drm/amd/amdgpu/../display/dc/irq/dcn21/irq_service_dcn21.c:43:20: 
warning: no previous prototype for 'to_dal_irq_source_dcn21' 
[-Wmissing-prototypes]
  43 | enum dc_irq_source to_dal_irq_source_dcn21(
 |^~~
>> drivers/gpu/drm/amd/amdgpu/../display/dc/irq/dcn21/irq_service_dcn21.c:242:39:
>>  warning: initialized field overwritten [-Woverride-init]
 242 |  [DC_IRQ_SOURCE_VUPDATE1 + reg_num] = {\
 |   ^~
 243 |   IRQ_REG_ENTRY(OTG, reg_num,\
 |
   
drivers/gpu/drm/amd/amdgpu/../display/dc/irq/dcn21/irq_service_dcn21.c:242:39: 
note: in definition of macro 'vupdate_no_lock_int_entry'
 242 |  [DC_IRQ_SOURCE_VUPDATE1 + reg_num] = {\
 |   ^~
 243 |   IRQ_REG_ENTRY(OTG, reg_num,\
 |
   
drivers/gpu/drm/amd/amdgpu/../display/dc/irq/dcn21/irq_service_dcn21.c:242:39: 
note: (near initialization for 'irq_source_info_dcn21[72]')
 242 |  [DC_IRQ_SOURCE_VUPDATE1 + reg_num] = {\
 |   ^~
 243 |   IRQ_REG_ENTRY(OTG, reg_num,\
 |
   
drivers/gpu/drm/amd/amdgpu/../display/dc/irq/dcn21/irq_service_dcn21.c:242:39: 
note: in definition of macro 'vupdate_no_lock_int_entry'
 242 |  [DC_IRQ_SOURCE_VUPDATE1 + reg_num] = {\
 |   ^~
 243 |   IRQ_REG_ENTRY(OTG, reg_num,\
 |
>> drivers/gpu/drm/amd/amdgpu/../display/dc/irq/dcn21/irq_service_dcn21.c:242:39:
>>  warning: initialized field overwritten [-Woverride-init]
 242 |  [DC_IRQ_SOURCE_VUPDATE1 + reg_num] = {\
 |   ^~
 243 |   IRQ_REG_ENTRY(OTG, reg_num,\
 |
   
drivers/gpu/drm/amd/amdgpu/../display/dc/irq/dcn21/irq_service_dcn21.c:242:39: 
note: in definition of macro 'vupdate_no_lock_int_entry'
 242 |  [DC_IRQ_SOURCE_VUPDATE1 + reg_num] = {\
 |   ^~
 243 |   IRQ_REG_ENTRY(OTG, reg_num,\
 |
   
drivers/gpu/drm/amd/amdgpu/../display/dc/irq/dcn21/irq_service_dcn21.c:242:39: 
note: (near initialization for 'irq_source_info_dcn21[73]')
 242 |  [DC_IRQ_SOURCE_VUPDATE1 + reg_num] = {\
 |   ^~
 243 |   IRQ_REG_ENTRY(OTG, reg_num,\
 |
   
drivers/gpu/drm/amd/amdgpu/../display/dc/irq/dcn21/irq_service_dcn21.c:242:39: 
note: in definition of macro 'vupdate_no_lock_int_entry'
 242 |  [DC_IRQ_SOURCE_VUPDATE1 + reg_num] = {\
 |   ^~
 243 |   IRQ_REG_ENTRY(OTG, reg_num,\
 |
>> drivers/gpu/drm/amd/amdgpu/../display/dc/irq/dcn21/irq_service_dcn21.c:242:39:
>>  warning: initialized field overwritten [-Woverride-init]
 242 |  [DC_IRQ_SOURCE_VUPDATE1 + reg_num] = {\
 |   ^~
 243 |   IRQ_REG_ENTRY(OTG, reg_num,\
 |
   
drivers/gpu/drm/amd/amdgpu/../display/dc/irq/dcn21/irq_service_dcn21.c:242:39: 
note: in definition of macro 'vupdate_no_lock_int_entry'
 242 |  [DC_IRQ_SOURCE_VUPDATE1 + reg_num] = {\
 |   ^~
 243 |   IRQ_REG_ENTRY(OTG, reg_num,\
 |
   
drivers/gpu/drm/amd/amdgpu/../display/dc/irq/dcn21/irq_service_dcn21.c:242:39: 
note: (near initialization for 'irq_source_info_dcn21[74]')
 242 |  [DC_IRQ_SOURCE_VUPDATE1 + reg_num] = {\
 |   ^~
 

Re: [PATCH 34/41] arm64: dts: qcom: sdm630-nile: Configure WCN3990 Bluetooth

[Konrad Dybcio]

> From: AngeloGioacchino Del Regno 

From: Martin Botka 


That got caught in rebasing madness.. Should any additional mistakes appear, 
I'll send a V2.


Konrad

Re: [PATCH 4.4.y] arm: kprobes: Allow to handle reentered kprobe on single-stepping

[Shaobo Huang]

> 
> From: Masami Hiramatsu 
> 
> commit f3fbd7ec62dec1528fb8044034e2885f2b257941 upstream
> 
> This is arm port of commit 6a5022a56ac3 ("kprobes/x86: Allow to
> handle reentered kprobe on single-stepping")
> 
> Since the FIQ handlers can interrupt in the single stepping
> (or preparing the single stepping, do_debug etc.), we should
> consider a kprobe is hit in the NMI handler. Even in that
> case, the kprobe is allowed to be reentered as same as the
> kprobes hit in kprobe handlers
> (KPROBE_HIT_ACTIVE or KPROBE_HIT_SSDONE).
> 
> The real issue will happen when a kprobe hit while another
> reentered kprobe is processing (KPROBE_REENTER), because
> we already consumed a saved-area for the previous kprobe.
> 
> Signed-off-by: Masami Hiramatsu 
> Signed-off-by: Jon Medhurst 
> Fixes: 24ba613c9d6c ("ARM kprobes: core code")
> Cc: sta...@vger.kernel.org #v2.6.25~v4.11
> Signed-off-by: huangshaobo 

arm32 jprobe does not handle interrupt reentry correctly. When jprobe is
running in singlestep, jprobe is triggered again in system interrupt, it
will run to the BUG function to cause panic.

jprobe needs to enter the kprobe_handler function twice, the first time to
enter kprobe_handler to save the context environment; the second time to
enter kprobe_handler to simulate the replaced instruction and restore the
context environment of the probed function.But the system interrupt is not
closed when the kprobe_handler is entered for the second time in jprobe_return. 
the code of jprobe_return is as follows:
void __kprobes jprobe_return(void)
{
struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
 
__asm__ __volatile__ (
/*
 * Setup an empty pt_regs. Fill SP and PC fields as
 * they're needed by longjmp_break_handler.
 *
 * We allocate some slack between the original SP and start of
 * our fabricated regs. To be precise we want to have worst case
 * covered which is STMFD with all 16 regs so we allocate 2 *
 * sizeof(struct_pt_regs)).
 *
 * This is to prevent any simulated instruction from writing
 * over the regs when they are accessing the stack.
 */
#ifdef CONFIG_THUMB2_KERNEL
...
#else
"subsp, %0, %1  \n\t"
#endif
"ldrr0, ="__stringify(JPROBE_MAGIC_ADDR)"\n\t"
"str%0, [sp, %2]\n\t"
"strr0, [sp, %3]\n\t"
"movr0, sp  \n\t"
"bl kprobe_handler  \n\t"
 
/*
 * Return to the context saved by setjmp_pre_handler
 * and restored by longjmp_break_handler.
 */
#ifdef CONFIG_THUMB2_KERNEL
...
#else
"ldrr0, [sp, %4]\n\t"
"msrcpsr_cxsf, r0   \n\t"
"ldmia  sp, {r0 - pc}   \n\t"
#endif
:
: "r" (kcb->jprobe_saved_regs.ARM_sp),
  "I" (sizeof(struct pt_regs) * 2),
  "J" (offsetof(struct pt_regs, ARM_sp)),
  "J" (offsetof(struct pt_regs, ARM_pc)),
  "J" (offsetof(struct pt_regs, ARM_cpsr)),
  "J" (offsetof(struct pt_regs, ARM_lr))
: "memory", "cc");
}
If the execution reaches the singlestep, the jprobe status is KPROBE_HIT_SS. 
If an interrupt is generated at this time, and jprobe is triggered again in
the interrupt, jprobe reentry will be generated, at this time 
kcb->kprobe_status==KPROBE_HIT_SS, Enter the default branch to execute the
BUG function, causing the system to panic. The partial code of kprobe_handler
is as follows:
void __kprobes kprobe_handler(struct pt_regs *regs)
{
struct kprobe *p, *cur;
struct kprobe_ctlblk *kcb;

kcb = get_kprobe_ctlblk();
cur = kprobe_running();

#ifdef CONFIG_THUMB2_KERNEL
/*
 * First look for a probe which was registered using an address with
 * bit 0 set, this is the usual situation for pointers to Thumb code.
 * If not found, fallback to looking for one with bit 0 clear.
 */
p = get_kprobe((kprobe_opcode_t *)(regs->ARM_pc | 1));
if (!p)
p = get_kprobe((kprobe_opcode_t *)regs->ARM_pc);

#else /* ! CONFIG_THUMB2_KERNEL */
p = get_kprobe((kprobe_opcode_t *)regs->ARM_pc);
#endif

if (p) {
if (cur) {
/* Kprobe is pending, so we're recursing. */
switch (kcb->kprobe_status) {
case KPROBE_HIT_ACTIVE:
case KPROBE_HIT_SSDONE:
/* A pre- or post-handler probe got us here. */
kprobes_inc_nmissed_count(p);
sa

Re: [PATCH 34/41] arm64: dts: qcom: sdm630-nile: Configure WCN3990 Bluetooth

[Martin Botka]

Signed-off-by: Martin Botka 

Sorry for the second Sob. Previous one was HTML. Sorry

On Sat, Feb 27, 2021 at 11:40, Konrad Dybcio 
 wrote:


 From: AngeloGioacchino Del Regno 



From: Martin Botka 


That got caught in rebasing madness.. Should any additional mistakes 
appear, I'll send a V2.



Konrad

Re: [PATCH] net/core/skbuff.c: __netdev_alloc_skb fix when len is greater than KMALLOC_MAX_SIZE

[Alexander Lobakin]

From: Pavel Skripkin 
Date: Fri, 26 Feb 2021 22:11:06 +0300

Hi,

> syzbot found WARNING in __alloc_pages_nodemask()[1] when order >= MAX_ORDER.
> It was caused by __netdev_alloc_skb(), which doesn't check len value after 
> adding NET_SKB_PAD.
> Order will be >= MAX_ORDER and passed to __alloc_pages_nodemask() if size > 
> KMALLOC_MAX_SIZE.
>
> static void *kmalloc_large_node(size_t size, gfp_t flags, int node)
> {
>   struct page *page;
>   void *ptr = NULL;
>   unsigned int order = get_order(size);
> ...
>   page = alloc_pages_node(node, flags, order);
> ...
>
> [1] WARNING in __alloc_pages_nodemask+0x5f8/0x730 mm/page_alloc.c:5014
> Call Trace:
>  __alloc_pages include/linux/gfp.h:511 [inline]
>  __alloc_pages_node include/linux/gfp.h:524 [inline]
>  alloc_pages_node include/linux/gfp.h:538 [inline]
>  kmalloc_large_node+0x60/0x110 mm/slub.c:3999
>  __kmalloc_node_track_caller+0x319/0x3f0 mm/slub.c:4496
>  __kmalloc_reserve net/core/skbuff.c:150 [inline]
>  __alloc_skb+0x4e4/0x5a0 net/core/skbuff.c:210
>  __netdev_alloc_skb+0x70/0x400 net/core/skbuff.c:446
>  netdev_alloc_skb include/linux/skbuff.h:2832 [inline]
>  qrtr_endpoint_post+0x84/0x11b0 net/qrtr/qrtr.c:442
>  qrtr_tun_write_iter+0x11f/0x1a0 net/qrtr/tun.c:98
>  call_write_iter include/linux/fs.h:1901 [inline]
>  new_sync_write+0x426/0x650 fs/read_write.c:518
>  vfs_write+0x791/0xa30 fs/read_write.c:605
>  ksys_write+0x12d/0x250 fs/read_write.c:658
>  do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
>  entry_SYSCALL_64_after_hwframe+0x44/0xa9
>
> Reported-by: syzbot+80dccaee7c6630fa9...@syzkaller.appspotmail.com
> Signed-off-by: Pavel Skripkin 
> Change-Id: I480a6d6f818a4c0a387db0cd3f230b68a7daeb16
> ---
>  net/core/skbuff.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index 785daff48030..dc28c8f7bf5f 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -443,6 +443,9 @@ struct sk_buff *__netdev_alloc_skb(struct net_device 
> *dev, unsigned int len,
>   if (len <= SKB_WITH_OVERHEAD(1024) ||
>   len > SKB_WITH_OVERHEAD(PAGE_SIZE) ||
>   (gfp_mask & (__GFP_DIRECT_RECLAIM | GFP_DMA))) {
> + if (len > KMALLOC_MAX_SIZE)
> + return NULL;

I'd use unlikely() for this as it's very very rare condition on the
very hot path.

Also, I'd add the same check below into __napi_alloc_skb() as it has
the same fallback.

>   skb = __alloc_skb(len, gfp_mask, SKB_ALLOC_RX, NUMA_NO_NODE);
>   if (!skb)
>   goto skb_fail;
> --
> 2.25.1

Thanks,
Al

Re: [PATCH v2] media: add a subsystem profile documentation

[Lukas Bulwahn]

On Thu, Feb 25, 2021 at 2:41 PM Mauro Carvalho Chehab
 wrote:
>
> Document the basic policies of the media subsystem profile.
>
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>
> v2: fix the Documentation/*/media directories
>
>
>  Documentation/driver-api/media/index.rst  |   2 +
>  .../media/maintainer-entry-profile.rst| 161 ++
>  .../maintainer/maintainer-entry-profile.rst   |   1 +
>  3 files changed, 164 insertions(+)
>  create mode 100644 
> Documentation/driver-api/media/maintainer-entry-profile.rst
>
> diff --git a/Documentation/driver-api/media/index.rst 
> b/Documentation/driver-api/media/index.rst
> index c140692454b1..2ad71dfa8828 100644
> --- a/Documentation/driver-api/media/index.rst
> +++ b/Documentation/driver-api/media/index.rst
> @@ -28,6 +28,8 @@ Please see:
>  :maxdepth: 5
>  :numbered:
>
> +maintainer-entry-profile
> +
>  v4l2-core
>  dtv-core
>  rc-core
> diff --git a/Documentation/driver-api/media/maintainer-entry-profile.rst 
> b/Documentation/driver-api/media/maintainer-entry-profile.rst
> new file mode 100644
> index ..6318be833bfb
> --- /dev/null
> +++ b/Documentation/driver-api/media/maintainer-entry-profile.rst
> @@ -0,0 +1,161 @@
> +Media Subsystem Profile
> +===
> +
> +Overview
> +
> +
> +The media subsystem covers support for a variety of devices: stream
> +capture, analog and digital TV, cameras, remote controllers, HDMI CEC
> +and media pipeline control.
> +
> +It covers, mainly, the contents of those directories:
> +
> +  - drivers/media
> +  - drivers/staging/media
> +  - Documentation/admin-guide/media
> +  - Documentation/driver-api/media
> +  - Documentation/userspace-api/media
> +  - include/media
> +
> +Both media userspace and Kernel APIs are documented and should be kept in
> +sync with the API changes. It means that all patches that add new
> +features to the subsystem should also bring changes to the corresponding
> +API files.
> +
> +Due to the size and wide scope of the media subsystem, media's
> +maintainership model is to have sub-maintainers that have a broad
> +knowledge of a specific aspect of the subsystem. It is the sub-maintainers'
> +task to review the patches, providing feedback to users if the patches are
> +following the subsystem rules and are properly using the media kernel and
> +userspace APIs.
> +
> +Patches for the media subsystem should be sent to the media mailing list
> +at linux-me...@vger.kernel.org as plain text only e-mail. Emails with
> +HTML will be automatically rejected by the mail server. It could be wise
> +to also copy the sub-maintainer(s).
> +
> +Media's workflow is heavily based on Patchwork, meaning that, once a patch
> +is submitted, it should appear at:
> +
> +   - https://patchwork.linuxtv.org/project/linux-media/list/
> +
> +If it doesn't automatically appear there after a few minutes, then
> +probably something got wrong on your submission. Please check if the
> +email is in plain text only and if your emailer is not mangling with
> +whitespaces before complaining or submitting them again.
> +
> +Sub-maintainers
> 
> +
> +At the media subsystem, we have a group of experienced developers that
> +are responsible for doing the code reviews at the drivers (called
> +sub-maintainers), and another senior developer responsible for the
> +subsystem as a hole. For core changes, whenever possible, multiple
> +media (sub-)maintainers do the review.
> +
> +The sub-maintainers work on specific areas of the subsystem, as
> +described below:
> +
> +Digital TV:
> +  Sean Young 
> +
> +HDMI CEC:
> +  Hans Verkuil 
> +
> +Media controller drivers:
> +  Laurent Pinchart 
> +
> +Remote Controllers:
> +  Sean Young 
> +
> +Sensor drivers:
> +  Sakari Ailus 
> +
> +V4L2 drivers:
> +  Hans Verkuil 
> +
> +Submit Checklist Addendum
> +-
> +
> +Patches that change the Open Firmware/Device Tree bindings should be
> +reviewed by the Device Tree maintainers. So, DT maintainers should be
> +c/c when those are submitted.
> +
> +There is a set of compliance tools at https://git.linuxtv.org/v4l-utils.git/
> +that should be used in order to check if the drivers are properly
> +implementing the media APIs.
> +
> +Those tests need to pass before the patches go upstream.
> +
> +Also, please notice that we build the Kernel with::
> +
> +   make CF=-D__CHECK_ENDIAN__ CONFIG_DEBUG_SECTION_MISMATCH=y C=1 W=1 
> CHECK=check_script
> +
> +Where the check script is::
> +
> +   #!/bin/bash
> +   /devel/smatch/smatch -p=kernel $@ >&2
> +   /devel/sparse/sparse $@ >&2
> +
> +Be sure to not introduce new warnings on your patches without a
> +very good reason.
> +
> +Style Cleanup Patches
> ++
> +
> +Style-cleanups are welcome when they come together with other changes
> +at the files where the style changes will affect.
> +
> +We may accept pure standalone style-cleanups, but they should ideally
> +be 

[PATCH] KVM: x86: fix Hot-plugged cpu hang when Configured tsc-frequency is not equal to host

[ann.zhuangyanying]

From: Zhuang Yanying 

If the TSC frequency of the VM is not equal to the host, hot-plugging vCPU
will cause the VM to be hang. The time of hang depends on the current TSC
value of the VM.

During hot-plugging vCPUs, kvm_arch_vcpu_create() uses max_tsc_khz,
that is the host TSC frequency, to initialize TSC frequency of the vcpu.
Then, configure the target frequency by using KVM_SET_TSC_KHZ.
Set the tsc valus of the vCPU to 0 by using MSR_IA32_TSC.

If the vCPU TSC frequency is the same as the host, kvm_synchronize_tsc()
adjusts the TSC value of the hot-plugged vCPU based on the elapsed time.
However, when the vCPU TSC frequency is different from the host,
the TSC value of the hot-plugged vCPU is 0 and is displayed to the guest
OS, trigger tsc adjustment. As a result, the guest OS marks TSC unstable
and hangs for a while.

The TSC frequency of the same CPU model may differ slightly.
After live migration, hot-plugging vCPU to the Destination VM, trigger the
VM hangs for a long while. After CPU supports TSC scaling, the TSC value
of the hot-plugged vCPU can be adjusted based on the elapsed time
even if the VM TSC frequency is different from the host TSC frequency.

kvm->arch.last_tsc_khz stores the TSC frequency value of the VM.
last_tsc_khz can be used to initialize the TSC frequency of the
hot-plugging vCPU.

Signed-off-by: Zhuang Yanying 
---
 Host:
  Intel(R) Xeon(R) Gold 6161 CPU @ 2.20GHz
  linux-5.11
  qemu-5.1

  


  
  
  

 Guest:
  entos8.1 (4.18.0-147.el8.x86_6)

 After Hotplug cpu, vm hang for 290s:
  [  283.224026] CPU3 has been hot-added
  [  283.226118] smpboot: Booting Node 0 Processor 3 APIC 0x3
  [  283.226964] kvm-clock: cpu 3, msr 9e5e010c1, secondary cpu clock
  [  283.247200] TSC ADJUST compensate: CPU3 observed 867529151959 warp. 
Adjust: 867529151959
  [  572.445543] KVM setup async PF for cpu 3
  [  572.446412] kvm-stealtime: cpu 3, msr a16ce5040
  [  572.448108] Will online and init hotplugged CPU: 3
  Feb 27 18:47:28 localhost kernel: CPU3 has been hot-added
  Feb 27 18:47:28 localhost kernel: smpboot: Booting Node 0 Processor 3 APIC 0x3
  Feb 27 18:47:28 localhost kernel: kvm-clock: cpu 3, msr 9e5e010c1, secondary 
cpu clock
  Feb 27 18:47:28 localhost kernel: TSC ADJUST compensate: CPU3 observed 
867529151959 warp. Adjust: 867529151959
  Feb 27 18:47:28 localhost kernel: KVM setup async PF for cpu 3
  Feb 27 18:47:28 localhost kernel: kvm-stealtime: cpu 3, msr a16ce5040
  Feb 27 18:47:28 localhost kernel: Will online and init hotplugged CPU: 3
  Feb 27 18:47:28 localhost systemd[1]: Started 
/usr/lib/udev/kdump-udev-throttler.
  [  572.495181] clocksource: timekeeping watchdog on CPU2: Marking clocksource 
'tsc' as unstable because the skew is too large:
  [  572.495181] clocksource:   'kvm-clock' wd_now: 
86ab1286a2 wd_last: 4344b44d09 mask: 
  [  572.495181] clocksource:   'tsc' cs_now: ca313c563b 
cs_last: c9d88b54d2 mask: 
  [  572.495181] tsc: Marking TSC unstable due to clocksource watchdog
  [  572.495181] clocksource: Switched to clocksource kvm-clock
  Feb 27 18:47:28 localhost kernel: clocksource: timekeeping watchdog on CPU2: 
Marking clocksource 'tsc' as unstable because the skew 
  Feb 27 18:47:28 localhost kernel: clocksource:   
'kvm-clock' wd_now: 86ab1286a2 wd_last: 4344b44d09 mask: ff
  Feb 27 18:47:28 localhost kernel: clocksource:   'tsc' 
cs_now: ca313c563b cs_last: c9d88b54d2 mask: 
  Feb 27 18:47:28 localhost kernel: tsc: Marking TSC unstable due to 
clocksource watchdog
  Feb 27 18:47:28 localhost kernel: clocksource: Switched to clocksource 
kvm-clock
  Feb 27 18:47:28 localhost systemd[1]: Started Getty on tty2.
  Feb 27 18:47:29 localhost kdump-udev-throttler[3530]: kexec: unloaded kdump 
kernel
  Feb 27 18:47:29 localhost kdump-udev-throttler[3530]: Stopping kdump: [OK]
  Feb 27 18:47:29 localhost kdump-udev-throttler[3530]: kexec: loaded kdump 
kernel
  Feb 27 18:47:29 localhost kdump-udev-throttler[3530]: Starting kdump: [OK]

---
 arch/x86/kvm/x86.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 1b404e4d7dd8..c3c62a9865d3 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -9952,7 +9952,12 @@ int kvm_arch_vcpu_create(struct kvm_vcpu *vcpu)
else
vcpu->arch.mp_state = KVM_MP_STATE_UNINITIALIZED;
 
-   kvm_set_tsc_khz(vcpu, max_tsc_khz);
+   if (vcpu->kvm->arch.last_tsc_khz)
+   r = kvm_set_tsc_khz(vcpu, vcpu->kvm->arch.last_tsc_khz);
+   else
+   r = kvm_set_tsc_khz(vcpu, max_tsc_khz);
+   if (r < 0)
+   return r;
 
r = kvm_mmu_create(vcpu);
if (r < 0)
-- 
2.23.0

[PATCH] rockchip: Make cdn_dp_resume depend on CONFIG_PM_SLEEP

[Chen Jun]

If build Image without CONFIG_PM_SLEEP, there would be a compile warning:
warning: ‘cdn_dp_resume’ defined but not used [-Wunused-function]

Because SET_SYSTEM_SLEEP_PM_OPS will do nothing without CONFIG_PM_SLEEP.

Make cdn_dp_resume depend on CONFIG_PM_SLEEP

Signed-off-by: Chen Jun 
---
 drivers/gpu/drm/rockchip/cdn-dp-core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c 
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index a4a45daf93f2..063a60d213ba 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -1121,6 +1121,7 @@ static int cdn_dp_suspend(struct device *dev)
return ret;
 }
 
+#ifdef CONFIG_PM_SLEEP
 static int cdn_dp_resume(struct device *dev)
 {
struct cdn_dp_device *dp = dev_get_drvdata(dev);
@@ -1133,6 +1134,7 @@ static int cdn_dp_resume(struct device *dev)
 
return 0;
 }
+#endif
 
 static int cdn_dp_probe(struct platform_device *pdev)
 {
-- 
2.25.0

[PATCH 1/3] f2fs: remove unnecessary IS_SWAPFILE check

[Huang Jianan]

Now swapfile in f2fs directly submit IO to blockdev according to
swapfile extents reported by f2fs when swapon, therefore there is
no need to check IS_SWAPFILE when exec filesystem operation.

Signed-off-by: Huang Jianan 
Signed-off-by: Guo Weichao 
---
 fs/f2fs/data.c | 2 +-
 fs/f2fs/f2fs.h | 3 +--
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index b9721c8f116c..a1498a1a345c 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -1723,7 +1723,7 @@ static int get_data_block_dio_write(struct inode *inode, 
sector_t iblock,
return __get_data_block(inode, iblock, bh_result, create,
F2FS_GET_BLOCK_DIO, NULL,
f2fs_rw_hint_to_seg_type(inode->i_write_hint),
-   IS_SWAPFILE(inode) ? false : true);
+   true);
 }
 
 static int get_data_block_dio(struct inode *inode, sector_t iblock,
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index cccdfb1a40ab..3f65cfe11a0f 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -4176,8 +4176,7 @@ static inline bool f2fs_force_buffered_io(struct inode 
*inode,
if (F2FS_IO_ALIGNED(sbi))
return true;
}
-   if (is_sbi_flag_set(F2FS_I_SB(inode), SBI_CP_DISABLED) &&
-   !IS_SWAPFILE(inode))
+   if (is_sbi_flag_set(F2FS_I_SB(inode), SBI_CP_DISABLED))
return true;
 
return false;
-- 
2.25.1

[PATCH 3/3] f2fs: check if swapfile is section-alligned

[Huang Jianan]

If the swapfile isn't created by pin and fallocate, it cann't be
guaranteed section-aligned, so it may be selected by f2fs gc. When
gc_pin_file_threshold is reached, the address of swapfile may change,
but won't be synchroniz to swap_extent, so swap will write to wrong
address, which will cause data corruption.

Signed-off-by: Huang Jianan 
Signed-off-by: Guo Weichao 
---
 fs/f2fs/data.c | 63 ++
 1 file changed, 63 insertions(+)

diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 4dbc1cafc55d..3e523d6e4643 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -3781,11 +3781,63 @@ int f2fs_migrate_page(struct address_space *mapping,
 #endif
 
 #ifdef CONFIG_SWAP
+static int f2fs_check_file_aligned(struct inode *inode)
+{
+   struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
+   block_t main_blkaddr = SM_I(sbi)->main_blkaddr;
+   block_t cur_lblock;
+   block_t last_lblock;
+   block_t pblock;
+   unsigned long len;
+   unsigned long nr_pblocks;
+   unsigned int blocks_per_sec = sbi->blocks_per_seg * sbi->segs_per_sec;
+   int ret;
+
+   cur_lblock = 0;
+   last_lblock = bytes_to_blks(inode, i_size_read(inode));
+   len = i_size_read(inode);
+
+   while (cur_lblock < last_lblock) {
+   struct f2fs_map_blocks map;
+   pgoff_t next_pgofs;
+
+   memset(&map, 0, sizeof(map));
+   map.m_lblk = cur_lblock;
+   map.m_len = bytes_to_blks(inode, len) - cur_lblock;
+   map.m_next_pgofs = &next_pgofs;
+   map.m_seg_type = NO_CHECK_TYPE;
+
+   ret = f2fs_map_blocks(inode, &map, 0, F2FS_GET_BLOCK_FIEMAP);
+
+   if (ret)
+   goto err_out;
+
+   /* hole */
+   if (!(map.m_flags & F2FS_MAP_FLAGS))
+   goto err_out;
+
+   pblock = map.m_pblk;
+   nr_pblocks = map.m_len;
+
+   if ((pblock - main_blkaddr) & (blocks_per_sec - 1) ||
+   nr_pblocks & (blocks_per_sec - 1))
+   goto err_out;
+
+   cur_lblock += nr_pblocks;
+   }
+
+   return 0;
+err_out:
+   pr_err("swapon: swapfile isn't section-aligned\n");
+   return -EINVAL;
+}
+
 static int check_swap_activate_fast(struct swap_info_struct *sis,
struct file *swap_file, sector_t *span)
 {
struct address_space *mapping = swap_file->f_mapping;
struct inode *inode = mapping->host;
+   struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
sector_t cur_lblock;
sector_t last_lblock;
sector_t pblock;
@@ -3793,6 +3845,7 @@ static int check_swap_activate_fast(struct 
swap_info_struct *sis,
sector_t highest_pblock = 0;
int nr_extents = 0;
unsigned long nr_pblocks;
+   unsigned int blocks_per_sec = sbi->blocks_per_seg * sbi->segs_per_sec;
u64 len;
int ret;
 
@@ -3827,6 +3880,13 @@ static int check_swap_activate_fast(struct 
swap_info_struct *sis,
pblock = map.m_pblk;
nr_pblocks = map.m_len;
 
+   if ((pblock - SM_I(sbi)->main_blkaddr) & (blocks_per_sec - 1) ||
+   nr_pblocks & (blocks_per_sec - 1)) {
+   pr_err("swapon: swapfile isn't section-aligned\n");
+   ret = -EINVAL;
+   goto out;
+   }
+
if (cur_lblock + nr_pblocks >= sis->max)
nr_pblocks = sis->max - cur_lblock;
 
@@ -3878,6 +3938,9 @@ static int check_swap_activate(struct swap_info_struct 
*sis,
if (PAGE_SIZE == F2FS_BLKSIZE)
return check_swap_activate_fast(sis, swap_file, span);
 
+   if (f2fs_check_file_aligned(inode))
+   return -EINVAL;
+
blocks_per_page = bytes_to_blks(inode, PAGE_SIZE);
 
/*
-- 
2.25.1

[PATCH 2/3] f2fs: fix last_lblock check in check_swap_activate_fast

[Huang Jianan]

Because page_no < sis->max guarantees that the while loop break out 
normally, the wrong check contidion here doesn't cause a problem.

Signed-off-by: Huang Jianan 
Signed-off-by: Guo Weichao 
---
 fs/f2fs/data.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index a1498a1a345c..4dbc1cafc55d 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -3804,7 +3804,7 @@ static int check_swap_activate_fast(struct 
swap_info_struct *sis,
last_lblock = bytes_to_blks(inode, i_size_read(inode));
len = i_size_read(inode);
 
-   while (cur_lblock <= last_lblock && cur_lblock < sis->max) {
+   while (cur_lblock + 1 <= last_lblock && cur_lblock < sis->max) {
struct f2fs_map_blocks map;
pgoff_t next_pgofs;
 
-- 
2.25.1

Re: [PATCH] copy_file_range.2: Kernel v5.12 updates

[Alejandro Colomar (man-pages)]

Hi Amir,

On 2/27/21 6:41 AM, Amir Goldstein wrote:

On Sat, Feb 27, 2021 at 12:19 AM Alejandro Colomar (man-pages)

On 2/24/21 5:10 PM, Amir Goldstein wrote:

On Wed, Feb 24, 2021 at 4:22 PM Luis Henriques  wrote:

   .TP
+.B EOPNOTSUPP


I'll add the kernel version here:

.BR EOPNOTSUPP " (since Linux 5.12)"


Error could be returned prior to 5.3 and would be probably returned
by future stable kernels 5.3..5.12 too


OK, I think I'll state <5.3 and >=5.12 for the moment, and if Greg adds 
that to stable 5.3..5.11 kernels, please update me.



   .B EXDEV
   The files referred to by
   .IR fd_in " and " fd_out
-are not on the same mounted filesystem (pre Linux 5.3).
+are not on the same mounted filesystem (pre Linux 5.3 and post Linux 5.12).


I'm not sure that 'mounted' adds any value here.  Would you remove the
word here?


See rename(2). 'mounted' in this context is explained there.
HOWEVER, it does not fit here.
copy_file_range() IS allowed between two mounts of the same filesystem instance.


Also allowed for <5.3 ?



To make things more complicated, it appears that cross mount clone is not
allowed via FICLONE/FICLONERANGE ioctl, so ioctl_ficlonerange(2) man page
also uses the 'mounted filesystem' terminology for EXDEV

As things stand now, because of the fallback to clone logic,
copy_file_range() provides a way for users to clone across different mounts
of the same filesystem instance, which they cannot do with the FICLONE ioctl.

Fun :)

BTW, I don't know if preventing cross mount clone was done intentionally,
but as I wrote in a comment in the code once:

 /*
  * FICLONE/FICLONERANGE ioctls enforce that src and dest files are on
  * the same mount. Practically, they only need to be on the same file
  * system.
  */


:)





It reads as if two separate devices with the same filesystem type would
still give this error.

Per the LWN.net article Amir shared, this is permitted ("When called
from user space, copy_file_range() will only try to copy a file across
filesystems if the two are of the same type").

This behavior was slightly different before 5.3 AFAICR (was it?) ("until
then, copy_file_range() refused to copy between files that were not
located on the same filesystem.").  If that's the case, I'd specify the
difference, or more probably split the error into two, one before 5.3,
and one since 5.12.



True.



I think you need to drop the (Linux range) altogether.


I'll keep the range.  Users of 5.3..5.11 might be surprised if the
filesystems are different and they don't get an error, I think.

I reworded it to follow other pages conventions:

.BR EXDEV " (before Linux 5.3; or since Linux 5.12)"

which renders as:

 EXDEV (before Linux 5.3; or since Linux 5.12)
The files referred to by fd_in and fd_out are not on
the same mounted filesystem.



drop 'mounted'


Yes






What's missing here is the NFS cross server copy use case.
Maybe:

...are not on the same mounted filesystem and the source and target filesystems
do not support cross-filesystem copy.


Yes.

Again, this wasn't true before 5.3, right?



Right.
Actually, v5.3 provides the vfs capabilities for filesystems to support
cross fs copy. I am not sure if NFS already implements cross fs copy in
v5.3 and not sure about cifs. Need to get input from nfs/cis developers
or dig in the release notes for server-side copy.


Okay

Thanks to LWN :)


:)

Thanks,

Alex


--
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/

[PATCH] MIPS: select CPU_MIPS64 for remaining MIPS64 CPUs

[Jason A. Donenfeld]

The CPU_MIPS64 and CPU_MIPS32 variables are supposed to be able to
distinguish broadly between 64-bit and 32-bit MIPS CPUs. However, they
weren't selected by the specialty CPUs, Octeon and Loongson, which meant
it was possible to hit a weird state of:

MIPS=y, CONFIG_64BIT=y, CPU_MIPS64=n

This commit rectifies the issue by having CPU_MIPS64 be selected when
the missing Octeon or Loongson models are selected.

Cc: Thomas Bogendoerfer 
Cc: Ralf Baechle 
Cc: George Cherian 
Cc: Huacai Chen 
Cc: Jiaxun Yang 
Signed-off-by: Jason A. Donenfeld 
---
 arch/mips/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index d89efba3d8a4..3e0e8f1d2e82 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -2118,7 +2118,7 @@ config CPU_MIPS32
 config CPU_MIPS64
bool
default y if CPU_MIPS64_R1 || CPU_MIPS64_R2 || CPU_MIPS64_R5 || \
-CPU_MIPS64_R6
+CPU_MIPS64_R6 || CPU_LOONGSON64 || CPU_CAVIUM_OCTEON
 
 #
 # These indicate the revision of the architecture
-- 
2.30.1

Re: [PATCH] ipc/msg: add msgsnd_timed and msgrcv_timed syscall for system V message queue

[Arnd Bergmann]

On Sat, Feb 27, 2021 at 7:52 AM Eric Gao  wrote:
>
> sometimes, we need the msgsnd or msgrcv syscall can return after a limited
> time, so that the business thread do not be blocked here all the time. In
> this case, I add the msgsnd_timed and msgrcv_timed syscall that with time
> parameter, which has a unit of ms.
>
> Signed-off-by: Eric Gao 

I have no opinion on whether we want or need this, but I'll have a look
at the implementation, to see if the ABI makes sense.

> index 8fd8c17..42b7db5 100644
> --- a/arch/mips/kernel/syscalls/syscall_n32.tbl
> +++ b/arch/mips/kernel/syscalls/syscall_n32.tbl
> @@ -381,3 +381,5 @@
>  440n32 process_madvise sys_process_madvise
>  441n32 epoll_pwait2compat_sys_epoll_pwait2
>  442n32 mount_setattr   sys_mount_setattr
> +443n32 msgrcv_timedsys_msgrcv_timed
> +444n32 msgsnd_timedsys_msgsnd_timed
> diff --git a/arch/mips/kernel/syscalls/syscall_o32.tbl 
> b/arch/mips/kernel/syscalls/syscall_o32.tbl
> index 090d29c..0f1f6ee 100644
> --- a/arch/mips/kernel/syscalls/syscall_o32.tbl
> +++ b/arch/mips/kernel/syscalls/syscall_o32.tbl
> @@ -430,3 +430,5 @@
>  440o32 process_madvise sys_process_madvise
>  441o32 epoll_pwait2sys_epoll_pwait2  
>   compat_sys_epoll_pwait2
>  442o32 mount_setattr   sys_mount_setattr
> +443o32 msgrcv_timedsys_msgrcv_timed
> +444o32 msgsnd_timedsys_msgsnd_timed

I think mips n32 and o32 both need to use the compat version when running on
a 64-bit kernel, while your patch makes them use the native version.

> @@ -905,7 +906,15 @@ static long do_msgsnd(int msqid, long mtype, void __user 
> *mtext,
>
> ipc_unlock_object(&msq->q_perm);
> rcu_read_unlock();
> -   schedule();
> +
> +   /* sometimes, we need msgsnd syscall return after a given 
> time */
> +   if (timeoutms <= 0) {
> +   schedule();
> +   } else {
> +   timeoutms = schedule_timeout(timeoutms);
> +   if (timeoutms == 0)
> +   timeoutflag = true;
> +   }

I wonder if this should be schedule_timeout_interruptible() or at least
schedule_timeout_killable() instead of schedule_timeout(). If it should,
this should probably be done as a separate change.

> +COMPAT_SYSCALL_DEFINE5(msgsnd_timed, int, msqid, compat_uptr_t, msgp,
> +  compat_ssize_t, msgsz, int, msgflg, compat_long_t, 
> timeoutms)
> +{
> +   struct compat_msgbuf __user *up = compat_ptr(msgp);
> +   compat_long_t mtype;
> +
> +   timeoutms = (timeoutms + 9) / 10;
> +
> +   if (get_user(mtype, &up->mtype))
> +   return -EFAULT;
> +
> +   return do_msgsnd(msqid, mtype, up->mtext, (ssize_t)msgsz, msgflg, 
> (long)timeoutms);
> +}

My preference would be to simplify both the timed and non-timed version by
moving the get_user() into do_msgsnd() and using in_compat_task() to pick
the right type. Same for the receive side of course. If you do this,
watch out for
x32 support, which uses the 64-bit version.

   Arnd

Re: [PATCH 2/2] PCI: controller: avoid building empty drivers

[Arnd Bergmann]

On Fri, Feb 26, 2021 at 8:08 PM Robert Richter  wrote:
> On 25.02.21 15:37:10, Arnd Bergmann wrote:
>
> A possible double inclusion isn't really nice here, but it should work
> that way.
>
> Also, the menu entry for the driver is in fact only for the OF case,
> as it is always included for ACPI even if the option is disabled (and
> thus the choice is useless). But this is unrelated to this patch.

Yes, I considered doing this using Kconfig syntax by adding another
symbol for each affected driver and selecting those, but the Makefile
hack seemed easier here.

> Reviewed-by: Robert Richter 

Thanks,

Arnd

[PATCH v6 0/2] hwspinlock: add sun6i hardware spinlock support

[Wilken Gottwalt]

Most of the Allwinner sun6i compatible devices contain a spinlock unit
which can be used to sync access to devices shared between the ARM cores
and the embedded companion core. According to the datasheets at least 32
spinlocks are supported. The implementation supports 32, 64, 128 and 256
spinlock setups, but there is no known SoC yet, which implements more
than 32 spinlocks.

This driver adds support for this hardware spinlock unit to Linux
including all 4 possible setups. The driver reports the found setup via
debugfs. It can be build as a builtin and normal module by using the
HWSPINLOCK_SUN8I symbol.

This driver is the first step to enable hwspinlock support in Linux, but
also requires support in the firmware of the companion core. This patch
provides the driver and binding documentation but is not yet included
into the sunxi files. Also not every sunxi seem to have support for this
hardware, but it can be found in sun6i, sun8i, sun9i and sun50i devices.

The spinlock hardware has two ways to figure out if a lock is taken. The
lock can simply be readi, or bits of a 32bit wide status register can be
checked. The status register only supports the first 32 locks and may
not cover bigger spinlock setups. Therefore reading/writing a specific
spinlock is used in the driver for checking the status of a lock.

The status register is now free for debugging/testing purposes and can
completely bypass the Linux hwspinlock ABI. This status register will be
used in some additional kernel modules to test the hwspinlock driver.

Testing the driver.

To run all tests it is necessary to take locks on the companion core and
show on the Linux side that the locks were taken by an external event.
This can be achived by using an Allwinner SoC which includes an OpenRisc
companion core and can use the free crust firmware. For this the crust
firmware needs to be changed to take and release spinlocks (a simple
MMIO operation on the hwlock registers), which is currently not
supported by the current crust firmware. The necessary crust fork can
be found here https://github.com/wgottwalt/crust (hwspinlock branch).
It is also necessary to build u-boot with support for this crust/SCP
firmware. This u-boot fork can be found here
https://github.com/crust-firmware/u-boot (crust branch).

To test this driver it is also necessary to pick a device that is fully
supported by the crust firmware. For this the H5 based Friendlyarm
NanoPi NEO2 was used. It is fully supported by u-boot (and the fork),
the crust firmware (via H5 target) and current Linux kernels. In the
crust fork it is necessary to go into debug menu of "make nconfig" and
select the hwspinlock test loop. This debug option enables a loop that
goes through the first 32 spinlocks. It takes/releases a lock one after
another using the timeout functions (and hw timers) of the crust
firmware. A timeout can be set in the debug menu.

Test 1:

This test was done using a mainline u-boot and a crust enabled u-boot.
For this a simple second kernel module was used, which can be found here
https://github.com/wgottwalt/sunxi_hwspinlock/tree/main/test.

Using mainline u-boot it shows that the Linux side correctly takes a
lock, tries to recursively take a lock again (which does not happen) and
releases a lock. This is done for all 32 locks several times.

# modprobe sun6i_hwspinlock_test
[  472.182172] [init]--- SUN6I HWSPINLOCK DRIVER TEST ---
[  472.187491] [run ]--- testing locks 0 to 31 ---
[  472.192058] [test] testing lock 0
[  472.195371] [test]+++ attempt #0 succeded
[  472.199394] [test]+++ attempt #1 succeded
[  472.203411] [test]+++ attempt #2 succeded
[  472.207433] [test] testing lock 1
[  472.210755] [test]+++ attempt #0 succeded
...
[  472.665684] [test]+++ attempt #2 succeded
[  472.669704] [test] testing lock 31
[  472.673117] [test]+++ attempt #0 succeded
[  472.677137] [test]+++ attempt #1 succeded
[  472.681152] [test]+++ attempt #2 succeded

If the same test is done with the hwspinlock loop enabled crust firmware
and the crust enabled u-boot fork, the Linux test kernel module hits the
one lock taken by the crust firmware.

# modprobe sun6i_hwspinlock_test
...
[  945.871840] [test]+++ attempt #1 succeded
[  945.875854] [test]+++ attempt #2 succeded
[  945.879875] [test] testing lock 18
[  945.883273] [test]+++ attempt #0 succeded
[  945.887293] [test]+++ attempt #1 succeded
[  945.891310] [test]+++ attempt #2 succeded
[  945.895329] [test] testing lock 19
[  945.898738] [test] taking lock attempt #0 failed (-16)
[  945.903886] [run ]--- testing specific lock 19 failed (-14) ---
[  945.909811] [test] testing lock 20
[  945.913224] [test]+++ attempt #0 succeded
[  945.917245] [test]+++ attempt #1 succeded
[  945.921265] [test]+++ attempt #2 succeded
[  945.925281] [test] testing lock 21
[  945.928694] [test]+++ attempt #0 succeded
[  945.932709] [test]+++ attempt #1 succeded
...

Test 2:

This is a more complex test which uses the status register to bypass the
Linux hwspinlock 

[PATCH v6 1/2] dt-bindings: hwlock: add sun6i_hwspinlock

[Wilken Gottwalt]

Adds documentation on how to use the sun6i_hwspinlock driver for sun6i
compatible series SoCs.

Signed-off-by: Wilken Gottwalt 
---
Changes in v6:
  - fixed formating and name issues in dt documentation

Changes in v5:
  - changed binding to earliest known supported SoC sun6i-a31
  - dropped unnecessary entries

Changes in v4:
  - changed binding to sun8i-a33-hwpinlock
  - added changes suggested by Maxime Ripard

Changes in v3:
  - changed symbols from sunxi to sun8i

Changes in v2:
  - fixed memory ranges
---
 .../hwlock/allwinner,sun6i-hwspinlock.yaml| 45 +++
 1 file changed, 45 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/hwlock/allwinner,sun6i-hwspinlock.yaml

diff --git 
a/Documentation/devicetree/bindings/hwlock/allwinner,sun6i-hwspinlock.yaml 
b/Documentation/devicetree/bindings/hwlock/allwinner,sun6i-hwspinlock.yaml
new file mode 100644
index ..733c3d01e56c
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwlock/allwinner,sun6i-hwspinlock.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwlock/allwinner,sun6i-hwspinlock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SUN6I hardware spinlock driver for Allwinner sun6i compatible SoCs
+
+maintainers:
+  - Wilken Gottwalt 
+
+description:
+  The hardware unit provides semaphores between the ARM cores and the embedded
+  companion core on the SoC.
+
+properties:
+  compatible:
+const: allwinner,sun6i-a31-hwspinlock
+
+  reg:
+maxItems: 1
+
+  clocks:
+maxItems: 1
+
+  resets:
+maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - resets
+
+additionalProperties: false
+
+examples:
+  - |
+hwlock@1c18000 {
+compatible = "allwinner,sun6i-a31-hwspinlock";
+reg = <0x01c18000 0x1000>;
+clocks = <&ccu CLK_BUS_SPINLOCK>;
+resets = <&ccu RST_BUS_SPINLOCK>;
+};
+...
-- 
2.30.1

[PATCH v6 2/2] hwspinlock: add sun6i hardware spinlock support

[Wilken Gottwalt]

Adds the sun6i_hwspinlock driver for the hardware spinlock unit found in
most of the sun6i compatible SoCs.

This unit provides at least 32 spinlocks in hardware. The implementation
supports 32, 64, 128 or 256 32bit registers. A lock can be taken by
reading a register and released by writing a 0 to it. This driver
supports all 4 spinlock setups, but for now only the first setup (32
locks) seem to exist in available devices. This spinlock unit is shared
between all ARM cores and the embedded companion core. All of them can
take/release a lock with a single cycle operation. It can be used to
sync access to devices shared by the ARM cores and the companion core.

There are two ways to check if a lock is taken. The first way is to read
a lock. If a 0 is returned, the lock was free and is taken now. If an 1
is returned, the caller has to try again. Which means the lock is taken.
The second way is to read a 32bit wide status register where every bit
represents one of the 32 first locks. According to the datasheets this
status register supports only the 32 first locks. This is the reason the
first way (lock read/write) approach is used to be able to cover all 256
locks in future devices. The driver also reports the amount of supported
locks via debugfs.

Signed-off-by: Wilken Gottwalt 
---
Changes in v6:
  - changed probe/remove function to use classic functions to better
handle failure situations

Changes in v5:
  - changed symbols to the earliest known supported SoC (sun6i/a31)
  - changed init back to classic probe/remove callbacks

Changes in v4:
  - further simplified driver
  - fixed an add_action_and_reset_ function issue
  - changed bindings from sun8i-hwspinlock to sun8i-a33-hwspinlock

Changes in v3:
  - moved test description to cover letter
  - changed name and symbols from sunxi to sun8i
  - improved driver description
  - further simplified driver
  - fully switched to devm_* and devm_add_action_* functions

Changes in v2:
  - added suggestions from Bjorn Andersson and Maxime Ripard
  - provided better driver and test description
---
 MAINTAINERS   |   6 +
 drivers/hwspinlock/Kconfig|   9 ++
 drivers/hwspinlock/Makefile   |   1 +
 drivers/hwspinlock/sun6i_hwspinlock.c | 217 ++
 4 files changed, 233 insertions(+)
 create mode 100644 drivers/hwspinlock/sun6i_hwspinlock.c

diff --git a/MAINTAINERS b/MAINTAINERS
index d92f85ca831d..d5821c52c502 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -734,6 +734,12 @@ L: linux-cry...@vger.kernel.org
 S: Maintained
 F: drivers/crypto/allwinner/
 
+ALLWINNER HARDWARE SPINLOCK SUPPORT
+M: Wilken Gottwalt 
+S: Maintained
+F: Documentation/devicetree/bindings/hwlock/allwinner,sun6i-hwspinlock.yaml
+F: drivers/hwspinlock/sun6i_hwspinlock.c
+
 ALLWINNER THERMAL DRIVER
 M: Vasily Khoruzhick 
 M: Yangtao Li 
diff --git a/drivers/hwspinlock/Kconfig b/drivers/hwspinlock/Kconfig
index 32cd26352f38..56ecc1aa3166 100644
--- a/drivers/hwspinlock/Kconfig
+++ b/drivers/hwspinlock/Kconfig
@@ -55,6 +55,15 @@ config HWSPINLOCK_STM32
 
  If unsure, say N.
 
+config HWSPINLOCK_SUN6I
+   tristate "SUN6I Hardware Spinlock device"
+   depends on ARCH_SUNXI || COMPILE_TEST
+   help
+ Say y here to support the SUN6I Hardware Spinlock device which can be
+ found in most of the sun6i compatible Allwinner SoCs.
+
+ If unsure, say N.
+
 config HSEM_U8500
tristate "STE Hardware Semaphore functionality"
depends on ARCH_U8500 || COMPILE_TEST
diff --git a/drivers/hwspinlock/Makefile b/drivers/hwspinlock/Makefile
index ed053e3f02be..83ec4f03decc 100644
--- a/drivers/hwspinlock/Makefile
+++ b/drivers/hwspinlock/Makefile
@@ -9,4 +9,5 @@ obj-$(CONFIG_HWSPINLOCK_QCOM)   += qcom_hwspinlock.o
 obj-$(CONFIG_HWSPINLOCK_SIRF)  += sirf_hwspinlock.o
 obj-$(CONFIG_HWSPINLOCK_SPRD)  += sprd_hwspinlock.o
 obj-$(CONFIG_HWSPINLOCK_STM32) += stm32_hwspinlock.o
+obj-$(CONFIG_HWSPINLOCK_SUN6I) += sun6i_hwspinlock.o
 obj-$(CONFIG_HSEM_U8500)   += u8500_hsem.o
diff --git a/drivers/hwspinlock/sun6i_hwspinlock.c 
b/drivers/hwspinlock/sun6i_hwspinlock.c
new file mode 100644
index ..98193c75d81b
--- /dev/null
+++ b/drivers/hwspinlock/sun6i_hwspinlock.c
@@ -0,0 +1,217 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * sun6i_hwspinlock.c - hardware spinlock driver for sun6i compatible 
Allwinner SoCs
+ * Copyright (C) 2020 Wilken Gottwalt 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "hwspinlock_internal.h"
+
+#define DRIVER_NAME"sun6i_hwspinlock"
+
+#define SPINLOCK_BASE_ID   0 /* there is only one hwspinlock device per 
SoC */
+#define SPINLOCK_SYSSTATUS_REG 0x
+#define SPINLOCK_LOCK_REGN 0x0100
+#define SPINLOCK_NOTTAKEN  0
+
+struct sun6i_hwspinlock_data {
+   

[rcu:dev.2021.02.23a] BUILD SUCCESS 9ec904dce852815c4fa5c8233cd347e2f3422b88

[kernel test robot]

tree/branch: 
https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git 
dev.2021.02.23a
branch HEAD: 9ec904dce852815c4fa5c8233cd347e2f3422b88  rcu: Add explicit 
barrier() to __rcu_read_unlock()

elapsed time: 722m

configs tested: 112
configs skipped: 2

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm64   defconfig
arm defconfig
arm64allyesconfig
arm  allyesconfig
arm  allmodconfig
h8300   h8s-sim_defconfig
powerpc   motionpro_defconfig
powerpc  pcm030_defconfig
m68k  sun3x_defconfig
openriscdefconfig
shsh7763rdp_defconfig
mipsomega2p_defconfig
riscvnommu_virt_defconfig
sh   sh2007_defconfig
h8300alldefconfig
arm   sama5_defconfig
armlart_defconfig
powerpcwarp_defconfig
armdove_defconfig
m68k  multi_defconfig
arm pxa_defconfig
armshmobile_defconfig
m68kmac_defconfig
powerpcicon_defconfig
arm bcm2835_defconfig
powerpc   mpc834x_itxgp_defconfig
mipsvocore2_defconfig
mips   ci20_defconfig
arcvdk_hs38_defconfig
mips  rm200_defconfig
powerpc  bamboo_defconfig
powerpc  ppc6xx_defconfig
powerpc  pmac32_defconfig
mips  cavium_octeon_defconfig
arc haps_hs_defconfig
arm   tegra_defconfig
ia64 allyesconfig
powerpc  ppc44x_defconfig
m68k alldefconfig
armrealview_defconfig
arm am200epdkit_defconfig
mips mpc30x_defconfig
powerpc  makalu_defconfig
ia64 allmodconfig
ia64defconfig
m68k allmodconfig
m68kdefconfig
m68k allyesconfig
nds32   defconfig
nios2allyesconfig
cskydefconfig
alpha   defconfig
alphaallyesconfig
nios2   defconfig
arc  allyesconfig
nds32 allnoconfig
c6x  allyesconfig
xtensa   allyesconfig
h8300allyesconfig
arc defconfig
sh   allmodconfig
parisc  defconfig
s390 allyesconfig
s390 allmodconfig
parisc   allyesconfig
s390defconfig
i386 allyesconfig
sparcallyesconfig
sparc   defconfig
i386   tinyconfig
i386defconfig
mips allyesconfig
mips allmodconfig
powerpc  allyesconfig
powerpc  allmodconfig
powerpc   allnoconfig
i386 randconfig-a005-20210227
i386 randconfig-a006-20210227
i386 randconfig-a004-20210227
i386 randconfig-a001-20210227
i386 randconfig-a003-20210227
i386 randconfig-a002-20210227
i386 randconfig-a013-20210226
i386 randconfig-a012-20210226
i386 randconfig-a011-20210226
i386 randconfig-a014-20210226
i386 randconfig-a016-20210226
i386 randconfig-a015-20210226
riscvnommu_k210_defconfig
riscvallyesconfig
riscv allnoconfig
riscv   defconfig
riscv  rv32_defconfig
riscvallmodconfig
x86_64   allyesconfig
x86_64rhel-7.6-kselftests
x86_64  defconfig
x86_64   rhel-8.3
x86_64  rhel-8.3-kbuiltin
x86_64  kexec

clang

Re: [PATCH] MIPS: select CPU_MIPS64 for remaining MIPS64 CPUs

[Maciej W. Rozycki]

On Sat, 27 Feb 2021, Jason A. Donenfeld wrote:

> The CPU_MIPS64 and CPU_MIPS32 variables are supposed to be able to
> distinguish broadly between 64-bit and 32-bit MIPS CPUs. However, they

 That is not true.  The purpose of these options is to identify MIPS64 and 
MIPS32 ISA processors respectively (and the generic features these ISAs 
imply).  There are 64-bit and 32-bit MIPS processors which do not qualify, 
specifically all MIPS I, MIPS II, MIPS III, and MIPS IV implementations.

> weren't selected by the specialty CPUs, Octeon and Loongson, which meant
> it was possible to hit a weird state of:
> 
> MIPS=y, CONFIG_64BIT=y, CPU_MIPS64=n

 This is a correct combination for MIPS III and MIPS IV processors.

> This commit rectifies the issue by having CPU_MIPS64 be selected when
> the missing Octeon or Loongson models are selected.

 From the description and/or other options selected by CPU_LOONGSON64 and 
CPU_CAVIUM_OCTEON I infer the change itself is correct, so you only need 
to rewrite the change description.

 Though overall it seems we have quite a mess here, several other CPUs, 
such as at the very least CPU_XLR and CPU_XLP, do not select this option 
either, and then we have say CPU_MIPSR2 that is selected by some CPUs 
while being conditional on other ones.  All this stuff asks for being 
rewritten in a consistent manner.

 In any case your change may have to be run-time verified though with the 
respective processors.

  Maciej

[PATCH v38 10/13] LRNG - add Jitter RNG fast noise source

[Stephan Müller]

The Jitter RNG fast noise source implemented as part of the kernel
crypto API is queried for 256 bits of entropy at the time the seed
buffer managed by the LRNG is about to be filled.

CC: Torsten Duwe 
CC: "Eric W. Biederman" 
CC: "Alexander E. Patrakov" 
CC: "Ahmed S. Darwish" 
CC: "Theodore Y. Ts'o" 
CC: Willy Tarreau 
CC: Matthew Garrett 
CC: Vito Caputo 
CC: Andreas Dilger 
CC: Jan Kara 
CC: Ray Strode 
CC: William Jon McCann 
CC: zhangjs 
CC: Andy Lutomirski 
CC: Florian Weimer 
CC: Lennart Poettering 
CC: Nicolai Stange 
Reviewed-by: Marcelo Henrique Cerri 
Reviewed-by: Roman Drahtmueller 
Tested-by: Roman Drahtmüller 
Tested-by: Marcelo Henrique Cerri 
Tested-by: Neil Horman 
Signed-off-by: Stephan Mueller 
---
 drivers/char/lrng/Kconfig | 12 +
 drivers/char/lrng/Makefile|  1 +
 drivers/char/lrng/lrng_jent.c | 88 +++
 3 files changed, 101 insertions(+)
 create mode 100644 drivers/char/lrng/lrng_jent.c

diff --git a/drivers/char/lrng/Kconfig b/drivers/char/lrng/Kconfig
index f16bd237ab9e..01185b985af4 100644
--- a/drivers/char/lrng/Kconfig
+++ b/drivers/char/lrng/Kconfig
@@ -156,4 +156,16 @@ config LRNG_KCAPI
  provided by the selected kernel crypto API RNG.
 endif # LRNG_DRNG_SWITCH
 
+config LRNG_JENT
+   bool "Enable Jitter RNG as LRNG Seed Source"
+   depends on CRYPTO
+   select CRYPTO_JITTERENTROPY
+   help
+ The Linux RNG may use the Jitter RNG as noise source. Enabling
+ this option enables the use of the Jitter RNG. Its default
+ entropy level is 16 bits of entropy per 256 data bits delivered
+ by the Jitter RNG. This entropy level can be changed at boot
+ time or at runtime with the lrng_base.jitterrng configuration
+ variable.
+
 endif # LRNG
diff --git a/drivers/char/lrng/Makefile b/drivers/char/lrng/Makefile
index 97d2b13d3227..6be88156010a 100644
--- a/drivers/char/lrng/Makefile
+++ b/drivers/char/lrng/Makefile
@@ -14,3 +14,4 @@ obj-$(CONFIG_LRNG_DRNG_SWITCH)+= lrng_switch.o
 obj-$(CONFIG_LRNG_KCAPI_HASH)  += lrng_kcapi_hash.o
 obj-$(CONFIG_LRNG_DRBG)+= lrng_drbg.o
 obj-$(CONFIG_LRNG_KCAPI)   += lrng_kcapi.o
+obj-$(CONFIG_LRNG_JENT)+= lrng_jent.o
diff --git a/drivers/char/lrng/lrng_jent.c b/drivers/char/lrng/lrng_jent.c
new file mode 100644
index ..9cae59678c1e
--- /dev/null
+++ b/drivers/char/lrng/lrng_jent.c
@@ -0,0 +1,88 @@
+// SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+/*
+ * LRNG Fast Noise Source: Jitter RNG
+ *
+ * Copyright (C) 2016 - 2021, Stephan Mueller 
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include 
+#include 
+
+#include "lrng_internal.h"
+
+/*
+ * Estimated entropy of data is a 16th of LRNG_DRNG_SECURITY_STRENGTH_BITS.
+ * Albeit a full entropy assessment is provided for the noise source indicating
+ * that it provides high entropy rates and considering that it deactivates
+ * when it detects insufficient hardware, the chosen under estimation of
+ * entropy is considered to be acceptable to all reviewers.
+ */
+static u32 jitterrng = LRNG_DRNG_SECURITY_STRENGTH_BITS>>4;
+module_param(jitterrng, uint, 0644);
+MODULE_PARM_DESC(jitterrng, "Entropy in bits of 256 data bits from Jitter RNG 
noise source");
+
+/**
+ * lrng_get_jent() - Get Jitter RNG entropy
+ *
+ * @outbuf: buffer to store entropy
+ * @outbuflen: length of buffer
+ *
+ * Return:
+ * * > 0 on success where value provides the added entropy in bits
+ * * 0 if no fast source was available
+ */
+static struct rand_data *lrng_jent_state;
+
+u32 lrng_get_jent(u8 *outbuf, unsigned int outbuflen)
+{
+   int ret;
+   u32 ent_bits = jitterrng;
+   unsigned long flags;
+   static DEFINE_SPINLOCK(lrng_jent_lock);
+   static int lrng_jent_initialized = 0;
+
+   spin_lock_irqsave(&lrng_jent_lock, flags);
+
+   if (!ent_bits || (lrng_jent_initialized == -1)) {
+   spin_unlock_irqrestore(&lrng_jent_lock, flags);
+   return 0;
+   }
+
+   if (!lrng_jent_initialized) {
+   lrng_jent_state = jent_lrng_entropy_collector();
+   if (!lrng_jent_state) {
+   jitterrng = 0;
+   lrng_jent_initialized = -1;
+   spin_unlock_irqrestore(&lrng_jent_lock, flags);
+   pr_info("Jitter RNG unusable on current system\n");
+   return 0;
+   }
+   lrng_jent_initialized = 1;
+   pr_debug("Jitter RNG working on current system\n");
+   }
+   ret = jent_read_entropy(lrng_jent_state, outbuf, outbuflen);
+   spin_unlock_irqrestore(&lrng_jent_lock, flags);
+
+   if (ret) {
+   pr_debug("Jitter RNG failed with %d\n", ret);
+   return 0;
+   }
+
+   /* Obtain entropy statement */
+   if (outbuflen != LRNG_DRNG_SECURITY_STRENGTH_BYTES)
+   ent_bits = (ent_bits * outbuflen<<3) /
+   

[PATCH v38 02/13] LRNG - allocate one DRNG instance per NUMA node

[Stephan Müller]

In order to improve NUMA-locality when serving getrandom(2) requests,
allocate one DRNG instance per node.

The DRNG instance that is present right from the start of the kernel is
reused as the first per-NUMA-node DRNG. For all remaining online NUMA
nodes a new DRNG instance is allocated.

During boot time, the multiple DRNG instances are seeded sequentially.
With this, the first DRNG instance (referenced as the initial DRNG
in the code) is completely seeded with 256 bits of entropy before the
next DRNG instance is completely seeded.

When random numbers are requested, the NUMA-node-local DRNG is checked
whether it has been already fully seeded. If this is not the case, the
initial DRNG is used to serve the request.

CC: Torsten Duwe 
CC: "Eric W. Biederman" 
CC: "Alexander E. Patrakov" 
CC: "Ahmed S. Darwish" 
CC: "Theodore Y. Ts'o" 
CC: Willy Tarreau 
CC: Matthew Garrett 
CC: Vito Caputo 
CC: Andreas Dilger 
CC: Jan Kara 
CC: Ray Strode 
CC: William Jon McCann 
CC: zhangjs 
CC: Andy Lutomirski 
CC: Florian Weimer 
CC: Lennart Poettering 
CC: Nicolai Stange 
CC: Eric Biggers 
Reviewed-by: Marcelo Henrique Cerri 
Reviewed-by: Roman Drahtmueller 
Tested-by: Roman Drahtmüller 
Tested-by: Marcelo Henrique Cerri 
Tested-by: Neil Horman 
Signed-off-by: Stephan Mueller 
---
 drivers/char/lrng/Makefile|   2 +
 drivers/char/lrng/lrng_internal.h |   5 ++
 drivers/char/lrng/lrng_numa.c | 120 ++
 3 files changed, 127 insertions(+)
 create mode 100644 drivers/char/lrng/lrng_numa.c

diff --git a/drivers/char/lrng/Makefile b/drivers/char/lrng/Makefile
index e72e01c15bb9..29724c65287d 100644
--- a/drivers/char/lrng/Makefile
+++ b/drivers/char/lrng/Makefile
@@ -7,3 +7,5 @@ obj-y   += lrng_pool.o lrng_aux.o \
   lrng_sw_noise.o lrng_archrandom.o \
   lrng_drng.o lrng_chacha20.o \
   lrng_interfaces.o
+
+obj-$(CONFIG_NUMA) += lrng_numa.o
diff --git a/drivers/char/lrng/lrng_internal.h 
b/drivers/char/lrng/lrng_internal.h
index d398ac6b5674..1bfb3710c767 100644
--- a/drivers/char/lrng/lrng_internal.h
+++ b/drivers/char/lrng/lrng_internal.h
@@ -214,8 +214,13 @@ int lrng_drng_get_sleep(u8 *outbuf, u32 outbuflen);
 void lrng_drng_force_reseed(void);
 void lrng_drng_seed_work(struct work_struct *dummy);
 
+#ifdef CONFIG_NUMA
+struct lrng_drng **lrng_drng_instances(void);
+void lrng_drngs_numa_alloc(void);
+#else  /* CONFIG_NUMA */
 static inline struct lrng_drng **lrng_drng_instances(void) { return NULL; }
 static inline void lrng_drngs_numa_alloc(void) { return; }
+#endif /* CONFIG_NUMA */
 
 /** Entropy pool management 
***/
 
diff --git a/drivers/char/lrng/lrng_numa.c b/drivers/char/lrng/lrng_numa.c
new file mode 100644
index ..37817771b97a
--- /dev/null
+++ b/drivers/char/lrng/lrng_numa.c
@@ -0,0 +1,120 @@
+// SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+/*
+ * LRNG NUMA support
+ *
+ * Copyright (C) 2016 - 2021, Stephan Mueller 
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include 
+#include 
+
+#include "lrng_internal.h"
+
+static struct lrng_drng **lrng_drng __read_mostly = NULL;
+
+struct lrng_drng **lrng_drng_instances(void)
+{
+   return smp_load_acquire(&lrng_drng);
+}
+
+/* Allocate the data structures for the per-NUMA node DRNGs */
+static void _lrng_drngs_numa_alloc(struct work_struct *work)
+{
+   struct lrng_drng **drngs;
+   struct lrng_drng *lrng_drng_init = lrng_drng_init_instance();
+   u32 node;
+   bool init_drng_used = false;
+
+   mutex_lock(&lrng_crypto_cb_update);
+
+   /* per-NUMA-node DRNGs are already present */
+   if (lrng_drng)
+   goto unlock;
+
+   drngs = kcalloc(nr_node_ids, sizeof(void *), GFP_KERNEL|__GFP_NOFAIL);
+   for_each_online_node(node) {
+   struct lrng_drng *drng;
+
+   if (!init_drng_used) {
+   drngs[node] = lrng_drng_init;
+   init_drng_used = true;
+   continue;
+   }
+
+   drng = kmalloc_node(sizeof(struct lrng_drng),
+GFP_KERNEL|__GFP_NOFAIL, node);
+   memset(drng, 0, sizeof(lrng_drng));
+
+   drng->crypto_cb = lrng_drng_init->crypto_cb;
+   drng->drng = drng->crypto_cb->lrng_drng_alloc(
+   LRNG_DRNG_SECURITY_STRENGTH_BYTES);
+   if (IS_ERR(drng->drng)) {
+   kfree(drng);
+   goto err;
+   }
+
+   drng->hash = drng->crypto_cb->lrng_hash_alloc();
+   if (IS_ERR(drng->hash)) {
+   drng->crypto_cb->lrng_drng_dealloc(drng->drng);
+   kfree(drng);
+   goto err;
+   }
+
+   mutex_init(&drng->lock);
+  

[PATCH v38 05/13] LRNG - add common generic hash support

[Stephan Müller]

The LRNG switchable DRNG support also allows the replacement of the hash
implementation used as conditioning component. The common generic hash
support code provides the required callbacks using the synchronous hash
implementations of the kernel crypto API.

All synchronous hash implementations supported by the kernel crypto API
can be used as part of the LRNG with this generic support.

The generic support is intended to be configured by separate switchable
DRNG backends.

CC: Torsten Duwe 
CC: "Eric W. Biederman" 
CC: "Alexander E. Patrakov" 
CC: "Ahmed S. Darwish" 
CC: "Theodore Y. Ts'o" 
CC: Willy Tarreau 
CC: Matthew Garrett 
CC: Vito Caputo 
CC: Andreas Dilger 
CC: Jan Kara 
CC: Ray Strode 
CC: William Jon McCann 
CC: zhangjs 
CC: Andy Lutomirski 
CC: Florian Weimer 
CC: Lennart Poettering 
CC: Nicolai Stange 
CC: "Peter, Matthias" 
CC: Roman Drahtmueller 
CC: Marcelo Henrique Cerri 
CC: Neil Horman 
Signed-off-by: Stephan Mueller 
---
 drivers/char/lrng/Kconfig   |  7 +++
 drivers/char/lrng/Makefile  |  1 +
 drivers/char/lrng/lrng_kcapi_hash.c | 97 +
 drivers/char/lrng/lrng_kcapi_hash.h | 19 ++
 4 files changed, 124 insertions(+)
 create mode 100644 drivers/char/lrng/lrng_kcapi_hash.c
 create mode 100644 drivers/char/lrng/lrng_kcapi_hash.h

diff --git a/drivers/char/lrng/Kconfig b/drivers/char/lrng/Kconfig
index fe6a7eaeabb0..423d54c64149 100644
--- a/drivers/char/lrng/Kconfig
+++ b/drivers/char/lrng/Kconfig
@@ -126,4 +126,11 @@ menuconfig LRNG_DRNG_SWITCH
  accessible via the external interfaces. With this configuration
  option other DRNGs can be selected and loaded at runtime.
 
+if LRNG_DRNG_SWITCH
+
+config LRNG_KCAPI_HASH
+   bool
+
+endif # LRNG_DRNG_SWITCH
+
 endif # LRNG
diff --git a/drivers/char/lrng/Makefile b/drivers/char/lrng/Makefile
index 0eb4a6849c88..40f8826edeeb 100644
--- a/drivers/char/lrng/Makefile
+++ b/drivers/char/lrng/Makefile
@@ -11,3 +11,4 @@ obj-y += lrng_pool.o lrng_aux.o \
 obj-$(CONFIG_NUMA) += lrng_numa.o
 obj-$(CONFIG_SYSCTL)   += lrng_proc.o
 obj-$(CONFIG_LRNG_DRNG_SWITCH) += lrng_switch.o
+obj-$(CONFIG_LRNG_KCAPI_HASH)  += lrng_kcapi_hash.o
diff --git a/drivers/char/lrng/lrng_kcapi_hash.c 
b/drivers/char/lrng/lrng_kcapi_hash.c
new file mode 100644
index ..37363c2b6ab2
--- /dev/null
+++ b/drivers/char/lrng/lrng_kcapi_hash.c
@@ -0,0 +1,97 @@
+// SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+/*
+ * Backend for providing the hash primitive using the kernel crypto API.
+ *
+ * Copyright (C) 2021, Stephan Mueller 
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include 
+
+#include "lrng_kcapi_hash.h"
+
+struct lrng_hash_info {
+   struct crypto_shash *tfm;
+};
+
+static inline void _lrng_kcapi_hash_free(struct lrng_hash_info *lrng_hash)
+{
+   struct crypto_shash *tfm = lrng_hash->tfm;
+
+   crypto_free_shash(tfm);
+   kfree(lrng_hash);
+}
+
+void *lrng_kcapi_hash_alloc(const char *name)
+{
+   struct lrng_hash_info *lrng_hash;
+   struct crypto_shash *tfm;
+   int ret;
+
+   if (!name) {
+   pr_err("Hash name missing\n");
+   return ERR_PTR(-EINVAL);
+   }
+
+   tfm = crypto_alloc_shash(name, 0, 0);
+   if (IS_ERR(tfm)) {
+   pr_err("could not allocate hash %s\n", name);
+   return ERR_CAST(tfm);
+   }
+
+   ret = sizeof(struct lrng_hash_info);
+   lrng_hash = kmalloc(ret, GFP_KERNEL);
+   if (!lrng_hash) {
+   crypto_free_shash(tfm);
+   return ERR_PTR(-ENOMEM);
+   }
+
+   lrng_hash->tfm = tfm;
+
+   pr_info("Hash %s allocated\n", name);
+
+   return lrng_hash;
+}
+EXPORT_SYMBOL(lrng_kcapi_hash_alloc);
+
+u32 lrng_kcapi_hash_digestsize(void *hash)
+{
+   struct lrng_hash_info *lrng_hash = (struct lrng_hash_info *)hash;
+   struct crypto_shash *tfm = lrng_hash->tfm;
+
+   return crypto_shash_digestsize(tfm);
+}
+EXPORT_SYMBOL(lrng_kcapi_hash_digestsize);
+
+void lrng_kcapi_hash_dealloc(void *hash)
+{
+   struct lrng_hash_info *lrng_hash = (struct lrng_hash_info *)hash;
+
+   _lrng_kcapi_hash_free(lrng_hash);
+   pr_info("Hash deallocated\n");
+}
+EXPORT_SYMBOL(lrng_kcapi_hash_dealloc);
+
+int lrng_kcapi_hash_init(struct shash_desc *shash, void *hash)
+{
+   struct lrng_hash_info *lrng_hash = (struct lrng_hash_info *)hash;
+   struct crypto_shash *tfm = lrng_hash->tfm;
+
+   shash->tfm = tfm;
+   return crypto_shash_init(shash);
+}
+EXPORT_SYMBOL(lrng_kcapi_hash_init);
+
+int lrng_kcapi_hash_update(struct shash_desc *shash, const u8 *inbuf,
+  u32 inbuflen)
+{
+   return crypto_shash_update(shash, inbuf, inbuflen);
+}
+EXPORT_SYMBOL(lrng_kcapi_hash_update);
+
+int lrng_kcapi_hash_final(struct shash_desc *shash, u8 *digest)
+{
+   return crypto_shash_final(shash, digest);
+}
+EXPORT_SYMBOL(lrng_kcapi_hash_final);
diff --

[PATCH v38 13/13] LRNG - add power-on and runtime self-tests

[Stephan Müller]

Parts of the LRNG are already covered by self-tests, including:

* Self-test of SP800-90A DRBG provided by the Linux kernel crypto API.

* Self-test of the PRNG provided by the Linux kernel crypto API.

* Raw noise source data testing including SP800-90B compliant
  tests when enabling CONFIG_LRNG_HEALTH_TESTS

This patch adds the self-tests for the remaining critical functions of
the LRNG that are essential to maintain entropy and provide
cryptographic strong random numbers. The following self-tests are
implemented:

* Self-test of the time array maintenance. This test verifies whether
the time stamp array management to store multiple values in one integer
implements a concatenation of the data.

* Self-test of the software hash implementation ensures that this
function operates compliant to the FIPS 180-4 specification. The
self-test performs a hash operation of a zeroized per-CPU data array.

* Self-test of the ChaCha20 DRNG is based on the self-tests that are
already present and implemented with the stand-alone user space
ChaCha20 DRNG implementation available at [1]. The self-tests cover
different use cases of the DRNG seeded with known seed data.

The status of the LRNG self-tests is provided with the selftest_status
SysFS file. If the file contains a zero, the self-tests passed. The
value 0x means that the self-tests were not executed. Any other
value indicates a self-test failure.

The self-test may be compiled to panic the system if the self-test
fails.

All self-tests operate on private state data structures. This implies
that none of the self-tests have any impact on the regular LRNG
operations. This allows the self-tests to be repeated at runtime by
writing anything into the selftest_status SysFS file.

[1] https://www.chronox.de/chacha20.html

CC: Torsten Duwe 
CC: "Eric W. Biederman" 
CC: "Alexander E. Patrakov" 
CC: "Ahmed S. Darwish" 
CC: "Theodore Y. Ts'o" 
CC: Willy Tarreau 
CC: Matthew Garrett 
CC: Vito Caputo 
CC: Andreas Dilger 
CC: Jan Kara 
CC: Ray Strode 
CC: William Jon McCann 
CC: zhangjs 
CC: Andy Lutomirski 
CC: Florian Weimer 
CC: Lennart Poettering 
CC: Nicolai Stange 
CC: Marcelo Henrique Cerri 
CC: Neil Horman 
Signed-off-by: Stephan Mueller 
---
 drivers/char/lrng/Kconfig |  26 +++
 drivers/char/lrng/Makefile|   1 +
 drivers/char/lrng/lrng_selftest.c | 351 ++
 3 files changed, 378 insertions(+)
 create mode 100644 drivers/char/lrng/lrng_selftest.c

diff --git a/drivers/char/lrng/Kconfig b/drivers/char/lrng/Kconfig
index 3e57068ccdff..2a7347e25834 100644
--- a/drivers/char/lrng/Kconfig
+++ b/drivers/char/lrng/Kconfig
@@ -374,4 +374,30 @@ config LRNG_TESTING
 
 endif #LRNG_TESTING_MENU
 
+config LRNG_SELFTEST
+   bool "Enable power-on and on-demand self-tests"
+   help
+ The power-on self-tests are executed during boot time
+ covering the ChaCha20 DRNG, the hash operation used for
+ processing the entropy pools and the auxiliary pool, and
+ the time stamp management of the LRNG.
+
+ The on-demand self-tests are triggered by writing any
+ value into the SysFS file selftest_status. At the same
+ time, when reading this file, the test status is
+ returned. A zero indicates that all tests were executed
+ successfully.
+
+ If unsure, say Y.
+
+if LRNG_SELFTEST
+
+config LRNG_SELFTEST_PANIC
+   bool "Panic the kernel upon self-test failure"
+   help
+ If the option is enabled, the kernel is terminated if an
+ LRNG power-on self-test failure is detected.
+
+endif # LRNG_SELFTEST
+
 endif # LRNG
diff --git a/drivers/char/lrng/Makefile b/drivers/char/lrng/Makefile
index 532501b38a00..a633638af991 100644
--- a/drivers/char/lrng/Makefile
+++ b/drivers/char/lrng/Makefile
@@ -17,3 +17,4 @@ obj-$(CONFIG_LRNG_KCAPI)  += lrng_kcapi.o
 obj-$(CONFIG_LRNG_JENT)+= lrng_jent.o
 obj-$(CONFIG_LRNG_HEALTH_TESTS)+= lrng_health.o
 obj-$(CONFIG_LRNG_TESTING) += lrng_testing.o
+obj-$(CONFIG_LRNG_SELFTEST)+= lrng_selftest.o
diff --git a/drivers/char/lrng/lrng_selftest.c 
b/drivers/char/lrng/lrng_selftest.c
new file mode 100644
index ..9540424cd073
--- /dev/null
+++ b/drivers/char/lrng/lrng_selftest.c
@@ -0,0 +1,351 @@
+// SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+/*
+ * LRNG power-on and on-demand self-test
+ *
+ * Copyright (C) 2016 - 2021, Stephan Mueller 
+ */
+
+/*
+ * In addition to the self-tests below, the following LRNG components
+ * are covered with self-tests during regular operation:
+ *
+ * * power-on self-test: SP800-90A DRBG provided by the Linux kernel crypto API
+ * * power-on self-test: PRNG provided by the Linux kernel crypto API
+ * * runtime test: Raw noise source data testing including SP800-90B compliant
+ *tests when enabling CONFIG_LRNG_HEALTH_TESTS
+ *
+ * Additional developer tests present with LRNG code:
+ * * SP800-90B APT and RCT test enforcem

[PATCH v38 07/13] LRNG - add SP800-90A DRBG extension

[Stephan Müller]

Using the LRNG switchable DRNG support, the SP800-90A DRBG extension is
implemented.

The DRBG uses the kernel crypto API DRBG implementation. In addition, it
uses the kernel crypto API SHASH support to provide the hashing
operation.

The DRBG supports the choice of either a CTR DRBG using AES-256, HMAC
DRBG with SHA-512 core or Hash DRBG with SHA-512 core. The used core can
be selected with the module parameter lrng_drbg_type. The default is the
CTR DRBG.

When compiling the DRBG extension statically, the DRBG is loaded at
late_initcall stage which implies that with the start of user space, the
user space interfaces of getrandom(2), /dev/random and /dev/urandom
provide random data produced by an SP800-90A DRBG.

CC: Torsten Duwe 
CC: "Eric W. Biederman" 
CC: "Alexander E. Patrakov" 
CC: "Ahmed S. Darwish" 
CC: "Theodore Y. Ts'o" 
CC: Willy Tarreau 
CC: Matthew Garrett 
CC: Vito Caputo 
CC: Andreas Dilger 
CC: Jan Kara 
CC: Ray Strode 
CC: William Jon McCann 
CC: zhangjs 
CC: Andy Lutomirski 
CC: Florian Weimer 
CC: Lennart Poettering 
CC: Nicolai Stange 
Reviewed-by: Roman Drahtmueller 
Tested-by: Roman Drahtmüller 
Tested-by: Marcelo Henrique Cerri 
Tested-by: Neil Horman 
Signed-off-by: Stephan Mueller 
---
 drivers/char/lrng/Kconfig |  10 ++
 drivers/char/lrng/Makefile|   1 +
 drivers/char/lrng/lrng_drbg.c | 197 ++
 3 files changed, 208 insertions(+)
 create mode 100644 drivers/char/lrng/lrng_drbg.c

diff --git a/drivers/char/lrng/Kconfig b/drivers/char/lrng/Kconfig
index 423d54c64149..0b94a96e4729 100644
--- a/drivers/char/lrng/Kconfig
+++ b/drivers/char/lrng/Kconfig
@@ -131,6 +131,16 @@ if LRNG_DRNG_SWITCH
 config LRNG_KCAPI_HASH
bool
 
+config LRNG_DRBG
+   tristate "SP800-90A support for the LRNG"
+   depends on CRYPTO
+   select CRYPTO_DRBG_MENU
+   select CRYPTO_SHA512
+   select LRNG_KCAPI_HASH
+   help
+ Enable the SP800-90A DRBG support for the LRNG. Once the
+ module is loaded, output from /dev/random, /dev/urandom,
+ getrandom(2), or get_random_bytes_full is provided by a DRBG.
 endif # LRNG_DRNG_SWITCH
 
 endif # LRNG
diff --git a/drivers/char/lrng/Makefile b/drivers/char/lrng/Makefile
index 40f8826edeeb..6ebd252db12f 100644
--- a/drivers/char/lrng/Makefile
+++ b/drivers/char/lrng/Makefile
@@ -12,3 +12,4 @@ obj-$(CONFIG_NUMA)+= lrng_numa.o
 obj-$(CONFIG_SYSCTL)   += lrng_proc.o
 obj-$(CONFIG_LRNG_DRNG_SWITCH) += lrng_switch.o
 obj-$(CONFIG_LRNG_KCAPI_HASH)  += lrng_kcapi_hash.o
+obj-$(CONFIG_LRNG_DRBG)+= lrng_drbg.o
diff --git a/drivers/char/lrng/lrng_drbg.c b/drivers/char/lrng/lrng_drbg.c
new file mode 100644
index ..d083ceb188fe
--- /dev/null
+++ b/drivers/char/lrng/lrng_drbg.c
@@ -0,0 +1,197 @@
+// SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+/*
+ * Backend for the LRNG providing the cryptographic primitives using the
+ * kernel crypto API and its DRBG.
+ *
+ * Copyright (C) 2016 - 2021, Stephan Mueller 
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include 
+#include 
+#include 
+#include 
+
+#include "lrng_kcapi_hash.h"
+
+/*
+ * Define a DRBG plus a hash / MAC used to extract data from the entropy pool.
+ * For LRNG_HASH_NAME you can use a hash or a MAC (HMAC or CMAC) of your choice
+ * (Note, you should use the suggested selections below -- using SHA-1 or MD5
+ * is not wise). The idea is that the used cipher primitive can be selected to
+ * be the same as used for the DRBG. I.e. the LRNG only uses one cipher
+ * primitive using the same cipher implementation with the options offered in
+ * the following. This means, if the CTR DRBG is selected and AES-NI is 
present,
+ * both the CTR DRBG and the selected cmac(aes) use AES-NI.
+ *
+ * The security strengths of the DRBGs are all 256 bits according to
+ * SP800-57 section 5.6.1.
+ *
+ * This definition is allowed to be changed.
+ */
+#ifdef CONFIG_CRYPTO_DRBG_CTR
+static unsigned int lrng_drbg_type = 0;
+#elif defined CONFIG_CRYPTO_DRBG_HMAC
+static unsigned int lrng_drbg_type = 1;
+#elif defined CONFIG_CRYPTO_DRBG_HASH
+static unsigned int lrng_drbg_type = 2;
+#else
+#error "Unknown DRBG in use"
+#endif
+
+/* The parameter must be r/o in sysfs as otherwise races appear. */
+module_param(lrng_drbg_type, uint, 0444);
+MODULE_PARM_DESC(lrng_drbg_type, "DRBG type used for LRNG (0->CTR_DRBG, 
1->HMAC_DRBG, 2->Hash_DRBG)");
+
+struct lrng_drbg {
+   const char *hash_name;
+   const char *drbg_core;
+};
+
+static const struct lrng_drbg lrng_drbg_types[] = {
+   {   /* CTR_DRBG with AES-256 using derivation function */
+   .hash_name = "sha512",
+   .drbg_core = "drbg_nopr_ctr_aes256",
+   }, {/* HMAC_DRBG with SHA-512 */
+   .hash_name = "sha512",
+   .drbg_core = "drbg_nopr_hmac_sha512",
+   }, {/* Hash_DRBG with SHA-512 using derivation function */
+   .hash_name = "sha512",
+   .

[PATCH v38 08/13] LRNG - add kernel crypto API PRNG extension

[Stephan Müller]

Add runtime-pluggable support for all PRNGs that are accessible via
the kernel crypto API, including hardware PRNGs. The PRNG is selected
with the module parameter drng_name where the name must be one that the
kernel crypto API can resolve into an RNG.

This allows using of the kernel crypto API PRNG implementations that
provide an interface to hardware PRNGs. Using this extension,
the LRNG uses the hardware PRNGs to generate random numbers. An
example is the S390 CPACF support providing such a PRNG.

The hash is provided by a kernel crypto API SHASH whose digest size
complies with the seedsize of the PRNG.

CC: Torsten Duwe 
CC: "Eric W. Biederman" 
CC: "Alexander E. Patrakov" 
CC: "Ahmed S. Darwish" 
CC: "Theodore Y. Ts'o" 
CC: Willy Tarreau 
CC: Matthew Garrett 
CC: Vito Caputo 
CC: Andreas Dilger 
CC: Jan Kara 
CC: Ray Strode 
CC: William Jon McCann 
CC: zhangjs 
CC: Andy Lutomirski 
CC: Florian Weimer 
CC: Lennart Poettering 
CC: Nicolai Stange 
Reviewed-by: Marcelo Henrique Cerri 
Reviewed-by: Roman Drahtmueller 
Tested-by: Roman Drahtmüller 
Tested-by: Marcelo Henrique Cerri 
Tested-by: Neil Horman 
Signed-off-by: Stephan Mueller 
---
 drivers/char/lrng/Kconfig  |  13 ++
 drivers/char/lrng/Makefile |   1 +
 drivers/char/lrng/lrng_kcapi.c | 225 +
 3 files changed, 239 insertions(+)
 create mode 100644 drivers/char/lrng/lrng_kcapi.c

diff --git a/drivers/char/lrng/Kconfig b/drivers/char/lrng/Kconfig
index 0b94a96e4729..f16bd237ab9e 100644
--- a/drivers/char/lrng/Kconfig
+++ b/drivers/char/lrng/Kconfig
@@ -141,6 +141,19 @@ config LRNG_DRBG
  Enable the SP800-90A DRBG support for the LRNG. Once the
  module is loaded, output from /dev/random, /dev/urandom,
  getrandom(2), or get_random_bytes_full is provided by a DRBG.
+
+config LRNG_KCAPI
+   tristate "Kernel Crypto API support for the LRNG"
+   depends on CRYPTO
+   depends on !LRNG_DRBG
+   select CRYPTO_RNG
+   select LRNG_KCAPI_HASH
+   help
+ Enable the support for generic pseudo-random number
+ generators offered by the kernel crypto API with the
+ LRNG. Once the module is loaded, output from /dev/random,
+ /dev/urandom, getrandom(2), or get_random_bytes is
+ provided by the selected kernel crypto API RNG.
 endif # LRNG_DRNG_SWITCH
 
 endif # LRNG
diff --git a/drivers/char/lrng/Makefile b/drivers/char/lrng/Makefile
index 6ebd252db12f..97d2b13d3227 100644
--- a/drivers/char/lrng/Makefile
+++ b/drivers/char/lrng/Makefile
@@ -13,3 +13,4 @@ obj-$(CONFIG_SYSCTL)  += lrng_proc.o
 obj-$(CONFIG_LRNG_DRNG_SWITCH) += lrng_switch.o
 obj-$(CONFIG_LRNG_KCAPI_HASH)  += lrng_kcapi_hash.o
 obj-$(CONFIG_LRNG_DRBG)+= lrng_drbg.o
+obj-$(CONFIG_LRNG_KCAPI)   += lrng_kcapi.o
diff --git a/drivers/char/lrng/lrng_kcapi.c b/drivers/char/lrng/lrng_kcapi.c
new file mode 100644
index ..caecb3841f5b
--- /dev/null
+++ b/drivers/char/lrng/lrng_kcapi.c
@@ -0,0 +1,225 @@
+// SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+/*
+ * Backend for the LRNG providing the cryptographic primitives using the
+ * kernel crypto API.
+ *
+ * Copyright (C) 2018 - 2021, Stephan Mueller 
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "lrng_kcapi_hash.h"
+
+static char *drng_name = NULL;
+module_param(drng_name, charp, 0444);
+MODULE_PARM_DESC(drng_name, "Kernel crypto API name of DRNG");
+
+static char *pool_hash = "sha512";
+module_param(pool_hash, charp, 0444);
+MODULE_PARM_DESC(pool_hash,
+"Kernel crypto API name of hash or keyed message digest to 
read the entropy pool");
+
+static char *seed_hash = NULL;
+module_param(seed_hash, charp, 0444);
+MODULE_PARM_DESC(seed_hash,
+"Kernel crypto API name of hash with output size equal to 
seedsize of DRNG to bring seed string to the size required by the DRNG");
+
+struct lrng_drng_info {
+   struct crypto_rng *kcapi_rng;
+   void *lrng_hash;
+};
+
+static void *lrng_kcapi_drng_hash_alloc(void)
+{
+   return lrng_kcapi_hash_alloc(pool_hash);
+}
+
+static int lrng_kcapi_drng_seed_helper(void *drng, const u8 *inbuf,
+  u32 inbuflen)
+{
+   SHASH_DESC_ON_STACK(shash, NULL);
+   struct lrng_drng_info *lrng_drng_info = (struct lrng_drng_info *)drng;
+   struct crypto_rng *kcapi_rng = lrng_drng_info->kcapi_rng;
+   void *hash = lrng_drng_info->lrng_hash;
+   u32 digestsize = lrng_kcapi_hash_digestsize(hash);
+   u8 digest[64] __aligned(8);
+   int ret;
+
+   if (!hash)
+   return crypto_rng_reset(kcapi_rng, inbuf, inbuflen);
+
+   BUG_ON(digestsize > sizeof(digest));
+
+   ret = lrng_kcapi_hash_init(shash, hash) ?:
+ lrng_kcapi_hash_update(shash, inbuf, inbuflen) ?:
+ lrng_kcapi_hash_final(shash, digest);
+   if (ret)
+   return ret;
+
+   ret 

[PATCH v38 11/13] LRNG - add SP800-90B compliant health tests

[Stephan Müller]

Implement health tests for LRNG's slow noise sources as mandated by
SP-800-90B The file contains the following health tests:

- stuck test: The stuck test calculates the first, second and third
  discrete derivative of the time stamp to be processed by the hash
  for the per-CPU entropy pool. Only if all three values are non-zero,
  the received time delta is considered to be non-stuck.

- SP800-90B Repetition Count Test (RCT): The LRNG uses an enhanced
  version of the RCT specified in SP800-90B section 4.4.1. Instead of
  counting identical back-to-back values, the input to the RCT is the
  counting of the stuck values during the processing of received
  interrupt events. The RCT is applied with alpha=2^-30 compliant to
  the recommendation of FIPS 140-2 IG 9.8. During the counting operation,
  the LRNG always calculates the RCT cut-off value of C. If that value
  exceeds the allowed cut-off value, the LRNG will trigger the health
  test failure discussed below. An error is logged to the kernel log
  that such RCT failure occurred. This test is only applied and
  enforced in FIPS mode, i.e. when the kernel compiled with
  CONFIG_CONFIG_FIPS is started with fips=1.

- SP800-90B Adaptive Proportion Test (APT): The LRNG implements the
  APT as defined in SP800-90B section 4.4.2. The applied significance
  level again is alpha=2^-30 compliant to the recommendation of FIPS
  140-2 IG 9.8.

The aforementioned health tests are applied to the first 1,024 time stamps
obtained from interrupt events. In case one error is identified for either
the RCT, or the APT, the collected entropy is invalidated and the
SP800-90B startup health test is restarted.

As long as the SP800-90B startup health test is not completed, all LRNG
random number output interfaces that may block will block and not generate
any data. This implies that only those potentially blocking interfaces are
defined to provide random numbers that are seeded with the interrupt noise
source being SP800-90B compliant. All other output interfaces will not be
affected by the SP800-90B startup test and thus are not considered
SP800-90B compliant.

At runtime, the SP800-90B APT and RCT are applied to each time stamp
generated for a received interrupt. When either the APT and RCT indicates
a noise source failure, the LRNG is reset to a state it has immediately
after boot:

- all entropy counters are set to zero

- the SP800-90B startup tests are re-performed which implies that
getrandom(2) would block again until new entropy was collected

To summarize, the following rules apply:

• SP800-90B compliant output interfaces

  - /dev/random

  - getrandom(2) system call

  -  get_random_bytes kernel-internal interface when being triggered by
 the callback registered with add_random_ready_callback

• SP800-90B non-compliant output interfaces

  - /dev/urandom

  - get_random_bytes kernel-internal interface called directly

  - randomize_page kernel-internal interface

  - get_random_u32 and get_random_u64 kernel-internal interfaces

  - get_random_u32_wait, get_random_u64_wait, get_random_int_wait, and
get_random_long_wait kernel-internal interfaces

If either the RCT, or the APT health test fails irrespective whether
during initialization or runtime, the following actions occur:

  1. The entropy of the entire entropy pool is invalidated.

  2. All DRNGs are reset which imply that they are treated as being
 not seeded and require a reseed during next invocation.

  3. The SP800-90B startup health test are initiated with all
 implications of the startup tests. That implies that from that point
 on, new events must be observed and its entropy must be inserted into
 the entropy pool before random numbers are calculated from the
 entropy pool.

Further details on the SP800-90B compliance and the availability of all
test tools required to perform all tests mandated by SP800-90B are
provided at [1].

The entire health testing code is compile-time configurable.

The patch provides a CONFIG_BROKEN configuration of the APT / RCT cutoff
values which have a high likelihood to trigger the health test failure.
The BROKEN APT cutoff is set to the exact mean of the expected value if
the time stamps are equally distributed (512 time stamps divided by 16
possible values due to using the 4 LSB of the time stamp). The BROKEN
RCT cutoff value is set to 1 which is likely to be triggered during
regular operation.

CC: Torsten Duwe 
CC: "Eric W. Biederman" 
CC: "Alexander E. Patrakov" 
CC: "Ahmed S. Darwish" 
CC: "Theodore Y. Ts'o" 
CC: Willy Tarreau 
CC: Matthew Garrett 
CC: Vito Caputo 
CC: Andreas Dilger 
CC: Jan Kara 
CC: Ray Strode 
CC: William Jon McCann 
CC: zhangjs 
CC: Andy Lutomirski 
CC: Florian Weimer 
CC: Lennart Poettering 
CC: Nicolai Stange 
Reviewed-by: Roman Drahtmueller 
Tested-by: Roman Drahtmüller 
Tested-by: Marcelo Henrique Cerri 
Tested-by: Neil Horman 
Signed-off-by: Stephan Mueller 
---
 drivers/char/lrng/Kconfig   |  56 +
 dri

[PATCH v38 04/13] LRNG - add switchable DRNG support

[Stephan Müller]

The DRNG switch support allows replacing the DRNG mechanism of the
LRNG. The switching support rests on the interface definition of
include/linux/lrng.h. A new DRNG is implemented by filling in the
interface defined in this header file.

In addition to the DRNG, the extension also has to provide a hash
implementation that is used to hash the entropy pool for random number
extraction.

Note: It is permissible to implement a DRNG whose operations may sleep.
However, the hash function must not sleep.

The switchable DRNG support allows replacing the DRNG at runtime.
However, only one DRNG extension is allowed to be loaded at any given
time. Before replacing it with another DRNG implementation, the possibly
existing DRNG extension must be unloaded.

The switchable DRNG extension activates the new DRNG during load time.
It is expected, however, that such a DRNG switch would be done only once
by an administrator to load the intended DRNG implementation.

It is permissible to compile DRNG extensions either as kernel modules or
statically. The initialization of the DRNG extension should be performed
with a late_initcall to ensure the extension is available when user
space starts but after all other initialization completed.
The initialization is performed by registering the function call data
structure with the lrng_set_drng_cb function. In order to unload the
DRNG extension, lrng_set_drng_cb must be invoked with the NULL
parameter.

The DRNG extension should always provide a security strength that is at
least as strong as LRNG_DRNG_SECURITY_STRENGTH_BITS.

The hash extension must not sleep and must not maintain a separate
state.

CC: Torsten Duwe 
CC: "Eric W. Biederman" 
CC: "Alexander E. Patrakov" 
CC: "Ahmed S. Darwish" 
CC: "Theodore Y. Ts'o" 
CC: Willy Tarreau 
CC: Matthew Garrett 
CC: Vito Caputo 
CC: Andreas Dilger 
CC: Jan Kara 
CC: Ray Strode 
CC: William Jon McCann 
CC: zhangjs 
CC: Andy Lutomirski 
CC: Florian Weimer 
CC: Lennart Poettering 
CC: Nicolai Stange 
Reviewed-by: Marcelo Henrique Cerri 
Reviewed-by: Roman Drahtmueller 
Tested-by: Roman Drahtmüller 
Tested-by: Marcelo Henrique Cerri 
Tested-by: Neil Horman 
Signed-off-by: Stephan Mueller 
---
 drivers/char/lrng/Kconfig   |   7 ++
 drivers/char/lrng/Makefile  |   1 +
 drivers/char/lrng/lrng_switch.c | 207 
 3 files changed, 215 insertions(+)
 create mode 100644 drivers/char/lrng/lrng_switch.c

diff --git a/drivers/char/lrng/Kconfig b/drivers/char/lrng/Kconfig
index 23b219093b07..fe6a7eaeabb0 100644
--- a/drivers/char/lrng/Kconfig
+++ b/drivers/char/lrng/Kconfig
@@ -119,4 +119,11 @@ config LRNG_COLLECTION_SIZE
default 4096 if LRNG_COLLECTION_SIZE_4096
default 8192 if LRNG_COLLECTION_SIZE_8192
 
+menuconfig LRNG_DRNG_SWITCH
+   bool "Support DRNG runtime switching"
+   help
+ The Linux RNG per default uses a ChaCha20 DRNG that is
+ accessible via the external interfaces. With this configuration
+ option other DRNGs can be selected and loaded at runtime.
+
 endif # LRNG
diff --git a/drivers/char/lrng/Makefile b/drivers/char/lrng/Makefile
index ac97f0b11cb7..0eb4a6849c88 100644
--- a/drivers/char/lrng/Makefile
+++ b/drivers/char/lrng/Makefile
@@ -10,3 +10,4 @@ obj-y += lrng_pool.o lrng_aux.o \
 
 obj-$(CONFIG_NUMA) += lrng_numa.o
 obj-$(CONFIG_SYSCTL)   += lrng_proc.o
+obj-$(CONFIG_LRNG_DRNG_SWITCH) += lrng_switch.o
diff --git a/drivers/char/lrng/lrng_switch.c b/drivers/char/lrng/lrng_switch.c
new file mode 100644
index ..40cea72fe06a
--- /dev/null
+++ b/drivers/char/lrng/lrng_switch.c
@@ -0,0 +1,207 @@
+// SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+/*
+ * LRNG DRNG switching support
+ *
+ * Copyright (C) 2016 - 2021, Stephan Mueller 
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include 
+
+#include "lrng_internal.h"
+
+static int lrng_drng_switch(struct lrng_drng *drng_store,
+   const struct lrng_crypto_cb *cb, int node)
+{
+   const struct lrng_crypto_cb *old_cb;
+   unsigned long flags = 0, flags2 = 0;
+   int ret;
+   u8 seed[LRNG_DRNG_SECURITY_STRENGTH_BYTES];
+   void *new_drng = cb->lrng_drng_alloc(LRNG_DRNG_SECURITY_STRENGTH_BYTES);
+   void *old_drng, *new_hash, *old_hash;
+   u32 current_security_strength;
+   bool sl = false, reset_drng = !lrng_get_available();
+
+   if (IS_ERR(new_drng)) {
+   pr_warn("could not allocate new DRNG for NUMA node %d (%ld)\n",
+   node, PTR_ERR(new_drng));
+   return PTR_ERR(new_drng);
+   }
+
+   new_hash = cb->lrng_hash_alloc();
+   if (IS_ERR(new_hash)) {
+   pr_warn("could not allocate new LRNG pool hash (%ld)\n",
+   PTR_ERR(new_hash));
+   cb->lrng_drng_dealloc(new_drng);
+   return PTR_ERR(new_hash);
+   }
+
+   if (cb->lrng_hash_digestsize(new_hash) > LRNG_MAX_D

[PATCH v38 00/13] /dev/random - a new approach

[Stephan Müller]

Hi,

The following patch set provides a different approach to /dev/random which
is called Linux Random Number Generator (LRNG) to collect entropy within
the Linux kernel. It provides the same API and ABI and can be used as a
drop-in replacement.

The LRNG implements at least all features of the existing /dev/random such as
NUMA-node-local DRNGs. Patches 1 through 3 provide the code that is feature-
identical. The following advantages compared to the existing /dev/random
implementation are present:

* Sole use of crypto for data processing:

 - Exclusive use of a hash operation for conditioning entropy data with
   a clear mathematical description as given in [2] section 2.2 -
   non-cryptographic operations like LFSR are not used.

 - The LRNG uses only properly defined and implemented cryptographic
   algorithms unlike the use of the SHA-1 transformation in the existing
   /dev/random implementation.

 - Hash operations use NUMA-node-local hash instances to benefit large
   parallel systems.

 - LRNG uses limited number of data post-processing steps as documented in
   [2] section 2.2 compared to the large variation of different
   post-processing steps in the existing /dev/random implementation that
   have no apparent mathematical description (see [2] section 4.5).

* Performance

 - Faster by up to 130% in the critical code path of the interrupt handler
   depending on data collection size configurable at kernel compile time -
   the default is now set such that the highest performance is achieved as
   outlined in [2] section 4.2.

 - Configurable data collection sizes to accommodate small environments
   and big environments via CONFIG_LRNG_COLLECTION_SIZE.

 - Entropy collection using an almost never contended lock to benefit
   large parallel systems – worst case rate of contention is the number
   of DRNG reseeds, usually the number of potential contentions per 10
   minutes is equal to number of NUMA nodes.

 - ChaCha20 DRNG is significantly faster as implemented in the existing
   /dev/random as demonstrated with [2] table 2.

 - Faster entropy collection during boot time to reach fully seeded
   level, including on virtual systems or systems with SSDs as outlined
   in [2] section 4.1.

* Testing

 - Availability of run-time health tests of the raw unconditioned
   noise source to identify degradation of the available entropy as
   documented in [2] section 2.5.4. Such health tests are important
   today due to virtual machine monitors reducing the resolution of
   or disabling the high-resolution timer.

 - Heuristic entropy estimation is based on quantitative measurements
   and analysis following SP800-90B and not on coincidental
   underestimation of entropy applied by the existing /dev/random as
   outlined in [4] section 4.4.

 - Power-on self tests for critical deterministic components (ChaCha20
   DRNG, software hash implementation, and entropy collection logic)
   not already covered by power-up tests of the kernel crypto API as
   documented in [2] section 2.14.

 - Availability of test interfaces for all operational stages of the
   LRNG including boot-time raw entropy event data sampling as outlined
   in [2] section 2.15.

 - Fully testable ChaCha20 DRNG via a userspace ChaCha20 DRNG
   implementation [3].

 - In case of using the kernel crypto API SHASH hash implementation, it
   is fully testable and tested via the NIST ACVP test framework, for
   example certificates A734, A737, and A738.

 - The LRNG offers a test interface to validate the used software hash
   implementation and in particular that the LRNG invokes the hash
   correctly, allowing a NIST ACVP-compliant test cycle - see [2]
   section 2.15.

 - Availability of stress testing covering the different code paths for
   data and mechanism (de)allocations and code paths covered with locks.

* Entropy collection

 - The LRNG is shipped with test tools allowing the collection of
   raw unconditioned entropy during runtime and boot time available at
   [1].

 - Full entropy assessment and description is provided with [2] chapter 3,
   specifically section 3.2.6.

 - Guarantee that entropy events are not credited with entropy twice
   (the existing /dev/random implementation credits HID/disk and
   interrupt events with entropy which are a derivative of each other).

* Configurable

 - LRNG kernel configuration allows configuration that is functionally
   equivalent to the existing /dev/random. Non-compiled additional code
   is folded into no-ops.

 - The following additional functions are compile-time selectable
   independent of each other:

  + Enabling of switchable cryptographic implementation support. This
allows enabling an SP800-90A DRBG.

  + Enabling of using Jitter RNG noise source.

  + Enabling of noise source health tests.

  + Enabling of test interface allowing to enable each test interface
individually.

  + Enabling of the power-up self test.

 - At boot-time, the SP800-90B health tests can be en

[PATCH v38 01/13] Linux Random Number Generator

[Stephan Müller]

In an effort to provide a flexible implementation for a random number
generator that also delivers entropy during early boot time, allows
replacement of the deterministic random number generation mechanism,
implement the various components in separate code for easier
maintenance, and provide compliance to SP800-90[A|B|C], introduce
the Linux Random Number Generator (LRNG) framework.

The general design is as follows. Additional implementation details
are given in [1]. The LRNG consists of the following components:

1. The LRNG implements a DRNG. The DRNG always generates the
requested amount of output. When using the SP800-90A terminology
it operates without prediction resistance. The secondary DRNG
maintains a counter of how many bytes were generated since last
re-seed and a timer of the elapsed time since last re-seed. If either
the counter or the timer reaches a threshold, the secondary DRNG is
seeded from the entropy pool.

In case the Linux kernel detects a NUMA system, one secondary DRNG
instance per NUMA node is maintained.

2. The DRNG is seeded by concatenating the data from the
following sources:

(a) the output of the entropy pool,

(b) the Jitter RNG if available and enabled, and

(c) the CPU-based noise source such as Intel RDRAND if available and
enabled.

The entropy estimate of the data of all noise sources are added to
form the entropy estimate of the data used to seed the DRNG with.
The LRNG ensures, however, that the DRNG after seeding is at
maximum the security strength of the DRNG.

The LRNG is designed such that none of these noise sources can dominate
the other noise sources to provide seed data to the DRNG during due to
the following:

(a) During boot time, the amount of received interrupts are the trigger
points to (re)seed the DRNG.

(b) At runtime, the available entropy from the slow noise source is
concatenated with a pre-defined amount of data from the fast noise
sources. In addition, each DRNG reseed operation triggers external
noise source providers to deliver one block of data.

3. The entropy pool accumulates entropy obtained from certain events,
which will henceforth be collectively called "slow noise sources".
The entropy pool collects noise data from slow noise sources. Any data
received by the LRNG from the slow noise sources is inserted into a
per-CPU entropy pool using a hash operation that can be changed during
runtime. Per default, SHA-256 is used.

 (a) When an interrupt occurs, the high-resolution time stamp is mixed
into the per-CPU entropy pool. This time stamp is credited with
heuristically implied entropy.

 (b) HID event data like the key stroke or the mouse coordinates are
mixed into the per-CPU entropy pool. This data is not credited with
entropy by the LRNG.

 (c) Device drivers may provide data that is mixed into an auxiliary
pool using the same hash that is used to process the per-CPU entropy
pool. This data is not credited with entropy by the LRNG.

Any data provided from user space by either writing to /dev/random,
/dev/urandom or the IOCTL of RNDADDENTROPY on both device files
are always injected into the auxiliary pool.

In addition, when a hardware random number generator covered by the
Linux kernel HW generator framework wants to deliver random numbers,
it is injected into the auxiliary pool as well. HW generator noise source
is handled separately from the other noise source due to the fact that
the HW generator framework may decide by itself when to deliver data
whereas the other noise sources always requested for data driven by the
LRNG operation. Similarly any user space provided data is inserted into
the entropy pool.

When seed data for the DRNG is to be generated, all per-CPU
entropy pools and the auxiliary pool are hashed. The message digest
forms the new auxiliary pool state. At the same time, this data
is used for seeding the DRNG.

To speed up the interrupt handling code of the LRNG, the time stamp
collected for an interrupt event is truncated to the 8 least
significant bits. 64 truncated time stamps are concatenated and then
jointly inserted into the per-CPU entropy pool. During boot time,
until the fully seeded stage is reached, each time stamp with its
32 least significant bits is are concatenated. When 16 such events
are received, they are injected into the per-CPU entropy pool.

The LRNG allows the DRNG mechanism to be changed at runtime. Per default,
a ChaCha20-based DRNG is used. The ChaCha20-DRNG implemented for the
LRNG is also provided as a stand-alone user space deterministic random
number generator. The LRNG also offers an SP800-90A DRBG based on the
Linux kernel crypto API DRBG implementation.

The processing of entropic data from the noise source before injecting
them into the DRNG is performed with the following mathematical
operations:

1. Truncation: The received time stamps are truncated to 8 least
significant bits (or 32 least significant bits during boot time)

2. Concatenation: The received and truncated time stamps a

Re: [PATCH v3 0/4] sched/fair: Burstable CFS bandwidth controller

[changhuaixin]

Hi，

Sorry for my late reply.

> On Feb 9, 2021, at 9:17 PM, Odin Ugedal  wrote:
> 
> 
> Hi! This looks quite useful, but I have a few quick thoughts. :)
> 
> I know of a lot of people who would love this (especially some
> Kubernetes users)! I really like how this allow users to use cfs
> in a more dynamic and flexible way, without interfering with those
> who like the enforce strict quotas.
> 
> 
>> +++ b/kernel/sched/core.c
>> @ -7900,7 +7910,7 @@ static int tg_set_cfs_bandwidth(struct task_group *tg, 
>> u64 period, u64
>> [...]
>> +/* burst_onset needed */
>> +if (cfs_b->quota != RUNTIME_INF &&
>> +sysctl_sched_cfs_bw_burst_enabled &&
>> +sysctl_sched_cfs_bw_burst_onset_percent > 0) {
>> +
>> +burst_onset = do_div(burst, 100) *
>> +sysctl_sched_cfs_bw_burst_onset_percent;
>> +
>> +cfs_b->runtime += burst_onset;
>> +cfs_b->runtime = min(max_cfs_runtime, cfs_b->runtime);
>> +}
> 
> I saw a comment about this behavior, but I think this can lead to a bit of
> confusion. If sysctl_sched_cfs_bw_burst_onset_percent=0, the amount of
> bandwidth when the first process starts up will depend on the time between
> the quota was set and the startup of the process, and that feel a bit like
> a "timing" race that end user application then will have to think about.
> 
> I suspect contianer runtimes and/or tools like Kubernetes will then have
> to tell users to set the value to a certan amount in order to make it
> work as expected.
> 
> Another thing is that when a cgroup has saved some time into the
> "burst quota", updating the quota, period or burst will then reset the
> "burst quota", even though eg. only the burst was changed. Some tools
> use dynamic quotas, resulting in multiple changes in the quota over time,
> and I am a bit scared that don't allowing them to control "start burst"
> on a write can be limiting.
> 
> Maybe we can allow people to set the "start bandwidth" explicitly when setting
> cfs_burst if they want to do that? (edit: that might be hard for cgroup v1, 
> but
> would I think that is a good solution on cgroup v2).
> 
> This is however just my thoughts, and I am not 100% sure about what the
> best solution is, but if we merge a certain behavior, we have no real
> chance of changing it later.
> 

If there are cases where the "start bandwidth" matters, I think there is need 
to expose the
"start bandwidth" explicitly too. However, I doubt the existence of such cases 
from my view
and the two examples above.

In my thoughts, this patchset keeps cgroup usage within the quota in the longer 
term, and allows 
cgroup to respond to a burst of work with the help of a reasonable burst 
buffer. If quota is set correctly
above average usage, and enough burst buffer is set to meet the needs of bursty 
work. In this
case, it makes no difference whether this cgroup runs with 0 start bandwidth or 
all of it.
Thus I used sysctl_sched_cfs_bw_burst_onset_percent to decided the start 
bandwidth
to leave some convenience here. If this sysctl interface is confusing, I wonder 
whether it
is a good idea not to expose this interface.

For the first case mentioned above, if Kubernet users care the "start 
bandwidth" for process startup,
maybe it is better to give all of it rather than a part?

For the second case with quota changes over time, I think it is important 
making sure each change works
long enough to enforce average quota limit. Does it really matter to control 
"start burst" on each change?



> 
>> +++ b/kernel/sched/sched.h
>> @@ -367,6 +367,7 @@ struct cfs_bandwidth {
>>  u64 burst;
>>  u64 buffer;
>>  u64 max_overrun;
>> +u64 previous_runtime;
>>  s64 hierarchical_quota;
> 
> Maybe indicate that this was the remaining runtime _after_ the previous
> period ended? Not 100% sure, but maybe sometihing like
> 'remaining_runtime_prev_period' or 'end_runtime_prev_period'(as inspiration). 
>   
> 

It is an copy of runtime at period start, and used to calculate burst time 
during a period.
Not quite remaining_runtime_prev_period.

> 
>> +++ b/kernel/sched/core.c
>> @@ -8234,6 +8236,10 @@ static int cpu_cfs_stat_show(struct seq_file *sf, 
>> void *v)
>>  seq_printf(sf, "wait_sum %llu\n", ws);
>>  }
>> 
>> +seq_printf(sf, "current_bw %llu\n", cfs_b->runtime);
>> +seq_printf(sf, "nr_burst %d\n", cfs_b->nr_burst);
>> +seq_printf(sf, "burst_time %llu\n", cfs_b->burst_time);
>> +
>>  return 0;
>> }
> 
> Looks like these metrics are missing from the cgroup v2 stats.
> 

Thanks, cgroup v2 stats and documentation should be handled. I will add them
in the following patchset.

> Are we sure it is smart to start exposing cfs_b->runtime, since it makes it
> harder to change the implementation at a later time? I don't thin it is that
> usefull, and if it is only exposed

[PATCH v38 12/13] LRNG - add interface for gathering of raw entropy

[Stephan Müller]

The test interface allows a privileged process to capture the raw
unconditioned noise that is collected by the LRNG for statistical
analysis. Such testing allows the analysis how much entropy
the interrupt noise source provides on a given platform.
Extracted noise data is not used to seed the LRNG. This
is a test interface and not appropriate for production systems.
Yet, the interface is considered to be sufficiently secured for
production systems.

Access to the data is given through the lrng_raw debugfs file. The
data buffer should be multiples of sizeof(u32) to fill the entire
buffer. Using the option lrng_testing.boot_test=1 the raw noise of
the first 1000 entropy events since boot can be sampled.

This test interface allows generating the data required for
analysis whether the LRNG is in compliance with SP800-90B
sections 3.1.3 and 3.1.4.

In addition, the test interface allows gathering of the concatenated raw
entropy data to verify that the concatenation works appropriately.
This includes sampling of the following raw data:

* high-resolution time stamp

* Jiffies

* IRQ number

* IRQ flags

* return instruction pointer

* interrupt register state

* array logic batching the high-resolution time stamp

Also, a testing interface to support ACVT of the hash implementation
is provided. The reason why only hash testing is supported (as
opposed to also provide testing for the DRNG) is the fact that the
LRNG software hash implementation contains glue code that may
warrant testing in addition to the testing of the software ciphers
via the kernel crypto API. Also, for testing the CTR-DRBG, the
underlying AES implementation would need to be tested. However,
such AES test interface cannot be provided by the LRNG as it has no
means to access the AES operation.

Finally, the execution duration for processing a time stamp can be
obtained with the LRNG raw entropy interface.

If a test interface is not compiled, its code is a noop which has no
impact on the performance.

CC: Torsten Duwe 
CC: "Eric W. Biederman" 
CC: "Alexander E. Patrakov" 
CC: "Ahmed S. Darwish" 
CC: "Theodore Y. Ts'o" 
CC: Willy Tarreau 
CC: Matthew Garrett 
CC: Vito Caputo 
CC: Andreas Dilger 
CC: Jan Kara 
CC: Ray Strode 
CC: William Jon McCann 
CC: zhangjs 
CC: Andy Lutomirski 
CC: Florian Weimer 
CC: Lennart Poettering 
CC: Nicolai Stange 
Reviewed-by: Roman Drahtmueller 
Tested-by: Roman Drahtmüller 
Tested-by: Marcelo Henrique Cerri 
Tested-by: Neil Horman 
Signed-off-by: Stephan Mueller 
---
 drivers/char/lrng/Kconfig| 150 +++
 drivers/char/lrng/Makefile   |   1 +
 drivers/char/lrng/lrng_testing.c | 689 +++
 3 files changed, 840 insertions(+)
 create mode 100644 drivers/char/lrng/lrng_testing.c

diff --git a/drivers/char/lrng/Kconfig b/drivers/char/lrng/Kconfig
index 743f717d6c19..3e57068ccdff 100644
--- a/drivers/char/lrng/Kconfig
+++ b/drivers/char/lrng/Kconfig
@@ -224,4 +224,154 @@ config LRNG_APT_CUTOFF
default 325 if !LRNG_APT_BROKEN
default 32 if LRNG_APT_BROKEN
 
+menuconfig LRNG_TESTING_MENU
+   bool "LRNG testing interfaces"
+   depends on DEBUG_FS
+   help
+ Enable one or more of the following test interfaces.
+
+ If unsure, say N.
+
+if LRNG_TESTING_MENU
+
+config LRNG_RAW_HIRES_ENTROPY
+   bool "Enable entropy test interface to hires timer noise source"
+   default y
+   help
+ The test interface allows a privileged process to capture
+ the raw unconditioned high resolution time stamp noise that
+ is collected by the LRNG for statistical analysis. Extracted
+ noise data is not used to seed the LRNG.
+
+ The raw noise data can be obtained using the lrng_raw_hires
+ debugfs file. Using the option lrng_testing.boot_raw_hires_test=1
+ the raw noise of the first 1000 entropy events since boot
+ can be sampled.
+
+config LRNG_RAW_JIFFIES_ENTROPY
+   bool "Enable entropy test interface to Jiffies noise source"
+   help
+ The test interface allows a privileged process to capture
+ the raw unconditioned Jiffies that is collected by
+ the LRNG for statistical analysis. This data is used for
+ seeding the LRNG if a high-resolution time stamp is not
+ available. If a high-resolution time stamp is detected,
+ the Jiffies value is not collected by the LRNG and no
+ data is provided via the test interface. Extracted noise
+ data is not used to seed the random number generator.
+
+ The raw noise data can be obtained using the lrng_raw_jiffies
+ debugfs file. Using the option lrng_testing.boot_raw_jiffies_test=1
+ the raw noise of the first 1000 entropy events since boot
+ can be sampled.
+
+config LRNG_RAW_IRQ_ENTROPY
+   bool "Enable entropy test interface to IRQ number noise source"
+   help
+ The test interface allows a privileged process to capture
+

Re: [PATCHv2 2/2] iommu/arm-smmu-qcom: Move the adreno smmu specific impl earlier

[Sai Prakash Ranjan]

Hi Bjorn,

On 2021-02-27 00:44, Bjorn Andersson wrote:
> On Fri 26 Feb 12:23 CST 2021, Rob Clark wrote:
> 
> 
> The current logic picks one of:
> 1) is the compatible mentioned in qcom_smmu_impl_of_match[]
> 2) is the compatible an adreno
> 3) no quirks needed
> 
> The change flips the order of these, so the only way I can see this
> change affecting things is if we expected a match on #2, but we got one
> on #1.
> 
> Which implies that the instance that we want to act according to the
> adreno impl was listed in qcom_smmu_impl_of_match[] - which either is
> wrong, or there's a single instance that needs both behaviors.
> 
> (And I believe Jordan's answer confirms the latter - there's a single
> SMMU instance that needs all them quirks at once)
> 

Let me go through the problem statement in case my commit message wasn't
clear. There are two SMMUs (APSS and GPU) on SC7280 and both are SMMU500
(ARM SMMU IP).

APSS SMMU compatible - ("qcom,sc7280-smmu-500", "arm,mmu-500")
GPU SMMU compatible - ("qcom,sc7280-smmu-500", "qcom,adreno-smmu", 
"arm,mmu-500")

Now if we take SC7180 as an example, GPU SMMU was QSMMU(QCOM SMMU IP)
and APSS SMMU was SMMU500(ARM SMMU IP).

APSS SMMU compatible - ("qcom,sc7180-smmu-500", "arm,mmu-500")
GPU SMMU compatible - ("qcom,sc7180-smmu-v2", "qcom,adreno-smmu", 
"qcom,smmu-v2")

Current code sequence without this patch,

if (of_match_node(qcom_smmu_impl_of_match, np))
 return qcom_smmu_create(smmu, &qcom_smmu_impl);

if (of_device_is_compatible(np, "qcom,adreno-smmu"))
return qcom_smmu_create(smmu, &qcom_adreno_smmu_impl);

Now if we look at the compatible for SC7180, there is no problem because
the APSS SMMU will match the one in qcom_smmu_impl_of_match[] and GPU SMMU
will match "qcom,adreno-smmu" because the compatible strings are different.
But for SC7280, both the APSS SMMU and GPU SMMU 
compatible("qcom,sc7280-smmu-500")
are same. So GPU SMMU will match with the one in qcom_smmu_impl_of_match[]
i.e.., "qcom,sc7280-smmu-500" which functionally doesn't cause any problem
but we will miss settings for split pagetables which are part of GPU SMMU
specific implementation.

We can avoid this with yet another new compatible for GPU SMMU something like
"qcom,sc7280-adreno-smmu-500" but since we can handle this easily in the
driver and since the IPs are same, meaning if there was a hardware quirk
required, then we would need to apply to both of them and would this additional
compatible be of any help?

Coming to the part of quirks now, you are right saying both SMMUs will need
to have the same quirks in SC7280 and similar others where both are based on
same IPs but those should probably be *hardware quirks* and if they are
software based like the S2CR quirk depending on the firmware, then it might
not be applicable to both. In case if it is applicable, then as Jordan 
mentioned,
we can add the same quirks in GPU SMMU implementation.

Thanks,
Sai

--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

[PATCH v38 09/13] crypto: provide access to a static Jitter RNG state

[Stephan Müller]

To support the LRNG operation which uses the Jitter RNG separately
from the kernel crypto API, at a time where potentially the regular
memory management is not yet initialized, the Jitter RNG needs to
provide a state whose memory is defined at compile time. As only once
instance will ever be needed by the LRNG, define once static memory
block which is solely to be used by the LRNG.

CC: Torsten Duwe 
CC: "Eric W. Biederman" 
CC: "Alexander E. Patrakov" 
CC: "Ahmed S. Darwish" 
CC: "Theodore Y. Ts'o" 
CC: Willy Tarreau 
CC: Matthew Garrett 
CC: Vito Caputo 
CC: Andreas Dilger 
CC: Jan Kara 
CC: Ray Strode 
CC: William Jon McCann 
CC: zhangjs 
CC: Andy Lutomirski 
CC: Florian Weimer 
CC: Lennart Poettering 
CC: Nicolai Stange 
Reviewed-by: Roman Drahtmueller 
Tested-by: Roman Drahtmüller 
Tested-by: Marcelo Henrique Cerri 
Tested-by: Neil Horman 
Signed-off-by: Stephan Mueller 
---
 crypto/jitterentropy-kcapi.c  |  3 +-
 crypto/jitterentropy.c| 31 ++-
 .../crypto/internal}/jitterentropy.h  |  3 ++
 3 files changed, 34 insertions(+), 3 deletions(-)
 rename {crypto => include/crypto/internal}/jitterentropy.h (84%)

diff --git a/crypto/jitterentropy-kcapi.c b/crypto/jitterentropy-kcapi.c
index e8a4165a1874..c90e60910827 100644
--- a/crypto/jitterentropy-kcapi.c
+++ b/crypto/jitterentropy-kcapi.c
@@ -43,8 +43,7 @@
 #include 
 #include 
 #include 
-
-#include "jitterentropy.h"
+#include 
 
 /***
  * Helper function
diff --git a/crypto/jitterentropy.c b/crypto/jitterentropy.c
index 6e147c43fc18..fa1459f09b01 100644
--- a/crypto/jitterentropy.c
+++ b/crypto/jitterentropy.c
@@ -117,7 +117,7 @@ struct rand_data {
 #define JENT_EHEALTH   9 /* Health test failed during initialization */
 #define JENT_ERCT  10 /* RCT failed during initialization */
 
-#include "jitterentropy.h"
+#include 
 
 /***
  * Adaptive Proportion Test
@@ -854,3 +854,32 @@ int jent_entropy_init(void)
 
return 0;
 }
+
+struct rand_data *jent_lrng_entropy_collector(void)
+{
+   static unsigned char lrng_jent_mem[JENT_MEMORY_SIZE];
+   static struct rand_data lrng_jent_state = {
+   .data   = 0,
+   .old_data   = 0,
+   .prev_time  = 0,
+   .last_delta = 0,
+   .last_delta2= 0,
+   .osr= 1,
+   .mem= lrng_jent_mem,
+   .memlocation= 0,
+   .memblocks  = JENT_MEMORY_BLOCKSIZE,
+   .memblocksize   = JENT_MEMORY_BLOCKS,
+   .memaccessloops = JENT_MEMORY_ACCESSLOOPS,
+   .rct_count  = 0,
+   .apt_observations = 0,
+   .apt_count  = 0,
+   .apt_base   = 0,
+   .apt_base_set   = 0,
+   .health_failure = 0
+   };
+
+   if (jent_entropy_init())
+   return NULL;
+
+   return &lrng_jent_state;
+}
diff --git a/crypto/jitterentropy.h b/include/crypto/internal/jitterentropy.h
similarity index 84%
rename from crypto/jitterentropy.h
rename to include/crypto/internal/jitterentropy.h
index c83fff32d130..6e07d86eac82 100644
--- a/crypto/jitterentropy.h
+++ b/include/crypto/internal/jitterentropy.h
@@ -15,3 +15,6 @@ extern int jent_read_entropy(struct rand_data *ec, unsigned 
char *data,
 extern struct rand_data *jent_entropy_collector_alloc(unsigned int osr,
  unsigned int flags);
 extern void jent_entropy_collector_free(struct rand_data *entropy_collector);
+
+/* Access to statically allocated Jitter RNG instance */
+extern struct rand_data *jent_lrng_entropy_collector(void);
-- 
2.29.2

[PATCH v38 06/13] crypto: DRBG - externalize DRBG functions for LRNG

[Stephan Müller]

This patch allows several DRBG functions to be called by the LRNG kernel
code paths outside the drbg.c file.

CC: Torsten Duwe 
CC: "Eric W. Biederman" 
CC: "Alexander E. Patrakov" 
CC: "Ahmed S. Darwish" 
CC: "Theodore Y. Ts'o" 
CC: Willy Tarreau 
CC: Matthew Garrett 
CC: Vito Caputo 
CC: Andreas Dilger 
CC: Jan Kara 
CC: Ray Strode 
CC: William Jon McCann 
CC: zhangjs 
CC: Andy Lutomirski 
CC: Florian Weimer 
CC: Lennart Poettering 
CC: Nicolai Stange 
Reviewed-by: Roman Drahtmueller 
Tested-by: Roman Drahtmüller 
Tested-by: Marcelo Henrique Cerri 
Tested-by: Neil Horman 
Signed-off-by: Stephan Mueller 
---
 crypto/drbg.c | 16 ++--
 include/crypto/drbg.h |  7 +++
 2 files changed, 17 insertions(+), 6 deletions(-)

diff --git a/crypto/drbg.c b/crypto/drbg.c
index 3132967a1749..58b1de903def 100644
--- a/crypto/drbg.c
+++ b/crypto/drbg.c
@@ -113,7 +113,7 @@
  * the SHA256 / AES 256 over other ciphers. Thus, the favored
  * DRBGs are the latest entries in this array.
  */
-static const struct drbg_core drbg_cores[] = {
+const struct drbg_core drbg_cores[] = {
 #ifdef CONFIG_CRYPTO_DRBG_CTR
{
.flags = DRBG_CTR | DRBG_STRENGTH128,
@@ -190,6 +190,7 @@ static const struct drbg_core drbg_cores[] = {
},
 #endif /* CONFIG_CRYPTO_DRBG_HMAC */
 };
+EXPORT_SYMBOL(drbg_cores);
 
 static int drbg_uninstantiate(struct drbg_state *drbg);
 
@@ -205,7 +206,7 @@ static int drbg_uninstantiate(struct drbg_state *drbg);
  * Return: normalized strength in *bytes* value or 32 as default
  *to counter programming errors
  */
-static inline unsigned short drbg_sec_strength(drbg_flag_t flags)
+unsigned short drbg_sec_strength(drbg_flag_t flags)
 {
switch (flags & DRBG_STRENGTH_MASK) {
case DRBG_STRENGTH128:
@@ -218,6 +219,7 @@ static inline unsigned short drbg_sec_strength(drbg_flag_t 
flags)
return 32;
}
 }
+EXPORT_SYMBOL(drbg_sec_strength);
 
 /*
  * FIPS 140-2 continuous self test for the noise source
@@ -1214,7 +1216,7 @@ static int drbg_seed(struct drbg_state *drbg, struct 
drbg_string *pers,
 }
 
 /* Free all substructures in a DRBG state without the DRBG state structure */
-static inline void drbg_dealloc_state(struct drbg_state *drbg)
+void drbg_dealloc_state(struct drbg_state *drbg)
 {
if (!drbg)
return;
@@ -1235,12 +1237,13 @@ static inline void drbg_dealloc_state(struct drbg_state 
*drbg)
drbg->fips_primed = false;
}
 }
+EXPORT_SYMBOL(drbg_dealloc_state);
 
 /*
  * Allocate all sub-structures for a DRBG state.
  * The DRBG state structure must already be allocated.
  */
-static inline int drbg_alloc_state(struct drbg_state *drbg)
+int drbg_alloc_state(struct drbg_state *drbg)
 {
int ret = -ENOMEM;
unsigned int sb_size = 0;
@@ -1321,6 +1324,7 @@ static inline int drbg_alloc_state(struct drbg_state 
*drbg)
drbg_dealloc_state(drbg);
return ret;
 }
+EXPORT_SYMBOL(drbg_alloc_state);
 
 /*
  * DRBG interface functions
@@ -1890,8 +1894,7 @@ static int drbg_kcapi_sym_ctr(struct drbg_state *drbg,
  *
  * return: flags
  */
-static inline void drbg_convert_tfm_core(const char *cra_driver_name,
-int *coreref, bool *pr)
+void drbg_convert_tfm_core(const char *cra_driver_name, int *coreref, bool *pr)
 {
int i = 0;
size_t start = 0;
@@ -1918,6 +1921,7 @@ static inline void drbg_convert_tfm_core(const char 
*cra_driver_name,
}
}
 }
+EXPORT_SYMBOL(drbg_convert_tfm_core);
 
 static int drbg_kcapi_init(struct crypto_tfm *tfm)
 {
diff --git a/include/crypto/drbg.h b/include/crypto/drbg.h
index c4165126937e..71d53e028e6d 100644
--- a/include/crypto/drbg.h
+++ b/include/crypto/drbg.h
@@ -278,4 +278,11 @@ enum drbg_prefixes {
DRBG_PREFIX3
 };
 
+extern int drbg_alloc_state(struct drbg_state *drbg);
+extern void drbg_dealloc_state(struct drbg_state *drbg);
+extern void drbg_convert_tfm_core(const char *cra_driver_name, int *coreref,
+ bool *pr);
+extern const struct drbg_core drbg_cores[];
+extern unsigned short drbg_sec_strength(drbg_flag_t flags);
+
 #endif /* _DRBG_H */
-- 
2.29.2

[PATCH v38 03/13] LRNG - sysctls and /proc interface

[Stephan Müller]

The LRNG sysctl interface provides the same controls as the existing
/dev/random implementation. These sysctls behave identically and are
implemented identically. The goal is to allow a possible merge of the
existing /dev/random implementation with this implementation which
implies that this patch tries have a very close similarity. Yet, all
sysctls are documented at [1].

In addition, it provides the file lrng_type which provides details about
the LRNG:

- the name of the DRNG that produces the random numbers for /dev/random,
/dev/urandom, getrandom(2)

- the hash used to produce random numbers from the entropy pool

- the number of secondary DRNG instances

- indicator whether the LRNG operates SP800-90B compliant

- indicator whether a high-resolution timer is identified - only with a
high-resolution timer the interrupt noise source will deliver sufficient
entropy

- indicator whether the LRNG has been minimally seeded (i.e. is the
secondary DRNG seeded with at least 128 bits of of entropy)

- indicator whether the LRNG has been fully seeded (i.e. is the
secondary DRNG seeded with at least 256 bits of entropy)

[1] https://www.chronox.de/lrng.html

CC: Torsten Duwe 
CC: "Eric W. Biederman" 
CC: "Alexander E. Patrakov" 
CC: "Ahmed S. Darwish" 
CC: "Theodore Y. Ts'o" 
CC: Willy Tarreau 
CC: Matthew Garrett 
CC: Vito Caputo 
CC: Andreas Dilger 
CC: Jan Kara 
CC: Ray Strode 
CC: William Jon McCann 
CC: zhangjs 
CC: Andy Lutomirski 
CC: Florian Weimer 
CC: Lennart Poettering 
CC: Nicolai Stange 
Reviewed-by: Marcelo Henrique Cerri 
Reviewed-by: Roman Drahtmueller 
Tested-by: Roman Drahtmüller 
Tested-by: Marcelo Henrique Cerri 
Tested-by: Neil Horman 
Signed-off-by: Stephan Mueller 
---
 drivers/char/lrng/Makefile  |   1 +
 drivers/char/lrng/lrng_interfaces.c |   2 -
 drivers/char/lrng/lrng_internal.h   |   4 +
 drivers/char/lrng/lrng_proc.c   | 184 
 4 files changed, 189 insertions(+), 2 deletions(-)
 create mode 100644 drivers/char/lrng/lrng_proc.c

diff --git a/drivers/char/lrng/Makefile b/drivers/char/lrng/Makefile
index 29724c65287d..ac97f0b11cb7 100644
--- a/drivers/char/lrng/Makefile
+++ b/drivers/char/lrng/Makefile
@@ -9,3 +9,4 @@ obj-y   += lrng_pool.o lrng_aux.o \
   lrng_interfaces.o
 
 obj-$(CONFIG_NUMA) += lrng_numa.o
+obj-$(CONFIG_SYSCTL)   += lrng_proc.o
diff --git a/drivers/char/lrng/lrng_interfaces.c 
b/drivers/char/lrng/lrng_interfaces.c
index efcadcfa79f2..8121ba495844 100644
--- a/drivers/char/lrng/lrng_interfaces.c
+++ b/drivers/char/lrng/lrng_interfaces.c
@@ -38,8 +38,6 @@ static DECLARE_WAIT_QUEUE_HEAD(lrng_write_wait);
 static DECLARE_WAIT_QUEUE_HEAD(lrng_init_wait);
 static struct fasync_struct *fasync;
 
-struct ctl_table random_table[];
-
 /** Helper ***/
 
 /* Is the DRNG seed level too low? */
diff --git a/drivers/char/lrng/lrng_internal.h 
b/drivers/char/lrng/lrng_internal.h
index 1bfb3710c767..0a9af852a8fe 100644
--- a/drivers/char/lrng/lrng_internal.h
+++ b/drivers/char/lrng/lrng_internal.h
@@ -108,7 +108,11 @@ void lrng_cc20_init_state_boot(struct chacha20_state 
*state);
 
 /** /proc 
*/
 
+#ifdef CONFIG_SYSCTL
+void lrng_pool_inc_numa_node(void);
+#else
 static inline void lrng_pool_inc_numa_node(void) { }
+#endif
 
 /** LRNG interfaces 
***/
 
diff --git a/drivers/char/lrng/lrng_proc.c b/drivers/char/lrng/lrng_proc.c
new file mode 100644
index ..244681679b39
--- /dev/null
+++ b/drivers/char/lrng/lrng_proc.c
@@ -0,0 +1,184 @@
+// SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+/*
+ * LRNG proc and sysctl interfaces
+ *
+ * Copyright (C) 2016 - 2021, Stephan Mueller 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "lrng_internal.h"
+#include "lrng_sw_noise.h"
+
+/*
+ * This function is used to return both the bootid UUID, and random
+ * UUID.  The difference is in whether table->data is NULL; if it is,
+ * then a new UUID is generated and returned to the user.
+ *
+ * If the user accesses this via the proc interface, the UUID will be
+ * returned as an ASCII string in the standard UUID format; if via the
+ * sysctl system call, as 16 bytes of binary data.
+ */
+static int lrng_proc_do_uuid(struct ctl_table *table, int write,
+void *buffer, size_t *lenp, loff_t *ppos)
+{
+   struct ctl_table fake_table;
+   unsigned char buf[64], tmp_uuid[16], *uuid;
+
+   uuid = table->data;
+   if (!uuid) {
+   uuid = tmp_uuid;
+   generate_random_uuid(uuid);
+   } else {
+   static DEFINE_SPINLOCK(bootid_spinlock);
+
+   spin_lock(&bootid_spinlock);
+   if (!uuid[8])
+   generate_random_uuid(uuid);
+   spin_unlock(

Re: [PATCH 8/9] arm64: dts: qcom: sc7280: Add AOSS QMP node

[Sai Prakash Ranjan]

On 2021-02-27 00:16, Stephen Boyd wrote:

Quoting Sai Prakash Ranjan (2021-02-25 23:51:00)

On 2021-02-26 01:11, Stephen Boyd wrote:
> Quoting Sai Prakash Ranjan (2021-02-25 01:30:24)
>> Add a DT node for the AOSS QMP on SC7280 SoC.
>>
>> Signed-off-by: Sai Prakash Ranjan 
>> ---
>>  arch/arm64/boot/dts/qcom/sc7280.dtsi | 14 ++
>>  1 file changed, 14 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
>> b/arch/arm64/boot/dts/qcom/sc7280.dtsi
>> index 65c1e0f2fb56..cbd567ccc04e 100644
>> --- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
>> @@ -9,6 +9,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>
>>  / {
>> @@ -368,6 +369,19 @@ pdc: interrupt-controller@b22 {
>> interrupt-controller;
>> };
>>
>> +   aoss_qmp: qmp@c30 {
>
> power-domain-controller@c30? power-controller@c30?
>

Its an AOSS message RAM and all other SM* SoCs have as qmp@
and the dt binding as well, I see only SM8150 with power-controller,
that should probably be fixed?


Node name should be generic while still being meaningful. Nobody knows
what qmp is, but power-controller makes sense. Can you fix this and the
others to be power-controller?



Ok makes sense, I will post changing others as well and see if we get
any comments there.

Thanks,
Sai

--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member

of Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH 3/9] arm64: dts: qcom: sc7280: Add device tree node for LLCC

[Sai Prakash Ranjan]

On 2021-02-27 00:15, Stephen Boyd wrote:

Quoting Sai Prakash Ranjan (2021-02-26 00:04:27)

On 2021-02-26 01:07, Stephen Boyd wrote:
> Quoting Sai Prakash Ranjan (2021-02-25 01:30:19)
>> Add a DT node for Last level cache (aka. system cache)
>> controller which provides control over the last level
>> cache present on SC7280 SoC.
>>
>> Signed-off-by: Sai Prakash Ranjan 
>> ---
>
> Reviewed-by: Stephen Boyd 
>
> Should add system-cache-controller to the devicetree spec. Or just use
> cache-controller for the node name.

This was as per discussion in [1][2] where dt-schema throws an error
since it expects cache-level to be associated with cache-controller.



Ah right. Can you add system-cache-controller to the dt spec?


Sure, I'll add it. Hopefully that won't have to block this change?
Because I might need some time to get permissions to add it there.

Thanks,
Sai

--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member

of Code Aurora Forum, hosted by The Linux Foundation

[RFC v2] copy_file_range.2: Update cross-filesystem support for 5.12

[Alejandro Colomar]

Linux 5.12 fixes a regression.

Cross-filesystem copies (introduced in 5.3) were buggy.

Move the statements documenting cross-fs to BUGS.
Kernels 5.3..5.11 should be patched soon.

State version information for some errors related to this.

Reported-by: Luis Henriques 
Reported-by: Amir Goldstein 
Related: 
Cc: Greg KH 
Cc: Michael Kerrisk 
Cc: Anna Schumaker 
Cc: Jeff Layton 
Cc: Steve French 
Cc: Miklos Szeredi 
Cc: Trond Myklebust 
Cc: Alexander Viro 
Cc: "Darrick J. Wong" 
Cc: Dave Chinner 
Cc: Nicolas Boichat 
Cc: Ian Lance Taylor 
Cc: Luis Lozano 
Cc: Andreas Dilger 
Cc: Olga Kornievskaia 
Cc: Christoph Hellwig 
Cc: ceph-devel 
Cc: linux-kernel 
Cc: CIFS 
Cc: samba-technical 
Cc: linux-fsdevel 
Cc: Linux NFS Mailing List 
Cc: Walter Harms 
Signed-off-by: Alejandro Colomar 
---

Hi all,

Please check that this is correct.
I wrote it as I understood copy_file_range() from the LWN article,
and the conversation on this thread,
but maybe someone with more experience on this syscall find bugs in my patch.

When kernels 5.3..5.11 fix this, some info could be compacted a bit more,
and maybe the BUGS section could be removed.

Also, I'd like to know which filesystems support cross-fs, and since when.

Amir, you said that it was only cifs and nfs (since when? 5.3? 5.12?).

Also, I'm a bit surprised that <5.3 could fail with EOPNOTSUPP
and it wasn't documented.  Is that for sure, Amir?

Thanks,

Alex

---
 man2/copy_file_range.2 | 29 -
 1 file changed, 20 insertions(+), 9 deletions(-)

diff --git a/man2/copy_file_range.2 b/man2/copy_file_range.2
index 611a39b80..93f54889d 100644
--- a/man2/copy_file_range.2
+++ b/man2/copy_file_range.2
@@ -169,6 +169,9 @@ Out of memory.
 .B ENOSPC
 There is not enough space on the target filesystem to complete the copy.
 .TP
+.BR EOPNOTSUPP " (before Linux 5.3; or since Linux 5.12)"
+The filesystem does not support this operation.
+.TP
 .B EOVERFLOW
 The requested source or destination range is too large to represent in the
 specified data types.
@@ -184,10 +187,17 @@ or
 .I fd_out
 refers to an active swap file.
 .TP
-.B EXDEV
+.BR EXDEV " (before Linux 5.3)"
 The files referred to by
 .IR fd_in " and " fd_out
-are not on the same mounted filesystem (pre Linux 5.3).
+are not on the same filesystem.
+.TP
+.BR EXDEV " (or since Linux 5.12)"
+The files referred to by
+.IR fd_in " and " fd_out
+are not on the same filesystem,
+and the source and target filesystems are not of the same type,
+or do not support cross-filesystem copy.
 .SH VERSIONS
 The
 .BR copy_file_range ()
@@ -195,13 +205,10 @@ system call first appeared in Linux 4.5, but glibc 2.27 
provides a user-space
 emulation when it is not available.
 .\" 
https://sourceware.org/git/?p=glibc.git;a=commit;f=posix/unistd.h;h=bad7a0c81f501fbbcc79af9eaa4b8254441c4a1f
 .PP
-A major rework of the kernel implementation occurred in 5.3.
-Areas of the API that weren't clearly defined were clarified and the API bounds
-are much more strictly checked than on earlier kernels.
-Applications should target the behaviour and requirements of 5.3 kernels.
-.PP
-First support for cross-filesystem copies was introduced in Linux 5.3.
-Older kernels will return -EXDEV when cross-filesystem copies are attempted.
+Since 5.12,
+cross-filesystem copies can be achieved
+when both filesystems are of the same type,
+and that filesystem implements support for it.
 .SH CONFORMING TO
 The
 .BR copy_file_range ()
@@ -226,6 +233,10 @@ gives filesystems an opportunity to implement "copy 
acceleration" techniques,
 such as the use of reflinks (i.e., two or more inodes that share
 pointers to the same copy-on-write disk blocks)
 or server-side-copy (in the case of NFS).
+.SH BUGS
+In Linux kernels 5.3 to 5.11, cross-filesystem copies were supported.
+However, on some virtual filesystems, the call failed to copy,
+eventhough it may have reported success.
 .SH EXAMPLES
 .EX
 #define _GNU_SOURCE
-- 
2.30.1.721.g45526154a5

ITd - fair pay & generalizations

[Ywe Cærlyn]

I made some generalisations to this project.

It is now ITd X, (IT developments X), and think a generalization of 
related media can be about 24-bit streaming.


And thus generalized media to this channel: 
https://www.youtube.com/channel/UCmcb1ZPp4tW3eji-0Jaja9Q/videos


Serenity,
Ywe.

[PULL REQUEST] i2c fixes for v5.12

[Wolfram Sang]

Linus,

I2C has three more bugfixes and one revert for you. I accidently applied
one patch too early.

Please pull.

Thanks,

   Wolfram


The following changes since commit 2c87f7a38f930ef6f6a7bdd04aeb82ce3971b54b:

  Merge tag 'pwm/for-5.12-rc1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm 
(2021-02-25 12:23:49 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/for-current

for you to fetch changes up to f4ff0104d4c807a7f96aa3358c03d694895ee8ea:

  i2c: exynos5: Preserve high speed master code (2021-02-26 11:47:42 +0100)


Liguang Zhang (1):
  i2c: designware: Get right data length

Maxime Ripard (1):
  i2c: brcmstb: Fix brcmstd_send_i2c_cmd condition

Mårten Lindahl (1):
  i2c: exynos5: Preserve high speed master code

Wolfram Sang (1):
  Revert "i2c: i2c-qcom-geni: Add shutdown callback for i2c"


with much appreciated quality assurance from

Andy Shevchenko (1):
  (Rev.) i2c: designware: Get right data length

Krzysztof Kozlowski (2):
  (Rev.) i2c: exynos5: Preserve high speed master code
  (Test) i2c: exynos5: Preserve high speed master code

 drivers/i2c/busses/i2c-brcmstb.c   |  2 +-
 drivers/i2c/busses/i2c-designware-core.h   |  2 ++
 drivers/i2c/busses/i2c-designware-master.c |  2 +-
 drivers/i2c/busses/i2c-exynos5.c   |  8 ++-
 drivers/i2c/busses/i2c-qcom-geni.c | 34 --
 5 files changed, 11 insertions(+), 37 deletions(-)


signature.asc
Description: PGP signature

[PATCH] kbuild: Fix for empty SUBLEVEL or PATCHLEVEL again

[Masahiro Yamada]

Commit 9b82f13e7ef3 ("kbuild: clamp SUBLEVEL to 255") breaks the build
if SUBLEVEL or PATCHLEVEL is empty.

Commit 78d3bb4483ba ("kbuild: Fix  for empty SUBLEVEL
or PATCHLEVEL") fixed the issue by prepending a zero.

This time, we cannot take the same approach because we have C code:

  #define LINUX_VERSION_PATCHLEVEL $(PATCHLEVEL)
  #define LINUX_VERSION_SUBLEVEL $(SUBLEVEL)

Replace empty SUBLEVEL or PATCHLEVEL with a zero.

Fixes: 9b82f13e7ef3 ("kbuild: clamp SUBLEVEL to 255")
Reported-by: Christian Zigotzky 
Signed-off-by: Masahiro Yamada 
---

 Makefile | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index f2dc2f953e23..14c13b09a9e7 100644
--- a/Makefile
+++ b/Makefile
@@ -1283,10 +1283,10 @@ endef
 define filechk_version.h
if [ $(SUBLEVEL) -gt 255 ]; then \
echo \#define LINUX_VERSION_CODE $(shell \
-   expr $(VERSION) \* 65536 + 0$(PATCHLEVEL) \* 256 + 255); \
+   expr $(VERSION) \* 65536 + $(PATCHLEVEL) \* 256 + 255); \
else \
echo \#define LINUX_VERSION_CODE $(shell \
-   expr $(VERSION) \* 65536 + 0$(PATCHLEVEL) \* 256 + 
$(SUBLEVEL)); \
+   expr $(VERSION) \* 65536 + $(PATCHLEVEL) \* 256 + $(SUBLEVEL)); 
\
fi;  \
echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) +  \
((c) > 255 ? 255 : (c)))';   \
@@ -1295,6 +1295,8 @@ define filechk_version.h
echo \#define LINUX_VERSION_SUBLEVEL $(SUBLEVEL)
 endef
 
+$(version_h): PATCHLEVEL := $(if $(PATCHLEVEL), $(PATCHLEVEL), 0)
+$(version_h): SUBLEVEL := $(if $(SUBLEVEL), $(SUBLEVEL), 0)
 $(version_h): FORCE
$(call filechk,version.h)
 
-- 
2.27.0

Re: [GIT PULL] Driver core / debugfs changes for 5.12-rc1

[Greg KH]

On Wed, Feb 24, 2021 at 10:20:44AM -0800, Linus Torvalds wrote:
> On Wed, Feb 24, 2021 at 6:27 AM Greg KH  wrote:
> >
> >  [..] I've reverted that change at
> > the very end so we don't have to worry about regressions in 5.12.
> 
> Side note: it would have been really nice to see links to the actual
> problem reports in the revert commit.

Odd, this showed up in my gmail spam folder, just saw this now :(

> Yes, there's a "Link:" line there, but that points to the
> less-than-useful patch submission for the revert, not to the actual
> _reasons_ for the revert.
> 
> Now I'm looking at that revert, and I have absolutely no idea why it
> happened. Only a very vague "there are still reported regressions
> happening".
> 
> I've pulled it, but wanted to just point out that when there's some
> fairly fundamental revert like this, it really would be good to link
> to the problems, so that when people try to re-enable it, they have
> the history for why it didn't work the first time.
> 
> Now all that history is basically lost (well, hopefully Saravana and
> you actually remember, but you get my point).

Sorry, the history is on the original commit Link that was reverted, and
in lots of other emails on lkml over the past few weeks.  Next time I'll
include links to those threads as well.

thanks,

greg k-h

Hello

[Tebanibe Guidayema]

Hi
Glad to contact you, my name is Reacheal and i wish to contact you for
an important purpose which can be of good benefit to you. I will give
you more details about me after receiving your reply indicating that
you have received this letter.
Regards,
Reacheal

Re: [PATCH] proc_sysctl: clamp sizes using table->maxlen

[Alex Xu (Hello71)]

Excerpts from Christoph Hellwig's message of February 16, 2021 3:47 am:
> How do these maxlen = 0 entries even survive the sysctl_check_table
> check?

maxlen!=0 is only checked for "default" handlers, e.g. proc_dostring, 
proc_dointvec. it is not checked for non-default handlers, because some 
of them use fixed lengths.

my patch is not correct though because some drivers neither set proper 
maxlen nor use memcpy themselves; instead, they construct a ctl_table on 
the stack and call proc_*.

> Please split this into one patch each each subsystem that sets maxlen
> to 0 and the actual change to proc_sysctl.c.

I will do this with a new patch version once I figure out a way to 
comprehensively fix all the drivers setting bogus values for maxlen 
(sometimes maxlen=0 is valid if only blank writes are permitted, and 
some drivers set random values which have no relation to the actual read 
size).

Thank you for the review.

Re: [blktrace] c055908abe: WARNING:at_kernel/trace/trace.c:#create_trace_option_files

[Steven Rostedt]

On Sat, 27 Feb 2021 19:44:40 +0800
kernel test robot  wrote:

> [   20.216017] WARNING: CPU: 0 PID: 1 at kernel/trace/trace.c:8370 
> create_trace_option_files (kbuild/src/consumer/kernel/trace/trace.c:8370 
> (discriminator 1)) 
> [   20.218480] Modules linked in:
> [   20.219395] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
> 5.11.0-09341-gc055908abe0d #1
> [   20.221182] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> 1.12.0-1 04/01/2014
> [   20.224540] EIP: create_trace_option_files 
> (kbuild/src/consumer/kernel/trace/trace.c:8370 (discriminator 1)) 
> [ 20.225816] Code: d5 01 83 15 2c b7 08 d5 00 83 c0 01 39 c8 0f 84 c7 00 00 
> 00 8b 14 c7 39 72 44 75 df 83 05 10 b7 08 d5 01 83 15 14 b7 08 d5 00 <0f> 0b 
> 83 05 18 b7 08 d5 01 83 15 1c b7 08 d5 00 83 05 20 b7 08 d5

Looks to be from this:

> +static struct tracer blk_tracer_ext __read_mostly = {
> + .name   = "blkext",
> + .init   = blk_tracer_init,
> + .reset  = blk_tracer_reset,
> + .start  = blk_tracer_start,
> + .stop   = blk_tracer_stop,
> + .print_header   = blk_tracer_print_header,
> + .print_line = blk_tracer_print_line_ext,
> + .flags  = &blk_tracer_flags,

  ^^^

As blk_tracer already registers those flags, when it gets registered as
a tracer, and flag names can not be duplicated.

I could fix the infrastructure to detect the same set of flags being
registered by two different tracers, but in the mean time, it may still
work to use the blk_trace_flags from blk_tracer, and keep .flags NULL
here.

-- Steve


> + .set_flag   = blk_tracer_set_flag,
> +};
> +

Re: [PATCH v11 0/2] UIO support for dfl devices

[Xu Yilun]

Hi Greg:

On Fri, Feb 26, 2021 at 07:40:56AM +0100, Greg KH wrote:
> On Fri, Feb 26, 2021 at 09:22:37AM +0800, Xu Yilun wrote:
> > On Mon, Feb 22, 2021 at 10:56:45AM -0800, Tom Rix wrote:
> > > Yilun,
> > > 
> > > Is there anything outstanding or remaining to be done ?
> > 
> > Sorry for late reply. No, this is my lastest version now.
> > 
> > 
> > Hi Greg:
> > 
> > Do you have some comments on this patchset?
> 
> It's the middle of the merge window, I can't accept anything right
> now...
> 
> But this doesn't even look like it is in my "to review" queue anymore,
> which means that there must have been a lot of discussion on it and
> others asking for changes, so why not work on that right now while you
> can and resubmit it when you have done that?
> 
> No need to ever wait on me for fixing things up.

I checked the mails again and confirmed all the comments from Moritz,
Tom and Hao are fixed. So could you help review it so it could be
accepted in next cycle?

Thanks,
Yilun

> 
> greg k-h

arch/powerpc/sysdev/xive/common.c:1614 xive_debug_show_irq() warn: variable dereferenced before check 'd' (see line 1596)

[Dan Carpenter]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   3fb6d0e00efc958d01c2f109c8453033a2d96796
commit: 930914b7d528fc6b0249bffc00564100bcf6ef75 powerpc/xive: Add a debugfs 
file to dump internal XIVE state
config: powerpc64-randconfig-m031-20210226 (attached as .config)
compiler: powerpc64-linux-gcc (GCC) 9.3.0

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 
Reported-by: Dan Carpenter 

New smatch warnings:
arch/powerpc/sysdev/xive/common.c:1614 xive_debug_show_irq() warn: variable 
dereferenced before check 'd' (see line 1596)

Old smatch warnings:
arch/powerpc/sysdev/xive/common.c:280 xmon_xive_get_irq_config() warn: variable 
dereferenced before check 'd' (see line 262)

vim +/d +1614 arch/powerpc/sysdev/xive/common.c

930914b7d528fc Cédric Le Goater 2020-03-06  1594  void 
xive_debug_show_irq(struct seq_file *m, u32 hw_irq, struct irq_data *d)
930914b7d528fc Cédric Le Goater 2020-03-06  1595  {
930914b7d528fc Cédric Le Goater 2020-03-06 @1596struct irq_chip *chip = 
irq_data_get_irq_chip(d);

  ^
Dereferenced inside function

930914b7d528fc Cédric Le Goater 2020-03-06  1597int rc;
930914b7d528fc Cédric Le Goater 2020-03-06  1598u32 target;
930914b7d528fc Cédric Le Goater 2020-03-06  1599u8 prio;
930914b7d528fc Cédric Le Goater 2020-03-06  1600u32 lirq;
930914b7d528fc Cédric Le Goater 2020-03-06  1601  
930914b7d528fc Cédric Le Goater 2020-03-06  1602if (!is_xive_irq(chip))
930914b7d528fc Cédric Le Goater 2020-03-06  1603return;
930914b7d528fc Cédric Le Goater 2020-03-06  1604  
930914b7d528fc Cédric Le Goater 2020-03-06  1605rc = 
xive_ops->get_irq_config(hw_irq, &target, &prio, &lirq);
930914b7d528fc Cédric Le Goater 2020-03-06  1606if (rc) {
930914b7d528fc Cédric Le Goater 2020-03-06  1607seq_printf(m, 
"IRQ 0x%08x : no config rc=%d\n", hw_irq, rc);
930914b7d528fc Cédric Le Goater 2020-03-06  1608return;
930914b7d528fc Cédric Le Goater 2020-03-06  1609}
930914b7d528fc Cédric Le Goater 2020-03-06  1610  
930914b7d528fc Cédric Le Goater 2020-03-06  1611seq_printf(m, "IRQ 
0x%08x : target=0x%x prio=%02x lirq=0x%x ",
930914b7d528fc Cédric Le Goater 2020-03-06  1612   hw_irq, 
target, prio, lirq);
930914b7d528fc Cédric Le Goater 2020-03-06  1613  
930914b7d528fc Cédric Le Goater 2020-03-06 @1614if (d) {

Checked too late.

930914b7d528fc Cédric Le Goater 2020-03-06  1615struct 
xive_irq_data *xd = irq_data_get_irq_handler_data(d);
930914b7d528fc Cédric Le Goater 2020-03-06  1616u64 val = 
xive_esb_read(xd, XIVE_ESB_GET);
930914b7d528fc Cédric Le Goater 2020-03-06  1617  
930914b7d528fc Cédric Le Goater 2020-03-06  1618seq_printf(m, 
"flags=%c%c%c PQ=%c%c",
930914b7d528fc Cédric Le Goater 2020-03-06  1619   
xd->flags & XIVE_IRQ_FLAG_STORE_EOI ? 'S' : ' ',
930914b7d528fc Cédric Le Goater 2020-03-06  1620   
xd->flags & XIVE_IRQ_FLAG_LSI ? 'L' : ' ',
930914b7d528fc Cédric Le Goater 2020-03-06  1621   
xd->flags & XIVE_IRQ_FLAG_H_INT_ESB ? 'H' : ' ',
930914b7d528fc Cédric Le Goater 2020-03-06  1622   val 
& XIVE_ESB_VAL_P ? 'P' : '-',
930914b7d528fc Cédric Le Goater 2020-03-06  1623   val 
& XIVE_ESB_VAL_Q ? 'Q' : '-');
930914b7d528fc Cédric Le Goater 2020-03-06  1624}
930914b7d528fc Cédric Le Goater 2020-03-06  1625seq_puts(m, "\n");
930914b7d528fc Cédric Le Goater 2020-03-06  1626  }

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip

Re: [PATCH v11 0/2] UIO support for dfl devices

[Greg KH]

On Sat, Feb 27, 2021 at 10:57:33PM +0800, Xu Yilun wrote:
> Hi Greg:
> 
> On Fri, Feb 26, 2021 at 07:40:56AM +0100, Greg KH wrote:
> > On Fri, Feb 26, 2021 at 09:22:37AM +0800, Xu Yilun wrote:
> > > On Mon, Feb 22, 2021 at 10:56:45AM -0800, Tom Rix wrote:
> > > > Yilun,
> > > > 
> > > > Is there anything outstanding or remaining to be done ?
> > > 
> > > Sorry for late reply. No, this is my lastest version now.
> > > 
> > > 
> > > Hi Greg:
> > > 
> > > Do you have some comments on this patchset?
> > 
> > It's the middle of the merge window, I can't accept anything right
> > now...
> > 
> > But this doesn't even look like it is in my "to review" queue anymore,
> > which means that there must have been a lot of discussion on it and
> > others asking for changes, so why not work on that right now while you
> > can and resubmit it when you have done that?
> > 
> > No need to ever wait on me for fixing things up.
> 
> I checked the mails again and confirmed all the comments from Moritz,
> Tom and Hao are fixed. So could you help review it so it could be
> accepted in next cycle?

Please resend it, as I said above, it is no longer in my queue.

greg k-h

Re: [PATCH] x86: mark some mpspec inline functions as __init

[Arnd Bergmann]

On Fri, Feb 26, 2021 at 2:24 PM Arnd Bergmann  wrote:
>
> On Fri, Feb 26, 2021 at 9:13 AM Borislav Petkov  wrote:
> >
> > On Thu, Feb 25, 2021 at 01:58:48PM -0800, Nick Desaulniers wrote:
> > > The config that reproduces it wasn't shared here; I wouldn't be
> > > surprised if this was found via randconfig that enabled some config
> > > that led to excessive code bloat somewhere somehow.
> >
> > I'm sceptical it is the .config. As I said, those single function calls
> > which I could replace by hand - the wrappers simply make the code
> > cleaner. They could just as well be macros FWIW and then the inlining
> > will be practically forced at preprocess time.
>
> I managed to track down the configurations: This particular function is
> not inlined whenever CONFIG_UBSAN_OBJECT_SIZE is enabled
> and CONFIG_UBSAN_TRAP is disabled, plus obviously any
> configuration option that is needed to build the file.

And I now had another look at the output after reducing the test case
with cvise to:

struct b {
  void *c;
};
struct {
  struct b d;
} extern e;
int f;

__attribute__((__cold__)) int a();
static inline void early_get_smp_config() {(void) e.d.c; }

int g()
{
  if (a())
return 2;
  a();
  if (f)
return f;
  a();
  early_get_smp_config();
  return 0;
}

See https://godbolt.org/z/8qbY65

Some observations:

- The early_get_smp_config function literally does nothing in the
   reduced test case, but is still not inlined.

- This happens regardless of target architecture

- It happens in a code path of the calling function that is 'cold'
   at this point, which presumably is an indication to clang that
   any functions called from here are also cold, and not worth
   inlining.

- I have found no indication why -fsanitize=object-size should
  make a difference.

 Arnd

[PATCH v4 0/8] Fork brute force attack mitigation

[John Wood]

Attacks against vulnerable userspace applications with the purpose to break
ASLR or bypass canaries traditionally use some level of brute force with
the help of the fork system call. This is possible since when creating a
new process using fork its memory contents are the same as those of the
parent process (the process that called the fork system call). So, the
attacker can test the memory infinite times to find the correct memory
values or the correct memory addresses without worrying about crashing the
application.

Based on the above scenario it would be nice to have this detected and
mitigated, and this is the goal of this patch serie. Specifically the
following attacks are expected to be detected:

1.- Launching (fork()/exec()) a setuid/setgid process repeatedly until a
desirable memory layout is got (e.g. Stack Clash).
2.- Connecting to an exec()ing network daemon (e.g. xinetd) repeatedly
until a desirable memory layout is got (e.g. what CTFs do for simple
network service).
3.- Launching processes without exec() (e.g. Android Zygote) and exposing
state to attack a sibling.
4.- Connecting to a fork()ing network daemon (e.g. apache) repeatedly until
the previously shared memory layout of all the other children is
exposed (e.g. kind of related to HeartBleed).

In each case, a privilege boundary has been crossed:

Case 1: setuid/setgid process
Case 2: network to local
Case 3: privilege changes
Case 4: network to local

So, what will really be detected are fork/exec brute force attacks that
cross any of the commented bounds.

The implementation details and comparison against other existing
implementations can be found in the "Documentation" patch.

This v4 version has changed a lot from the v2. Basically the application
crash period is now compute on an on-going basis using an exponential
moving average (EMA), a detection of a brute force attack through the
"execve" system call has been added and the crossing of the commented
privilege bounds are taken into account. Also, the fine tune has also been
removed and now, all this kind of attacks are detected without
administrator intervention.

In the v2 version Kees Cook suggested to study if the statistical data
shared by all the fork hierarchy processes can be tracked in some other
way. Specifically the question was if this info can be hold by the family
hierarchy of the mm struct. After studying this hierarchy I think it is not
suitable for the Brute LSM since they are totally copied on fork() and in
this case we want that they are shared. So I leave this road.

So, knowing all this information I will explain now the different patches:

The 1/8 patch defines a new LSM hook to get the fatal signal of a task.
This will be useful during the attack detection phase.

The 2/8 patch defines a new LSM and manages the statistical data shared by
all the fork hierarchy processes.

The 3/8 patch detects a fork/exec brute force attack.

The 4/8 patch narrows the detection taken into account the privilege
boundary crossing.

The 5/8 patch mitigates a brute force attack.

The 6/8 patch adds self-tests to validate the Brute LSM expectations.

The 7/8 patch adds the documentation to explain this implementation.

The 8/8 patch updates the maintainers file.

This patch serie is a task of the KSPP [1] and can also be accessed from my
github tree [2] in the "brute_v4" branch.

[1] https://github.com/KSPP/linux/issues/39
[2] https://github.com/johwood/linux/

The previous versions can be found in:

RFC
https://lore.kernel.org/kernel-hardening/20200910202107.3799376-1-keesc...@chromium.org/

Version 2
https://lore.kernel.org/kernel-hardening/20201025134540.3770-1-john.w...@gmx.com/

Version 3
https://lore.kernel.org/lkml/20210221154919.68050-1-john.w...@gmx.com/

Changelog RFC -> v2
---
- Rename this feature with a more suitable name (Jann Horn, Kees Cook).
- Convert the code to an LSM (Kees Cook).
- Add locking  to avoid data races (Jann Horn).
- Add a new LSM hook to get the fatal signal of a task (Jann Horn, Kees
  Cook).
- Add the last crashes timestamps list to avoid false positives in the
  attack detection (Jann Horn).
- Use "period" instead of "rate" (Jann Horn).
- Other minor changes suggested (Jann Horn, Kees Cook).

Changelog v2 -> v3
--
- Compute the application crash period on an on-going basis (Kees Cook).
- Detect a brute force attack through the execve system call (Kees Cook).
- Detect an slow brute force attack (Randy Dunlap).
- Fine tuning the detection taken into account privilege boundary crossing
  (Kees Cook).
- Taken into account only fatal signals delivered by the kernel (Kees
  Cook).
- Remove the sysctl attributes to fine tuning the detection (Kees Cook).
- Remove the prctls to allow per process enabling/disabling (Kees Cook).
- Improve the documentation (Kees Cook).
- Fix some typos in the documentation (Randy Dunlap).
- Add self-test to validate the expectations (Kees Cook).

Changelog v3 -> v4

Re: [PATCH v8 19/22] counter: Implement extension*_name sysfs attributes

[Jonathan Cameron]

On Fri, 26 Feb 2021 08:32:59 +0900
William Breathitt Gray  wrote:

> On Sun, Feb 21, 2021 at 02:05:07PM +, Jonathan Cameron wrote:
> > On Fri, 19 Feb 2021 17:51:37 +0900
> > William Breathitt Gray  wrote:
> >   
> > > On Sun, Feb 14, 2021 at 06:09:13PM +, Jonathan Cameron wrote:  
> > > > On Fri, 12 Feb 2021 21:13:43 +0900
> > > > William Breathitt Gray  wrote:
> > > > 
> > > > > The Generic Counter chrdev interface expects users to supply extension
> > > > > IDs in order to select extensions for requests. In order for users to
> > > > > know what extension ID belongs to which extension this information 
> > > > > must
> > > > > be exposed. The extension*_name attribute provides a way for users to
> > > > > discover what extension ID belongs to which extension by reading the
> > > > > respective extension name for an extension ID.
> > > > > 
> > > > > Cc: David Lechner 
> > > > > Cc: Gwendal Grignou 
> > > > > Cc: Dan Carpenter 
> > > > > Signed-off-by: William Breathitt Gray 
> > > > > ---
> > > > >  Documentation/ABI/testing/sysfs-bus-counter |  9 
> > > > >  drivers/counter/counter-sysfs.c | 51 
> > > > > +
> > > > >  2 files changed, 50 insertions(+), 10 deletions(-)
> > > > > 
> > > > > diff --git a/Documentation/ABI/testing/sysfs-bus-counter 
> > > > > b/Documentation/ABI/testing/sysfs-bus-counter
> > > > > index 6353f0a2f8f8..847e96f19d19 100644
> > > > > --- a/Documentation/ABI/testing/sysfs-bus-counter
> > > > > +++ b/Documentation/ABI/testing/sysfs-bus-counter
> > > > > @@ -100,6 +100,15 @@ Description:
> > > > >   Read-only attribute that indicates whether excessive 
> > > > > noise is
> > > > >   present at the channel Y counter inputs.
> > > > >  
> > > > > +What:
> > > > > /sys/bus/counter/devices/counterX/countY/extensionZ_name
> > > > > +What:
> > > > > /sys/bus/counter/devices/counterX/extensionZ_name
> > > > > +What:
> > > > > /sys/bus/counter/devices/counterX/signalY/extensionZ_name
> > > > > +KernelVersion:   5.13
> > > > > +Contact: linux-...@vger.kernel.org
> > > > > +Description:
> > > > > + Read-only attribute that indicates the component name of
> > > > > + Extension Z.
> > > > 
> > > > Good to say what form this takes.
> > > 
> > > Do you mean a description like this: "Read-only string attribute that
> > > indicates the component name of Extension Z"?  
> > 
> > My expectation would be that the possible strings are tightly constrained
> > (perhaps via review). So I'd like to see what they are and a brief 
> > description
> > of what each one means.
> > 
> > Jonathan  
> 
> Okay I see what you mean now. These names will match the sysfs attribute
> filenames. So for example, if Extension 9 of Count 2 of Counter device
> is /sys/bus/counter/devices/counter4/count2/ceiling, then the attribute
> /sys/bus/counter/devices/counter4/count2/extension9_name will hold a
> value of "ceiling".
> 
> The idea is that the user walks down through each extension*_name to
> find sysfs attribute name for the Extension that they want. When they
> find the desired Extension name in say sysfs attribute extension9_name,
> then they know 9 is the ID number for that Extension.
> 
> There is an alternative design I was considering: instead of
> extension*_name attributes, we could have each Extension sysfs attribute
> have a matching *_extension_id attribute which provides the respective
> Extension ID. So for example, using the same Extension as before:
> /sys/bus/counter/devices/counter4/count2/ceiling_extension_id will hold
> a value of 9.
> 
> Do you think this alternative design would be more intuitive to users?
It feels like the user is going to start from what they want to enable
then get the ID from that.   With the current way around they'll have
to search the extensionX_name files to find it, rather than a direct
look up.  So immediate thought is this second way would be easier to
use, but perhaps others think differently.

Jonathan

> 
> William Breathitt Gray

Re: [PATCH v8 20/22] counter: Implement events_queue_size sysfs attribute

[Jonathan Cameron]

On Fri, 26 Feb 2021 09:03:48 +0900
William Breathitt Gray  wrote:

> On Sun, Feb 21, 2021 at 03:51:40PM +, Jonathan Cameron wrote:
> > On Thu, 18 Feb 2021 19:32:16 +0900
> > William Breathitt Gray  wrote:
> >   
> > > On Sun, Feb 14, 2021 at 06:11:46PM +, Jonathan Cameron wrote:  
> > > > On Fri, 12 Feb 2021 21:13:44 +0900
> > > > William Breathitt Gray  wrote:
> > > > 
> > > > > The events_queue_size sysfs attribute provides a way for users to
> > > > > dynamically configure the Counter events queue size for the Counter
> > > > > character device interface. The size is in number of struct
> > > > > counter_event data structures. The number of elements will be 
> > > > > rounded-up
> > > > > to a power of 2 due to a requirement of the kfifo_alloc function 
> > > > > called
> > > > > during reallocation of the queue.
> > > > > 
> > > > > Cc: Oleksij Rempel 
> > > > > Signed-off-by: William Breathitt Gray 
> > > > > ---
> > > > >  Documentation/ABI/testing/sysfs-bus-counter |  8 +++
> > > > >  drivers/counter/counter-chrdev.c| 23 +++
> > > > >  drivers/counter/counter-chrdev.h|  2 ++
> > > > >  drivers/counter/counter-sysfs.c | 25 
> > > > > +
> > > > >  4 files changed, 58 insertions(+)
> > > > > 
> > > > > diff --git a/Documentation/ABI/testing/sysfs-bus-counter 
> > > > > b/Documentation/ABI/testing/sysfs-bus-counter
> > > > > index 847e96f19d19..f6cb2a8b08a7 100644
> > > > > --- a/Documentation/ABI/testing/sysfs-bus-counter
> > > > > +++ b/Documentation/ABI/testing/sysfs-bus-counter
> > > > > @@ -212,6 +212,14 @@ Description:
> > > > >   both edges:
> > > > >   Any state transition.
> > > > >  
> > > > > +What:
> > > > > /sys/bus/counter/devices/counterX/events_queue_size
> > > > > +KernelVersion:   5.13
> > > > > +Contact: linux-...@vger.kernel.org
> > > > > +Description:
> > > > > + Size of the Counter events queue in number of struct
> > > > > + counter_event data structures. The number of elements 
> > > > > will be
> > > > > + rounded-up to a power of 2.
> > > > > +
> > > > >  What:/sys/bus/counter/devices/counterX/name
> > > > >  KernelVersion:   5.2
> > > > >  Contact: linux-...@vger.kernel.org
> > > > > diff --git a/drivers/counter/counter-chrdev.c 
> > > > > b/drivers/counter/counter-chrdev.c
> > > > > index 16f02df7f73d..53eea894e13f 100644
> > > > > --- a/drivers/counter/counter-chrdev.c
> > > > > +++ b/drivers/counter/counter-chrdev.c
> > > > > @@ -375,6 +375,29 @@ void counter_chrdev_remove(struct counter_device 
> > > > > *const counter)
> > > > >   cdev_del(&counter->chrdev);
> > > > >  }
> > > > >  
> > > > > +int counter_chrdev_realloc_queue(struct counter_device *const 
> > > > > counter,
> > > > > +  size_t queue_size)
> > > > > +{
> > > > > + int err;
> > > > > + DECLARE_KFIFO_PTR(events, struct counter_event);
> > > > > + unsigned long flags;
> > > > > +
> > > > > + /* Allocate new events queue */
> > > > > + err = kfifo_alloc(&events, queue_size, GFP_ATOMIC);
> > > > 
> > > > Is there any potential for losing events?
> > > 
> > > We take the events_list_lock down below so we're safe against missing an
> > > event, but past events currently unread in the queue will be lost.
> > > 
> > > Shortening the size of the queue is inherently a destructive process if
> > > we have more events in the current queue than can fit in the new queue.
> > > Because we a liable to lose some events in such a case, I think it's
> > > best to keep the behavior of this reallocation consistent and have it
> > > provide a fresh empty queue every time, as opposed to sometimes dropping
> > > events and sometimes not.
> > > 
> > > I also suspect an actual user would be setting the size of their queue
> > > to the required amount before they begin watching events, rather than
> > > adjusting it sporadically during a live operation.
> > >  
> > 
> > Absolutely agree.   As such I wonder if you are better off enforcing this
> > behaviour?  If the cdev is open for reading, don't allow the fifo to be
> > resized. 
> > 
> > Jonathan  
> 
> I can't really think of a good reason not to, so let's enforce it: if
> the cdev is open, then we'll return an EINVAL if the user attempts to
> resize the queue.
> 
> What is a good way to check for this condition? Should I just call
> kref_read() and see if it's greater than 1? For example, in
> counter_chrdev_realloc_queue():
> 
>   if (kref_read(&counter->dev.kobj.kref) > 1)
>   return -EINVAL;
In theory at least you might want the kobj.kref to be incremented
for other reasons than just open.   So to keep different concepts
separate, perhaps it's worth a separate variable somewhere to
track whether the file is open currently.

However, it's reasonable (I think) to assume the kref will have a
minimum value

WARNING: modpost: vmlinux.o(.text.unlikely+0x23ac): Section mismatch in reference from the function highmem_setup() to the function .meminit.text:memblock_is_reserved()

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   3fb6d0e00efc958d01c2f109c8453033a2d96796
commit: a0cd7a7c4bc004587d1f4785a320f58e72d880eb mm: simplify 
free_highmem_page() and free_reserved_page()
date:   3 days ago
config: microblaze-randconfig-r006-20210226 (attached as .config)
compiler: microblaze-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a0cd7a7c4bc004587d1f4785a320f58e72d880eb
git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout a0cd7a7c4bc004587d1f4785a320f58e72d880eb
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=microblaze 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>, old ones prefixed by <<):

>> WARNING: modpost: vmlinux.o(.text.unlikely+0x23ac): Section mismatch in 
>> reference from the function highmem_setup() to the function 
>> .meminit.text:memblock_is_reserved()
The function highmem_setup() references
the function __meminit memblock_is_reserved().
This is often because highmem_setup lacks a __meminit
annotation or the annotation of memblock_is_reserved is wrong.

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip

Re: [PATCH v4 3/5] arm64: dts: imx8mm: Add Engicam i.Core MX8M Mini C.TOUCH 2.0

[Krzysztof Kozlowski]

On Fri, Feb 26, 2021 at 12:54:02AM +0530, Jagan Teki wrote:
> Engicam C.TOUCH 2.0 is an EDIMM compliant general purpose Carrier
> board.
> 
> Genaral features:
> - Ethernet 10/100
> - Wifi/BT
> - USB Type A/OTG
> - Audio Out
> - CAN
> - LVDS panel connector
> 
> i.Core MX8M Mini is an EDIMM SoM based on NXP i.MX8M Mini from Engicam.
> 
> i.Core MX8M Mini needs to mount on top of this Carrier board for
> creating complete i.Core MX8M Mini C.TOUCH 2.0 board.
> 
> Add support for it.
> 
> Signed-off-by: Matteo Lisi 
> Signed-off-by: Jagan Teki 
> ---

Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof
> + };
> +};
> +
> +&uart2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_uart2>;
> + status = "okay";
> +};
> +
> +/* SD */
> +&usdhc1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usdhc1>, <&pinctrl_usdhc1_gpio>;
> + cd-gpios = <&gpio1 6 GPIO_ACTIVE_LOW>;
> + max-frequency = <5000>;
> + bus-width = <4>;
> + no-1-8-v;
> + pm-ignore-notify;
> + keep-power-in-suspend;
> + status = "okay";
> +};
> -- 
> 2.25.1
> 

Re: [PATCH v4 4/5] dt-bindings: arm: fsl: Add Engicam i.Core MX8M Mini EDIMM2.2 Starter Kit

[Krzysztof Kozlowski]

On Fri, Feb 26, 2021 at 12:54:03AM +0530, Jagan Teki wrote:
> i.Core MX8M Mini is an EDIMM SoM based on NXP i.MX8M Mini from Engicam.
> 
> EDIMM2.2 Starter Kit is an EDIMM 2.2 Form Factor Capacitive Evaluation
> Board from Engicam.
> 
> i.Core MX8M Mini needs to mount on top of this Evaluation board for
> creating complete i.Core MX8M Mini EDIMM2.2 Starter Kit.
> 
> Add bindings for it.
> 
> Signed-off-by: Jagan Teki 
> Acked-by: Rob Herring 
> ---
> Changes for v4:
> - collect ack's
> Changes for v3:
> - fix dt-bindings
> Changes for v2:
> - update commit message
> 
>  Documentation/devicetree/bindings/arm/fsl.yaml | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 

Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

[RESEND PATCH v11 0/2] UIO support for dfl devices

[Xu Yilun]

This patchset supports some dfl device drivers written in userspace.

In the patchset v1, the "driver_override" interface should be used to bind
the DFL UIO driver to DFL devices. But there is concern that the
"driver_override" interface is not OK itself.

In v2, we use a new matching algorithem. The "driver_override" interface
is abandoned, the DFL UIO driver matches any DFL device which could not be
handled by other DFL drivers. So the DFL UIO driver could be used for new
DFL devices which are not supported by kernel. The concern is the UIO may
not be suitable as a default/generic driver for all dfl features, such as
features with multiple interrupts.

In v4, we specify each matching device in the id_table of the UIO driver,
just the same as other dfl drivers do. Now the UIO driver supports Ether
Group feature. To support more DFL features, their feature ids should be
added to the driver's id_table.

Before v9, we create a "uio_pdrv_genirq" platform device using DFL devices'
resources. Then we leverage the uio_pdrv_genirq driver for UIO support. It
is suggested that we implement a driver in drivers/uio that directly calls
UIO framework APIs. So we implement the uio_dfl driver in v9. The driver
now only binds the ether group feature, which has no irq. So the irq
support is not implemented yet.


Main changes from v1:
- switch to the new matching algorithem. It matches DFL devices which could
  not be handled by other DFL drivers.
- refacor the code about device resources filling.
- add the documentation.

Main changes from v2:
- split the match ops changes in dfl.c to an independent patch.
- move the declarations needed for dfl-uio-pdev from include/linux/dfl.h
  to driver/fpga/dfl.h
- some minor fixes.

Main changes from v3:
- switch to specifying each matching device in the driver's id_table.
- refactor the irq handling code.

Main changes from v4:
- refactor the irq handling code.

Main changes from v5:
- fix the res[] zero initialization issue.
- improve the return code for probe().
- some doc improvement.

Main changes from v6:
- use platform_device_register_resndata() for pdev creation.

Main changes from v7:
- some doc fixes.

Main changes from v8:
- switch to add a uio driver in drivers/uio

Main changes from v9:
- add this source file in MAINTAINERS
- improve the Kconfig, add more descriptive Kconfig header, add detailed
  path for opae uio example in Kconfig.

Main changes from v10:
- add description in doc that interrupt support is not implemented yet.


Xu Yilun (2):
  uio: uio_dfl: add userspace i/o driver for DFL bus
  Documentation: fpga: dfl: Add description for DFL UIO support

 Documentation/fpga/dfl.rst | 26 ++
 MAINTAINERS|  1 +
 drivers/uio/Kconfig| 17 
 drivers/uio/Makefile   |  1 +
 drivers/uio/uio_dfl.c  | 66 ++
 5 files changed, 111 insertions(+)
 create mode 100644 drivers/uio/uio_dfl.c

-- 
2.7.4

[RESEND PATCH v11 2/2] Documentation: fpga: dfl: Add description for DFL UIO support

[Xu Yilun]

This patch adds description for UIO support for dfl devices on DFL
bus.

Signed-off-by: Xu Yilun 
Reviewed-by: Tom Rix 
Reviewed-by: Wu Hao 
---
v2: no doc in v1, add it for v2.
v3: some documentation fixes.
v4: documentation change since the driver matching is changed.
v5: no change.
v6: improve the title of the userspace driver support section.
some word improvement.
v7: rebased to next-20210119
v8: some doc fixes.
v9: some doc change since we switch to the driver in drivers/uio.
v10: no change.
v11: add description that interrupt support is not implemented yet.
---
 Documentation/fpga/dfl.rst | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/Documentation/fpga/dfl.rst b/Documentation/fpga/dfl.rst
index c41ac76..f3a1223 100644
--- a/Documentation/fpga/dfl.rst
+++ b/Documentation/fpga/dfl.rst
@@ -7,6 +7,7 @@ Authors:
 - Enno Luebbers 
 - Xiao Guangrong 
 - Wu Hao 
+- Xu Yilun 
 
 The Device Feature List (DFL) FPGA framework (and drivers according to
 this framework) hides the very details of low layer hardwares and provides
@@ -530,6 +531,31 @@ Being able to specify more than one DFL per BAR has been 
considered, but it
 was determined the use case did not provide value.  Specifying a single DFL
 per BAR simplifies the implementation and allows for extra error checking.
 
+
+Userspace driver support for DFL devices
+
+The purpose of an FPGA is to be reprogrammed with newly developed hardware
+components. New hardware can instantiate a new private feature in the DFL, and
+then present a DFL device in the system. In some cases users may need a
+userspace driver for the DFL device:
+
+* Users may need to run some diagnostic test for their hardware.
+* Users may prototype the kernel driver in user space.
+* Some hardware is designed for specific purposes and does not fit into one of
+  the standard kernel subsystems.
+
+This requires direct access to MMIO space and interrupt handling from
+userspace. The uio_dfl module exposes the UIO device interfaces for this
+purpose.
+
+Currently the uio_dfl driver only supports the Ether Group sub feature, which
+has no irq in hardware. So the interrupt handling is not added in this driver.
+
+UIO_DFL should be selected to enable the uio_dfl module driver. To support a
+new DFL feature via UIO direct access, its feature id should be added to the
+driver's id_table.
+
+
 Open discussion
 ===
 FME driver exports one ioctl (DFL_FPGA_FME_PORT_PR) for partial reconfiguration
-- 
2.7.4

[PATCH v5 0/8] Fork brute force attack mitigation

[John Wood]

Attacks against vulnerable userspace applications with the purpose to break
ASLR or bypass canaries traditionally use some level of brute force with
the help of the fork system call. This is possible since when creating a
new process using fork its memory contents are the same as those of the
parent process (the process that called the fork system call). So, the
attacker can test the memory infinite times to find the correct memory
values or the correct memory addresses without worrying about crashing the
application.

Based on the above scenario it would be nice to have this detected and
mitigated, and this is the goal of this patch serie. Specifically the
following attacks are expected to be detected:

1.- Launching (fork()/exec()) a setuid/setgid process repeatedly until a
desirable memory layout is got (e.g. Stack Clash).
2.- Connecting to an exec()ing network daemon (e.g. xinetd) repeatedly
until a desirable memory layout is got (e.g. what CTFs do for simple
network service).
3.- Launching processes without exec() (e.g. Android Zygote) and exposing
state to attack a sibling.
4.- Connecting to a fork()ing network daemon (e.g. apache) repeatedly until
the previously shared memory layout of all the other children is
exposed (e.g. kind of related to HeartBleed).

In each case, a privilege boundary has been crossed:

Case 1: setuid/setgid process
Case 2: network to local
Case 3: privilege changes
Case 4: network to local

So, what will really be detected are fork/exec brute force attacks that
cross any of the commented bounds.

The implementation details and comparison against other existing
implementations can be found in the "Documentation" patch.

This v5 version has changed a lot from the v2. Basically the application
crash period is now compute on an on-going basis using an exponential
moving average (EMA), a detection of a brute force attack through the
"execve" system call has been added and the crossing of the commented
privilege bounds are taken into account. Also, the fine tune has also been
removed and now, all this kind of attacks are detected without
administrator intervention.

In the v2 version Kees Cook suggested to study if the statistical data
shared by all the fork hierarchy processes can be tracked in some other
way. Specifically the question was if this info can be hold by the family
hierarchy of the mm struct. After studying this hierarchy I think it is not
suitable for the Brute LSM since they are totally copied on fork() and in
this case we want that they are shared. So I leave this road.

So, knowing all this information I will explain now the different patches:

The 1/8 patch defines a new LSM hook to get the fatal signal of a task.
This will be useful during the attack detection phase.

The 2/8 patch defines a new LSM and manages the statistical data shared by
all the fork hierarchy processes.

The 3/8 patch detects a fork/exec brute force attack.

The 4/8 patch narrows the detection taken into account the privilege
boundary crossing.

The 5/8 patch mitigates a brute force attack.

The 6/8 patch adds self-tests to validate the Brute LSM expectations.

The 7/8 patch adds the documentation to explain this implementation.

The 8/8 patch updates the maintainers file.

This patch serie is a task of the KSPP [1] and can also be accessed from my
github tree [2] in the "brute_v4" branch.

[1] https://github.com/KSPP/linux/issues/39
[2] https://github.com/johwood/linux/

The previous versions can be found in:

RFC
https://lore.kernel.org/kernel-hardening/20200910202107.3799376-1-keesc...@chromium.org/

Version 2
https://lore.kernel.org/kernel-hardening/20201025134540.3770-1-john.w...@gmx.com/

Version 3
https://lore.kernel.org/lkml/20210221154919.68050-1-john.w...@gmx.com/

Version 4
https://lore.kernel.org/lkml/20210227150956.6022-1-john.w...@gmx.com/

Changelog RFC -> v2
---
- Rename this feature with a more suitable name (Jann Horn, Kees Cook).
- Convert the code to an LSM (Kees Cook).
- Add locking  to avoid data races (Jann Horn).
- Add a new LSM hook to get the fatal signal of a task (Jann Horn, Kees
  Cook).
- Add the last crashes timestamps list to avoid false positives in the
  attack detection (Jann Horn).
- Use "period" instead of "rate" (Jann Horn).
- Other minor changes suggested (Jann Horn, Kees Cook).

Changelog v2 -> v3
--
- Compute the application crash period on an on-going basis (Kees Cook).
- Detect a brute force attack through the execve system call (Kees Cook).
- Detect an slow brute force attack (Randy Dunlap).
- Fine tuning the detection taken into account privilege boundary crossing
  (Kees Cook).
- Taken into account only fatal signals delivered by the kernel (Kees
  Cook).
- Remove the sysctl attributes to fine tuning the detection (Kees Cook).
- Remove the prctls to allow per process enabling/disabling (Kees Cook).
- Improve the documentation (Kees Cook).
- Fix some typos in the documentation (Randy Dunlap

[RESEND PATCH v11 1/2] uio: uio_dfl: add userspace i/o driver for DFL bus

[Xu Yilun]

This patch supports the DFL drivers be written in userspace. This is
realized by exposing the userspace I/O device interfaces.

The driver now only binds the ether group feature, which has no irq. So
the irq support is not implemented yet.

Signed-off-by: Xu Yilun 
Reviewed-by: Tom Rix 
---
v9: switch to add a uio driver in drivers/uio
v10: add the source file in MAINTAINERS
 more descriptive Kconfig header
 add detailed path for opae uio example
v11: no change
---
 MAINTAINERS   |  1 +
 drivers/uio/Kconfig   | 17 +
 drivers/uio/Makefile  |  1 +
 drivers/uio/uio_dfl.c | 66 +++
 4 files changed, 85 insertions(+)
 create mode 100644 drivers/uio/uio_dfl.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 000fe0b..4dc0354 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6943,6 +6943,7 @@ S:Maintained
 F: Documentation/ABI/testing/sysfs-bus-dfl*
 F: Documentation/fpga/dfl.rst
 F: drivers/fpga/dfl*
+F: drivers/uio/uio_dfl.c
 F: include/linux/dfl.h
 F: include/uapi/linux/fpga-dfl.h
 
diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
index 202ee81..5531f3a 100644
--- a/drivers/uio/Kconfig
+++ b/drivers/uio/Kconfig
@@ -165,4 +165,21 @@ config UIO_HV_GENERIC
  to network and storage devices from userspace.
 
  If you compile this as a module, it will be called uio_hv_generic.
+
+config UIO_DFL
+   tristate "Generic driver for DFL (Device Feature List) bus"
+   depends on FPGA_DFL
+   help
+ Generic DFL (Device Feature List) driver for Userspace I/O devices.
+ It is useful to provide direct access to DFL devices from userspace.
+ A sample userspace application using this driver is available for
+ download in a git repository:
+
+   git clone https://github.com/OPAE/opae-sdk.git
+
+ It could be found at:
+
+   opae-sdk/tools/libopaeuio/
+
+ If you compile this as a module, it will be called uio_dfl.
 endif
diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile
index c285dd2..f2f416a1 100644
--- a/drivers/uio/Makefile
+++ b/drivers/uio/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_UIO_PRUSS) += uio_pruss.o
 obj-$(CONFIG_UIO_MF624) += uio_mf624.o
 obj-$(CONFIG_UIO_FSL_ELBC_GPCM)+= uio_fsl_elbc_gpcm.o
 obj-$(CONFIG_UIO_HV_GENERIC)   += uio_hv_generic.o
+obj-$(CONFIG_UIO_DFL)  += uio_dfl.o
diff --git a/drivers/uio/uio_dfl.c b/drivers/uio/uio_dfl.c
new file mode 100644
index 000..89c0fc7
--- /dev/null
+++ b/drivers/uio/uio_dfl.c
@@ -0,0 +1,66 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Generic DFL driver for Userspace I/O devicess
+ *
+ * Copyright (C) 2021 Intel Corporation, Inc.
+ */
+#include 
+#include 
+#include 
+#include 
+
+#define DRIVER_NAME "uio_dfl"
+
+static int uio_dfl_probe(struct dfl_device *ddev)
+{
+   struct resource *r = &ddev->mmio_res;
+   struct device *dev = &ddev->dev;
+   struct uio_info *uioinfo;
+   struct uio_mem *uiomem;
+   int ret;
+
+   uioinfo = devm_kzalloc(dev, sizeof(struct uio_info), GFP_KERNEL);
+   if (!uioinfo)
+   return -ENOMEM;
+
+   uioinfo->name = DRIVER_NAME;
+   uioinfo->version = "0";
+
+   uiomem = &uioinfo->mem[0];
+   uiomem->memtype = UIO_MEM_PHYS;
+   uiomem->addr = r->start & PAGE_MASK;
+   uiomem->offs = r->start & ~PAGE_MASK;
+   uiomem->size = (uiomem->offs + resource_size(r)
+   + PAGE_SIZE - 1) & PAGE_MASK;
+   uiomem->name = r->name;
+
+   /* Irq is yet to be supported */
+   uioinfo->irq = UIO_IRQ_NONE;
+
+   ret = devm_uio_register_device(dev, uioinfo);
+   if (ret)
+   dev_err(dev, "unable to register uio device\n");
+
+   return ret;
+}
+
+#define FME_FEATURE_ID_ETH_GROUP   0x10
+
+static const struct dfl_device_id uio_dfl_ids[] = {
+   { FME_ID, FME_FEATURE_ID_ETH_GROUP },
+   { }
+};
+MODULE_DEVICE_TABLE(dfl, uio_dfl_ids);
+
+static struct dfl_driver uio_dfl_driver = {
+   .drv = {
+   .name = DRIVER_NAME,
+   },
+   .id_table   = uio_dfl_ids,
+   .probe  = uio_dfl_probe,
+};
+module_dfl_driver(uio_dfl_driver);
+
+MODULE_DESCRIPTION("Generic DFL driver for Userspace I/O devices");
+MODULE_AUTHOR("Intel Corporation");
+MODULE_LICENSE("GPL v2");
-- 
2.7.4

Re: [RESEND PATCH v11 1/2] uio: uio_dfl: add userspace i/o driver for DFL bus

[Greg KH]

On Sat, Feb 27, 2021 at 11:27:03PM +0800, Xu Yilun wrote:
> This patch supports the DFL drivers be written in userspace. This is
> realized by exposing the userspace I/O device interfaces.
> 
> The driver now only binds the ether group feature, which has no irq. So
> the irq support is not implemented yet.
> 
> Signed-off-by: Xu Yilun 
> Reviewed-by: Tom Rix 
> ---
> v9: switch to add a uio driver in drivers/uio
> v10: add the source file in MAINTAINERS
>  more descriptive Kconfig header
>  add detailed path for opae uio example
> v11: no change
> ---
>  MAINTAINERS   |  1 +
>  drivers/uio/Kconfig   | 17 +
>  drivers/uio/Makefile  |  1 +
>  drivers/uio/uio_dfl.c | 66 
> +++
>  4 files changed, 85 insertions(+)
>  create mode 100644 drivers/uio/uio_dfl.c
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 000fe0b..4dc0354 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6943,6 +6943,7 @@ S:  Maintained
>  F:   Documentation/ABI/testing/sysfs-bus-dfl*
>  F:   Documentation/fpga/dfl.rst
>  F:   drivers/fpga/dfl*
> +F:   drivers/uio/uio_dfl.c
>  F:   include/linux/dfl.h
>  F:   include/uapi/linux/fpga-dfl.h
>  
> diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
> index 202ee81..5531f3a 100644
> --- a/drivers/uio/Kconfig
> +++ b/drivers/uio/Kconfig
> @@ -165,4 +165,21 @@ config UIO_HV_GENERIC
> to network and storage devices from userspace.
>  
> If you compile this as a module, it will be called uio_hv_generic.
> +
> +config UIO_DFL
> + tristate "Generic driver for DFL (Device Feature List) bus"
> + depends on FPGA_DFL
> + help
> +   Generic DFL (Device Feature List) driver for Userspace I/O devices.
> +   It is useful to provide direct access to DFL devices from userspace.
> +   A sample userspace application using this driver is available for
> +   download in a git repository:
> +
> + git clone https://github.com/OPAE/opae-sdk.git
> +
> +   It could be found at:
> +
> + opae-sdk/tools/libopaeuio/
> +
> +   If you compile this as a module, it will be called uio_dfl.
>  endif
> diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile
> index c285dd2..f2f416a1 100644
> --- a/drivers/uio/Makefile
> +++ b/drivers/uio/Makefile
> @@ -11,3 +11,4 @@ obj-$(CONFIG_UIO_PRUSS) += uio_pruss.o
>  obj-$(CONFIG_UIO_MF624) += uio_mf624.o
>  obj-$(CONFIG_UIO_FSL_ELBC_GPCM)  += uio_fsl_elbc_gpcm.o
>  obj-$(CONFIG_UIO_HV_GENERIC) += uio_hv_generic.o
> +obj-$(CONFIG_UIO_DFL)+= uio_dfl.o
> diff --git a/drivers/uio/uio_dfl.c b/drivers/uio/uio_dfl.c
> new file mode 100644
> index 000..89c0fc7
> --- /dev/null
> +++ b/drivers/uio/uio_dfl.c
> @@ -0,0 +1,66 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Generic DFL driver for Userspace I/O devicess
> + *
> + * Copyright (C) 2021 Intel Corporation, Inc.
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define DRIVER_NAME "uio_dfl"
> +
> +static int uio_dfl_probe(struct dfl_device *ddev)
> +{
> + struct resource *r = &ddev->mmio_res;
> + struct device *dev = &ddev->dev;
> + struct uio_info *uioinfo;
> + struct uio_mem *uiomem;
> + int ret;
> +
> + uioinfo = devm_kzalloc(dev, sizeof(struct uio_info), GFP_KERNEL);
> + if (!uioinfo)
> + return -ENOMEM;
> +
> + uioinfo->name = DRIVER_NAME;
> + uioinfo->version = "0";
> +
> + uiomem = &uioinfo->mem[0];
> + uiomem->memtype = UIO_MEM_PHYS;
> + uiomem->addr = r->start & PAGE_MASK;
> + uiomem->offs = r->start & ~PAGE_MASK;
> + uiomem->size = (uiomem->offs + resource_size(r)
> + + PAGE_SIZE - 1) & PAGE_MASK;
> + uiomem->name = r->name;
> +
> + /* Irq is yet to be supported */
> + uioinfo->irq = UIO_IRQ_NONE;
> +
> + ret = devm_uio_register_device(dev, uioinfo);
> + if (ret)
> + dev_err(dev, "unable to register uio device\n");
> +
> + return ret;
> +}
> +
> +#define FME_FEATURE_ID_ETH_GROUP 0x10

Why are you saying that an ethernet driver should be using the UIO
interface?

And why can't you use the existing UIO drivers that bind to memory
regions specified by firmware?  Without an interrupt being used, why is
UIO needed at all?

thanks,

greg k-h

Re: [PATCH v2 5/5] iio: dac: ad5686: Add PWM as a trigger source

[Jonathan Cameron]

On Tue, 23 Feb 2021 17:37:40 +0100
Lars-Peter Clausen  wrote:

> On 2/18/21 3:05 PM, Jonathan Cameron wrote:
> > On Wed, 17 Feb 2021 10:34:38 +0200
> > Alexandru Ardelean  wrote:
> >  
> >> From: Mircea Caprioru 
> >>
> >> A PWM signal will be used as a trigger source to have a deterministic
> >> sampling frequency since this family of DAC has no hardware interrupt
> >> source.
> >>
> >> This feature is made optional however, as there are some board setups where
> >> this isn't used.
> >>  
> > So this is taking a very generic setup, but then implementing it
> > as a bit of a hack within the driver.
> >
> > It's effectively a PWM connected up to an instance
> > of iio/triggers/iio-trig-interrupt.c
> >
> > Now, I've not looked at that trigger driver for a while, so you may well
> > need to figure out how to add a binding to instantiate it.
> > (looks like no one has used it since board file days, or via instantiation
> > from another driver).
> >
> > It's a slightly odd corner case as what it reflects is that we have
> > an interrupt available that is intended to drive some sort of data
> > capture or output (it's a trigger signal) - but exactly what is done
> > is a runtime configurable.  In this particular case that interrupt
> > is hooked up to a PWM and we also want to represent that.
> >
> > The fact it's being driven via a PWM is interesting but we should be
> > able to extend that trigger driver to optionally accept a pwm provider
> > and if it has one provide frequency control.
> >
> > Binding might look something like the following..
> >
> > interrupt-trigger {
> > interrupts = <>;
> > pwms = <&pwm 0 4000 PWM_POLARITY_INVERTED>; 
> > };
> >
> > @Rob, what do you think of this odd beast?
> >
> > So all in all, this generic facility needs a generic implementation, not
> > one buried in a driver.
> >
> > Another open question here is whether you really can't just use an hrtimer
> > to get similar precision?  Way back at the dawn of time in IIO we had
> > code to use the RTC periodic ticks as a trigger with the theory that they
> > would give very precise and even timing.  In the end it turned out that
> > hrtimers worked just as well (and RTCs drivers emulated the periodic
> > ticks via hrtimers, dropping their use of the hardware periodic timers).
> >  
> The way this DAC works is that it has a "latch" pin and some shadow 
> registers. The way this is supposed to be used is that you update the 
> shadow registers and then when the there is a rising edge on the latch 
> pin all the shadow register values are transferred to DAC output registers.
> 
> This means if you hook up a periodic signal like a PWM or clock to the 
> latch pin you can generate very precise waveforms that have much lower 
> jitter than when using a hrtimer since there is no variable interrupt 
> latency for the update step itself. This is useful when generating 
> periodic signals.
> 
> But you could for example also use a GPIO to update multiple discrete 
> DACs at the same time.
> 
> This is not specific to this particular chip. There are quite a few ADI 
> (and probably from other vendors) precision DACs that have this 
> functionality. I agree that this should be a some sort of generic 
> trigger helper module.
> 
> Now for the implementation since there is a direct connection between 
> the PWM and the DAC I think it makes sense to describe this connection 
> in the DT. After all if there is no connection this will not work.

Thanks for the detailed description. That makes a lot more sense. 

This is some sort of hybrid of the hardware internal triggers
we have for some SoC ADCs and wiring up a gpio pin to trigger the latch
signal.   PWM is one valid way of wiring it up (possibly most sensible
one), but not necessarily the only one.
I guess the one behind element is also a bit non intuitive (data is
put in place on previous interrupt / edge but latched on the next
one)

Hmm. If we makes sure the binding is cleanly defined, we could do
a driver specific implementation for now, with the option to figure
something else out later.

Exactly how to do this needs some thought...
+ lifting this description of hot it works into the patch description
would help :)

Jonathan

> 
> As for the interrupt, most PWM controllers do have the ability to 
> generate an IRQ by themselves once per period. There should be not need 
> for a hardware loopback. Unfortunately the PWM framework does not have a 
> mechanism yet to expose those IRQs and register a callback.
> 
> A similar feature btw exists for many of the ADCs and we did have this 
> special Blackfin PWM trigger[1] back in the day to support this. The 
> bfin PWM trigger driver essentially implements what I'm describing 
> above, but without using the PWM framework.



> 
> - Lars
> 
> [1] 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/iio/trigger/iio-trig-bfin-timer.c?h=v3.15
> 

[PATCH v5 1/8] security: Add LSM hook at the point where a task gets a fatal signal

[John Wood]

Add a security hook that allows a LSM to be notified when a task gets a
fatal signal. This patch is a previous step on the way to compute the
task crash period by the "brute" LSM (linux security module to detect
and mitigate fork brute force attack against vulnerable userspace
processes).

Signed-off-by: John Wood 
---
 include/linux/lsm_hook_defs.h | 1 +
 include/linux/lsm_hooks.h | 4 
 include/linux/security.h  | 4 
 kernel/signal.c   | 1 +
 security/security.c   | 5 +
 5 files changed, 15 insertions(+)

diff --git a/include/linux/lsm_hook_defs.h b/include/linux/lsm_hook_defs.h
index 477a597db013..0208df0955fa 100644
--- a/include/linux/lsm_hook_defs.h
+++ b/include/linux/lsm_hook_defs.h
@@ -220,6 +220,7 @@ LSM_HOOK(int, -ENOSYS, task_prctl, int option, unsigned 
long arg2,
 unsigned long arg3, unsigned long arg4, unsigned long arg5)
 LSM_HOOK(void, LSM_RET_VOID, task_to_inode, struct task_struct *p,
 struct inode *inode)
+LSM_HOOK(void, LSM_RET_VOID, task_fatal_signal, const kernel_siginfo_t 
*siginfo)
 LSM_HOOK(int, 0, ipc_permission, struct kern_ipc_perm *ipcp, short flag)
 LSM_HOOK(void, LSM_RET_VOID, ipc_getsecid, struct kern_ipc_perm *ipcp,
 u32 *secid)
diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index fb7f3193753d..beedaa6ee745 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -784,6 +784,10 @@
  * security attributes, e.g. for /proc/pid inodes.
  * @p contains the task_struct for the task.
  * @inode contains the inode structure for the inode.
+ * @task_fatal_signal:
+ * This hook allows security modules to be notified when a task gets a
+ * fatal signal.
+ * @siginfo contains the signal information.
  *
  * Security hooks for Netlink messaging.
  *
diff --git a/include/linux/security.h b/include/linux/security.h
index 8aeebd6646dc..e4025a13630f 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -430,6 +430,7 @@ int security_task_kill(struct task_struct *p, struct 
kernel_siginfo *info,
 int security_task_prctl(int option, unsigned long arg2, unsigned long arg3,
unsigned long arg4, unsigned long arg5);
 void security_task_to_inode(struct task_struct *p, struct inode *inode);
+void security_task_fatal_signal(const kernel_siginfo_t *siginfo);
 int security_ipc_permission(struct kern_ipc_perm *ipcp, short flag);
 void security_ipc_getsecid(struct kern_ipc_perm *ipcp, u32 *secid);
 int security_msg_msg_alloc(struct msg_msg *msg);
@@ -1165,6 +1166,9 @@ static inline int security_task_prctl(int option, 
unsigned long arg2,
 static inline void security_task_to_inode(struct task_struct *p, struct inode 
*inode)
 { }

+static inline void security_task_fatal_signal(const kernel_siginfo_t *siginfo)
+{ }
+
 static inline int security_ipc_permission(struct kern_ipc_perm *ipcp,
  short flag)
 {
diff --git a/kernel/signal.c b/kernel/signal.c
index 5ad8566534e7..893c07a77c76 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -2750,6 +2750,7 @@ bool get_signal(struct ksignal *ksig)
/*
 * Anything else is fatal, maybe with a core dump.
 */
+   security_task_fatal_signal(&ksig->info);
current->flags |= PF_SIGNALED;

if (sig_kernel_coredump(signr)) {
diff --git a/security/security.c b/security/security.c
index 5ac96b16f8fa..d9cf653a4e70 100644
--- a/security/security.c
+++ b/security/security.c
@@ -1840,6 +1840,11 @@ void security_task_to_inode(struct task_struct *p, 
struct inode *inode)
call_void_hook(task_to_inode, p, inode);
 }

+void security_task_fatal_signal(const kernel_siginfo_t *siginfo)
+{
+   call_void_hook(task_fatal_signal, siginfo);
+}
+
 int security_ipc_permission(struct kern_ipc_perm *ipcp, short flag)
 {
return call_int_hook(ipc_permission, 0, ipcp, flag);
--
2.25.1

Re: [PATCH] iio: accel: mma8452: fix indentation

[Jonathan Cameron]

On Fri, 26 Feb 2021 12:11:42 +0100
Sean Nyekjaer  wrote:

> Improve readability by using empty linies instead of extra spaces.
> 
> Signed-off-by: Sean Nyekjaer 
> ---
>  drivers/iio/accel/mma8452.c | 120 
>  1 file changed, 67 insertions(+), 53 deletions(-)
> 
> diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
> index b0176d936423..9fc1f7550b9c 100644
> --- a/drivers/iio/accel/mma8452.c
> +++ b/drivers/iio/accel/mma8452.c
> @@ -34,52 +34,66 @@
>  #include 
>  
>  #define MMA8452_STATUS   0x00
> -#define  MMA8452_STATUS_DRDY (BIT(2) | BIT(1) | BIT(0))
> +#define MMA8452_STATUS_DRDY  (BIT(2) | BIT(1) | BIT(0))

This indentation is deliberate.  It is to visibly distinguish register
addresses from the fields.

> +
>  #define MMA8452_OUT_X0x01 /* MSB first */
>  #define MMA8452_OUT_Y0x03
>  #define MMA8452_OUT_Z0x05
>  #define MMA8452_INT_SRC  0x0c
>  #define MMA8452_WHO_AM_I 0x0d
> +
>  #define MMA8452_DATA_CFG 0x0e
> -#define  MMA8452_DATA_CFG_FS_MASKGENMASK(1, 0)
> -#define  MMA8452_DATA_CFG_FS_2G  0
> -#define  MMA8452_DATA_CFG_FS_4G  1
> -#define  MMA8452_DATA_CFG_FS_8G  2
> -#define  MMA8452_DATA_CFG_HPF_MASK   BIT(4)
> +#define MMA8452_DATA_CFG_FS_MASK GENMASK(1, 0)
> +#define MMA8452_DATA_CFG_FS_2G   0
> +#define MMA8452_DATA_CFG_FS_4G   1
> +#define MMA8452_DATA_CFG_FS_8G   2
> +#define MMA8452_DATA_CFG_HPF_MASKBIT(4)
> +
>  #define MMA8452_HP_FILTER_CUTOFF 0x0f
> -#define  MMA8452_HP_FILTER_CUTOFF_SEL_MASK   GENMASK(1, 0)
> +#define MMA8452_HP_FILTER_CUTOFF_SEL_MASKGENMASK(1, 0)
> +
>  #define MMA8452_FF_MT_CFG0x15
> -#define  MMA8452_FF_MT_CFG_OAE   BIT(6)
> -#define  MMA8452_FF_MT_CFG_ELE   BIT(7)
> +#define MMA8452_FF_MT_CFG_OAEBIT(6)
> +#define MMA8452_FF_MT_CFG_ELEBIT(7)
> +
>  #define MMA8452_FF_MT_SRC0x16
> -#define  MMA8452_FF_MT_SRC_XHE   BIT(1)
> -#define  MMA8452_FF_MT_SRC_YHE   BIT(3)
> -#define  MMA8452_FF_MT_SRC_ZHE   BIT(5)
> +#define MMA8452_FF_MT_SRC_XHEBIT(1)
> +#define MMA8452_FF_MT_SRC_YHEBIT(3)
> +#define MMA8452_FF_MT_SRC_ZHEBIT(5)
> +
>  #define MMA8452_FF_MT_THS0x17
> -#define  MMA8452_FF_MT_THS_MASK  0x7f
> +#define MMA8452_FF_MT_THS_MASK   0x7f
> +
>  #define MMA8452_FF_MT_COUNT  0x18
> -#define MMA8452_FF_MT_CHAN_SHIFT 3
> +#define MMA8452_FF_MT_CHAN_SHIFT 3
> +
>  #define MMA8452_TRANSIENT_CFG0x1d
> -#define  MMA8452_TRANSIENT_CFG_CHAN(chan)BIT(chan + 1)
> -#define  MMA8452_TRANSIENT_CFG_HPF_BYP   BIT(0)
> -#define  MMA8452_TRANSIENT_CFG_ELE   BIT(4)
> +#define MMA8452_TRANSIENT_CFG_CHAN(chan) BIT(chan + 1)
> +#define MMA8452_TRANSIENT_CFG_HPF_BYPBIT(0)
> +#define MMA8452_TRANSIENT_CFG_ELEBIT(4)
> +
>  #define MMA8452_TRANSIENT_SRC0x1e
> -#define  MMA8452_TRANSIENT_SRC_XTRANSE   BIT(1)
> -#define  MMA8452_TRANSIENT_SRC_YTRANSE   BIT(3)
> -#define  MMA8452_TRANSIENT_SRC_ZTRANSE   BIT(5)
> +#define MMA8452_TRANSIENT_SRC_XTRANSEBIT(1)
> +#define MMA8452_TRANSIENT_SRC_YTRANSEBIT(3)
> +#define MMA8452_TRANSIENT_SRC_ZTRANSEBIT(5)
> +
>  #define MMA8452_TRANSIENT_THS0x1f
> -#define  MMA8452_TRANSIENT_THS_MASK  GENMASK(6, 0)
> +#define MMA8452_TRANSIENT_THS_MASK   GENMASK(6, 0)
> +
>  #define MMA8452_TRANSIENT_COUNT  0x20
> -#define MMA8452_TRANSIENT_CHAN_SHIFT 1
> +#define MMA8452_TRANSIENT_CHAN_SHIFT 1
> +
>  #define MMA8452_CTRL_REG10x2a
> -#define  MMA8452_CTRL_ACTIVE BIT(0)
> -#define  MMA8452_CTRL_DR_MASKGENMASK(5, 3)
> -#define  MMA8452_CTRL_DR_SHIFT   3
> -#define  MMA8452_CTRL_DR_DEFAULT 0x4 /* 50 Hz sample frequency */
> +#define MMA8452_CTRL_ACTIVE  BIT(0)
> +#define MMA8452_CTRL_DR_MASK GENMASK(5, 3)
> +#define MMA8452_CTRL_DR_SHIFT3
> +#define MMA8452_CTRL_DR_DEFAULT  0x4 /* 50 Hz sample 
> frequency */
> +
>  #define MMA8452_CTRL_REG20x2b
> -#define  MMA8452_CTRL_REG2_RST   BIT(6)
> -#define  MMA8452_CTRL_REG2_MOD

Re: [RFC v2] copy_file_range.2: Update cross-filesystem support for 5.12

[Amir Goldstein]

On Sat, Feb 27, 2021 at 3:59 PM Alejandro Colomar
 wrote:
>
> Linux 5.12 fixes a regression.
>
> Cross-filesystem copies (introduced in 5.3) were buggy.
>
> Move the statements documenting cross-fs to BUGS.
> Kernels 5.3..5.11 should be patched soon.
>
> State version information for some errors related to this.
>
> Reported-by: Luis Henriques 
> Reported-by: Amir Goldstein 
> Related: 
> Cc: Greg KH 
> Cc: Michael Kerrisk 
> Cc: Anna Schumaker 
> Cc: Jeff Layton 
> Cc: Steve French 
> Cc: Miklos Szeredi 
> Cc: Trond Myklebust 
> Cc: Alexander Viro 
> Cc: "Darrick J. Wong" 
> Cc: Dave Chinner 
> Cc: Nicolas Boichat 
> Cc: Ian Lance Taylor 
> Cc: Luis Lozano 
> Cc: Andreas Dilger 
> Cc: Olga Kornievskaia 
> Cc: Christoph Hellwig 
> Cc: ceph-devel 
> Cc: linux-kernel 
> Cc: CIFS 
> Cc: samba-technical 
> Cc: linux-fsdevel 
> Cc: Linux NFS Mailing List 
> Cc: Walter Harms 
> Signed-off-by: Alejandro Colomar 
> ---
>
> Hi all,
>
> Please check that this is correct.
> I wrote it as I understood copy_file_range() from the LWN article,
> and the conversation on this thread,
> but maybe someone with more experience on this syscall find bugs in my patch.
>
> When kernels 5.3..5.11 fix this, some info could be compacted a bit more,
> and maybe the BUGS section could be removed.
>
> Also, I'd like to know which filesystems support cross-fs, and since when.
>
> Amir, you said that it was only cifs and nfs (since when? 5.3? 5.12?).
>
> Also, I'm a bit surprised that <5.3 could fail with EOPNOTSUPP
> and it wasn't documented.  Is that for sure, Amir?

No. You are right. EOPNOTSUPP is new.
Kernel always fell back to sendfile(2) if the filesystem did not support
copy_file_range().

>
> Thanks,
>
> Alex
>
> ---
>  man2/copy_file_range.2 | 29 -
>  1 file changed, 20 insertions(+), 9 deletions(-)
>
> diff --git a/man2/copy_file_range.2 b/man2/copy_file_range.2
> index 611a39b80..93f54889d 100644
> --- a/man2/copy_file_range.2
> +++ b/man2/copy_file_range.2
> @@ -169,6 +169,9 @@ Out of memory.
>  .B ENOSPC
>  There is not enough space on the target filesystem to complete the copy.
>  .TP
> +.BR EOPNOTSUPP " (before Linux 5.3; or since Linux 5.12)"
> +The filesystem does not support this operation.
> +.TP

so not before 5.3

>  .B EOVERFLOW
>  The requested source or destination range is too large to represent in the
>  specified data types.
> @@ -184,10 +187,17 @@ or
>  .I fd_out
>  refers to an active swap file.
>  .TP
> -.B EXDEV
> +.BR EXDEV " (before Linux 5.3)"
>  The files referred to by
>  .IR fd_in " and " fd_out
> -are not on the same mounted filesystem (pre Linux 5.3).
> +are not on the same filesystem.
> +.TP
> +.BR EXDEV " (or since Linux 5.12)"
> +The files referred to by
> +.IR fd_in " and " fd_out
> +are not on the same filesystem,
> +and the source and target filesystems are not of the same type,
> +or do not support cross-filesystem copy.

ok.

>  .SH VERSIONS
>  The
>  .BR copy_file_range ()
> @@ -195,13 +205,10 @@ system call first appeared in Linux 4.5, but glibc 2.27 
> provides a user-space
>  emulation when it is not available.
>  .\" 
> https://sourceware.org/git/?p=glibc.git;a=commit;f=posix/unistd.h;h=bad7a0c81f501fbbcc79af9eaa4b8254441c4a1f
>  .PP
> -A major rework of the kernel implementation occurred in 5.3.
> -Areas of the API that weren't clearly defined were clarified and the API 
> bounds
> -are much more strictly checked than on earlier kernels.
> -Applications should target the behaviour and requirements of 5.3 kernels.
> -.PP

That information is useful. Why remove it?
FYI, the LTP tests written to velidate the copy_file_range() API are not running
on kernel < 5.3 at all.

> -First support for cross-filesystem copies was introduced in Linux 5.3.
> -Older kernels will return -EXDEV when cross-filesystem copies are attempted.
> +Since 5.12,
> +cross-filesystem copies can be achieved
> +when both filesystems are of the same type,
> +and that filesystem implements support for it.
>  .SH CONFORMING TO
>  The
>  .BR copy_file_range ()
> @@ -226,6 +233,10 @@ gives filesystems an opportunity to implement "copy 
> acceleration" techniques,
>  such as the use of reflinks (i.e., two or more inodes that share
>  pointers to the same copy-on-write disk blocks)
>  or server-side-copy (in the case of NFS).
> +.SH BUGS
> +In Linux kernels 5.3 to 5.11, cross-filesystem copies were supported.

I think it is a bit confusing to say "were supported", because how come
support went away from kernel 5.12? maybe something along the lines
that kernel implementation of copy was used if there was no filesystem
support for the operation...

> +However, on some virtual filesystems, the call failed to copy,
> +eventhough it may have reported success.
>  .SH EXAMPLES
>  .EX
>  #define _GNU_SOURCE
> --
> 2.30.1.721.g45526154a5
>