Re: [PATCH] virtio_mem: prevent overflow with subblock size

[David Hildenbrand]

On 08.06.20 08:14, Michael S. Tsirkin wrote:
> If subblock size is large (e.g. 1G) 32 bit math involving it
> can overflow. Rather than try to catch all instances of that,
> let's tweak block size to 64 bit.

I fail to see where we could actually trigger an overflow. The reported
warning looked like a false positive to me.

> 
> It ripples through UAPI which is an ABI change, but it's not too late to
> make it, and it will allow supporting >4Gbyte blocks while might
> become necessary down the road.
> 

This might break cloud-hypervisor, who's already implementing this
protocol upstream (ccing Hui).
https://github.com/cloud-hypervisor/cloud-hypervisor/blob/master/vm-virtio/src/mem.rs

(blocks in the gigabyte range were never the original intention of
virtio-mem, but I am not completely opposed to that)

> Fixes: 5f1f79bbc9e26 ("virtio-mem: Paravirtualized memory hotplug")
> Signed-off-by: Michael S. Tsirkin 
> ---
>  drivers/virtio/virtio_mem.c | 14 +++---
>  include/uapi/linux/virtio_mem.h |  4 ++--
>  2 files changed, 9 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/virtio/virtio_mem.c b/drivers/virtio/virtio_mem.c
> index 2f357142ea5e..7b1bece8a331 100644
> --- a/drivers/virtio/virtio_mem.c
> +++ b/drivers/virtio/virtio_mem.c
> @@ -77,7 +77,7 @@ struct virtio_mem {
>   uint64_t requested_size;
>  
>   /* The device block size (for communicating with the device). */
> - uint32_t device_block_size;
> + uint64_t device_block_size;
>   /* The translated node id. NUMA_NO_NODE in case not specified. */
>   int nid;
>   /* Physical start address of the memory region. */
> @@ -86,7 +86,7 @@ struct virtio_mem {
>   uint64_t region_size;
>  
>   /* The subblock size. */
> - uint32_t subblock_size;
> + uint64_t subblock_size;
>   /* The number of subblocks per memory block. */
>   uint32_t nb_sb_per_mb;
>  
> @@ -1698,9 +1698,9 @@ static int virtio_mem_init(struct virtio_mem *vm)
>* - At least the device block size.
>* In the worst case, a single subblock per memory block.
>*/
> - vm->subblock_size = PAGE_SIZE * 1u << max_t(uint32_t, MAX_ORDER - 1,
> - pageblock_order);
> - vm->subblock_size = max_t(uint32_t, vm->device_block_size,
> + vm->subblock_size = PAGE_SIZE * 1ul << max_t(uint32_t, MAX_ORDER - 1,
> +  pageblock_order);
> + vm->subblock_size = max_t(uint64_t, vm->device_block_size,
> vm->subblock_size);
>   vm->nb_sb_per_mb = memory_block_size_bytes() / vm->subblock_size;
>  
> @@ -1713,8 +1713,8 @@ static int virtio_mem_init(struct virtio_mem *vm)
>  
>   dev_info(&vm->vdev->dev, "start address: 0x%llx", vm->addr);
>   dev_info(&vm->vdev->dev, "region size: 0x%llx", vm->region_size);
> - dev_info(&vm->vdev->dev, "device block size: 0x%x",
> -  vm->device_block_size);
> + dev_info(&vm->vdev->dev, "device block size: 0x%llx",
> +  (unsigned long long)vm->device_block_size);
>   dev_info(&vm->vdev->dev, "memory block size: 0x%lx",
>memory_block_size_bytes());
>   dev_info(&vm->vdev->dev, "subblock size: 0x%x",
> diff --git a/include/uapi/linux/virtio_mem.h b/include/uapi/linux/virtio_mem.h
> index a455c488a995..a9ffe041843c 100644
> --- a/include/uapi/linux/virtio_mem.h
> +++ b/include/uapi/linux/virtio_mem.h
> @@ -185,10 +185,10 @@ struct virtio_mem_resp {
>  
>  struct virtio_mem_config {
>   /* Block size and alignment. Cannot change. */
> - __u32 block_size;
> + __u64 block_size;
>   /* Valid with VIRTIO_MEM_F_ACPI_PXM. Cannot change. */
>   __u16 node_id;
> - __u16 padding;
> + __u8 padding[6];
>   /* Start address of the memory region. Cannot change. */
>   __u64 addr;
>   /* Region size (maximum). Cannot change. */
> 


-- 
Thanks,

David / dhildenb

Re: [f2fs-dev] [PATCH] f2fs: add F2FS_IOC_TRIM_FILE ioctl

[Chao Yu]

On 2020/6/8 11:36, Daeho Jeong wrote:
> Yes, this is for security key destruction.
> 
> AFAIK, discard will unmap the data block and, after done it,
> we can read either zero data or garbage data from that block depending
> on eMMC/UFS.

Since spec didn't restrict how vendor implement the erase interface, so
in order to enhance performance of discard interface, vendor could implement
it as an async one, which may not zero mapping entry(L1 table), instead, it
could set related bitmap to invalid that mapping entry, than later if device
allow user to access that invalid mapping entry, key info may be explosed,

It's completely up to how vendor implement the interface, so I think there is
still risk to use discard.

Thanks,

> In a view point of read data, it might be the same with zeroing the data 
> block.
> However, since we can even unmap that block, I believe discard is
> safer than zeroing out.
> 
> 2020년 6월 8일 (월) 오전 11:46, Chao Yu 님이 작성:
>>
>> On 2020/6/5 12:27, Daeho Jeong wrote:
>>> From: Daeho Jeong 
>>>
>>> Added a new ioctl to send discard commands to whole data area of
>>> a regular file for security reason.
>>
>> I guess this interface is introduced for security key destruction, if I'm
>> right, however, IIRC, discard(erase) semantics in eMMC/UFS spec won't
>> guarantee that data which was discard could be zeroed out, so after discard,
>> the key still have risk of exposure. So instead, should we use 
>> sb_issue_zeroout()?
>>
>> Thanks,
>>
>>>
>>> Signed-off-by: Daeho Jeong 
>>> ---
>>>  fs/f2fs/f2fs.h |   1 +
>>>  fs/f2fs/file.c | 129 +
>>>  2 files changed, 130 insertions(+)
>>>
>>> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
>>> index c812fb8e2d9c..9ae81d0fefa0 100644
>>> --- a/fs/f2fs/f2fs.h
>>> +++ b/fs/f2fs/f2fs.h
>>> @@ -434,6 +434,7 @@ static inline bool __has_cursum_space(struct 
>>> f2fs_journal *journal,
>>>   _IOR(F2FS_IOCTL_MAGIC, 18, __u64)
>>>  #define F2FS_IOC_RESERVE_COMPRESS_BLOCKS \
>>>   _IOR(F2FS_IOCTL_MAGIC, 19, __u64)
>>> +#define F2FS_IOC_TRIM_FILE   _IO(F2FS_IOCTL_MAGIC, 20)
>>>
>>>  #define F2FS_IOC_GET_VOLUME_NAME FS_IOC_GETFSLABEL
>>>  #define F2FS_IOC_SET_VOLUME_NAME FS_IOC_SETFSLABEL
>>> diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
>>> index dfa1ac2d751a..58507bb5649c 100644
>>> --- a/fs/f2fs/file.c
>>> +++ b/fs/f2fs/file.c
>>> @@ -3749,6 +3749,132 @@ static int f2fs_reserve_compress_blocks(struct file 
>>> *filp, unsigned long arg)
>>>   return ret;
>>>  }
>>>
>>> +static int f2fs_trim_file(struct file *filp)
>>> +{
>>> + struct inode *inode = file_inode(filp);
>>> + struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
>>> + struct address_space *mapping = inode->i_mapping;
>>> + struct bio *bio = NULL;
>>> + struct block_device *prev_bdev = NULL;
>>> + loff_t file_size;
>>> + pgoff_t index, pg_start = 0, pg_end;
>>> + block_t prev_block = 0, len = 0;
>>> + int ret = 0;
>>> +
>>> + if (!f2fs_hw_support_discard(sbi))
>>> + return -EOPNOTSUPP;
>>> +
>>> + if (!S_ISREG(inode->i_mode) || f2fs_is_atomic_file(inode) ||
>>> + f2fs_compressed_file(inode))
>>> + return -EINVAL;
>>> +
>>> + if (f2fs_readonly(sbi->sb))
>>> + return -EROFS;
>>> +
>>> + ret = mnt_want_write_file(filp);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + inode_lock(inode);
>>> +
>>> + file_size = i_size_read(inode);
>>> + if (!file_size)
>>> + goto err;
>>> + pg_end = (pgoff_t)round_up(file_size, PAGE_SIZE) >> PAGE_SHIFT;
>>> +
>>> + ret = f2fs_convert_inline_inode(inode);
>>> + if (ret)
>>> + goto err;
>>> +
>>> + down_write(&F2FS_I(inode)->i_gc_rwsem[WRITE]);
>>> + down_write(&F2FS_I(inode)->i_mmap_sem);
>>> +
>>> + ret = filemap_write_and_wait(mapping);
>>> + if (ret)
>>> + goto out;
>>> +
>>> + truncate_inode_pages(mapping, 0);
>>> +
>>> + for (index = pg_start; index < pg_end;) {
>>> + struct dnode_of_data dn;
>>> + unsigned int end_offset;
>>> +
>>> + set_new_dnode(&dn, inode, NULL, NULL, 0);
>>> + ret = f2fs_get_dnode_of_data(&dn, index, LOOKUP_NODE);
>>> + if (ret)
>>> + goto out;
>>> +
>>> + end_offset = ADDRS_PER_PAGE(dn.node_page, inode);
>>> + if (pg_end < end_offset + index)
>>> + end_offset = pg_end - index;
>>> +
>>> + for (; dn.ofs_in_node < end_offset;
>>> + dn.ofs_in_node++, index++) {
>>> + struct block_device *cur_bdev;
>>> + block_t blkaddr = f2fs_data_blkaddr(&dn);
>>> +
>>> + if (__is_valid_data_blkaddr(blkaddr)) {
>>> + if (!f2fs_is_valid_blkaddr(F2FS_I_SB(inode),
>>> 

回复: [PATCH] usb: gadget: function: printer: Fix use-after-free in __lock_acquire()

[Zhang, Qiang]

Hi Markus.
I don't need to add Fix tag to view the code.


发件人: Markus Elfring 
发送时间: 2020年6月5日 16:57
收件人: Zhang, Qiang; linux-...@vger.kernel.org
抄送: kernel-janit...@vger.kernel.org; linux-kernel@vger.kernel.org; Alan Stern; 
Felipe Balbi; Greg Kroah-Hartman; Kyungtae Kim
主题: Re: [PATCH] usb: gadget: function: printer: Fix use-after-free in 
__lock_acquire()

> Fix this by increase object reference count.

I find this description incomplete according to the proposed changes.

Would you like to add the tag “Fixes” to the commit message?

Regards,
Markus

Re: [PATCH 2/2][RFC] PM-runtime: add tracepoints to cover all usage_count changes

[Chen Yu]

On Sun, Jun 07, 2020 at 06:55:35AM +0200, Michal Miroslaw wrote:
> On Sat, Jun 06, 2020 at 03:14:59PM +0800, Chen Yu wrote:
> > Hi,
> > On Fri, Jun 05, 2020 at 09:33:11PM +0200, Michal Miroslaw wrote:
> > > On Sat, Jun 06, 2020 at 03:05:52AM +0800, Chen Yu wrote:
> > > > Commit d229290689ae ("PM-runtime: add tracepoints for usage_count 
> > > > changes")
> > > > has added some tracepoints to monitor the change of runtime usage, and
> > > > there is something to improve:
> > > > 1. There are some places that adjust the usage count have not
> > > >been traced yet. For example, pm_runtime_get_noresume() and
> > > >pm_runtime_put_noidle()
> > > > 2. The change of the usage count will not be tracked if decreased
> > > >from 1 to 0.
> > > [...]
> > > > @@ -1448,16 +1453,17 @@ EXPORT_SYMBOL_GPL(pm_runtime_forbid);
> > > >   */
> > > >  void pm_runtime_allow(struct device *dev)
> > > >  {
> > > > +   bool is_zero;
> > > > +
> > > > spin_lock_irq(&dev->power.lock);
> > > > if (dev->power.runtime_auto)
> > > > goto out;
> > > >  
> > > > dev->power.runtime_auto = true;
> > > > -   if (atomic_dec_and_test(&dev->power.usage_count))
> > > > +   is_zero = atomic_dec_and_test(&dev->power.usage_count);
> > > > +   trace_rpm_usage_rcuidle(dev, RPM_AUTO | RPM_ASYNC);
> > > > +   if (is_zero)
> > > > rpm_idle(dev, RPM_AUTO | RPM_ASYNC);
> > > > -   else
> > > > -   trace_rpm_usage_rcuidle(dev, RPM_AUTO | RPM_ASYNC);
> > > > -
> > > [...]
> > > 
> > > IIRC, rpm_idle() has a tracepoint already.
> > > 
> > Yes, this is what I concerned previously. If someone
> > want to track the change of usage_count, then he might
> > have to enable both trace rpm_usage and rpm_idle so
> > as to track the moment when the counter drops from 1 to
> > 0. It might be more consistent if we only enable
> > trace rpm_usage to track the whole process.
> > > > @@ -1523,9 +1529,8 @@ static void update_autosuspend(struct device 
> > > > *dev, int old_delay, int old_use)
> > > > /* If it used to be allowed then prevent it. */
> > > > if (!old_use || old_delay >= 0) {
> > > > atomic_inc(&dev->power.usage_count);
> > > > -   rpm_resume(dev, 0);
> > > > -   } else {
> > > > trace_rpm_usage_rcuidle(dev, 0);
> > > > +   rpm_resume(dev, 0);
> > > > }
> > > > }
> > > [...]
> > > 
> > > This actually changes logic, so it doesn't match the patch description.
> > > 
> > This patch intends to adjust the logic to be consistent with
> > the change of usage_counter, that is to say, only after the
> > counter has been possibly modified, we record it. In current
> > logic above, it tracks the usage count where the latter does
> > not change.
> 
> I see now what you intended. I think it would be nice to put the idea
> (that all usage changes be shown using rpm_usage even if included in
> other trace points) into the commit message. Otherwise, looks ok.
>
Okay, will do in next version, thanks!

Chenyu

Re: [PATCH v4] block: Fix use-after-free in blkdev_get()

[Sedat Dilek]

On Mon, Jun 8, 2020 at 8:47 AM Sedat Dilek  wrote:
>
> On Mon, Jun 8, 2020 at 8:18 AM Christoph Hellwig  wrote:
> >
> > Looks good,
> >
> > Reviewed-by: Christoph Hellwig 
> >
> > Can you dig into the history for a proper fixes tag?
>
> [ CC Dan ]
>
> Dan gave the hint for the Fixes: tag in reply to the first patch:
>
> > The Fixes tag is a good idea though:
> >
> > Fixes: 89e524c04fa9 ("loop: Fix mount(2) failure due to race with 
> > LOOP_SET_FD")
>
> > It broke last July.  Before that, we used to check if __blkdev_get()
> > failed before dereferencing "bdev".
>

Here is the Link.

https://www.spinics.net/lists/linux-block/msg54825.html

- Sedat -

Re: WARNING: CPU: 1 PID: 52 at mm/page_alloc.c:4826 __alloc_pages_nodemask (Re: [PATCH 5/5] sysctl: pass kernel pointers to ->proc_handler)

[Christoph Hellwig]

On Thu, Jun 04, 2020 at 10:22:21PM +0200, Vegard Nossum wrote:
> It's easy to reproduce by just doing
>
> read(open("/proc/sys/vm/swappiness", O_RDONLY), 0, 512UL * 1024 * 1024 
> * 1024);
>
> or so. Reverting the commit fixes the issue for me.

Yes, doing giant allocations will fail and trace.  We have to options
here that both seems sensible:

 - trunate sysctrl calls to some sensible length
 - (optionally) use vmalloc

Is this a real application or just a test case trying to do the
stupidmost possible thing?

Re: [Tee-dev] [PATCH v2] drivers: optee: allow op-tee to access devices on the i2c bus

[Jens Wiklander]

On Mon, Jun 01, 2020 at 09:24:46AM +0200, Jorge Ramirez-Ortiz, Foundries wrote:
> On 01/06/20, Sumit Garg wrote:
> > Hi Jorge,
> 
> hey
> 
> > 
> > On Mon, 1 Jun 2020 at 04:41, Jorge Ramirez-Ortiz  wrote:
> > >
> > > Some secure elements like NXP's SE050 sit on I2C buses. For OP-TEE to
> > > control this type of cryptographic devices it needs coordinated access
> > > to the bus, so collisions and RUNTIME_PM dont get in the way.
> > >
> > > This trampoline driver allow OP-TEE to access them.
> > >
> > 
> > This sounds like an interesting use-case but I would like to
> > understand how secure is this communication interface with the secure
> > element? Like in the case of RPMB, secure world data is encrypted
> > which flows via tee-supplicant to RPMB device.
> 
> right, the data in the buffer should be encrypted in both directions
> (in the case of the SE050 [1] we have the option to operate with or
> without encryption which is what I am doing during development
> [2]).
> 
> But ultimately -before any product can be shipped- all comms must be
> encrypted: this means that when OP-TEE uses the SE050 for crypto, it
> must encrypt the data on write and decrypt what is comming from the
> SE050 on read. I am now looking into how to enable this.
> 
> [1] https://www.nxp.com/docs/en/data-sheet/SE050-DATASHEET.pdf
> [2] https://github.com/ldts/optee_os/commits/se050
This link doesn't work.

> 
> > 
> > -Sumit
> > 
> > > Signed-off-by: Jorge Ramirez-Ortiz 
> > > ---
> > >  drivers/tee/optee/optee_msg.h | 18 +++
> > >  drivers/tee/optee/rpc.c   | 57 +++
> > >  2 files changed, 75 insertions(+)
> > >
> > > diff --git a/drivers/tee/optee/optee_msg.h b/drivers/tee/optee/optee_msg.h
> > > index 795bc19ae17a..b6cc964fdeea 100644
> > > --- a/drivers/tee/optee/optee_msg.h
> > > +++ b/drivers/tee/optee/optee_msg.h
> > > @@ -419,4 +419,22 @@ struct optee_msg_arg {
> > >   */
> > >  #define OPTEE_MSG_RPC_CMD_SHM_FREE 7
> > >
> > > +/*
> > > + * Access a device on an i2c bus
> > > + *
> > > + * [in]  param[0].u.value.amode: RD(0), WR(1)
> > > + * [in]  param[0].u.value.bi2c adapter
> > > + * [in]  param[0].u.value.ci2c chip
> > > + *
> > > + * [io]  param[1].u.tmem.buf_ptr   physical address
> > > + * [io]  param[1].u.tmem.size  transfer size in bytes
> > > + * [io]  param[1].u.tmem.shm_ref   shared memory reference

This should be "[in/out] memref[1]" instead to be able to use
all kinds of memory references.

> > > + *
> > > + * [out]  param[0].u.value.a   bytes transferred
> > > + *
> > > + */
> > > +#define OPTEE_MSG_RPC_CMD_I2C_TRANSFER 8
> > > +#define OPTEE_MSG_RPC_CMD_I2C_TRANSFER_RD 0
> > > +#define OPTEE_MSG_RPC_CMD_I2C_TRANSFER_WR 1
> > > +
> > >  #endif /* _OPTEE_MSG_H */
> > > diff --git a/drivers/tee/optee/rpc.c b/drivers/tee/optee/rpc.c
> > > index b4ade54d1f28..21d452805c6f 100644
> > > --- a/drivers/tee/optee/rpc.c
> > > +++ b/drivers/tee/optee/rpc.c
> > > @@ -9,6 +9,7 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > >  #include "optee_private.h"
> > >  #include "optee_smc.h"
> > >
> > > @@ -48,6 +49,59 @@ static void handle_rpc_func_cmd_get_time(struct 
> > > optee_msg_arg *arg)
> > >  bad:
> > > arg->ret = TEEC_ERROR_BAD_PARAMETERS;
> > >  }
> > > +static void handle_rpc_func_cmd_i2c_transfer(struct tee_context *ctx,
> > > +struct optee_msg_arg *arg)
> > > +{
> > > +   struct i2c_client client;
> > > +   struct tee_shm *shm;
> > > +   int i, ret;
> > > +   char *buf;
> > > +   uint32_t attr[] = {
> > > +   OPTEE_MSG_ATTR_TYPE_VALUE_INPUT,
> > > +   OPTEE_MSG_ATTR_TYPE_TMEM_INOUT,
> > > +   OPTEE_MSG_ATTR_TYPE_VALUE_OUTPUT,
> > > +   };
> > > +
> > > +   if (arg->num_params != ARRAY_SIZE(attr))
> > > +   goto bad;

Use optee_from_msg_param() to translate this into a struct tee_param,
that way you cover all kinds of memory references. Before returning it
nees to be translated back with optee_to_msg_param().

Cheers,
Jens

> > > +
> > > +   for (i = 0; i < ARRAY_SIZE(attr); i++)
> > > +   if ((arg->params[i].attr & OPTEE_MSG_ATTR_TYPE_MASK) != 
> > > attr[i])
> > > +   goto bad;
> > > +
> > > +   shm = (struct tee_shm *)(unsigned 
> > > long)arg->params[1].u.tmem.shm_ref;
> > > +   buf = (char *)shm->kaddr;
> > > +
> > > +   client.addr = arg->params[0].u.value.c;
> > > +   client.adapter = i2c_get_adapter(arg->params[0].u.value.b);
> > > +   if (!client.adapter)
> > > +   goto bad;
> > > +
> > > +   snprintf(client.name, I2C_NAME_SIZE, "i2c%d", client.adapter->nr);
> > > +
> > > +   switch (arg->params[0].u.value.a) {
> > > +   case OPTEE_MSG_RPC_CMD_I2C_TRANSFER_RD:
> > > +   ret = i2c_master_recv(&client, buf, 
> > > arg->params[1].u.tmem.size);
> > > +   

Re: [PATCH v4] block: Fix use-after-free in blkdev_get()

[Sedat Dilek]

On Mon, Jun 8, 2020 at 8:18 AM Christoph Hellwig  wrote:
>
> Looks good,
>
> Reviewed-by: Christoph Hellwig 
>
> Can you dig into the history for a proper fixes tag?

[ CC Dan ]

Dan gave the hint for the Fixes: tag in reply to the first patch:

> The Fixes tag is a good idea though:
>
> Fixes: 89e524c04fa9 ("loop: Fix mount(2) failure due to race with 
> LOOP_SET_FD")

> It broke last July.  Before that, we used to check if __blkdev_get()
> failed before dereferencing "bdev".

- Sedat -

Re: [PATCH RFC v5 13/13] vhost: drop head based APIs

[Michael S. Tsirkin]

On Mon, Jun 08, 2020 at 11:57:48AM +0800, Jason Wang wrote:
> 
> On 2020/6/7 下午10:11, Michael S. Tsirkin wrote:
> > Everyone's using buf APIs, no need for head based ones anymore.
> > 
> > Signed-off-by: Michael S. Tsirkin
> > ---
> >   drivers/vhost/vhost.c | 36 
> >   drivers/vhost/vhost.h | 12 
> >   2 files changed, 8 insertions(+), 40 deletions(-)
> > 
> > diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> > index 72ee55c810c4..e6931b760b61 100644
> > --- a/drivers/vhost/vhost.c
> > +++ b/drivers/vhost/vhost.c
> > @@ -2299,12 +2299,12 @@ static int fetch_buf(struct vhost_virtqueue *vq)
> > return 1;
> >   }
> > -/* Reverse the effect of vhost_get_vq_desc. Useful for error handling. */
> > +/* Revert the effect of fetch_buf. Useful for error handling. */
> > +static
> >   void vhost_discard_vq_desc(struct vhost_virtqueue *vq, int n)
> >   {
> > vq->last_avail_idx -= n;
> >   }
> > -EXPORT_SYMBOL_GPL(vhost_discard_vq_desc);
> 
> 
> The same question as previous version.
> 
> Do we need to rewind cached descriptor here?
> 
> Thanks

Good point.  This needs more thought, we need to also
rewind the avail idx each time we flush the descriptor cache.

-- 
MST

Re: [PATCH] virtio-mem: drop unnecessary initialization

[David Hildenbrand]

On 08.06.20 07:45, Michael S. Tsirkin wrote:
> rc is initialized to -ENIVAL but that's never used. Drop it.
> 
> Fixes: 5f1f79bbc9e2 ("virtio-mem: Paravirtualized memory hotplug")
> Reported-by: kernel test robot 
> Signed-off-by: Michael S. Tsirkin 
> ---
>  drivers/virtio/virtio_mem.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/virtio/virtio_mem.c b/drivers/virtio/virtio_mem.c
> index f658fe9149be..2f357142ea5e 100644
> --- a/drivers/virtio/virtio_mem.c
> +++ b/drivers/virtio/virtio_mem.c
> @@ -1768,7 +1768,7 @@ static void virtio_mem_delete_resource(struct 
> virtio_mem *vm)
>  static int virtio_mem_probe(struct virtio_device *vdev)
>  {
>   struct virtio_mem *vm;
> - int rc = -EINVAL;
> + int rc;
>  
>   BUILD_BUG_ON(sizeof(struct virtio_mem_req) != 24);
>   BUILD_BUG_ON(sizeof(struct virtio_mem_resp) != 10);
> 

Acked-by: David Hildenbrand 

-- 
Thanks,

David / dhildenb

Re: [PATCH v4] block: Fix use-after-free in blkdev_get()

[Jason Yan]

Hi Christoph,

在 2020/6/8 14:15, Christoph Hellwig 写道:

Looks good,

Reviewed-by: Christoph Hellwig 

Can you dig into the history for a proper fixes tag?



This one started to accessing bdev after __blkdev_get(). So I think it 
may be a proper fixes tag:


Fixes: e525fd89d380 ("block: make blkdev_get/put() handle exclusive access")

Thanks,
Jason


.

Re: [PATCH] tty: serial: cpm_uart: Fix behaviour for non existing GPIOs

[Johan Hovold]

On Sat, Jun 06, 2020 at 07:30:21AM +, Christophe Leroy wrote:
> devm_gpiod_get_index() doesn't return NULL but -ENOENT when the
> requested GPIO doesn't exist,  leading to the following messages:
> 
> [2.742468] gpiod_direction_input: invalid GPIO (errorpointer)
> [2.748147] can't set direction for gpio #2: -2
> [2.753081] gpiod_direction_input: invalid GPIO (errorpointer)
> [2.758724] can't set direction for gpio #3: -2
> [2.763666] gpiod_direction_output: invalid GPIO (errorpointer)
> [2.769394] can't set direction for gpio #4: -2
> [2.774341] gpiod_direction_input: invalid GPIO (errorpointer)
> [2.779981] can't set direction for gpio #5: -2
> [2.784545] ff000a20.serial: ttyCPM1 at MMIO 0xfff00a20 (irq = 39, 
> base_baud = 825) is a CPM UART
> 
> Use IS_ERR_OR_NULL() to properly check gpiod validity.

Why check for NULL at all?

> Fixes: 97cbaf2c829b ("tty: serial: cpm_uart: Convert to use GPIO descriptors")
> Cc: sta...@vger.kernel.org
> Cc: Linus Walleij 
> Signed-off-by: Christophe Leroy 
> ---
>  drivers/tty/serial/cpm_uart/cpm_uart_core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/tty/serial/cpm_uart/cpm_uart_core.c 
> b/drivers/tty/serial/cpm_uart/cpm_uart_core.c
> index a04f74d2e854..3cbe24802296 100644
> --- a/drivers/tty/serial/cpm_uart/cpm_uart_core.c
> +++ b/drivers/tty/serial/cpm_uart/cpm_uart_core.c
> @@ -1217,7 +1217,7 @@ static int cpm_uart_init_port(struct device_node *np,
>  
>   gpiod = devm_gpiod_get_index(dev, NULL, i, GPIOD_ASIS);
>  
> - if (gpiod) {
> + if (!IS_ERR_OR_NULL(gpiod)) {
>   if (i == GPIO_RTS || i == GPIO_DTR)
>   ret = gpiod_direction_output(gpiod, 0);
>   else

Johan

Re: [PATCH v3 2/3] leds: pwm: add support for default-state device property

[Denis Osterland-Heim]

Hi Jacek,

is your ack still valid for the new versions of the patch-set?
Due to the changes I made, I am not sure.

Regards, Denis

Am Dienstag, den 17.03.2020, 21:43 +0100 schrieb Jacek Anaszewski:
> Hi Denis,
> 
> On 3/16/20 9:24 PM, Denis Osterland-Heim wrote:
> > Hi Jacek,
> > 
> > Am Montag, den 16.03.2020, 19:36 +0100 schrieb Jacek Anaszewski:
> > > Hi Denis,
> > > 
> > > On 3/16/20 1:53 PM, Denis Osterland-Heim wrote:
> > 
> > ...
> > > >  
> > > > @@ -92,13 +96,27 @@ static int led_pwm_add(struct device *dev, struct 
> > > > led_pwm_priv *priv,
> > > >  
> > > > pwm_init_state(led_data->pwm, &led_data->pwmstate);
> > > >  
> > > > +   if (led->default_state == LEDS_PWM_DEFSTATE_ON)
> > > > +   led_data->cdev.brightness = led->max_brightness;
> > > > +   else if (led->default_state == LEDS_PWM_DEFSTATE_KEEP) {
> > > > +   uint64_t brightness;
> > > > +
> > > > +   pwm_get_state(led_data->pwm, &led_data->pwmstate);
> > > 
> > > This seems to not be reading the device state, i.e. what you tried
> > > to address by direct call to pwm->chip->ops->get_state() before.
> > > 
> > > Am I missing something?
> > > 
> > 
> > well, not you, but I missed cfc4c189bc70b1acc17e6f1abf1dc1c0ae890bd8.
> > Since this commit pwm_get_state() is sufficient.
> 
> I assume you tested it?
> 
> With that, for the whole set:
> 
> Acked-by: Jacek Anaszewski 
> 


Diehl Connectivity Solutions GmbH
Geschäftsführung: Horst Leonberger
Sitz der Gesellschaft: Nürnberg - Registergericht: Amtsgericht
Nürnberg: HRB 32315
___

Der Inhalt der vorstehenden E-Mail ist nicht rechtlich bindend. Diese E-Mail 
enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen.
Informieren Sie uns bitte, wenn Sie diese E-Mail faelschlicherweise erhalten 
haben. Bitte loeschen Sie in diesem Fall die Nachricht.
Jede unerlaubte Form der Reproduktion, Bekanntgabe, Aenderung, Verteilung 
und/oder Publikation dieser E-Mail ist strengstens untersagt.
- Informationen zum Datenschutz, insbesondere zu Ihren Rechten, erhalten Sie 
unter https://www.diehl.com/group/de/transparenz-und-informationspflichten/

The contents of the above mentioned e-mail is not legally binding. This e-mail 
contains confidential and/or legally protected information. Please inform us if 
you have received this e-mail by
mistake and delete it in such a case. Each unauthorized reproduction, 
disclosure, alteration, distribution and/or publication of this e-mail is 
strictly prohibited. 
- For general information on data protection and your respective rights please 
visit https://www.diehl.com/group/en/transparency-and-information-obligations/

Re: [PATCH v2 0/6] iio: core: pass parent device as parameter during allocation

[Alexandru Ardelean]

On Sat, Jun 6, 2020 at 7:03 PM Jonathan Cameron  wrote:
>
> On Thu, 4 Jun 2020 18:34:40 +0100
> Jonathan Cameron  wrote:
>
> > On Wed, 3 Jun 2020 11:41:52 +
> > "Ardelean, Alexandru"  wrote:
> >
> > > On Wed, 2020-06-03 at 14:40 +0300, Alexandru Ardelean wrote:
> > > > This patch updates the {devm_}iio_device_alloc() functions to 
> > > > automatically
> > > > assign the parent device on allocation.
> > > > For iio_device_alloc() this means a new parameter.
> > > > For devm_iio_device_alloc() this means a new behavior; the device 
> > > > object is
> > > > the parent. For this one, this is the common case for most drivers 
> > > > (except
> > > > one: 'lm3533-als').
> > > >
> > > > For the special cases an iio_device_set_parent() has been created to 
> > > > change
> > > > the parent betwee allocation & registration.
> > > > The purpose of this helper, is mostly to highlight the new behavior of
> > > > devm_iio_device_alloc().
> > > >
> > > > This patchset also removes explicit parent assignments from most IIO
> > > > drivers (except for lm3533-als).
> > > >
> > > > Using a semantic patch, about 303 drivers are updated, and some needed 
> > > > some
> > > > manual attention. This is probably due to some limitations of spatch. At
> > > > least in some cases the parent device is not the same variable as 
> > > > passed to
> > > > devm_iio_device_alloc(), OR the parent assignment is moved to a separate
> > > > function than where devm_iio_device_alloc() is called.
> > > >
> > >
> > > Forgot to explicitly CC Jonathan.
> > > But I'm hoping this shows up from the list.
> >
> > No problem.  I filter anything going to the list into the same folder
> > whether or not I'm cc'd :) Well several folders on different machines via
> > different email addresses, but you get the idea...
>
> Patch 3 doesn't seem to have made it to me or the list.
>

hmm, that's weird;
i'll check my work email inbox and see if it got there;
i'm in a short vacation this week; and left everything at work [intentionally]

> I assumed no change from patch 2 in previous set and applied that.
>
that looks like the spatch patch;
nothing changed there;

> After applying the rest of the series, there were left over cases in:
>
> vcnl3020 (new)
> ms5611 (hidden via an extra call)
> st_sensors_spi (hidden via an extra call)
> st_sensors_i2c (hidden via an extra call)
> cros_ec_sensors_core (hidden via an extra call)
>
> I've added them to patch 6 - with a note to say why.
> If you could do a quick sanity check that would be great.
>

did you push the branch anywhere?
i can't seem to find the patches

> Thanks,
>
> Jonathan
>
>
> Thanks,
>
> Jonathan
>
> >
> >
> > >
> > > > Changelog v1 -> v2:
> > > > * added iio_device_set_parent() helper (new commit)
> > > > * update commit for lm3533-als to use iio_device_set_parent()
> > > >
> > > > Alexandru Ardelean (6):
> > > >   iio: core: pass parent device as parameter during allocation
> > > >   iio: core: add iio_device_set_parent() helper
> > > >   iio: remove explicit IIO device parent assignment
> > > >   iio: remove left-over comments about parent assignment
> > > >   iio: light: lm3533-als: use iio_device_set_parent() to assign parent
> > > >   iio: remove left-over parent assignments
> > > >
> > > >  drivers/counter/104-quad-8.c  |  1 -
> > > >  drivers/counter/stm32-lptimer-cnt.c   |  1 -
> > > >  drivers/iio/accel/adis16201.c |  1 -
> > > >  drivers/iio/accel/adis16209.c |  1 -
> > > >  drivers/iio/accel/adxl345_core.c  |  1 -
> > > >  drivers/iio/accel/adxl372.c   |  1 -
> > > >  drivers/iio/accel/bma180.c|  1 -
> > > >  drivers/iio/accel/bma220_spi.c|  1 -
> > > >  drivers/iio/accel/bma400_core.c   |  1 -
> > > >  drivers/iio/accel/bmc150-accel-core.c |  1 -
> > > >  drivers/iio/accel/da280.c |  1 -
> > > >  drivers/iio/accel/da311.c |  1 -
> > > >  drivers/iio/accel/dmard06.c   |  1 -
> > > >  drivers/iio/accel/dmard09.c   |  1 -
> > > >  drivers/iio/accel/dmard10.c   |  1 -
> > > >  drivers/iio/accel/hid-sensor-accel-3d.c   |  1 -
> > > >  drivers/iio/accel/kxcjk-1013.c|  1 -
> > > >  drivers/iio/accel/kxsd9.c |  1 -
> > > >  drivers/iio/accel/mc3230.c|  1 -
> > > >  drivers/iio/accel/mma7455_core.c  |  1 -
> > > >  drivers/iio/accel/mma7660.c   |  1 -
> > > >  drivers/iio/accel/mma8452.c   |  1 -
> > > >  drivers/iio/accel/mma9551.c   |  1 -
> > > >  drivers/iio/accel/mma9553.c   |  1 -
> > > >  drivers/iio/accel/mxc4005.c   |  1 -
> > > >  drivers/iio/accel/mxc6255.c   |  1 -
> > > >  drivers/iio/accel/sca3000.c   |  1 -
> > > >  drivers/iio/accel/ssp_accel_sensor.c  |  1 -
> > 

RE: [PATCH v9 0/5] Add MMC software queue support

[BOUGH CHEN]

> -Original Message-
> From: linux-mmc-ow...@vger.kernel.org
> [mailto:linux-mmc-ow...@vger.kernel.org] On Behalf Of Baolin Wang
> Sent: 2020年2月19日 9:35
> To: Ulf Hansson 
> Cc: Adrian Hunter ; Asutosh Das
> ; Orson Zhai ; Chunyan
> Zhang ; Arnd Bergmann ; Linus
> Walleij ; Baolin Wang ;
> linux-...@vger.kernel.org; Linux Kernel Mailing List
> 
> Subject: Re: [PATCH v9 0/5] Add MMC software queue support
> 
> On Wed, Feb 19, 2020 at 7:38 AM Ulf Hansson 
> wrote:
> >
> > On Wed, 12 Feb 2020 at 05:14, Baolin Wang 
> wrote:
> > >
> > > Hi All,
> > >
> > > Now the MMC read/write stack will always wait for previous request
> > > is completed by mmc_blk_rw_wait(), before sending a new request to
> > > hardware, or queue a work to complete request, that will bring
> > > context switching overhead, especially for high I/O per second
> > > rates, to affect the IO performance.
> > >
> > > Thus this patch set will introduce the MMC software command queue
> > > support based on command queue engine's interfaces, and set the
> > > queue depth as 64 to allow more requests can be be prepared, merged
> > > and inserted into IO scheduler, but we only allow 2 requests in
> > > flight, that is enough to let the irq handler always trigger the
> > > next request without a context switch, as well as avoiding a long latency.
> > >
> > > Moreover we can expand the MMC software queue interface to support
> > > MMC packed request or packed command instead of adding new
> > > interfaces, according to previosus discussion.
> > >
> > > Below are some comparison data with fio tool. The fio command I used
> > > is like below with changing the '--rw' parameter and enabling the
> > > direct IO flag to measure the actual hardware transfer speed in 4K block
> size.
> > >
> > > ./fio --filename=/dev/mmcblk0p30 --direct=1 --iodepth=20 --rw=read
> > > --bs=4K --size=1G --group_reporting --numjobs=20 --name=test_read
> > >
> > > My eMMC card working at HS400 Enhanced strobe mode:
> > > [2.229856] mmc0: new HS400 Enhanced strobe MMC card at address
> 0001
> > > [2.237566] mmcblk0: mmc0:0001 HBG4a2 29.1 GiB
> > > [2.242621] mmcblk0boot0: mmc0:0001 HBG4a2 partition 1 4.00 MiB
> > > [2.249110] mmcblk0boot1: mmc0:0001 HBG4a2 partition 2 4.00 MiB
> > > [2.255307] mmcblk0rpmb: mmc0:0001 HBG4a2 partition 3 4.00 MiB,
> chardev (248:0)
> > >
> > > 1. Without MMC software queue
> > > I tested 5 times for each case and output a average speed.
> > >
> > > 1) Sequential read:
> > > Speed: 59.4MiB/s, 63.4MiB/s, 57.5MiB/s, 57.2MiB/s, 60.8MiB/s Average
> > > speed: 59.66MiB/s
> > >
> > > 2) Random read:
> > > Speed: 26.9MiB/s, 26.9MiB/s, 27.1MiB/s, 27.1MiB/s, 27.2MiB/s Average
> > > speed: 27.04MiB/s
> > >
> > > 3) Sequential write:
> > > Speed: 71.6MiB/s, 72.5MiB/s, 72.2MiB/s, 64.6MiB/s, 67.5MiB/s Average
> > > speed: 69.68MiB/s
> > >
> > > 4) Random write:
> > > Speed: 36.3MiB/s, 35.4MiB/s, 38.6MiB/s, 34MiB/s, 35.5MiB/s Average
> > > speed: 35.96MiB/s
> > >
> > > 2. With MMC software queue
> > > I tested 5 times for each case and output a average speed.
> > >
> > > 1) Sequential read:
> > > Speed: 59.2MiB/s, 60.4MiB/s, 63.6MiB/s, 60.3MiB/s, 59.9MiB/s Average
> > > speed: 60.68MiB/s
> > >
> > > 2) Random read:
> > > Speed: 31.3MiB/s, 31.4MiB/s, 31.5MiB/s, 31.3MiB/s, 31.3MiB/s Average
> > > speed: 31.36MiB/s
> > >
> > > 3) Sequential write:
> > > Speed: 71MiB/s, 71.8MiB/s, 72.3MiB/s, 72.2MiB/s, 71MiB/s Average
> > > speed: 71.66MiB/s
> > >
> > > 4) Random write:
> > > Speed: 68.9MiB/s, 68.7MiB/s, 68.8MiB/s, 68.6MiB/s, 68.8MiB/s Average
> > > speed: 68.76MiB/s
> > >
> > > Form above data, we can see the MMC software queue can help to
> > > improve some performance obviously for random read and write, though
> > > no obvious improvement for sequential read and write.
> > >
> > > Any comments are welcome. Thanks a lot.
> > >

Hi Baolin,

I refer to your code, and add the software queue support on i.MX based on the 
Linux next-20200602, but unfortunately, I see an obvious performance drop when 
change to use software queue.
I test on our imx850-evk board, with eMMC soldered.
From the result listing below, only random write has a little performance 
improve, for others, seems performance drop a lot.
I noticed that, this software queue need no-removable card, any other 
limitation? For host?
From the code logic, software queue complete the request in irq handler, seems 
no other change, I do not figure out why this will trigger a performance drop 
on my platform. Any comment would be appreciate! 
 
Without software queue, normal read/write method:
Sequential read: 56MB/s
Random read: 23.5MB/s
Sequential write: 43.7MB/s
Random write: 19MB/s

With mmc software queue:
Sequential read: 33.5MB/s
Random read: 18.7 MB/s
Sequential write: 37.7MB/s
Random write: 19.8MB/s


Here, I also list my change code to support software queue 

diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index eb85237bf2d6..996b8cc5c381 100644
--- a/driver

Re: [PATCH 5/6] vdpa: introduce virtio pci driver

[Michael S. Tsirkin]

On Mon, Jun 08, 2020 at 11:32:31AM +0800, Jason Wang wrote:
> 
> On 2020/6/7 下午9:51, Michael S. Tsirkin wrote:
> > On Fri, Jun 05, 2020 at 04:54:17PM +0800, Jason Wang wrote:
> > > On 2020/6/2 下午3:08, Jason Wang wrote:
> > > > > > +static const struct pci_device_id vp_vdpa_id_table[] = {
> > > > > > +    { PCI_DEVICE(PCI_VENDOR_ID_REDHAT_QUMRANET, PCI_ANY_ID) },
> > > > > > +    { 0 }
> > > > > > +};
> > > > > This looks like it'll create a mess with either virtio pci
> > > > > or vdpa being loaded at random. Maybe just don't specify
> > > > > any IDs for now. Down the road we could get a
> > > > > distinct vendor ID or a range of device IDs for this.
> > > > 
> > > > Right, will do.
> > > > 
> > > > Thanks
> > > 
> > > Rethink about this. If we don't specify any ID, the binding won't work.
> > We can bind manually. It's not really for production anyway, so
> > not a big deal imho.
> 
> 
> I think you mean doing it via "new_id", right.

I really meant driver_override. This is what people have been using
with pci-stub for years now.

> 
> > 
> > > How about using a dedicated subsystem vendor id for this?
> > > 
> > > Thanks
> > If virtio vendor id is used then standard driver is expected
> > to bind, right? Maybe use a dedicated vendor id?
> 
> 
> I meant something like:
> 
> static const struct pci_device_id vp_vdpa_id_table[] = {
>     { PCI_DEVICE_SUB(PCI_VENDOR_ID_REDHAT_QUMRANET, PCI_ANY_ID,
> VP_TEST_VENDOR_ID, VP_TEST_DEVICE_ID) },
>     { 0 }
> };
> 
> Thanks
> 

Then regular virtio will still bind to it. It has

drivers/virtio/virtio_pci_common.c: { 
PCI_DEVICE(PCI_VENDOR_ID_REDHAT_QUMRANET, PCI_ANY_ID) },


-- 
MST

[PATCH] ALSA: usb-audio: Add vendor, product and profile name for HP Thunderbolt Dock

[Kai-Heng Feng]

The HP Thunderbolt Dock has two separate USB devices, one is for speaker
and one is for headset. Add names for them so userspace can apply UCM
settings.

Signed-off-by: Kai-Heng Feng 
---
 sound/usb/quirks-table.h | 20 
 1 file changed, 20 insertions(+)

diff --git a/sound/usb/quirks-table.h b/sound/usb/quirks-table.h
index 6d6492195bdc..90d65bfa733d 100644
--- a/sound/usb/quirks-table.h
+++ b/sound/usb/quirks-table.h
@@ -40,6 +40,26 @@
.ifnum = QUIRK_NO_INTERFACE \
}
 
+/* HP Thunderbolt Dock Audio Headset */
+{
+   USB_DEVICE(0x03f0, 0x0269),
+   .driver_info = (unsigned long) &(const struct snd_usb_audio_quirk) {
+   .vendor_name = "HP",
+   .product_name = "Thunderbolt Dock Audio Headset",
+   .profile_name = "HP-Thunderbolt-Dock-Audio-Headset",
+   .ifnum = QUIRK_NO_INTERFACE
+   }
+},
+/* HP Thunderbolt Dock Audio Module */
+{
+   USB_DEVICE(0x03f0, 0x0567),
+   .driver_info = (unsigned long) &(const struct snd_usb_audio_quirk) {
+   .vendor_name = "HP",
+   .product_name = "Thunderbolt Dock Audio Module",
+   .profile_name = "HP-Thunderbolt-Dock-Audio-Module",
+   .ifnum = QUIRK_NO_INTERFACE
+   }
+},
 /* FTDI devices */
 {
USB_DEVICE(0x0403, 0xb8d8),
-- 
2.17.1

Re: [PATCHv2 0/2] SBS battery PEC support

[Marek Szyprowski]

Hi Sebastian,

On 06.06.2020 01:06, Sebastian Reichel wrote:
> Second try to enable PEC for SBS battery. Mainline currently
> has 3 different platforms using sbs-battery with an I2C driver
> not implementing I2C_M_RECV_LEN:
>
>   * i2c-exynos5
>   * i2c-rk3x
>   * i2c-tegra
>
> On those platforms PEC will be temporarly disabled for SBS
> functions requesting strings. I considered moving the emulation
> to I2C core, but it's specific to the SBS battery. The hack
> only works because the strings are constant.

Thanks for the update. Works fine on Samsung Exynos-based Chromebooks: 
Snow, Peach-Pit and Peach-Pi.

Tested-by: Marek Szyprowski 

> Changes since PATCHv1:
>   * dropped all applied changes
>   * rebased on top of power-supply's for-next branch
>   * keep existing string reading method as fallback
>
> -- Sebastian
>
> Sebastian Reichel (2):
>power: supply: sbs-battery: use i2c_smbus_read_block_data()
>power: supply: sbs-battery: add PEC support"
>
>   drivers/power/supply/sbs-battery.c | 89 +-
>   1 file changed, 87 insertions(+), 2 deletions(-)
>
Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

Re: next-0519 on thinkpad x60: sound related? window manager crash

[Christoph Hellwig]

Can you do a listing using gdb where this happens?

gdb vmlinux

l *(snd_pcm_hw_params+0x3f3)

?

On Sun, Jun 07, 2020 at 11:58:21AM -0400, Alex Xu (Hello71) wrote:
> I have a similar issue, caused between aaa2faab4ed8 and b170290c2836.
> 
> [   20.263098] BUG: unable to handle page fault for address: b2b582cc2000
> [   20.263104] #PF: supervisor write access in kernel mode
> [   20.263105] #PF: error_code(0x000b) - reserved bit violation
> [   20.263107] PGD 3fd03b067 P4D 3fd03b067 PUD 3fd03c067 PMD 3f8822067 PTE 
> 8000273942ab2163
> [   20.263113] Oops: 000b [#1] PREEMPT SMP
> [   20.263117] CPU: 3 PID: 691 Comm: mpv Not tainted 
> 5.7.0-11262-gb170290c2836 #1
> [   20.263119] Hardware name: To Be Filled By O.E.M. To Be Filled By 
> O.E.M./B450 Pro4, BIOS P4.10 03/05/2020
> [   20.263125] RIP: 0010:__memset+0x24/0x30
> [   20.263128] Code: cc cc cc cc cc cc 0f 1f 44 00 00 49 89 f9 48 89 d1 83 e2 
> 07 48 c1 e9 03 40 0f b6 f6 48 b8 01 01 01 01 01 01 01 01 48 0f af c6  48 
> ab 89 d1 f3 aa 4c 89 c8 c3 90 49 89 f9 40 88 f0 48 89 d1 f3
> [   20.263131] RSP: 0018:b2b583d07e10 EFLAGS: 00010216
> [   20.263133] RAX:  RBX: 8b8000102c00 RCX: 
> 4000
> [   20.263134] RDX:  RSI:  RDI: 
> b2b582cc2000
> [   20.263136] RBP: 8b8000101000 R08:  R09: 
> b2b582cc2000
> [   20.263137] R10: 5356 R11: 8b8000102c18 R12: 
> 
> [   20.263139] R13:  R14: 8b8039944200 R15: 
> 9794daa0
> [   20.263141] FS:  7f41aa4b4200() GS:8b803ecc() 
> knlGS:
> [   20.263143] CS:  0010 DS:  ES:  CR0: 80050033
> [   20.263144] CR2: b2b582cc2000 CR3: 0003b6731000 CR4: 
> 003406e0
> [   20.263146] Call Trace:
> [   20.263151]  ? snd_pcm_hw_params+0x3f3/0x47a
> [   20.263154]  ? snd_pcm_common_ioctl+0xf2/0xf73
> [   20.263158]  ? snd_pcm_ioctl+0x1e/0x29
> [   20.263161]  ? ksys_ioctl+0x77/0x91
> [   20.263163]  ? __x64_sys_ioctl+0x11/0x14
> [   20.263166]  ? do_syscall_64+0x3d/0xf5
> [   20.263170]  ? entry_SYSCALL_64_after_hwframe+0x44/0xa9
> [   20.263173] Modules linked in: uvcvideo videobuf2_vmalloc videobuf2_memops 
> videobuf2_v4l2 videodev snd_usb_audio videobuf2_common snd_hwdep 
> snd_usbmidi_lib input_leds snd_rawmidi led_class
> [   20.263182] CR2: b2b582cc2000
> [   20.263184] ---[ end trace c6b47a774b91f0a0 ]---
> [   20.263187] RIP: 0010:__memset+0x24/0x30
> [   20.263190] Code: cc cc cc cc cc cc 0f 1f 44 00 00 49 89 f9 48 89 d1 83 e2 
> 07 48 c1 e9 03 40 0f b6 f6 48 b8 01 01 01 01 01 01 01 01 48 0f af c6  48 
> ab 89 d1 f3 aa 4c 89 c8 c3 90 49 89 f9 40 88 f0 48 89 d1 f3
> [   20.263192] RSP: 0018:b2b583d07e10 EFLAGS: 00010216
> [   20.263193] RAX:  RBX: 8b8000102c00 RCX: 
> 4000
> [   20.263195] RDX:  RSI:  RDI: 
> b2b582cc2000
> [   20.263196] RBP: 8b8000101000 R08:  R09: 
> b2b582cc2000
> [   20.263197] R10: 5356 R11: 8b8000102c18 R12: 
> 
> [   20.263199] R13:  R14: 8b8039944200 R15: 
> 9794daa0
> [   20.263201] FS:  7f41aa4b4200() GS:8b803ecc() 
> knlGS:
> [   20.263202] CS:  0010 DS:  ES:  CR0: 80050033
> [   20.263204] CR2: b2b582cc2000 CR3: 0003b6731000 CR4: 
> 003406e0
> 
> I bisected this to 82fef0ad811f "x86/mm: unencrypted non-blocking DMA 
> allocations use coherent pools". Reverting 1ee18de92927 resolves the 
> issue.
> 
> Looks like Thinkpad X60 doesn't have VT-d, but could still be DMA 
> related.
---end quoted text---

[PATCH] virtio_mem: prevent overflow with subblock size

[Michael S. Tsirkin]

If subblock size is large (e.g. 1G) 32 bit math involving it
can overflow. Rather than try to catch all instances of that,
let's tweak block size to 64 bit.

It ripples through UAPI which is an ABI change, but it's not too late to
make it, and it will allow supporting >4Gbyte blocks while might
become necessary down the road.

Fixes: 5f1f79bbc9e26 ("virtio-mem: Paravirtualized memory hotplug")
Signed-off-by: Michael S. Tsirkin 
---
 drivers/virtio/virtio_mem.c | 14 +++---
 include/uapi/linux/virtio_mem.h |  4 ++--
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/virtio/virtio_mem.c b/drivers/virtio/virtio_mem.c
index 2f357142ea5e..7b1bece8a331 100644
--- a/drivers/virtio/virtio_mem.c
+++ b/drivers/virtio/virtio_mem.c
@@ -77,7 +77,7 @@ struct virtio_mem {
uint64_t requested_size;
 
/* The device block size (for communicating with the device). */
-   uint32_t device_block_size;
+   uint64_t device_block_size;
/* The translated node id. NUMA_NO_NODE in case not specified. */
int nid;
/* Physical start address of the memory region. */
@@ -86,7 +86,7 @@ struct virtio_mem {
uint64_t region_size;
 
/* The subblock size. */
-   uint32_t subblock_size;
+   uint64_t subblock_size;
/* The number of subblocks per memory block. */
uint32_t nb_sb_per_mb;
 
@@ -1698,9 +1698,9 @@ static int virtio_mem_init(struct virtio_mem *vm)
 * - At least the device block size.
 * In the worst case, a single subblock per memory block.
 */
-   vm->subblock_size = PAGE_SIZE * 1u << max_t(uint32_t, MAX_ORDER - 1,
-   pageblock_order);
-   vm->subblock_size = max_t(uint32_t, vm->device_block_size,
+   vm->subblock_size = PAGE_SIZE * 1ul << max_t(uint32_t, MAX_ORDER - 1,
+pageblock_order);
+   vm->subblock_size = max_t(uint64_t, vm->device_block_size,
  vm->subblock_size);
vm->nb_sb_per_mb = memory_block_size_bytes() / vm->subblock_size;
 
@@ -1713,8 +1713,8 @@ static int virtio_mem_init(struct virtio_mem *vm)
 
dev_info(&vm->vdev->dev, "start address: 0x%llx", vm->addr);
dev_info(&vm->vdev->dev, "region size: 0x%llx", vm->region_size);
-   dev_info(&vm->vdev->dev, "device block size: 0x%x",
-vm->device_block_size);
+   dev_info(&vm->vdev->dev, "device block size: 0x%llx",
+(unsigned long long)vm->device_block_size);
dev_info(&vm->vdev->dev, "memory block size: 0x%lx",
 memory_block_size_bytes());
dev_info(&vm->vdev->dev, "subblock size: 0x%x",
diff --git a/include/uapi/linux/virtio_mem.h b/include/uapi/linux/virtio_mem.h
index a455c488a995..a9ffe041843c 100644
--- a/include/uapi/linux/virtio_mem.h
+++ b/include/uapi/linux/virtio_mem.h
@@ -185,10 +185,10 @@ struct virtio_mem_resp {
 
 struct virtio_mem_config {
/* Block size and alignment. Cannot change. */
-   __u32 block_size;
+   __u64 block_size;
/* Valid with VIRTIO_MEM_F_ACPI_PXM. Cannot change. */
__u16 node_id;
-   __u16 padding;
+   __u8 padding[6];
/* Start address of the memory region. Cannot change. */
__u64 addr;
/* Region size (maximum). Cannot change. */
-- 
MST

Re: [PATCH v4] block: Fix use-after-free in blkdev_get()

[Christoph Hellwig]

Looks good,

Reviewed-by: Christoph Hellwig 

Can you dig into the history for a proper fixes tag?

Re: [PATCH] Fix build failure of OCFS2 when TCP/IP is disabled

[Christoph Hellwig]

On Sat, Jun 06, 2020 at 02:08:26PM -0500, Tom Seewald wrote:
> After commit 12abc5ee7873 ("tcp: add tcp_sock_set_nodelay") and
> commit c488aeadcbd0 ("tcp: add tcp_sock_set_user_timeout"), building the
> kernel with OCFS2_FS=y but without INET=y causes it to fail with:
> 
> ld: fs/ocfs2/cluster/tcp.o: in function `o2net_accept_many':
> tcp.c:(.text+0x21b1): undefined reference to `tcp_sock_set_nodelay'
> ld: tcp.c:(.text+0x21c1): undefined reference to `tcp_sock_set_user_timeout
> '
> ld: fs/ocfs2/cluster/tcp.o: in function `o2net_start_connect':
> tcp.c:(.text+0x2633): undefined reference to `tcp_sock_set_nodelay'
> ld: tcp.c:(.text+0x2643): undefined reference to `tcp_sock_set_user_timeout
> '
> 
> This is due to tcp_sock_set_nodelay() and tcp_sock_set_user_timeout() being
> declared in linux/tcp.h and defined in net/ipv4/tcp.c, which depend on
> TCP/IP being enabled.
> 
> To fix this, make OCFS2_FS depend on INET=y which already requires NET=y.
> 
> Signed-off-by: Tom Seewald 

Looks good, and this is the same that I did for nfsd:

Acked-by: Christoph Hellwig 

Re: [PATCH v11 00/16] per memcg lru lock

[Alex Shi]

在 2020/6/8 下午12:15, Hugh Dickins 写道:
>>  24 files changed, 487 insertions(+), 312 deletions(-)
> Hi Alex,
> 
> I didn't get to try v10 at all, waited until Johannes's preparatory
> memcg swap cleanup was in mmotm; but I have spent a while thrashing
> this v11, and can happily report that it is much better than v9 etc:
> I believe this memcg lru_lock work will soon be ready for v5.9.
> 
> I've not yet found any flaw at the swapping end, but fixes are needed
> for isolate_migratepages_block() and mem_cgroup_move_account(): I've
> got a series of 4 fix patches to send you (I guess two to fold into
> existing patches of yours, and two to keep as separate from me).
> 
> I haven't yet written the patch descriptions, will return to that
> tomorrow.  I expect you will be preparing a v12 rebased on v5.8-rc1
> or v5.8-rc2, and will be able to include these fixes in that.

I am very glad to get your help on this feature! 

and looking forward for your fixes tomorrow. :)

Thanks a lot!
Alex

Re: [PATCH RFC 03/13] vhost: batching fetches

[Michael S. Tsirkin]

On Mon, Jun 08, 2020 at 11:35:40AM +0800, Jason Wang wrote:
> 
> On 2020/6/7 下午9:57, Michael S. Tsirkin wrote:
> > On Fri, Jun 05, 2020 at 11:40:17AM +0800, Jason Wang wrote:
> > > On 2020/6/4 下午4:59, Michael S. Tsirkin wrote:
> > > > On Wed, Jun 03, 2020 at 03:27:39PM +0800, Jason Wang wrote:
> > > > > On 2020/6/2 下午9:06, Michael S. Tsirkin wrote:
> > > > > > With this patch applied, new and old code perform identically.
> > > > > > 
> > > > > > Lots of extra optimizations are now possible, e.g.
> > > > > > we can fetch multiple heads with copy_from/to_user now.
> > > > > > We can get rid of maintaining the log array.  Etc etc.
> > > > > > 
> > > > > > Signed-off-by: Michael S. Tsirkin
> > > > > > Signed-off-by: Eugenio Pérez
> > > > > > Link:https://lore.kernel.org/r/20200401183118.8334-4-epere...@redhat.com
> > > > > > Signed-off-by: Michael S. Tsirkin
> > > > > > ---
> > > > > > drivers/vhost/test.c  |  2 +-
> > > > > > drivers/vhost/vhost.c | 47 
> > > > > > ++-
> > > > > > drivers/vhost/vhost.h |  5 -
> > > > > > 3 files changed, 47 insertions(+), 7 deletions(-)
> > > > > > 
> > > > > > diff --git a/drivers/vhost/test.c b/drivers/vhost/test.c
> > > > > > index 9a3a09005e03..02806d6f84ef 100644
> > > > > > --- a/drivers/vhost/test.c
> > > > > > +++ b/drivers/vhost/test.c
> > > > > > @@ -119,7 +119,7 @@ static int vhost_test_open(struct inode *inode, 
> > > > > > struct file *f)
> > > > > > dev = &n->dev;
> > > > > > vqs[VHOST_TEST_VQ] = &n->vqs[VHOST_TEST_VQ];
> > > > > > n->vqs[VHOST_TEST_VQ].handle_kick = handle_vq_kick;
> > > > > > -   vhost_dev_init(dev, vqs, VHOST_TEST_VQ_MAX, UIO_MAXIOV,
> > > > > > +   vhost_dev_init(dev, vqs, VHOST_TEST_VQ_MAX, UIO_MAXIOV + 64,
> > > > > >VHOST_TEST_PKT_WEIGHT, 
> > > > > > VHOST_TEST_WEIGHT, NULL);
> > > > > > f->private_data = n;
> > > > > > diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> > > > > > index 8f9a07282625..aca2a5b0d078 100644
> > > > > > --- a/drivers/vhost/vhost.c
> > > > > > +++ b/drivers/vhost/vhost.c
> > > > > > @@ -299,6 +299,7 @@ static void vhost_vq_reset(struct vhost_dev 
> > > > > > *dev,
> > > > > > {
> > > > > > vq->num = 1;
> > > > > > vq->ndescs = 0;
> > > > > > +   vq->first_desc = 0;
> > > > > > vq->desc = NULL;
> > > > > > vq->avail = NULL;
> > > > > > vq->used = NULL;
> > > > > > @@ -367,6 +368,11 @@ static int vhost_worker(void *data)
> > > > > > return 0;
> > > > > > }
> > > > > > +static int vhost_vq_num_batch_descs(struct vhost_virtqueue *vq)
> > > > > > +{
> > > > > > +   return vq->max_descs - UIO_MAXIOV;
> > > > > > +}
> > > > > 1 descriptor does not mean 1 iov, e.g userspace may pass several 1 
> > > > > byte
> > > > > length memory regions for us to translate.
> > > > > 
> > > > Yes but I don't see the relevance. This tells us how many descriptors to
> > > > batch, not how many IOVs.
> > > Yes, but questions are:
> > > 
> > > - this introduce another obstacle to support more than 1K queue size
> > > - if we support 1K queue size, does it mean we need to cache 1K 
> > > descriptors,
> > > which seems a large stress on the cache
> > > 
> > > Thanks
> > > 
> > > 
> > Still don't understand the relevance. We support up to 1K descriptors
> > per buffer just for IOV since we always did. This adds 64 more
> > descriptors - is that a big deal?
> 
> 
> If I understanding correctly, for net, the code tries to batch descriptors
> for at last one packet.
> 
> If we allow 1K queue size then we allow a packet that consists of 1K
> descriptors. Then we need to cache 1K descriptors.
> 
> Thanks

That case is already so pathological, I am not at all worried about
it performing well.

-- 
MST

Re: [PATCH v4 1/3] virtio: add dma-buf support for exported objects

[Michael S. Tsirkin]

On Mon, Jun 08, 2020 at 10:33:09AM +0900, David Stevens wrote:
> On Sun, Jun 7, 2020 at 5:04 AM Michael S. Tsirkin  wrote:
> >
> > On Fri, Jun 05, 2020 at 10:28:42AM +0900, David Stevens wrote:
> > > On Fri, Jun 5, 2020 at 4:05 AM Michael S. Tsirkin  wrote:
> > > >
> > > > On Tue, May 26, 2020 at 07:58:09PM +0900, David Stevens wrote:
> > > > > This change adds a new flavor of dma-bufs that can be used by virtio
> > > > > drivers to share exported objects. A virtio dma-buf can be queried by
> > > > > virtio drivers to obtain the UUID which identifies the underlying
> > > > > exported object.
> > > > >
> > > > > Signed-off-by: David Stevens 
> > > >
> > > > Is this just for graphics? If yes I'd rather we put it in the graphics
> > > > driver. We can always move it later ...
> > >
> > > As stated in the cover letter, this will be used by virtio-video.
> > >
> > > The proposed virtio-video patches: 
> > > https://markmail.org/thread/p5d3k566srtdtute
> > > The patch which imports these dma-bufs (slightly out of data, uses v3
> > > of this patch set): https://markmail.org/thread/j4xlqaaim266qpks
> > >
> > > > > ---
> > > > >  drivers/virtio/Makefile |  2 +-
> > > > >  drivers/virtio/virtio.c |  6 +++
> > > > >  drivers/virtio/virtio_dma_buf.c | 89 
> > > > > +
> > > > >  include/linux/virtio.h  |  1 +
> > > > >  include/linux/virtio_dma_buf.h  | 58 +
> > > > >  5 files changed, 155 insertions(+), 1 deletion(-)
> > > > >  create mode 100644 drivers/virtio/virtio_dma_buf.c
> > > > >  create mode 100644 include/linux/virtio_dma_buf.h
> > > > >
> > > > > diff --git a/drivers/virtio/Makefile b/drivers/virtio/Makefile
> > > > > index 29a1386ecc03..ecdae5b596de 100644
> > > > > --- a/drivers/virtio/Makefile
> > > > > +++ b/drivers/virtio/Makefile
> > > > > @@ -1,5 +1,5 @@
> > > > >  # SPDX-License-Identifier: GPL-2.0
> > > > > -obj-$(CONFIG_VIRTIO) += virtio.o virtio_ring.o
> > > > > +obj-$(CONFIG_VIRTIO) += virtio.o virtio_ring.o virtio_dma_buf.o
> > > > >  obj-$(CONFIG_VIRTIO_MMIO) += virtio_mmio.o
> > > > >  obj-$(CONFIG_VIRTIO_PCI) += virtio_pci.o
> > > > >  virtio_pci-y := virtio_pci_modern.o virtio_pci_common.o
> > > > > diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c
> > > > > index a977e32a88f2..5d46f0ded92d 100644
> > > > > --- a/drivers/virtio/virtio.c
> > > > > +++ b/drivers/virtio/virtio.c
> > > > > @@ -357,6 +357,12 @@ int register_virtio_device(struct virtio_device 
> > > > > *dev)
> > > > >  }
> > > > >  EXPORT_SYMBOL_GPL(register_virtio_device);
> > > > >
> > > > > +bool is_virtio_device(struct device *dev)
> > > > > +{
> > > > > + return dev->bus == &virtio_bus;
> > > > > +}
> > > > > +EXPORT_SYMBOL_GPL(is_virtio_device);
> > > > > +
> > > > >  void unregister_virtio_device(struct virtio_device *dev)
> > > > >  {
> > > > >   int index = dev->index; /* save for after device release */
> > > > > diff --git a/drivers/virtio/virtio_dma_buf.c 
> > > > > b/drivers/virtio/virtio_dma_buf.c
> > > > > new file mode 100644
> > > > > index ..23e3399b11ed
> > > > > --- /dev/null
> > > > > +++ b/drivers/virtio/virtio_dma_buf.c
> > > > > @@ -0,0 +1,89 @@
> > > > > +// SPDX-License-Identifier: GPL-2.0-or-later
> > > > > +/*
> > > > > + * dma-bufs for virtio exported objects
> > > > > + *
> > > > > + * Copyright (C) 2020 Google, Inc.
> > > > > + */
> > > > > +
> > > > > +#include 
> > > > > +
> > > > > +/**
> > > > > + * virtio_dma_buf_export - Creates a new dma-buf for a virtio 
> > > > > exported object
> > > > > + *
> > > > > + * This wraps dma_buf_export() to allow virtio drivers to create a 
> > > > > dma-buf
> > > > > + * for an virtio exported object that can be queried by other virtio 
> > > > > drivers
> > > > > + * for the object's UUID.
> > > > > + */
> > > > > +struct dma_buf *virtio_dma_buf_export(
> > > > > + const struct virtio_dma_buf_export_info 
> > > > > *virtio_exp_info)
> > > > > +{
> > > > > + struct dma_buf_export_info exp_info;
> > > > > +
> > > > > + if (!virtio_exp_info->ops
> > > > > + || virtio_exp_info->ops->ops.attach != 
> > > > > &virtio_dma_buf_attach
> > > > > + || !virtio_exp_info->ops->get_uuid) {
> > > > > + return ERR_PTR(-EINVAL);
> > > > > + }
> > > > > +
> > > > > + exp_info.exp_name = virtio_exp_info->exp_name;
> > > > > + exp_info.owner = virtio_exp_info->owner;
> > > > > + exp_info.ops = &virtio_exp_info->ops->ops;
> > > > > + exp_info.size = virtio_exp_info->size;
> > > > > + exp_info.flags = virtio_exp_info->flags;
> > > > > + exp_info.resv = virtio_exp_info->resv;
> > > > > + exp_info.priv = virtio_exp_info->priv;
> > > > > + BUILD_BUG_ON(sizeof(struct virtio_dma_buf_export_info)
> > > > > +  != sizeof(struct dma_buf_export_info));
> > > >
> > > > This is the only part that gives me pause. Why do we need this hack?
> > > > What's wrong with just using dma_b

Re: Forest Bond ,Greg Kroah-Hartman ,de...@driverdev.osuosl.org,linux-kernel@vger.kernel.org

[Julia Lawall]

On Mon, 8 Jun 2020, Al Viro wrote:

> On Sun, Jun 07, 2020 at 10:41:56PM +, Rodolfo C. Villordo wrote:
> > Multiple line over 80 characters fixes by splitting in multiple lines.
> > Warning found by checkpatch.pl
>
> I doubt that checkpatch.pl can catch the real problems there:
>
> * Hungarian Notation Sucks.  Really.
> * so does CamelCase, especially for wonders like s_uGetRTSCTSRsvTime

Rodolfo,

If you work hard with Coccinelle and python scripting, it can help with
the first two problems.

julia


> * local variables are useful
> * if a long expression keeps cropping up all over the place, you
> probably are missing an inline helper.
>
> PS: this
> > -   buf->time_stamp_off_a = vnt_time_stamp_off(pDevice, 
> > wCurrentRate);
> > -   buf->time_stamp_off_b = vnt_time_stamp_off(pDevice, 
> > pDevice->byTopCCKBasicRate);
> > +   buf->time_stamp_off_a =
> > +   vnt_time_stamp_off(pDevice, wCurrentRate);
> > +   buf->time_stamp_off_b =
> > +   vnt_time_stamp_off(pDevice,
> > +  pDevice->byTopCCKBasicRate);
> is no improvement.
>

Re: [PATCH] virtio-mem: drop unnecessary initialization

[Jason Wang]

On 2020/6/8 下午1:45, Michael S. Tsirkin wrote:

rc is initialized to -ENIVAL but that's never used. Drop it.

Fixes: 5f1f79bbc9e2 ("virtio-mem: Paravirtualized memory hotplug")
Reported-by: kernel test robot 
Signed-off-by: Michael S. Tsirkin 
---
  drivers/virtio/virtio_mem.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/virtio/virtio_mem.c b/drivers/virtio/virtio_mem.c
index f658fe9149be..2f357142ea5e 100644
--- a/drivers/virtio/virtio_mem.c
+++ b/drivers/virtio/virtio_mem.c
@@ -1768,7 +1768,7 @@ static void virtio_mem_delete_resource(struct virtio_mem 
*vm)
  static int virtio_mem_probe(struct virtio_device *vdev)
  {
struct virtio_mem *vm;
-   int rc = -EINVAL;
+   int rc;
  
  	BUILD_BUG_ON(sizeof(struct virtio_mem_req) != 24);

BUILD_BUG_ON(sizeof(struct virtio_mem_resp) != 10);



Acked-by: Jason Wang 

[PATCH 0/2] Driver for watchdog timer on Intel Lightning Mountain SoC

[Dilip Kota]

This patch series adds watchdog timer driver and respective yaml schemas
for watchdog timer on Intel Lightning Mountain SoC.

This patch series is rebased and tested on mainline linux kernel 5.7:
base-commit: 3d77e6a8804a ("Linux 5.7")
tags: v5.7

Dilip Kota (2):
  dt-bindings: watchdog: intel: Add YAML Schemas for Watchdog timer
  watchdog: intel: Watchdog timer support on Lightning Mountain

 .../bindings/watchdog/intel,lgm-gptc-wdt.yaml  |  75 
 drivers/watchdog/Kconfig   |  13 +
 drivers/watchdog/Makefile  |   1 +
 drivers/watchdog/intel_lgm_gptc_wdt.c  | 420 +
 4 files changed, 509 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/watchdog/intel,lgm-gptc-wdt.yaml
 create mode 100644 drivers/watchdog/intel_lgm_gptc_wdt.c

-- 
2.11.0

[PATCH 1/2] dt-bindings: watchdog: intel: Add YAML Schemas for Watchdog timer

[Dilip Kota]

Add YAML schemas for the watchdog timer on Intel Lightning
Mountain SoC.

Signed-off-by: Dilip Kota 
---
 .../bindings/watchdog/intel,lgm-gptc-wdt.yaml  | 75 ++
 1 file changed, 75 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/watchdog/intel,lgm-gptc-wdt.yaml

diff --git a/Documentation/devicetree/bindings/watchdog/intel,lgm-gptc-wdt.yaml 
b/Documentation/devicetree/bindings/watchdog/intel,lgm-gptc-wdt.yaml
new file mode 100644
index 0..83dc39a5090c1
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/intel,lgm-gptc-wdt.yaml
@@ -0,0 +1,75 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/watchdog/intel,lgm-gptc-wdt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Intel Lightning Mountain Watchdog timer.
+
+maintainers:
+  - Dilip Kota 
+
+description: |
+  Intel Lightning Mountain SoC has General Purpose Timer Counter(GPTC) which 
can
+  be configured as Clocksource, real time clock and Watchdog timer.
+  Each General Purpose Timer Counter has three timers. And total four General
+  Purpose Timer Counters are present on Lightning Mountain SoC which sums up
+  to 12 timers.
+  Lightning Mountain has four CPUs and each CPU is configured with one GPTC
+  timer as watchdog timer. Total four timers are configured as watchdog timers
+  on Lightning Mountain SoC.
+
+allOf:
+  - $ref: "watchdog.yaml#"
+
+properties:
+  compatible:
+enum:
+  - intel,lgm-gptc-wdt
+
+  reg:
+maxItems: 1
+
+  clocks:
+items:
+  - description: Frequency clock
+  - description: Core clock
+
+  clock-names:
+items:
+  - const: freq
+  - const: gptc
+
+  intel,wdt-rst-hndl:
+$ref: /schemas/types.yaml#/definitions/phandle
+description: Watchdog timer registers handle
+
+  intel,timer-cfg:
+description: Watchdog Timer id and CPU id
+allOf:
+  - $ref: /schemas/types.yaml#/definitions/uint32-array
+  - minItems: 2
+maxItems: 4
+items:
+  minimum: 0
+  maximum: 3
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - clock-names
+  - intel,wdt-rst-hndl
+  - intel,timer-cfg
+
+examples:
+  - |
+watchdog@e250 {
+  compatible = "intel,lgm-gptc-wdt";
+  reg = <0xe250 0x1>;
+  intel,wdt-rst-hndl = <&sysconf>;
+  clocks = <&cgu0 31>, <&cgu0 136>;
+  clock-names = "freq", "gptc";
+  timeout-sec = <30>;
+  intel,timer-cfg =  <1 0 2 1>;
+};
-- 
2.11.0

[PATCH 2/2] watchdog: intel: Watchdog timer support on Lightning Mountain

[Dilip Kota]

On Intel Lightning Mountain SoC, General Purpose Timer Counter(GPTC)
programmable as clocksource, real time clock or watchdog timer.

This driver configures GPTC as Watchdog timer and triggers reset signal
to CPU on timeout.

Signed-off-by: Dilip Kota 
---
 drivers/watchdog/Kconfig  |  13 ++
 drivers/watchdog/Makefile |   1 +
 drivers/watchdog/intel_lgm_gptc_wdt.c | 420 ++
 3 files changed, 434 insertions(+)
 create mode 100644 drivers/watchdog/intel_lgm_gptc_wdt.c

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 0663c604bd642..8009c11e75dda 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -1789,6 +1789,19 @@ config IMGPDC_WDT
  To compile this driver as a loadable module, choose M here.
  The module will be called imgpdc_wdt.
 
+config INTEL_LGM_GPTC_WDT
+   tristate "INTEL LGM SoC Watchdog"
+   depends on X86 || COMPILE_TEST
+   depends on OF && HAS_IOMEM
+   select REGMAP
+   select MFD_SYSCON
+   select WATCHDOG_CORE
+   help
+ Driver for Watchdog Timer on Intel Lightning Mountain SoC.
+
+ To compile this driver as a loadable module, choose M here.
+ The module will be called intel_lgm_gptc_wdt.
+
 config LANTIQ_WDT
tristate "Lantiq SoC watchdog"
depends on LANTIQ
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 6de2e4ceef190..92c99e4c46eb7 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -166,6 +166,7 @@ obj-$(CONFIG_TXX9_WDT) += txx9wdt.o
 obj-$(CONFIG_OCTEON_WDT) += octeon-wdt.o
 octeon-wdt-y := octeon-wdt-main.o octeon-wdt-nmi.o
 obj-$(CONFIG_LANTIQ_WDT) += lantiq_wdt.o
+obj-$(CONFIG_INTEL_LGM_GPTC_WDT) += intel_lgm_gptc_wdt.o
 obj-$(CONFIG_LOONGSON1_WDT) += loongson1_wdt.o
 obj-$(CONFIG_RALINK_WDT) += rt2880_wdt.o
 obj-$(CONFIG_IMGPDC_WDT) += imgpdc_wdt.o
diff --git a/drivers/watchdog/intel_lgm_gptc_wdt.c 
b/drivers/watchdog/intel_lgm_gptc_wdt.c
new file mode 100644
index 0..52be7cc194f8f
--- /dev/null
+++ b/drivers/watchdog/intel_lgm_gptc_wdt.c
@@ -0,0 +1,420 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 Intel Corporation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define GPTC_CLC   0x00
+#define GPTC_CLC_SUSPEND   BIT(4)
+#define GPTC_CLC_RMC   GENMASK(15, 8)
+
+/* divider 10 to produce 200 / 10 = 20 MHz clock */
+#define CLC_RMC_DIV10
+
+#define GPTC_CON(X)(0x10 + (X) * 0x20)
+#define GPTC_CON_CNT_UPBIT(1)
+#define GPTC_CON_ONESHOT   BIT(3)
+#define GPTC_CON_EXT   BIT(4)
+
+#define GPTC_RUN(X)(0x18 + (X) * 0x20)
+#define GPTC_RUN_ENBIT(0)
+#define GPTC_RUN_STOP  BIT(1)
+#define GPTC_RUN_RELOADBIT(2)
+
+#define GPTC_RLD(X)(0x20 + (X) * 0x20)
+#define GPTC_CNT(X)(0x28 + (X) * 0x20)
+
+#define GPTC_IRNENCLR  0xF0
+#define GPTC_IRNEN 0xF4
+#define GPTC_IRNCR 0xFC
+
+/* Watchdog Timeout Reset register offset and bitfeilds */
+#define BIA_WDT_RST_EN 0x1E0
+#define BIA_WDTBIT(6)
+
+#define MAX_TIMERID2
+#define MAX_CPUID  3
+#define TIMER_MARGIN_SEC   300
+
+static bool nowayout = WATCHDOG_NOWAYOUT;
+module_param(nowayout, bool, 0);
+MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started\n"
+   " (default=" __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
+
+struct lgm_gptc_timer {
+   struct lgm_gptc_wdt *wdt_node;
+   struct watchdog_device  wdd;
+   unsigned inttid;
+   unsigned intcpuid;
+   unsigned intfrequency;
+   unsigned intcycles;
+   boolenable;
+};
+
+struct lgm_gptc_wdt {
+   struct device   *dev;
+   void __iomem*gptc_base;
+   struct regmap   *rst_hndl;
+   struct clk  *freqclk;
+   struct clk  *gateclk;
+   unsigned intfpifreq;
+   enum cpuhp_statestate;
+};
+
+DEFINE_PER_CPU(struct lgm_gptc_timer, lgm_timer_per_cpu);
+
+static void lgm_gptc_wdt_cfg_timer(struct lgm_gptc_timer *timer)
+{
+   struct lgm_gptc_wdt *wdt_node = timer->wdt_node;
+   void __iomem *base = wdt_node->gptc_base;
+   u32 val;
+
+   val = readl(base + GPTC_CON(timer->tid));
+   val &= ~GPTC_CON_CNT_UP;
+   val |= GPTC_CON_EXT;
+   val &= ~GPTC_CON_ONESHOT;
+   writel(val, base + GPTC_CON(timer->tid));
+   writel(U32_MAX, base + GPTC_RLD(timer->tid));
+   writel(BIT(timer->tid * 2), base + GPTC_IRNEN);
+}
+
+static void lgm_gptc_wdt_init(struct lgm_gptc_wdt *wdt_node)
+{
+   void __iomem *base = wdt_node->gptc_base;
+
+   writel(GPTC_CLC_SUSPEND | FIELD_PREP(GPTC_CLC_RMC, CLC_R

Re: Forest Bond ,Greg Kroah-Hartman ,de...@driverdev.osuosl.org,linux-kernel@vger.kernel.org

[Al Viro]

On Sun, Jun 07, 2020 at 10:41:56PM +, Rodolfo C. Villordo wrote:
> Multiple line over 80 characters fixes by splitting in multiple lines.
> Warning found by checkpatch.pl

I doubt that checkpatch.pl can catch the real problems there:

* Hungarian Notation Sucks.  Really.
* so does CamelCase, especially for wonders like s_uGetRTSCTSRsvTime
* local variables are useful
* if a long expression keeps cropping up all over the place, you
probably are missing an inline helper.

PS: this
> - buf->time_stamp_off_a = vnt_time_stamp_off(pDevice, 
> wCurrentRate);
> - buf->time_stamp_off_b = vnt_time_stamp_off(pDevice, 
> pDevice->byTopCCKBasicRate);
> + buf->time_stamp_off_a =
> + vnt_time_stamp_off(pDevice, wCurrentRate);
> + buf->time_stamp_off_b =
> + vnt_time_stamp_off(pDevice,
> +pDevice->byTopCCKBasicRate);
is no improvement.

[PATCH] virtio-mem: drop unnecessary initialization

[Michael S. Tsirkin]

rc is initialized to -ENIVAL but that's never used. Drop it.

Fixes: 5f1f79bbc9e2 ("virtio-mem: Paravirtualized memory hotplug")
Reported-by: kernel test robot 
Signed-off-by: Michael S. Tsirkin 
---
 drivers/virtio/virtio_mem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/virtio/virtio_mem.c b/drivers/virtio/virtio_mem.c
index f658fe9149be..2f357142ea5e 100644
--- a/drivers/virtio/virtio_mem.c
+++ b/drivers/virtio/virtio_mem.c
@@ -1768,7 +1768,7 @@ static void virtio_mem_delete_resource(struct virtio_mem 
*vm)
 static int virtio_mem_probe(struct virtio_device *vdev)
 {
struct virtio_mem *vm;
-   int rc = -EINVAL;
+   int rc;
 
BUILD_BUG_ON(sizeof(struct virtio_mem_req) != 24);
BUILD_BUG_ON(sizeof(struct virtio_mem_resp) != 10);
-- 
MST

Re: [PATCH v3 0/7] Support inhibiting input devices

[Dmitry Torokhov]

On Sun, Jun 07, 2020 at 10:24:14PM +0200, Pavel Machek wrote:
> On Fri 2020-06-05 19:33:28, Andrzej Pietrasiewicz wrote:
> > Userspace might want to implement a policy to temporarily disregard input
> > from certain devices.
> 
> Wow, you certainly cc a lot of lists.
> 
> > An example use case is a convertible laptop, whose keyboard can be folded
> > under the screen to create tablet-like experience. The user then must hold
> > the laptop in such a way that it is difficult to avoid pressing the keyboard
> > keys. It is therefore desirable to temporarily disregard input from the
> > keyboard, until it is folded back. This obviously is a policy which should
> > be kept out of the kernel, but the kernel must provide suitable means to
> > implement such a policy.
> > 
> > Due to interactions with suspend/resume, a helper has been added for drivers
> > to decide if the device is being used or not (PATCH 1/7) and it has been
> > applied to relevant drivers (PATCH 2,4,5,6/7).
> 
> But is that a right way to implement it?
> 
> We want this for cellphones, too -- touchscreen should be disabled
> while the device is locked in the pocket -- but we really want the
> touchscreen hardware to be powered down in that case (because it keeps
> SoC busy and eats a _lot_ of electricity).
> 
> But simplistic "receive an event and then drop it if device is
> inhibited" does not allow that...

I do not think you read the entirety of this patch series...

Thanks.

-- 
Dmitry

Re: [PATCH] MAINTAINERS: Update PARAVIRT_OPS_INTERFACE and VMWARE_HYPERVISOR_INTERFACE

[Jürgen Groß]

On 17.04.20 01:45, Deep Shah wrote:

Thomas Hellstrom will be handing over VMware's maintainership of these
interfaces to Deep Shah.

Signed-off-by: Deep Shah 
Acked-by: Thomas Hellstrom 

Pushed to xen/tip.git for-linus-5.8


Juergen

[PATCH] [v2] media: vsp1: Fix runtime PM imbalance on error

[Dinghao Liu]

pm_runtime_get_sync() increments the runtime PM usage counter even
when it returns an error code. Thus a pairing decrement is needed on
the error handling path to keep the counter balanced.

Signed-off-by: Dinghao Liu 
---

Changelog:

v2: - Fix the imbalance in vsp1_device_get().
  Use vsp1_device_get() and vsp1_device_put()
  to replace pm_runtime_get_sync() and
  pm_runtime_put_sync() in vsp1_probe().
---
 drivers/media/platform/vsp1/vsp1_drv.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_drv.c 
b/drivers/media/platform/vsp1/vsp1_drv.c
index c650e45bb0ad..dc62533cf32c 100644
--- a/drivers/media/platform/vsp1/vsp1_drv.c
+++ b/drivers/media/platform/vsp1/vsp1_drv.c
@@ -562,7 +562,12 @@ int vsp1_device_get(struct vsp1_device *vsp1)
int ret;
 
ret = pm_runtime_get_sync(vsp1->dev);
-   return ret < 0 ? ret : 0;
+   if (ret < 0) {
+   pm_runtime_put_noidle(vsp1->dev);
+   return ret;
+   }
+
+   return 0;
 }
 
 /*
@@ -845,12 +850,12 @@ static int vsp1_probe(struct platform_device *pdev)
/* Configure device parameters based on the version register. */
pm_runtime_enable(&pdev->dev);
 
-   ret = pm_runtime_get_sync(&pdev->dev);
+   ret = vsp1_device_get(vsp1);
if (ret < 0)
goto done;
 
vsp1->version = vsp1_read(vsp1, VI6_IP_VERSION);
-   pm_runtime_put_sync(&pdev->dev);
+   vsp1_device_put(vsp1);
 
for (i = 0; i < ARRAY_SIZE(vsp1_device_infos); ++i) {
if ((vsp1->version & VI6_IP_VERSION_MODEL_MASK) ==
-- 
2.17.1

Re: Forest Bond ,Greg Kroah-Hartman ,de...@driverdev.osuosl.org,linux-kernel@vger.kernel.org

[Greg Kroah-Hartman]

On Sun, Jun 07, 2020 at 10:41:56PM +, Rodolfo C. Villordo wrote:
> Multiple line over 80 characters fixes by splitting in multiple lines.
> Warning found by checkpatch.pl
> 
> Signed-off-by: Rodolfo C. Villordo 
> ---
>  drivers/staging/vt6655/rxtx.c | 225 --
>  1 file changed, 162 insertions(+), 63 deletions(-)
> 

Your subject is a bit odd :(

RE: [PATCH 3/3] exfat: set EXFAT_SB_DIRTY and VOL_DIRTY at the same timing

[kohada.tetsuh...@dc.mitsubishielectric.co.jp]

Thank you for your comment.

> >> Can you split this patch into two? (Don't set VOL_DIRTY on -ENOTEMPTY and
> >> Setting EXFAT_SB_DIRTY is
> >> merged into exfat_set_vol_flag). I need to check the second one more.
> >
> > Can't do that.
> >
> > exfat_set_vol_flag() is called when rmdir processing begins. When Not-empty
> > is detected,
> > VOL_DIRTY has already been written and synced to the media.
> You can move it before calling exfat_remove_entries().

Can be moved, but that doesn't solve the problem.
It causes the similar problem as before.

exfat_remove_entries() calls exfat_get_dentry().
If exfat_get_dentry() fails, update bh and set SB_DIRTY will not be executed.
As a result, SB_DIRTY is not set and sync does not work.
Similar problems occur with other writing functions.
Similar problems occur when pre-write checks are added in the future.

If you don't set VOL_DIRTY at the beginning, you should delay to set VOL_DIRTY 
until update-bh & set SB_DIRTY.
This avoids unnecessary changes to VOL_DIRTY/VOL_CLEAN.
I think this method is smart, but it is difficult to decide when to set 
VOL_CLEAN.
(I tried to implement it, but gave up)

> > By doing this, sync is guaranteed if VOL_DIRTY is set by calling
> > exfat_set_vol_flag.
> >
> > This change may still have problems, but it's little better than before, I
> > think.
> I need to check more if it is the best or there is more better way.

I think the sync-problems still exist.
Let's improve little by little. :-)

BR
---
Kohada Tetsuhiro 

Re: [PATCH v5] kbuild: add variables for compression tools

[Masahiro Yamada]

On Mon, Jun 8, 2020 at 10:30 AM Guenter Roeck  wrote:
>
> Hi,
>
> On Fri, Jun 05, 2020 at 10:39:55AM +0300, Denis Efremov wrote:
> > Allow user to use alternative implementations of compression tools,
> > such as pigz, pbzip2, pxz. For example, multi-threaded tools to
> > speed up the build:
> > $ make GZIP=pigz BZIP2=pbzip2
> >
> > Variables _GZIP, _BZIP2, _LZOP are used internally because original env
> > vars are reserved by the tools. The use of GZIP in gzip tool is obsolete
> > since 2015. However, alternative implementations (e.g., pigz) still rely
> > on it. BZIP2, BZIP, LZOP vars are not obsolescent.
> >
>
> When building mips:defconfig, this patch results in:
>
> Building mips:defconfig ... failed
> --
> Error log:
> /bin/sh: -n: command not found
> make[3]: *** [kernel/config_data.gz] Error 127
> make[3]: *** Deleting file 'kernel/config_data.gz'
> make[3]: *** Waiting for unfinished jobs
> make[2]: *** [kernel] Error 2
> make[2]: *** Waiting for unfinished jobs
> make[1]: *** [autoksyms_recursive] Error 2
> make: *** [__sub-make] Error 2
>
> Reverting this patch fixes the problem. Bisect log is attached.
>
> Guenter


Agh, this is because of CONFIG_TRIM_UNUSED_KSYMS.

Also, the distro package builds are broken
e.g.  make GZIP=gzip bindeb-pkg


Denis,

I think we should go back to the original
KGZIP, KBZIP2, KLZOP.




>
> ---
> # bad: [cf0c97f148e9e50aa5a7ddd1984a604dd2bde4af] Merge tag 'pinctrl-v5.8-1' 
> of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
> # good: [aaa2faab4ed8e5fe0111e04d6e168c028fe2987f] Merge tag 
> 'for-linus-5.8-ofs1' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/hubcap/linux
> git bisect start 'HEAD' 'aaa2faab4ed8'
> # good: [77f55d1305c11fb729b88f2c3f7881ba0831fa6f] staging: rtl8723bs: Use 
> common packet header constants
> git bisect good 77f55d1305c11fb729b88f2c3f7881ba0831fa6f
> # bad: [e611c0fe318c6d6827ee2bba660fbc23cf73f7dc] Merge tag 'usb-5.8-rc1' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
> git bisect bad e611c0fe318c6d6827ee2bba660fbc23cf73f7dc
> # bad: [cff11abeca78aa782378401ca2800bd2194aa14e] Merge tag 'kbuild-v5.8' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild
> git bisect bad cff11abeca78aa782378401ca2800bd2194aa14e
> # good: [2bd81cd04a3f5eb873cc81fa16c469377be3b092] Merge branch 
> 'remotes/lorenzo/pci/vmd'
> git bisect good 2bd81cd04a3f5eb873cc81fa16c469377be3b092
> # good: [269a535ca931b754a40dda3ab60514e68773c759] modpost: generate 
> vmlinux.symvers and reuse it for the second modpost
> git bisect good 269a535ca931b754a40dda3ab60514e68773c759
> # good: [e542e0dc3ee3eafc46dd8e3073388079d69cace0] Merge branch 
> 'dmi-for-linus' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging
> git bisect good e542e0dc3ee3eafc46dd8e3073388079d69cace0
> # good: [4de7b62936122570408357417f21072e78292926] modpost: remove 
> is_vmlinux() helper
> git bisect good 4de7b62936122570408357417f21072e78292926
> # good: [1ee18de92927f37e6948d5a6fc73cbf89f806905] Merge tag 
> 'dma-mapping-5.8' of git://git.infradead.org/users/hch/dma-mapping
> git bisect good 1ee18de92927f37e6948d5a6fc73cbf89f806905
> # bad: [8dfb61dcbaceb19a5ded5e9c9dcf8d05acc32294] kbuild: add variables for 
> compression tools
> git bisect bad 8dfb61dcbaceb19a5ded5e9c9dcf8d05acc32294
> # good: [c0901577e1dcc8d1c0fd1a11c8d571f650df845f] kbuild: doc: rename 
> LDFLAGS to KBUILD_LDFLAGS
> git bisect good c0901577e1dcc8d1c0fd1a11c8d571f650df845f
> # good: [e0b250b57dcf403529081e5898a9de717f96b76b] Makefile: install 
> modules.builtin even if CONFIG_MODULES=n
> git bisect good e0b250b57dcf403529081e5898a9de717f96b76b
> # first bad commit: [8dfb61dcbaceb19a5ded5e9c9dcf8d05acc32294] kbuild: add 
> variables for compression tools



-- 
Best Regards
Masahiro Yamada

Re: [PATCH] shmem, memcg: enable memcg aware shrinker

[Hugh Dickins]

On Sun, 31 May 2020, Greg Thelen wrote:

> Since v4.19 commit b0dedc49a2da ("mm/vmscan.c: iterate only over charged
> shrinkers during memcg shrink_slab()") a memcg aware shrinker is only
> called when the per-memcg per-node shrinker_map indicates that the
> shrinker may have objects to release to the memcg and node.
> 
> shmem_unused_huge_count and shmem_unused_huge_scan support the per-tmpfs
> shrinker which advertises per memcg and numa awareness.  The shmem
> shrinker releases memory by splitting hugepages that extend beyond
> i_size.
> 
> Shmem does not currently set bits in shrinker_map.  So, starting with
> b0dedc49a2da, memcg reclaim avoids calling the shmem shrinker under
> pressure.  This leads to undeserved memcg OOM kills.
> Example that reliably sees memcg OOM kill in unpatched kernel:
>   FS=/tmp/fs
>   CONTAINER=/cgroup/memory/tmpfs_shrinker
>   mkdir -p $FS
>   mount -t tmpfs -o huge=always nodev $FS
>   # Create 1000 MB container, which shouldn't suffer OOM.
>   mkdir $CONTAINER
>   echo 1000M > $CONTAINER/memory.limit_in_bytes
>   echo $BASHPID >> $CONTAINER/cgroup.procs
>   # Create 4000 files.  Ideally each file uses 4k data page + a little
>   # metadata.  Assume 8k total per-file, 32MB (4000*8k) should easily
>   # fit within container's 1000 MB.  But if data pages use 2MB
>   # hugepages (due to aggressive huge=always) then files consume 8GB,
>   # which hits memcg 1000 MB limit.
>   for i in {1..4000}; do
> echo . > $FS/$i
>   done
> 
> v5.4 commit 87eaceb3faa5 ("mm: thp: make deferred split shrinker memcg
> aware") maintains the per-node per-memcg shrinker bitmap for THP
> shrinker.  But there's no such logic in shmem.  Make shmem set the
> per-memcg per-node shrinker bits when it modifies inodes to have
> shrinkable pages.
> 
> Fixes: b0dedc49a2da ("mm/vmscan.c: iterate only over charged shrinkers during 
> memcg shrink_slab()")
> Cc:  # 4.19+
> Signed-off-by: Greg Thelen 
> ---
>  mm/shmem.c | 61 +++---
>  1 file changed, 35 insertions(+), 26 deletions(-)
> 
> diff --git a/mm/shmem.c b/mm/shmem.c
> index bd8840082c94..e11090f78cb5 100644
> --- a/mm/shmem.c
> +++ b/mm/shmem.c
> @@ -1002,6 +1002,33 @@ static int shmem_getattr(const struct path *path, 
> struct kstat *stat,
>   return 0;
>  }
>  
> +/*
> + * Expose inode and optional page to shrinker as having a possibly splittable
> + * hugepage that reaches beyond i_size.
> + */
> +static void shmem_shrinker_add(struct shmem_sb_info *sbinfo,
> +struct inode *inode, struct page *page)
> +{
> + struct shmem_inode_info *info = SHMEM_I(inode);
> +
> + spin_lock(&sbinfo->shrinklist_lock);
> + /*
> +  * _careful to defend against unlocked access to ->shrink_list in
> +  * shmem_unused_huge_shrink()
> +  */
> + if (list_empty_careful(&info->shrinklist)) {
> + list_add_tail(&info->shrinklist, &sbinfo->shrinklist);
> + sbinfo->shrinklist_len++;
> + }
> + spin_unlock(&sbinfo->shrinklist_lock);
> +
> +#ifdef CONFIG_MEMCG
> + if (page && PageTransHuge(page))
> + memcg_set_shrinker_bit(page->mem_cgroup, page_to_nid(page),
> +inode->i_sb->s_shrink.id);
> +#endif
> +}
> +
>  static int shmem_setattr(struct dentry *dentry, struct iattr *attr)
>  {
>   struct inode *inode = d_inode(dentry);
> @@ -1048,17 +1075,13 @@ static int shmem_setattr(struct dentry *dentry, 
> struct iattr *attr)
>* to shrink under memory pressure.
>*/
>   if (IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE)) {
> - spin_lock(&sbinfo->shrinklist_lock);
> - /*
> -  * _careful to defend against unlocked access to
> -  * ->shrink_list in shmem_unused_huge_shrink()
> -  */
> - if (list_empty_careful(&info->shrinklist)) {
> - list_add_tail(&info->shrinklist,
> - &sbinfo->shrinklist);
> - sbinfo->shrinklist_len++;
> - }
> - spin_unlock(&sbinfo->shrinklist_lock);
> + struct page *page;
> +
> + page = find_get_page(inode->i_mapping,
> + (newsize & HPAGE_PMD_MASK) >> 
> PAGE_SHIFT);
> + shmem_shrinker_add(sbinfo, inode, page);
> + if (page)
> + put_page(page);
>   }
>   }
>   }

Thanks Greg. But it looks like v5.7's 71725ed10c40 ("mm: huge tmpfs:
try to split_huge_page() when punching hole") actually made this block
of shmem_setattr() redundant, and I should have deleted it

Re: [PATCH] nvme: do not call del_gendisk() on a disk that was never added

[Sagi Grimberg]

Reviewed-by: Sagi Grimberg 

Re: [PATCH v2] drm/rcar-du: DRM_RCAR_WRITEBACK depends on DRM

[Qian Cai]

> On Jun 7, 2020, at 11:16 PM, Laurent Pinchart 
>  wrote:
> 
> I forgot to mention, I think the subject line should be
> 
> drm/rcar-du: Make DRM_RCAR_WRITEBACK depend on DRM_RCAR_DU
> 
> Could you please let me know if you're OK with these two small changes ?

Yes, I am fine with those.

[PATCH 3/3] platform/x86: dell-wmi: add keys to bios_to_linux_keycode

[Y Paritcher]

Increase length of bios_to_linux_keycode to 2 bytes to allow for a new
keycode 0x, this silences the following messages being logged at
startup on a Dell Inspiron 5593

dell_wmi: firmware scancode 0x48 maps to unrecognized keycode 0x
dell_wmi: firmware scancode 0x50 maps to unrecognized keycode 0x

Signed-off-by: Y Paritcher 
---
 drivers/platform/x86/dell-wmi.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/platform/x86/dell-wmi.c b/drivers/platform/x86/dell-wmi.c
index f37e7e9093c2..5ef716e3034f 100644
--- a/drivers/platform/x86/dell-wmi.c
+++ b/drivers/platform/x86/dell-wmi.c
@@ -196,7 +196,7 @@ struct dell_dmi_results {
 };
 
 /* Uninitialized entries here are KEY_RESERVED == 0. */
-static const u16 bios_to_linux_keycode[256] = {
+static const u16 bios_to_linux_keycode[65536] = {
[0] = KEY_MEDIA,
[1] = KEY_NEXTSONG,
[2] = KEY_PLAYPAUSE,
@@ -237,6 +237,7 @@ static const u16 bios_to_linux_keycode[256] = {
[37]= KEY_UNKNOWN,
[38]= KEY_MICMUTE,
[255]   = KEY_PROG3,
+   [65535] = KEY_UNKNOWN,
 };
 
 /*
-- 
2.27.0

[PATCH 0/3] platform/x86: dell-wmi: new keys

[Y Paritcher]

add new backlight events with a type of 0x0010 and a code of 0x57 / 0x58,
add a new keymap type table 0x0012 for keycode of 0xe035 from the Fn-lock
key
extend bios_to_linux_keycode to 2 bytes to allow for a new keycode 0x

Y Paritcher (3):
  platform/x86: dell-wmi: add new backlight events
  platform/x86: dell-wmi: add new keymap type 0x0012
  platform/x86: dell-wmi: add new dmi keys to bios_to_linux_keycode

 drivers/platform/x86/dell-wmi.c | 24 +++-
 1 file changed, 23 insertions(+), 1 deletion(-)

-- 
2.27.0

[PATCH 1/3] platform/x86: dell-wmi: add new backlight events

[Y Paritcher]

Ignore events with a type of 0x0010 and a code of 0x57 / 0x58,
this silences the following messages being logged on a
Dell Inspiron 5593:

dell_wmi: Unknown key with type 0x0010 and code 0x0057 pressed
dell_wmi: Unknown key with type 0x0010 and code 0x0058 pressed

Signed-off-by: Y Paritcher 
---
 drivers/platform/x86/dell-wmi.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/platform/x86/dell-wmi.c b/drivers/platform/x86/dell-wmi.c
index c25a4286d766..0b4f72f923cd 100644
--- a/drivers/platform/x86/dell-wmi.c
+++ b/drivers/platform/x86/dell-wmi.c
@@ -252,6 +252,10 @@ static const struct key_entry dell_wmi_keymap_type_0010[] 
= {
/* Fn-lock switched to multimedia keys */
{ KE_IGNORE, 0x1, { KEY_RESERVED } },
 
+   /* Backlight brightness level */
+   { KE_KEY,0x57, { KEY_BRIGHTNESSDOWN } },
+   { KE_KEY,0x58, { KEY_BRIGHTNESSUP } },
+
/* Keyboard backlight change notification */
{ KE_IGNORE, 0x3f, { KEY_RESERVED } },
 
-- 
2.27.0

[PATCH 2/3] platform/x86: dell-wmi: add new keymap type 0x0012

[Y Paritcher]

Ignore events with a type of 0x0012 and a code of 0xe035,
this silences the following messages being logged when
pressing the Fn-lock key on a Dell Inspiron 5593:

dell_wmi: Unknown WMI event type 0x12
dell_wmi: Unknown key with type 0x0012 and code 0xe035 pressed

Signed-off-by: Y Paritcher 
---
 drivers/platform/x86/dell-wmi.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/platform/x86/dell-wmi.c b/drivers/platform/x86/dell-wmi.c
index 0b4f72f923cd..f37e7e9093c2 100644
--- a/drivers/platform/x86/dell-wmi.c
+++ b/drivers/platform/x86/dell-wmi.c
@@ -334,6 +334,14 @@ static const struct key_entry dell_wmi_keymap_type_0011[] 
= {
{ KE_IGNORE, KBD_LED_AUTO_100_TOKEN, { KEY_RESERVED } },
 };
 
+/*
+ * Keymap for WMI events of type 0x0012
+ */
+static const struct key_entry dell_wmi_keymap_type_0012[] = {
+   /* Fn-lock button pressed */
+   { KE_IGNORE, 0xe035, { KEY_RESERVED } },
+};
+
 static void dell_wmi_process_key(struct wmi_device *wdev, int type, int code)
 {
struct dell_wmi_priv *priv = dev_get_drvdata(&wdev->dev);
@@ -425,6 +433,7 @@ static void dell_wmi_notify(struct wmi_device *wdev,
break;
case 0x0010: /* Sequence of keys pressed */
case 0x0011: /* Sequence of events occurred */
+   case 0x0012: /* Sequence of events occurred */
for (i = 2; i < len; ++i)
dell_wmi_process_key(wdev, buffer_entry[1],
 buffer_entry[i]);
@@ -556,6 +565,7 @@ static int dell_wmi_input_setup(struct wmi_device *wdev)
 ARRAY_SIZE(dell_wmi_keymap_type_) +
 ARRAY_SIZE(dell_wmi_keymap_type_0010) +
 ARRAY_SIZE(dell_wmi_keymap_type_0011) +
+ARRAY_SIZE(dell_wmi_keymap_type_0012) +
 1,
 sizeof(struct key_entry), GFP_KERNEL);
if (!keymap) {
@@ -600,6 +610,13 @@ static int dell_wmi_input_setup(struct wmi_device *wdev)
pos++;
}
 
+   /* Append table with events of type 0x0012 */
+   for (i = 0; i < ARRAY_SIZE(dell_wmi_keymap_type_0012); i++) {
+   keymap[pos] = dell_wmi_keymap_type_0012[i];
+   keymap[pos].code |= (0x0012 << 16);
+   pos++;
+   }
+
/*
 * Now append also table with "legacy" events of type 0x. Some of
 * them are reported also on laptops which have scancodes in DMI.
-- 
2.27.0

Re: [PATCH RESEND] device_cgroup: Fix RCU list debugging warning

[Serge E. Hallyn]

On Sun, Jun 07, 2020 at 12:08:40PM -0700, Paul E. McKenney wrote:
> On Sun, Jun 07, 2020 at 06:23:40AM +1000, Stephen Rothwell wrote:
> > Hi all,
> > 
> > On Mon, 6 Apr 2020 16:29:50 +0530 Amol Grover  wrote:
> > >
> > > exceptions may be traversed using list_for_each_entry_rcu()
> > > outside of an RCU read side critical section BUT under the
> > > protection of decgroup_mutex. Hence add the corresponding
> > > lockdep expression to fix the following false-positive
> > > warning:
> > > 
> > > [2.304417] =
> > > [2.304418] WARNING: suspicious RCU usage
> > > [2.304420] 5.5.4-stable #17 Tainted: GE
> > > [2.304422] -
> > > [2.304424] security/device_cgroup.c:355 RCU-list traversed in 
> > > non-reader section!!
> > > 
> > > Signed-off-by: Amol Grover 
> > > ---
> > >  security/device_cgroup.c | 3 ++-
> > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/security/device_cgroup.c b/security/device_cgroup.c
> > > index 7d0f8f7431ff..b7da9e0970d9 100644
> > > --- a/security/device_cgroup.c
> > > +++ b/security/device_cgroup.c
> > > @@ -352,7 +352,8 @@ static bool match_exception_partial(struct list_head 
> > > *exceptions, short type,
> > >  {
> > >   struct dev_exception_item *ex;
> > >  
> > > - list_for_each_entry_rcu(ex, exceptions, list) {
> > > + list_for_each_entry_rcu(ex, exceptions, list,
> > > + lockdep_is_held(&devcgroup_mutex)) {
> > >   if ((type & DEVCG_DEV_BLOCK) && !(ex->type & DEVCG_DEV_BLOCK))
> > >   continue;
> > >   if ((type & DEVCG_DEV_CHAR) && !(ex->type & DEVCG_DEV_CHAR))
> > > -- 
> > > 2.24.1
> > > 
> > 
> > I have been carrying the above patch in linux-next for some time now.
> > I have been carrying it because it fixes problems for syzbot (see the
> > third warning in
> > https://lore.kernel.org/linux-next/cact4y+ynjk+kq0pfb5fe-q1bqe2t1jq_mvkhf--z80z3wky...@mail.gmail.com/).
> > Is there some reason it has not been applied to some tree?
> 
> The RCU changes on which this patch depends have long since made it to
> mainline, so it can go up any tree.  I can take it if no one else will,
> but it might be better going in via the security tree.
> 
>   Thanx, Paul

James, do you mind pulling it in?

Re: [PATCH v11 00/16] per memcg lru lock

[Hugh Dickins]

On Thu, 28 May 2020, Alex Shi wrote:

> This is a new version which bases on linux-next 
> 
> Johannes Weiner has suggested:
> "So here is a crazy idea that may be worth exploring:
> 
> Right now, pgdat->lru_lock protects both PageLRU *and* the lruvec's
> linked list.
> 
> Can we make PageLRU atomic and use it to stabilize the lru_lock
> instead, and then use the lru_lock only serialize list operations?
> ..."
> 
> With new memcg charge path and this solution, we could isolate
> LRU pages to exclusive visit them in compaction, page migration, reclaim,
> memcg move_accunt, huge page split etc scenarios while keeping pages' 
> memcg stable. Then possible to change per node lru locking to per memcg
> lru locking. As to pagevec_lru_move_fn funcs, it would be safe to let
> pages remain on lru list, lru lock could guard them for list integrity.
> 
> The patchset includes 3 parts:
> 1, some code cleanup and minimum optimization as a preparation.
> 2, use TestCleanPageLRU as page isolation's precondition
> 3, replace per node lru_lock with per memcg per node lru_lock
> 
> The 3rd part moves per node lru_lock into lruvec, thus bring a lru_lock for
> each of memcg per node. So on a large machine, each of memcg don't
> have to suffer from per node pgdat->lru_lock competition. They could go
> fast with their self lru_lock
> 
> Following Daniel Jordan's suggestion, I have run 208 'dd' with on 104
> containers on a 2s * 26cores * HT box with a modefied case:
> https://git.kernel.org/pub/scm/linux/kernel/git/wfg/vm-scalability.git/tree/case-lru-file-readtwice
> 
> With this patchset, the readtwice performance increased about 80%
> in concurrent containers.
> 
> Thanks Hugh Dickins and Konstantin Khlebnikov, they both brought this
> idea 8 years ago, and others who give comments as well: Daniel Jordan, 
> Mel Gorman, Shakeel Butt, Matthew Wilcox etc.
> 
> Thanks for Testing support from Intel 0day and Rong Chen, Fengguang Wu,
> and Yun Wang. Hugh Dickins also shared his kbuild-swap case. Thanks!
> 
> 
> Alex Shi (14):
>   mm/vmscan: remove unnecessary lruvec adding
>   mm/page_idle: no unlikely double check for idle page counting
>   mm/compaction: correct the comments of compact_defer_shift
>   mm/compaction: rename compact_deferred as compact_should_defer
>   mm/thp: move lru_add_page_tail func to huge_memory.c
>   mm/thp: clean up lru_add_page_tail
>   mm/thp: narrow lru locking
>   mm/memcg: add debug checking in lock_page_memcg
>   mm/lru: introduce TestClearPageLRU
>   mm/compaction: do page isolation first in compaction
>   mm/mlock: reorder isolation sequence during munlock
>   mm/lru: replace pgdat lru_lock with lruvec lock
>   mm/lru: introduce the relock_page_lruvec function
>   mm/pgdat: remove pgdat lru_lock
> 
> Hugh Dickins (2):
>   mm/vmscan: use relock for move_pages_to_lru
>   mm/lru: revise the comments of lru_lock
> 
>  Documentation/admin-guide/cgroup-v1/memcg_test.rst |  15 +-
>  Documentation/admin-guide/cgroup-v1/memory.rst |   8 +-
>  Documentation/trace/events-kmem.rst|   2 +-
>  Documentation/vm/unevictable-lru.rst   |  22 +--
>  include/linux/compaction.h |   4 +-
>  include/linux/memcontrol.h |  92 +++
>  include/linux/mm_types.h   |   2 +-
>  include/linux/mmzone.h |   6 +-
>  include/linux/page-flags.h |   1 +
>  include/linux/swap.h   |   4 +-
>  include/trace/events/compaction.h  |   2 +-
>  mm/compaction.c| 104 -
>  mm/filemap.c   |   4 +-
>  mm/huge_memory.c   |  51 +--
>  mm/memcontrol.c|  87 ++-
>  mm/mlock.c |  93 ++--
>  mm/mmzone.c|   1 +
>  mm/page_alloc.c|   1 -
>  mm/page_idle.c |   8 -
>  mm/rmap.c  |   2 +-
>  mm/swap.c  | 112 --
>  mm/swap_state.c|   6 +-
>  mm/vmscan.c| 168 
> +++--
>  mm/workingset.c|   4 +-
>  24 files changed, 487 insertions(+), 312 deletions(-)

Hi Alex,

I didn't get to try v10 at all, waited until Johannes's preparatory
memcg swap cleanup was in mmotm; but I have spent a while thrashing
this v11, and can happily report that it is much better than v9 etc:
I believe this memcg lru_lock work will soon be ready for v5.9.

I've not yet found any flaw at the swapping end, but fixes are needed
for isolate_migratepages_block() and mem_cgroup_move_account(): I've
got a series of 4 fix patches to send you (I guess two to fold

Re: [PATCH] pinctrl: mcp23s08: Split to three parts: fix ptr_ret.cocci warnings

[Andy Shevchenko]

On Mon, Jun 08, 2020 at 09:02:53AM +0800, kernel test robot wrote:
> From: kernel test robot 
> 
> drivers/pinctrl/pinctrl-mcp23s08_spi.c:129:1-3: WARNING: PTR_ERR_OR_ZERO can 
> be used
> 
> 
>  Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR
> 
> Generated by: scripts/coccinelle/api/ptr_ret.cocci

Makes sense.
Acked-by: Andy Shevchenko 

> 
> Fixes: 0f04a81784fe ("pinctrl: mcp23s08: Split to three parts: core, I²C, 
> SPI")
> CC: Andy Shevchenko 
> Signed-off-by: kernel test robot 
> ---
> 
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
> master
> head:   cf0c97f148e9e50aa5a7ddd1984a604dd2bde4af
> commit: 0f04a81784fe3ddc00cae74c517265b3ddb8825c pinctrl: mcp23s08: Split to 
> three parts: core, I²C, SPI
> 
>  pinctrl-mcp23s08_spi.c |5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
> 
> --- a/drivers/pinctrl/pinctrl-mcp23s08_spi.c
> +++ b/drivers/pinctrl/pinctrl-mcp23s08_spi.c
> @@ -126,10 +126,7 @@ static int mcp23s08_spi_regmap_init(stru
>   copy->name = name;
>  
>   mcp->regmap = devm_regmap_init(dev, &mcp23sxx_spi_regmap, mcp, copy);
> - if (IS_ERR(mcp->regmap))
> - return PTR_ERR(mcp->regmap);
> -
> - return 0;
> + return PTR_ERR_OR_ZERO(mcp->regmap);
>  }
>  
>  static int mcp23s08_probe(struct spi_device *spi)

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 2/2] xhci: Poll for U0 after disabling USB2 LPM

[Kai-Heng Feng]

> On May 20, 2020, at 18:18, Kai-Heng Feng  wrote:
> 
> USB2 devices with LPM enabled may interrupt the system suspend:
> [  932.510475] usb 1-7: usb suspend, wakeup 0
> [  932.510549] hub 1-0:1.0: hub_suspend
> [  932.510581] usb usb1: bus suspend, wakeup 0
> [  932.510590] xhci_hcd :00:14.0: port 9 not suspended
> [  932.510593] xhci_hcd :00:14.0: port 8 not suspended
> ..
> [  932.520323] xhci_hcd :00:14.0: Port change event, 1-7, id 7, portsc: 
> 0x400e03
> ..
> [  932.591405] PM: pci_pm_suspend(): hcd_pci_suspend+0x0/0x30 returns -16
> [  932.591414] PM: dpm_run_callback(): pci_pm_suspend+0x0/0x160 returns -16
> [  932.591418] PM: Device :00:14.0 failed to suspend async: error -16
> 
> During system suspend, USB core will let HC suspends the device if it
> doesn't have remote wakeup enabled and doesn't have any children.
> However, from the log above we can see that the usb 1-7 doesn't get bus
> suspended due to not in U0. After a while the port finished U2 -> U0
> transition, interrupts the suspend process.
> 
> The observation is that after disabling LPM, port doesn't transit to U0
> immediately and can linger in U2. xHCI spec 4.23.5.2 states that the
> maximum exit latency for USB2 LPM should be BESL + 10us. The BESL for
> the affected device is advertised as 400us, which is still not enough
> based on my testing result.
> 
> So let's use the maximum permitted latency, 1, to poll for U0
> status to solve the issue.
> 
> Signed-off-by: Kai-Heng Feng 

A gentle ping...

> ---
> drivers/usb/host/xhci.c | 3 +++
> 1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> index 14181a7ea375..1058f604975b 100644
> --- a/drivers/usb/host/xhci.c
> +++ b/drivers/usb/host/xhci.c
> @@ -4474,6 +4474,9 @@ static int xhci_set_usb2_hardware_lpm(struct usb_hcd 
> *hcd,
>   mutex_lock(hcd->bandwidth_mutex);
>   xhci_change_max_exit_latency(xhci, udev, 0);
>   mutex_unlock(hcd->bandwidth_mutex);
> + readl_poll_timeout(ports[port_num]->addr, pm_val,
> +(pm_val & PORT_PLS_MASK) == XDEV_U0,
> +100, 1);
>   return 0;
>   }
>   }
> -- 
> 2.17.1
> 

Re: [PATCH RFC v5 13/13] vhost: drop head based APIs

[Jason Wang]

On 2020/6/7 下午10:11, Michael S. Tsirkin wrote:

Everyone's using buf APIs, no need for head based ones anymore.

Signed-off-by: Michael S. Tsirkin
---
  drivers/vhost/vhost.c | 36 
  drivers/vhost/vhost.h | 12 
  2 files changed, 8 insertions(+), 40 deletions(-)

diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 72ee55c810c4..e6931b760b61 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -2299,12 +2299,12 @@ static int fetch_buf(struct vhost_virtqueue *vq)
return 1;
  }
  
-/* Reverse the effect of vhost_get_vq_desc. Useful for error handling. */

+/* Revert the effect of fetch_buf. Useful for error handling. */
+static
  void vhost_discard_vq_desc(struct vhost_virtqueue *vq, int n)
  {
vq->last_avail_idx -= n;
  }
-EXPORT_SYMBOL_GPL(vhost_discard_vq_desc);



The same question as previous version.

Do we need to rewind cached descriptor here?

Thanks

Re: [PATCH] xhci: Make debug message consistent with bus and port number

[Kai-Heng Feng]

> On May 7, 2020, at 18:35, Mathias Nyman  wrote:
> 
> On 7.5.2020 11.21, Greg Kroah-Hartman wrote:
>> On Thu, May 07, 2020 at 03:58:36PM +0800, Kai-Heng Feng wrote:
>>> 
>>> 
 On May 7, 2020, at 15:31, Greg Kroah-Hartman  
 wrote:
 
 On Thu, May 07, 2020 at 03:15:01PM +0800, Kai-Heng Feng wrote:
> 
> 
>> On May 7, 2020, at 14:45, Greg Kroah-Hartman 
>>  wrote:
>> 
>> On Thu, May 07, 2020 at 02:17:55PM +0800, Kai-Heng Feng wrote:
>>> Current xhci debug message doesn't always output bus number, so it's
>>> hard to figure out it's from USB2 or USB3 root hub.
>>> 
>>> In addition to that, some port numbers are offset to 0 and others are
>>> offset to 1. Use the latter to match the USB core.
>>> 
>>> So use "bus number - port index + 1" to make debug message consistent.
>>> 
>>> Signed-off-by: Kai-Heng Feng 
>>> ---
>>> drivers/usb/host/xhci-hub.c | 41 +
>>> 1 file changed, 23 insertions(+), 18 deletions(-)
>>> 
>>> diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
>>> index f37316d2c8fa..83088c262cc4 100644
>>> --- a/drivers/usb/host/xhci-hub.c
>>> +++ b/drivers/usb/host/xhci-hub.c
>>> @@ -1241,7 +1241,8 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 
>>> typeReq, u16 wValue,
>>> temp = readl(ports[wIndex]->addr);
>>> /* Disable port */
>>> if (link_state == USB_SS_PORT_LS_SS_DISABLED) {
>>> -   xhci_dbg(xhci, "Disable port %d\n", 
>>> wIndex);
>>> +   xhci_dbg(xhci, "Disable port %d-%d\n",
>>> +hcd->self.busnum, wIndex + 1);
>> 
>> Shouldn't xhci_dbg() show the bus number already?  
> 
> It's the PCI bus number, different to USB2/USB3 root hub bus number...
 
 But if this is using dev_dbg(), and it is, then you know how to look
 that up by seeing where that device is in sysfs at that point in time.
 
 So why add this again?
>>> 
>>> xHCI has two HCD, one for USB2 and one for USB3.
>>> If both of their port with same number are in use, for instance, port 1, 
>>> then they are port 1-1 and port 2-1.
>>> Right now the debug message only show "Port 1", we still can't find the 
>>> corresponding port via sysfs with insufficient info.
>> 
>> Look at the full kernel log line, the xhci hcd device should be showing
>> you unique information.  If not, something else is wrong.
>> 
> 
> What Kai-Heng suggest here makes sense, and is useful.
> We use similar style debugging in other places, and it is helpful as it 
> matches
> usb core debugging style.
> 
> This might seem odd but reason is that the xHC controller is one device which
> doesn't really separate USB2 and USB3.
> All ports are for example in one long array.
> 
> On the xhci driver side things look very different. We register two HCD's,
> one for usb 2 and one for USB 3. In many cases the debugging is not tied to a 
> HCD
> in any way,  (starting, stopping controller, command completion interrupts 
> etc),
> other cases the debugging is very much tied to a specific hcd,
> for example when we are handling a port requsts for the roothub.

A gentle ping...

> 
> Thanks
> -Mathias

Re: [PATCH v3] xhci: Prevent runtime suspend on Etron EJ168

[Kai-Heng Feng]

> On May 5, 2020, at 01:16, Kai-Heng Feng  wrote:
> 
> Etron EJ168 USB 3.0 Host Controller stops working after S3, if it was
> runtime suspended previously:
> [  370.080359] pci :02:00.0: can't change power state from D3cold to D0 
> (config space inaccessible)
> [  370.080477] xhci_hcd :04:00.0: can't change power state from D3cold to 
> D0 (config space inaccessible)
> [  370.080532] pcieport :00:1c.0: DPC: containment event, status:0x1f05 
> source:0x0200
> [  370.080533] pcieport :00:1c.0: DPC: ERR_FATAL detected
> [  370.080536] xhci_hcd :04:00.0: can't change power state from D3hot to 
> D0 (config space inaccessible)
> [  370.080552] xhci_hcd :04:00.0: AER: can't recover (no error_detected 
> callback)
> [  370.080566] usb usb3: root hub lost power or was reset
> [  370.080566] usb usb4: root hub lost power or was reset
> [  370.080572] xhci_hcd :04:00.0: Host halt failed, -19
> [  370.080574] xhci_hcd :04:00.0: Host not accessible, reset failed.
> [  370.080575] xhci_hcd :04:00.0: PCI post-resume error -19!
> [  370.080586] xhci_hcd :04:00.0: HC died; cleaning up
> 
> This can be fixed by not runtime suspend the controller at all.
> 
> So disable runtime suspend for EJ168 xHCI device.
> 
> Signed-off-by: Kai-Heng Feng 

A gentle ping...

> ---
> v3:
> - Balance rpm refcount in remove callback.
> 
> v2:
> - Use a new quirk to avoid changing existing behavior.
> 
> drivers/usb/host/xhci-pci.c | 7 ++-
> drivers/usb/host/xhci.h | 1 +
> 2 files changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
> index 766b74723e64..67b4b433a93e 100644
> --- a/drivers/usb/host/xhci-pci.c
> +++ b/drivers/usb/host/xhci-pci.c
> @@ -227,6 +227,7 @@ static void xhci_pci_quirks(struct device *dev, struct 
> xhci_hcd *xhci)
>   xhci->quirks |= XHCI_RESET_ON_RESUME;
>   xhci->quirks |= XHCI_TRUST_TX_LENGTH;
>   xhci->quirks |= XHCI_BROKEN_STREAMS;
> + xhci->quirks |= XHCI_DISABLE_RUNTIME_SUSPEND;
>   }
>   if (pdev->vendor == PCI_VENDOR_ID_RENESAS &&
>   pdev->device == 0x0014) {
> @@ -371,7 +372,8 @@ static int xhci_pci_probe(struct pci_dev *dev, const 
> struct pci_device_id *id)
>   xhci->shared_hcd->can_do_streams = 1;
> 
>   /* USB-2 and USB-3 roothubs initialized, allow runtime pm suspend */
> - pm_runtime_put_noidle(&dev->dev);
> + if (!(xhci->quirks & XHCI_DISABLE_RUNTIME_SUSPEND))
> + pm_runtime_put_noidle(&dev->dev);
> 
>   if (xhci->quirks & XHCI_DEFAULT_PM_RUNTIME_ALLOW)
>   pm_runtime_allow(&dev->dev);
> @@ -397,6 +399,9 @@ static void xhci_pci_remove(struct pci_dev *dev)
>   if (xhci->quirks & XHCI_DEFAULT_PM_RUNTIME_ALLOW)
>   pm_runtime_forbid(&dev->dev);
> 
> + if (!(xhci->quirks & XHCI_DISABLE_RUNTIME_SUSPEND))
> + pm_runtime_get_noresume(&dev->dev);
> +
>   if (xhci->shared_hcd) {
>   usb_remove_hcd(xhci->shared_hcd);
>   usb_put_hcd(xhci->shared_hcd);
> diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
> index 86cfefdd6632..d9c209a10d3f 100644
> --- a/drivers/usb/host/xhci.h
> +++ b/drivers/usb/host/xhci.h
> @@ -1873,6 +1873,7 @@ struct xhci_hcd {
> #define XHCI_DEFAULT_PM_RUNTIME_ALLOW BIT_ULL(33)
> #define XHCI_RESET_PLL_ON_DISCONNECT  BIT_ULL(34)
> #define XHCI_SNPS_BROKEN_SUSPENDBIT_ULL(35)
> +#define XHCI_DISABLE_RUNTIME_SUSPENDBIT_ULL(36)
> 
>   unsigned intnum_active_eps;
>   unsigned intlimit_active_eps;
> -- 
> 2.17.1
> 

APPROVAL OF YOUR FUND.

[Notification Result]

From:
The affiliate office of the:
*International Monetary Fund,
*International Fund Regulatory Board,
*Capital Flight Fund Regulation,
Reliance Bank Limited
London EC3R 8EB,
United Kingdom

 Sub: Payment approval of GBP£3,150,000.00/

Good day, this is a comprehensive summary as to what have been agreed on your 
pending transfer. The hiccup which led to delay of the transfer of your funds 
into your account has been rectified in agreement with the Financial Regulatory 
Body of the United Kingdom. You do not have anything to fear or worry at all as 
the entire paper work have been concluded and the transfer approval documents 
have all been endorsed.

The transfer is approved to be completed into your account in 4 days so that 
there will be no further hitches, please, note that the final payment approval 
is endorsed in favour of the Reliance Bank as the accredited bank, therefore, 
we have received all your payment related papers to enable us transfer the 
funds to you. Kindly reply and confirm if you are still using the same bank 
account or, furnish your alternative bank account for immediate processing of 
the transfer into your account.

Waiting for you prompt reply.

Faithfully,
Mrs Leanna McEwan
Head of operation/services &
Commercial Director.
Reliance Bank Limited
Billingsgate, London EC3R 8EB,
United Kingdom
facsimile +44-155-5559-597
www.reliancebankltd.com

Re: [PATCH v5] drm/i915: Init lspcon chip dynamically

[Kai-Heng Feng]

> On May 6, 2020, at 18:28, Kai-Heng Feng  wrote:
> 
> On HP 800 G4 DM, if HDMI cable isn't plugged before boot, the HDMI port
> becomes useless and never responds to cable hotplugging:
> [3.031904] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon
> [3.031945] [drm:intel_ddi_init [i915]] *ERROR* LSPCON init failed on port 
> D
> 
> Seems like the lspcon chip on the system only gets powered after the
> cable is plugged.
> 
> Consolidate lspcon_init() into lspcon_resume() to dynamically init
> lspcon chip, and make HDMI port work.
> 
> Closes: https://gitlab.freedesktop.org/drm/intel/issues/203
> Signed-off-by: Kai-Heng Feng 

A gentle ping...

> ---
> v5:
> - Consolidate lspcon_resume() with lspcon_init().
> - Move more logic into lspcon code.
> 
> v4:
> - Trust VBT in intel_infoframe_init().
> - Init lspcon in intel_dp_detect().
> 
> v3:
> - Make sure it's handled under long HPD case.
> 
> v2: 
> - Move lspcon_init() inside of intel_dp_hpd_pulse().
> 
> drivers/gpu/drm/i915/display/intel_ddi.c| 19 +--
> drivers/gpu/drm/i915/display/intel_dp.c | 10 ++--
> drivers/gpu/drm/i915/display/intel_hdmi.c   |  3 +-
> drivers/gpu/drm/i915/display/intel_lspcon.c | 63 -
> drivers/gpu/drm/i915/display/intel_lspcon.h |  3 +-
> 5 files changed, 43 insertions(+), 55 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 5601673c3f30..798fd640da54 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -4770,7 +4770,7 @@ void intel_ddi_init(struct drm_i915_private *dev_priv, 
> enum port port)
> {
>   struct intel_digital_port *intel_dig_port;
>   struct intel_encoder *encoder;
> - bool init_hdmi, init_dp, init_lspcon = false;
> + bool init_hdmi, init_dp;
>   enum phy phy = intel_port_to_phy(dev_priv, port);
> 
>   init_hdmi = intel_bios_port_supports_dvi(dev_priv, port) ||
> @@ -4784,7 +4784,6 @@ void intel_ddi_init(struct drm_i915_private *dev_priv, 
> enum port port)
>* is initialized before lspcon.
>*/
>   init_dp = true;
> - init_lspcon = true;
>   init_hdmi = false;
>   drm_dbg_kms(&dev_priv->drm, "VBT says port %c has lspcon\n",
>   port_name(port));
> @@ -4869,22 +4868,6 @@ void intel_ddi_init(struct drm_i915_private *dev_priv, 
> enum port port)
>   goto err;
>   }
> 
> - if (init_lspcon) {
> - if (lspcon_init(intel_dig_port))
> - /* TODO: handle hdmi info frame part */
> - drm_dbg_kms(&dev_priv->drm,
> - "LSPCON init success on port %c\n",
> - port_name(port));
> - else
> - /*
> -  * LSPCON init faied, but DP init was success, so
> -  * lets try to drive as DP++ port.
> -  */
> - drm_err(&dev_priv->drm,
> - "LSPCON init failed on port %c\n",
> - port_name(port));
> - }
> -
>   intel_infoframe_init(intel_dig_port);
> 
>   return;
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 6952b0295096..e26aa35d6e37 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -5938,15 +5938,14 @@ static enum drm_connector_status
> intel_dp_detect_dpcd(struct intel_dp *intel_dp)
> {
>   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> - struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
> + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
>   u8 *dpcd = intel_dp->dpcd;
>   u8 type;
> 
>   if (WARN_ON(intel_dp_is_edp(intel_dp)))
>   return connector_status_connected;
> 
> - if (lspcon->active)
> - lspcon_resume(lspcon);
> + lspcon_resume(dig_port);
> 
>   if (!intel_dp_get_dpcd(intel_dp))
>   return connector_status_disconnected;
> @@ -7198,14 +7197,13 @@ void intel_dp_encoder_reset(struct drm_encoder 
> *encoder)
> {
>   struct drm_i915_private *dev_priv = to_i915(encoder->dev);
>   struct intel_dp *intel_dp = enc_to_intel_dp(to_intel_encoder(encoder));
> - struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
> + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
>   intel_wakeref_t wakeref;
> 
>   if (!HAS_DDI(dev_priv))
>   intel_dp->DP = intel_de_read(dev_priv, intel_dp->output_reg);
> 
> - if (lspcon->active)
> - lspcon_resume(lspcon);
> + lspcon_resume(dig_port);
> 
>   intel_dp->reset_link_params = true;
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
> b/drivers/gpu/drm/i915/display/intel_hdmi.c
> index 010f37240710..643ad

Re: [PATCH] io: pressure: zpa2326: handle pm_runtime_get_sync failure

[Navid Emamdoost]

On Sat, Jun 6, 2020 at 2:29 PM Andy Shevchenko
 wrote:
>
>
>
> On Saturday, June 6, 2020, Jonathan Cameron  wrote:
>>
>> On Thu,  4 Jun 2020 21:44:44 -0500
>> Navid Emamdoost  wrote:
>>
>> > Calling pm_runtime_get_sync increments the counter even in case of
>> > failure, causing incorrect ref count. Call pm_runtime_put if
>> > pm_runtime_get_sync fails.
>> >
>> > Signed-off-by: Navid Emamdoost 
>>
>> Hi Navid,
>>
>> This looks to be a fix, be it for a case that we are hopefully
>> unlikely to ever hit.  Please could you add an appropriate
>> Fixes tag so we can work out how far to backport it?
>>
>> Patch looks good to me so if you just reply with a suitable
>> tag I can add it whilst applying.

Hi Jonathan,
Here is the fixes tag:

Fixes: 03b262f2bbf4 ("iio:pressure: initial zpa2326 barometer support")

>
>
>
> Should not be "iio: ..." in the prefix?

Yes! It should be "iio" in the patch name.


>>
>>
>> Thanks,
>>
>> Jonathan
>>
>> > ---
>> >  drivers/iio/pressure/zpa2326.c | 4 +++-
>> >  1 file changed, 3 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/iio/pressure/zpa2326.c 
>> > b/drivers/iio/pressure/zpa2326.c
>> > index 99dfe33ee402..245f2e2d412b 100644
>> > --- a/drivers/iio/pressure/zpa2326.c
>> > +++ b/drivers/iio/pressure/zpa2326.c
>> > @@ -664,8 +664,10 @@ static int zpa2326_resume(const struct iio_dev 
>> > *indio_dev)
>> >   int err;
>> >
>> >   err = pm_runtime_get_sync(indio_dev->dev.parent);
>> > - if (err < 0)
>> > + if (err < 0) {
>> > + pm_runtime_put(indio_dev->dev.parent);
>> >   return err;
>> > + }
>> >
>> >   if (err > 0) {
>> >   /*
>>
>
>
> --
> With Best Regards,
> Andy Shevchenko
>
>


-- 
Navid.

[PATCH 1/2] iommu: Mark __iommu_map/__iommu_map_sg as static

[Baolin Wang]

Now the __iommu_map() and __iommu_map_sg() are used only in iommu.c
file, so mark them as static.

Signed-off-by: Baolin Wang 
---
 drivers/iommu/iommu.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index ac91024..04ba8f7 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -1924,8 +1924,8 @@ static size_t iommu_pgsize(struct iommu_domain *domain,
return pgsize;
 }
 
-int __iommu_map(struct iommu_domain *domain, unsigned long iova,
- phys_addr_t paddr, size_t size, int prot, gfp_t gfp)
+static int __iommu_map(struct iommu_domain *domain, unsigned long iova,
+  phys_addr_t paddr, size_t size, int prot, gfp_t gfp)
 {
const struct iommu_ops *ops = domain->ops;
unsigned long orig_iova = iova;
@@ -2075,9 +2075,9 @@ size_t iommu_unmap_fast(struct iommu_domain *domain,
 }
 EXPORT_SYMBOL_GPL(iommu_unmap_fast);
 
-size_t __iommu_map_sg(struct iommu_domain *domain, unsigned long iova,
-   struct scatterlist *sg, unsigned int nents, int prot,
-   gfp_t gfp)
+static size_t __iommu_map_sg(struct iommu_domain *domain, unsigned long iova,
+struct scatterlist *sg, unsigned int nents, int 
prot,
+gfp_t gfp)
 {
size_t len = 0, mapped = 0;
phys_addr_t start;
-- 
1.8.3.1

[PATCH 2/2] iommu: Add gfp parameter to io_pgtable_ops->map()

[Baolin Wang]

Now the ARM page tables are always allocated by GFP_ATOMIC parameter,
but the iommu_ops->map() function has been added a gfp_t parameter by
commit 781ca2de89ba ("iommu: Add gfp parameter to iommu_ops::map"),
thus io_pgtable_ops->map() should use the gfp parameter passed from
iommu_ops->map() to allocate page pages, which can avoid wasting the
memory allocators atomic pools for some non-atomic contexts.

Signed-off-by: Baolin Wang 
---
 drivers/gpu/drm/panfrost/panfrost_mmu.c |  2 +-
 drivers/iommu/arm-smmu-v3.c |  2 +-
 drivers/iommu/arm-smmu.c|  2 +-
 drivers/iommu/io-pgtable-arm-v7s.c  | 10 +-
 drivers/iommu/io-pgtable-arm.c  | 10 +-
 drivers/iommu/ipmmu-vmsa.c  |  2 +-
 drivers/iommu/msm_iommu.c   |  2 +-
 drivers/iommu/mtk_iommu.c   |  2 +-
 drivers/iommu/qcom_iommu.c  |  2 +-
 include/linux/io-pgtable.h  |  2 +-
 10 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c 
b/drivers/gpu/drm/panfrost/panfrost_mmu.c
index ed28aeb..5a39eee 100644
--- a/drivers/gpu/drm/panfrost/panfrost_mmu.c
+++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c
@@ -262,7 +262,7 @@ static int mmu_map_sg(struct panfrost_device *pfdev, struct 
panfrost_mmu *mmu,
while (len) {
size_t pgsize = get_pgsize(iova | paddr, len);
 
-   ops->map(ops, iova, paddr, pgsize, prot);
+   ops->map(ops, iova, paddr, pgsize, prot, GFP_KERNEL);
iova += pgsize;
paddr += pgsize;
len -= pgsize;
diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index 8250873..433b680 100644
--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c
@@ -2845,7 +2845,7 @@ static int arm_smmu_map(struct iommu_domain *domain, 
unsigned long iova,
if (!ops)
return -ENODEV;
 
-   return ops->map(ops, iova, paddr, size, prot);
+   return ops->map(ops, iova, paddr, size, prot, gfp);
 }
 
 static size_t arm_smmu_unmap(struct iommu_domain *domain, unsigned long iova,
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index a6a5796..bf640aa 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -1237,7 +1237,7 @@ static int arm_smmu_map(struct iommu_domain *domain, 
unsigned long iova,
return -ENODEV;
 
arm_smmu_rpm_get(smmu);
-   ret = ops->map(ops, iova, paddr, size, prot);
+   ret = ops->map(ops, iova, paddr, size, prot, gfp);
arm_smmu_rpm_put(smmu);
 
return ret;
diff --git a/drivers/iommu/io-pgtable-arm-v7s.c 
b/drivers/iommu/io-pgtable-arm-v7s.c
index 4272fe4..ebbe2c5 100644
--- a/drivers/iommu/io-pgtable-arm-v7s.c
+++ b/drivers/iommu/io-pgtable-arm-v7s.c
@@ -470,7 +470,7 @@ static arm_v7s_iopte arm_v7s_install_table(arm_v7s_iopte 
*table,
 
 static int __arm_v7s_map(struct arm_v7s_io_pgtable *data, unsigned long iova,
 phys_addr_t paddr, size_t size, int prot,
-int lvl, arm_v7s_iopte *ptep)
+int lvl, arm_v7s_iopte *ptep, gfp_t gfp)
 {
struct io_pgtable_cfg *cfg = &data->iop.cfg;
arm_v7s_iopte pte, *cptep;
@@ -491,7 +491,7 @@ static int __arm_v7s_map(struct arm_v7s_io_pgtable *data, 
unsigned long iova,
/* Grab a pointer to the next level */
pte = READ_ONCE(*ptep);
if (!pte) {
-   cptep = __arm_v7s_alloc_table(lvl + 1, GFP_ATOMIC, data);
+   cptep = __arm_v7s_alloc_table(lvl + 1, gfp, data);
if (!cptep)
return -ENOMEM;
 
@@ -512,11 +512,11 @@ static int __arm_v7s_map(struct arm_v7s_io_pgtable *data, 
unsigned long iova,
}
 
/* Rinse, repeat */
-   return __arm_v7s_map(data, iova, paddr, size, prot, lvl + 1, cptep);
+   return __arm_v7s_map(data, iova, paddr, size, prot, lvl + 1, cptep, 
gfp);
 }
 
 static int arm_v7s_map(struct io_pgtable_ops *ops, unsigned long iova,
-   phys_addr_t paddr, size_t size, int prot)
+   phys_addr_t paddr, size_t size, int prot, gfp_t gfp)
 {
struct arm_v7s_io_pgtable *data = io_pgtable_ops_to_data(ops);
struct io_pgtable *iop = &data->iop;
@@ -530,7 +530,7 @@ static int arm_v7s_map(struct io_pgtable_ops *ops, unsigned 
long iova,
paddr >= (1ULL << data->iop.cfg.oas)))
return -ERANGE;
 
-   ret = __arm_v7s_map(data, iova, paddr, size, prot, 1, data->pgd);
+   ret = __arm_v7s_map(data, iova, paddr, size, prot, 1, data->pgd, gfp);
/*
 * Synchronise all PTE updates for the new mapping before there's
 * a chance for anything to kick off a table walk for the new iova.
diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
index 04fbd4b..3ced132 100644
--- a/drivers/

[PATCH 0/2] Some improvements for iommu

[Baolin Wang]

Hi,

The first patch masks some functions as static, and the second patch
changes to use the gfp parameter from iommu_ops->map() to allocate
ARM page pages. Any comments are welcome. Thanks.

Baolin Wang (2):
  iommu: Mark __iommu_map/__iommu_map_sg as static
  iommu: Add gfp parameter to io_pgtable_ops->map()

 drivers/gpu/drm/panfrost/panfrost_mmu.c |  2 +-
 drivers/iommu/arm-smmu-v3.c |  2 +-
 drivers/iommu/arm-smmu.c|  2 +-
 drivers/iommu/io-pgtable-arm-v7s.c  | 10 +-
 drivers/iommu/io-pgtable-arm.c  | 10 +-
 drivers/iommu/iommu.c   | 10 +-
 drivers/iommu/ipmmu-vmsa.c  |  2 +-
 drivers/iommu/msm_iommu.c   |  2 +-
 drivers/iommu/mtk_iommu.c   |  2 +-
 drivers/iommu/qcom_iommu.c  |  2 +-
 include/linux/io-pgtable.h  |  2 +-
 11 files changed, 23 insertions(+), 23 deletions(-)

-- 
1.8.3.1

Re: [f2fs-dev] [PATCH] f2fs: add F2FS_IOC_TRIM_FILE ioctl

[Daeho Jeong]

Yes, this is for security key destruction.

AFAIK, discard will unmap the data block and, after done it,
we can read either zero data or garbage data from that block depending
on eMMC/UFS.
In a view point of read data, it might be the same with zeroing the data block.
However, since we can even unmap that block, I believe discard is
safer than zeroing out.

2020년 6월 8일 (월) 오전 11:46, Chao Yu 님이 작성:
>
> On 2020/6/5 12:27, Daeho Jeong wrote:
> > From: Daeho Jeong 
> >
> > Added a new ioctl to send discard commands to whole data area of
> > a regular file for security reason.
>
> I guess this interface is introduced for security key destruction, if I'm
> right, however, IIRC, discard(erase) semantics in eMMC/UFS spec won't
> guarantee that data which was discard could be zeroed out, so after discard,
> the key still have risk of exposure. So instead, should we use 
> sb_issue_zeroout()?
>
> Thanks,
>
> >
> > Signed-off-by: Daeho Jeong 
> > ---
> >  fs/f2fs/f2fs.h |   1 +
> >  fs/f2fs/file.c | 129 +
> >  2 files changed, 130 insertions(+)
> >
> > diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> > index c812fb8e2d9c..9ae81d0fefa0 100644
> > --- a/fs/f2fs/f2fs.h
> > +++ b/fs/f2fs/f2fs.h
> > @@ -434,6 +434,7 @@ static inline bool __has_cursum_space(struct 
> > f2fs_journal *journal,
> >   _IOR(F2FS_IOCTL_MAGIC, 18, __u64)
> >  #define F2FS_IOC_RESERVE_COMPRESS_BLOCKS \
> >   _IOR(F2FS_IOCTL_MAGIC, 19, __u64)
> > +#define F2FS_IOC_TRIM_FILE   _IO(F2FS_IOCTL_MAGIC, 20)
> >
> >  #define F2FS_IOC_GET_VOLUME_NAME FS_IOC_GETFSLABEL
> >  #define F2FS_IOC_SET_VOLUME_NAME FS_IOC_SETFSLABEL
> > diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
> > index dfa1ac2d751a..58507bb5649c 100644
> > --- a/fs/f2fs/file.c
> > +++ b/fs/f2fs/file.c
> > @@ -3749,6 +3749,132 @@ static int f2fs_reserve_compress_blocks(struct file 
> > *filp, unsigned long arg)
> >   return ret;
> >  }
> >
> > +static int f2fs_trim_file(struct file *filp)
> > +{
> > + struct inode *inode = file_inode(filp);
> > + struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
> > + struct address_space *mapping = inode->i_mapping;
> > + struct bio *bio = NULL;
> > + struct block_device *prev_bdev = NULL;
> > + loff_t file_size;
> > + pgoff_t index, pg_start = 0, pg_end;
> > + block_t prev_block = 0, len = 0;
> > + int ret = 0;
> > +
> > + if (!f2fs_hw_support_discard(sbi))
> > + return -EOPNOTSUPP;
> > +
> > + if (!S_ISREG(inode->i_mode) || f2fs_is_atomic_file(inode) ||
> > + f2fs_compressed_file(inode))
> > + return -EINVAL;
> > +
> > + if (f2fs_readonly(sbi->sb))
> > + return -EROFS;
> > +
> > + ret = mnt_want_write_file(filp);
> > + if (ret)
> > + return ret;
> > +
> > + inode_lock(inode);
> > +
> > + file_size = i_size_read(inode);
> > + if (!file_size)
> > + goto err;
> > + pg_end = (pgoff_t)round_up(file_size, PAGE_SIZE) >> PAGE_SHIFT;
> > +
> > + ret = f2fs_convert_inline_inode(inode);
> > + if (ret)
> > + goto err;
> > +
> > + down_write(&F2FS_I(inode)->i_gc_rwsem[WRITE]);
> > + down_write(&F2FS_I(inode)->i_mmap_sem);
> > +
> > + ret = filemap_write_and_wait(mapping);
> > + if (ret)
> > + goto out;
> > +
> > + truncate_inode_pages(mapping, 0);
> > +
> > + for (index = pg_start; index < pg_end;) {
> > + struct dnode_of_data dn;
> > + unsigned int end_offset;
> > +
> > + set_new_dnode(&dn, inode, NULL, NULL, 0);
> > + ret = f2fs_get_dnode_of_data(&dn, index, LOOKUP_NODE);
> > + if (ret)
> > + goto out;
> > +
> > + end_offset = ADDRS_PER_PAGE(dn.node_page, inode);
> > + if (pg_end < end_offset + index)
> > + end_offset = pg_end - index;
> > +
> > + for (; dn.ofs_in_node < end_offset;
> > + dn.ofs_in_node++, index++) {
> > + struct block_device *cur_bdev;
> > + block_t blkaddr = f2fs_data_blkaddr(&dn);
> > +
> > + if (__is_valid_data_blkaddr(blkaddr)) {
> > + if (!f2fs_is_valid_blkaddr(F2FS_I_SB(inode),
> > + blkaddr, DATA_GENERIC_ENHANCE)) {
> > + ret = -EFSCORRUPTED;
> > + goto out;
> > + }
> > + } else
> > + continue;
> > +
> > + cur_bdev = f2fs_target_device(sbi, blkaddr, NULL);
> > + if (f2fs_is_multi_device(sbi)) {
> > + int i = f2fs_target_device_index(sbi, 
> > blkaddr);
> > +
> > +  

Re: [PATCH RFC 03/13] vhost: batching fetches

[Jason Wang]

On 2020/6/7 下午9:57, Michael S. Tsirkin wrote:

On Fri, Jun 05, 2020 at 11:40:17AM +0800, Jason Wang wrote:

On 2020/6/4 下午4:59, Michael S. Tsirkin wrote:

On Wed, Jun 03, 2020 at 03:27:39PM +0800, Jason Wang wrote:

On 2020/6/2 下午9:06, Michael S. Tsirkin wrote:

With this patch applied, new and old code perform identically.

Lots of extra optimizations are now possible, e.g.
we can fetch multiple heads with copy_from/to_user now.
We can get rid of maintaining the log array.  Etc etc.

Signed-off-by: Michael S. Tsirkin
Signed-off-by: Eugenio Pérez
Link:https://lore.kernel.org/r/20200401183118.8334-4-epere...@redhat.com
Signed-off-by: Michael S. Tsirkin
---
drivers/vhost/test.c  |  2 +-
drivers/vhost/vhost.c | 47 ++-
drivers/vhost/vhost.h |  5 -
3 files changed, 47 insertions(+), 7 deletions(-)

diff --git a/drivers/vhost/test.c b/drivers/vhost/test.c
index 9a3a09005e03..02806d6f84ef 100644
--- a/drivers/vhost/test.c
+++ b/drivers/vhost/test.c
@@ -119,7 +119,7 @@ static int vhost_test_open(struct inode *inode, struct file 
*f)
dev = &n->dev;
vqs[VHOST_TEST_VQ] = &n->vqs[VHOST_TEST_VQ];
n->vqs[VHOST_TEST_VQ].handle_kick = handle_vq_kick;
-   vhost_dev_init(dev, vqs, VHOST_TEST_VQ_MAX, UIO_MAXIOV,
+   vhost_dev_init(dev, vqs, VHOST_TEST_VQ_MAX, UIO_MAXIOV + 64,
   VHOST_TEST_PKT_WEIGHT, VHOST_TEST_WEIGHT, NULL);
f->private_data = n;
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 8f9a07282625..aca2a5b0d078 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -299,6 +299,7 @@ static void vhost_vq_reset(struct vhost_dev *dev,
{
vq->num = 1;
vq->ndescs = 0;
+   vq->first_desc = 0;
vq->desc = NULL;
vq->avail = NULL;
vq->used = NULL;
@@ -367,6 +368,11 @@ static int vhost_worker(void *data)
return 0;
}
+static int vhost_vq_num_batch_descs(struct vhost_virtqueue *vq)
+{
+   return vq->max_descs - UIO_MAXIOV;
+}

1 descriptor does not mean 1 iov, e.g userspace may pass several 1 byte
length memory regions for us to translate.


Yes but I don't see the relevance. This tells us how many descriptors to
batch, not how many IOVs.

Yes, but questions are:

- this introduce another obstacle to support more than 1K queue size
- if we support 1K queue size, does it mean we need to cache 1K descriptors,
which seems a large stress on the cache

Thanks



Still don't understand the relevance. We support up to 1K descriptors
per buffer just for IOV since we always did. This adds 64 more
descriptors - is that a big deal?



If I understanding correctly, for net, the code tries to batch 
descriptors for at last one packet.


If we allow 1K queue size then we allow a packet that consists of 1K 
descriptors. Then we need to cache 1K descriptors.


Thanks

[PATCH v6] media: rcar-csi2: Correct the selection of hsfreqrange

[Suresh Udipi]

hsfreqrange should be chosen based on the calculated mbps which
is closer to the default bit rate  and within the range as per
table[1]. But current calculation always selects first value which
is greater than or equal to the calculated mbps which may lead
to chosing a wrong range in some cases.

For example for 360 mbps for H3/M3N
Existing logic selects
Calculated value 360Mbps : Default 400Mbps Range [368.125 -433.125 mbps]

This hsfreqrange is out of range.

The logic is changed to get the default value which is closest to the
calculated value [1]

Calculated value 360Mbps : Default 350Mbps  Range [320.625 -380.625 mpbs]

[1] specs r19uh0105ej0200-r-car-3rd-generation.pdf [Table 25.9]

Please note that According to Renesas in Table 25.9 the range for
220 default value is corrected as below

 |Range (Mbps) |  Default  Bit rate (Mbps) |
 ---
 | 197.125-244.125 | 220   |
 ---

Fixes: 769afd212b16 ("media: rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver 
driver")

Signed-off-by: Suresh Udipi 
Signed-off-by: Kazuyoshi Akiyama 
Signed-off-by: Michael Rodin 
---
 Changes in v2:
  - Added the boundary check for the maximum bit rate.

  - Simplified the logic by remmoving range check
as only the closest default value covers most
of the use cases.

  - Aligning the commit message based on the above change


 Changes in v3:
- Added max member from struct rcsi2_mbps_reg.
  mbps varialbe cannot be removed from rcsi2_mbps_reg,
  since this structure is reused for
  phtw_mbps_h3_v3h_m3n/phtw_mbps_v3m_e3 where mbps is
  used.


   -  Update the walk of the array in rcsi2_set_phypll() so that it finds
  the first entry where the calculated bit rate is less than the max.

   - Support lower bit rates less than 80Mbps like 48Mbps
 (Raspberry pi camera 640x480 connected to Kingfisher)
 can also be supported by selecting the lowest default bit rate 80Mbps
 as done before this fix

   - Alignement of the commit message based on above changes.

 Changes in v4:
  -  Remove unncessary braces.

 Changes in v5:
   - Removed mbps variable in rcsi2_mbps_reg and aligned all 
 tables accordingly
 
 Changes in v6
   - Renesas correct the range of default value 220Mbps. Now
 if we select the nearest value to the default value all
 the values are in range. So reverting back to original patch
 
   - Added warning for values less than Minimum 80Mbps


 drivers/media/platform/rcar-vin/rcar-csi2.c | 23 ++-
 1 file changed, 18 insertions(+), 5 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-csi2.c 
b/drivers/media/platform/rcar-vin/rcar-csi2.c
index 151e6a9..8c502b7 100644
--- a/drivers/media/platform/rcar-vin/rcar-csi2.c
+++ b/drivers/media/platform/rcar-vin/rcar-csi2.c
@@ -199,6 +199,8 @@ static const struct rcsi2_mbps_reg phtw_mbps_v3m_e3[] = {
 /* PHY Frequency Control */
 #define PHYPLL_REG 0x68
 #define PHYPLL_HSFREQRANGE(n)  ((n) << 16)
+#define PHYPLL_HSFREQRANGE_MAX 1500
+#define PHYPLL_HSFREQRANGE_MIN   80
 
 static const struct rcsi2_mbps_reg hsfreqrange_h3_v3h_m3n[] = {
{ .mbps =   80, .reg = 0x00 },
@@ -431,16 +433,27 @@ static int rcsi2_wait_phy_start(struct rcar_csi2 *priv)
 static int rcsi2_set_phypll(struct rcar_csi2 *priv, unsigned int mbps)
 {
const struct rcsi2_mbps_reg *hsfreq;
+   const struct rcsi2_mbps_reg *hsfreq_prev = NULL;
 
-   for (hsfreq = priv->info->hsfreqrange; hsfreq->mbps != 0; hsfreq++)
-   if (hsfreq->mbps >= mbps)
-   break;
-
-   if (!hsfreq->mbps) {
+   if (mbps > PHYPLL_HSFREQRANGE_MAX) {
dev_err(priv->dev, "Unsupported PHY speed (%u Mbps)", mbps);
return -ERANGE;
}
 
+   if (mbps < PHYPLL_HSFREQRANGE_MIN)
+   dev_warn(priv->dev, "PHY speed (%u Mbps) less \
+than Min 80Mbps\n", mbps);
+
+   for (hsfreq = priv->info->hsfreqrange; hsfreq->mbps != 0; hsfreq++) {
+   if (hsfreq->mbps >= mbps)
+   break;
+   hsfreq_prev = hsfreq;
+   }
+
+   if (hsfreq_prev &&
+   ((mbps - hsfreq_prev->mbps) <= (hsfreq->mbps - mbps)))
+   hsfreq = hsfreq_prev;
+
rcsi2_write(priv, PHYPLL_REG, PHYPLL_HSFREQRANGE(hsfreq->reg));
 
return 0;
-- 
2.7.4

[git pull] drm msm next for 5.8-rc1

[Dave Airlie]

Hi Linus,

This should be the final feature pull for drm for rc1. This tree has
been in next for a couple of weeks, but Rob missed an arm32 build
issue, so I was awaiting the tree with a patch reverted. The tree was
also based on an 5.7-rc5 tree so I didn't want to futz around with
backmerging just for this, so I'm sending it from a topic branch based
on v5.7.

Dave.

drm-next-msm-5.8-2020-06-08:
drm msm next for 5.8-rc1

* new gpu support: a405, a640, a650
* dpu: color processing support
* mdp5: support for msm8x36 (the thing with a405)
* some prep work for per-context pagetables (ie the part that
  does not depend on in-flight iommu patches)
* last but not least, UABI update for submit ioctl to support
  syncobj (from Bas)
The following changes since commit 3d77e6a8804abcc0504c904bd6e5cdf3a5cf8162:

  Linux 5.7 (2020-05-31 16:49:15 -0700)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm tags/drm-next-msm-5.8-2020-06-08

for you to fetch changes up to efe792f39ddbc6396b9142afff97855ee357b492:

  Merge https://gitlab.freedesktop.org/drm/msm into drm-next-msm-5.8
(2020-06-08 13:22:57 +1000)


drm msm next for 5.8-rc1

* new gpu support: a405, a640, a650
* dpu: color processing support
* mdp5: support for msm8x36 (the thing with a405)
* some prep work for per-context pagetables (ie the part that
  does not depend on in-flight iommu patches)
* last but not least, UABI update for submit ioctl to support
  syncobj (from Bas)


Bas Nieuwenhuizen (1):
  drm/msm: Add syncobj support.

Bjorn Andersson (1):
  drm/msm: Fix undefined "rd_full" link error

Christophe JAILLET (2):
  drm/msm/a6xx: Fix a typo in an error message
  drm/msm: Fix typo

Dave Airlie (1):
  Merge https://gitlab.freedesktop.org/drm/msm into drm-next-msm-5.8

Hongbo Yao (1):
  drm/msm/dpu: Fix compile warnings

Jonathan Marek (10):
  drm/msm: add msm_gem_get_and_pin_iova_range
  drm/msm: add internal MSM_BO_MAP_PRIV flag
  drm/msm/a6xx: use msm_gem for GMU memory objects
  drm/msm/a6xx: add A640/A650 to gpulist
  drm/msm/a6xx: HFI v2 for A640 and A650
  drm/msm/a6xx: A640/A650 GMU firmware path
  drm/msm/a6xx: update pdc/rscc GMU registers for A640/A650
  drm/msm/a6xx: enable GMU log
  drm/msm/a6xx: update a6xx_hw_init for A640 and A650
  drm/msm/a6xx: skip HFI set freq if GMU is powered down

Jordan Crouse (4):
  drm/msm: Check for powered down HW in the devfreq callbacks
  drm/msm: Attach the IOMMU device during initialization
  drm/msm: Refactor address space initialization
  drm/msm: Update the MMU helper function APIs

Kalyan Thota (3):
  drm/msm/dpu: add support for color processing blocks in dpu driver
  drm/msm/dpu: add support for pcc color block in dpu driver
  drm/msm/dpu: add support for clk and bw scaling for display

Konrad Dybcio (1):
  drm/msm/mdp5: Add MDP5 configuration for MSM8x36.

Krishna Manikandan (1):
  drm/msm/dpu: update bandwidth threshold check

Rob Clark (1):
  Revert "drm/msm/dpu: add support for clk and bw scaling for display"

Roy Spliet (1):
  drm/msm/mdp5: Fix mdp5_init error path for failed mdp5_kms allocation

Shawn Guo (2):
  drm/msm/a4xx: add adreno a405 support
  drm/msm/a4xx: add a405_registers for a405 device

kbuild test robot (2):
  drm/msm/a6xx: a6xx_hfi_send_start() can be static
  drm/msm/dpu: dpu_setup_dspp_pcc() can be static

 drivers/gpu/drm/msm/Makefile   |   1 +
 drivers/gpu/drm/msm/adreno/a2xx_gpu.c  |  16 +
 drivers/gpu/drm/msm/adreno/a3xx_gpu.c  |   1 +
 drivers/gpu/drm/msm/adreno/a4xx_gpu.c  |  83 -
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c  |   7 +
 drivers/gpu/drm/msm/adreno/a6xx.xml.h  |  14 +
 drivers/gpu/drm/msm/adreno/a6xx_gmu.c  | 418 +++--
 drivers/gpu/drm/msm/adreno/a6xx_gmu.h  |  37 ++-
 drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h  |  48 +--
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c  |  70 -
 drivers/gpu/drm/msm/adreno/a6xx_hfi.c  | 123 +++-
 drivers/gpu/drm/msm/adreno/a6xx_hfi.h  |  50 ++-
 drivers/gpu/drm/msm/adreno/adreno_device.c |  35 +++
 drivers/gpu/drm/msm/adreno/adreno_gpu.c|  27 +-
 drivers/gpu/drm/msm/adreno/adreno_gpu.h|  23 ++
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c  |  23 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c   |  95 --
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h   |   2 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c|  12 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c |  48 ++-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h |  39 +++
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c |  26 ++
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h |   3 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c| 129 
 drivers

Re: Re: Re: [PATCH] media: vsp1: Fix runtime PM imbalance in vsp1_probe

[dinghao . liu]

> 
> The vsp1_probe() function has a struct vsp1_device whose dev field is
> populated by the time it needs to call pm_runtime_get_sync() and
> pm_runtime_get_put(), so I think you can use vsp1_device_get() and
> vsp1_device_put() as drop-in replacements without changing the
> parameters to these two functions.
> 

It's clear to me, thanks!

Regards,
Dinghao

Re: [PATCH 5/6] vdpa: introduce virtio pci driver

[Jason Wang]

On 2020/6/7 下午9:51, Michael S. Tsirkin wrote:

On Fri, Jun 05, 2020 at 04:54:17PM +0800, Jason Wang wrote:

On 2020/6/2 下午3:08, Jason Wang wrote:

+static const struct pci_device_id vp_vdpa_id_table[] = {
+    { PCI_DEVICE(PCI_VENDOR_ID_REDHAT_QUMRANET, PCI_ANY_ID) },
+    { 0 }
+};

This looks like it'll create a mess with either virtio pci
or vdpa being loaded at random. Maybe just don't specify
any IDs for now. Down the road we could get a
distinct vendor ID or a range of device IDs for this.


Right, will do.

Thanks


Rethink about this. If we don't specify any ID, the binding won't work.

We can bind manually. It's not really for production anyway, so
not a big deal imho.



I think you mean doing it via "new_id", right.





How about using a dedicated subsystem vendor id for this?

Thanks

If virtio vendor id is used then standard driver is expected
to bind, right? Maybe use a dedicated vendor id?



I meant something like:

static const struct pci_device_id vp_vdpa_id_table[] = {
    { PCI_DEVICE_SUB(PCI_VENDOR_ID_REDHAT_QUMRANET, PCI_ANY_ID, 
VP_TEST_VENDOR_ID, VP_TEST_DEVICE_ID) },

    { 0 }
};

Thanks

Re: [rcu:dev.2020.06.02a 67/90] kernel/rcu/rcuperf.c:727:38: warning: format specifies type 'size_t' (aka 'unsigned int') but the argument has type 'unsigned long'

[Nathan Chancellor]

On Mon, Jun 08, 2020 at 09:56:16AM +0800, Kefeng Wang wrote:
> 
> On 2020/6/8 3:00, Paul E. McKenney wrote:
> > On Fri, Jun 05, 2020 at 05:19:14PM -0700, Paul E. McKenney wrote:
> > > On Sat, Jun 06, 2020 at 07:07:10AM +0800, kernel test robot wrote:
> > > > tree:   
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git 
> > > > dev.2020.06.02a
> > > > head:   5216948905dd07a84cef8a7dc72c2ec076802efd
> > > > commit: 7d16add62717136b1839f0b3d7ea4cbb98f38c2a [67/90] rcuperf: Fix 
> > > > kfree_mult to match printk() format
> > > > config: arm-randconfig-r004-20200605 (attached as .config)
> > > > compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project 
> > > > 6dd738e2f0609f7d3313b574a1d471263d2d3ba1)
> > > > 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
> > > >  git checkout 7d16add62717136b1839f0b3d7ea4cbb98f38c2a
> > > >  # 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 
> > > Adding Kefeng on CC.  Kefeng, thoughts?
> > Like this, perhaps?
> 
> Hi Paul，I check https://lkml.org/lkml/2020/6/2/286 and 
> 
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git/log/?h=dev.2020.06.02a
> 
> There are two different ways to fix the same issue
> 
> patch 1:  rcuperf: Fix printk format warning urgent-for-mingo
> 
> patch 2:  'rcuperf: Fix kfree_mult to match printk() format' from Ingo 
> after my patch
> 
> since patch1 already merged,  patch2 is not needed, so skip patch2?
> 
> Thanks.
> 
> 
> 
> 
> > 
> > Thanx, Paul
> > 
> > diff --git a/kernel/rcu/rcuperf.c b/kernel/rcu/rcuperf.c
> > index 962869d..dc7483a 100644
> > --- a/kernel/rcu/rcuperf.c
> > +++ b/kernel/rcu/rcuperf.c
> > @@ -724,7 +724,7 @@ kfree_perf_init(void)
> > schedule_timeout_uninterruptible(1);
> > }
> > -   pr_alert("kfree object size=%zu\n", kfree_mult * sizeof(struct 
> > kfree_obj));
> > +   pr_alert("kfree object size=%zu\n", (size_t)kfree_mult * sizeof(struct 
> > kfree_obj));
> > kfree_reader_tasks = kcalloc(kfree_nrealthreads, 
> > sizeof(kfree_reader_tasks[0]),
> >GFP_KERNEL);
> > 
> > > > All warnings (new ones prefixed by >>, old ones prefixed by <<):
> > > > 
> > > > > > kernel/rcu/rcuperf.c:727:38: warning: format specifies type 
> > > > > > 'size_t' (aka 'unsigned int') but the argument has type 'unsigned 
> > > > > > long' [-Wformat]
> > > > pr_alert("kfree object size=%zun", kfree_mult * sizeof(struct 
> > > > kfree_obj));
> > > > ~~~ ^
> > > > %lu
> > > > include/linux/printk.h:295:35: note: expanded from macro 'pr_alert'
> > > > printk(KERN_ALERT pr_fmt(fmt), ##__VA_ARGS__)
> > > > ~~~ ^~~
> > > > 1 warning generated.
> > > > 
> > > > vim +727 kernel/rcu/rcuperf.c
> > > > 
> > > > e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  709)
> > > > e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  710) static int 
> > > > __init
> > > > e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  711) 
> > > > kfree_perf_init(void)
> > > > e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  712) {
> > > > e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  713) long i;
> > > > e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  714) int 
> > > > firsterr = 0;
> > > > e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  715)
> > > > e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  716) 
> > > > kfree_nrealthreads = compute_real(kfree_nthreads);
> > > > e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  717) /* 
> > > > Start up the kthreads. */
> > > > e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  718) if 
> > > > (shutdown) {
> > > > e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  719) 
> > > > init_waitqueue_head(&shutdown_wq);
> > > > e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  720) 
> > > > firsterr = torture_create_kthread(kfree_perf_shutdown, NULL,
> > > > e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  721) 
> > > >   shutdown_task);
> > > > e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  722) 
> > > > if (firsterr)
> > > > e6e78b004fa7e0 Joel Fernandes (Google  2019-08-30  723) 
> > > > goto unwind;
> > > > e6e78b004fa7e0 Joel Fernandes (Google  2019-08-3

Re: [PATCH v2] drm/rcar-du: DRM_RCAR_WRITEBACK depends on DRM

[Laurent Pinchart]

Hi Qian,

I forgot to mention, I think the subject line should be

drm/rcar-du: Make DRM_RCAR_WRITEBACK depend on DRM_RCAR_DU

Could you please let me know if you're OK with these two small changes ?

On Mon, Jun 08, 2020 at 06:14:43AM +0300, Laurent Pinchart wrote:
> On Sun, Jun 07, 2020 at 10:53:40PM -0400, Qian Cai wrote:
> > There is no need to select DRM_RCAR_WRITEBACK if DRM=n which just make
> 
> s/DRM=n/DRM_RCAR_DU=n/ here.
> 
> > the generated .config a bit ugly.
> > 
> >  # ARM devices
> >  #
> >  # end of ARM devices
> > 
> >  CONFIG_DRM_RCAR_WRITEBACK=y
> > 
> >  #
> >  # Frame buffer Devices
> > 
> > Let DRM_RCAR_WRITEBACK depend on DRM_RCAR_DU instead.
> > 
> > Signed-off-by: Qian Cai 
> 
> Reviewed-by: Laurent Pinchart 
> 
> No need to submit a v3 if you agree with the above change, I'll fix it
> in my tree.
> 
> > ---
> >  drivers/gpu/drm/rcar-du/Kconfig | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/gpu/drm/rcar-du/Kconfig 
> > b/drivers/gpu/drm/rcar-du/Kconfig
> > index 0919f1f159a4..3304b41f5611 100644
> > --- a/drivers/gpu/drm/rcar-du/Kconfig
> > +++ b/drivers/gpu/drm/rcar-du/Kconfig
> > @@ -48,3 +48,4 @@ config DRM_RCAR_VSP
> >  config DRM_RCAR_WRITEBACK
> > bool
> > default y if ARM64
> > +   depends on DRM_RCAR_DU

-- 
Regards,

Laurent Pinchart

[git pull] drm next fixes for 5.7-rc1

[Dave Airlie]

Hey Linus,

This are the fixes from last week for the stuff merged in the merge
window. It got a bunch of nouveau fixes for HDA audio on some new
GPUs, some i915 and some amdpgu fixes.

I've got another pull request with Rob's msm next stuff in it I'll
send along after this, it was in -next all along, but it needed a
revert before I merged it, and it also was on a different base, so
I'll sent a separate pull from my fixes branch to avoid me having to
backmerge anything here yet.

Dave.

drm-next-2020-06-08:
drm fixes for 5.7-rc1

i915:
- gvt: Fix one clang warning on debug only function
   Use ARRAY_SIZE for coccicheck warn
- Use after free fix for display global state.
- Whitelisting context-local timestamp on Gen9
  and two scheduler fixes with deps (Cc: stable)
- Removal of write flag from sysfs files where
  ineffective

nouveau:
- HDMI/DP audio HDA fixes
- display hang fix for Volta/Turing
- GK20A regression fix.

amdgpu:
- Prevent hwmon accesses while GPU is in reset
- CTF interrupt fix
- Backlight fix for renoir
- Fix for display sync groups
- Display bandwidth validation workaround
The following changes since commit 9ca1f474cea0edc14a1d7ec933e5472c0ff115d3:

  Merge tag 'amd-drm-next-5.8-2020-05-27' of
git://people.freedesktop.org/~agd5f/linux into drm-next (2020-05-28
16:10:17 +1000)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm tags/drm-next-2020-06-08

for you to fetch changes up to 8d286e2ff4400d313955b4203fc640ca6fd9228b:

  Merge tag 'drm-intel-next-fixes-2020-06-04' of
git://anongit.freedesktop.org/drm/drm-intel into drm-next (2020-06-08
11:59:57 +1000)


drm fixes for 5.7-rc1

i915:
- gvt: Fix one clang warning on debug only function
   Use ARRAY_SIZE for coccicheck warn
- Use after free fix for display global state.
- Whitelisting context-local timestamp on Gen9
  and two scheduler fixes with deps (Cc: stable)
- Removal of write flag from sysfs files where
  ineffective

nouveau:
- HDMI/DP audio HDA fixes
- display hang fix for Volta/Turing
- GK20A regression fix.

amdgpu:
- Prevent hwmon accesses while GPU is in reset
- CTF interrupt fix
- Backlight fix for renoir
- Fix for display sync groups
- Display bandwidth validation workaround


Aishwarya Ramakrishnan (1):
  drm/i915/gvt: Use ARRAY_SIZE for vgpu_types

Alex Deucher (2):
  drm/amdgpu/pm: return an error during GPU reset or suspend (v2)
  drm/amdgpu/display: use blanked rather than plane state for sync groups

Ben Skeggs (8):
  drm/nouveau/disp/gm200-: fix NV_PDISP_SOR_HDMI2_CTRL(n) selection
  drm/nouveau/kms/gt215-: fix race with audio driver runpm
  drm/nouveau/disp: provide hint to OR allocation about HDA requirements
  drm/nouveau/disp: split part of OR allocation logic into a function
  drm/nouveau/disp: modify OR allocation policy to account for HDA
requirements
  drm/nouveau/disp/gp100: split SOR implementation from gm200
  drm/nouveau/disp/gm200-: detect and potentially disable HDA
support on some SORs
  drm/nouveau/kms/nv50-: clear SW state of disabled windows harder

Chris Wilson (9):
  drm/i915: Don't set queue-priority hint when supressing the reschedule
  drm/i915/gt: Remove errant assertion in __intel_context_do_pin
  drm/i915: Disable semaphore inter-engine sync without timeslicing
  drm/i915: Avoid using rq->engine after free during i915_fence_release
  drm/i915/gem: Avoid iterating an empty list
  drm/i915: Reorder await_execution before await_request
  drm/i915/gt: Do not schedule normal requests immediately along virtual
  drm/i915: Check for awaits on still currently executing requests
  drm/i915: Whitelist context-local timestamp in the gen9 cmdparser

Dave Airlie (3):
  Merge branch 'linux-5.8' of git://github.com/skeggsb/linux into drm-next
  Merge tag 'amd-drm-fixes-5.8-2020-06-04' of
git://people.freedesktop.org/~agd5f/linux into drm-next
  Merge tag 'drm-intel-next-fixes-2020-06-04' of
git://anongit.freedesktop.org/drm/drm-intel into drm-next

Evan Quan (1):
  drm/amd/powerplay: ack the SMUToHost interrupt on receive V2

Harry Wentland (1):
  Revert "drm/amd/display: disable dcn20 abm feature for bring up"

Jani Nikula (2):
  drm/i915/params: don't expose inject_probe_failure in debugfs
  drm/i915/params: fix i915.fake_lmem_start module param sysfs permissions

Joonas Lahtinen (1):
  Merge tag 'gvt-next-fixes-2020-05-28' of
https://github.com/intel/gvt-linux into drm-intel-next-fixes

Nathan Chancellor (1):
  drm/i915: Mark check_shadow_context_ppgtt as maybe unused

Nicholas Kazlauskas (1):
  drm/amd/display: Revalidate bandwidth before commiting DC updates

Thierry Reding (1):
  drm/nouveau: gr/gk20a: Use firmware version 0

Ville Syrjälä (1):
  drm/i915: Fix global state use-after-frees with a refcount

 driv

Re: [PATCH v2] drm/rcar-du: DRM_RCAR_WRITEBACK depends on DRM

[Laurent Pinchart]

Hi Qian,

Thank you for the patch.

On Sun, Jun 07, 2020 at 10:53:40PM -0400, Qian Cai wrote:
> There is no need to select DRM_RCAR_WRITEBACK if DRM=n which just make

s/DRM=n/DRM_RCAR_DU=n/ here.

> the generated .config a bit ugly.
> 
>  # ARM devices
>  #
>  # end of ARM devices
> 
>  CONFIG_DRM_RCAR_WRITEBACK=y
> 
>  #
>  # Frame buffer Devices
> 
> Let DRM_RCAR_WRITEBACK depend on DRM_RCAR_DU instead.
> 
> Signed-off-by: Qian Cai 

Reviewed-by: Laurent Pinchart 

No need to submit a v3 if you agree with the above change, I'll fix it
in my tree.

> ---
>  drivers/gpu/drm/rcar-du/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
> index 0919f1f159a4..3304b41f5611 100644
> --- a/drivers/gpu/drm/rcar-du/Kconfig
> +++ b/drivers/gpu/drm/rcar-du/Kconfig
> @@ -48,3 +48,4 @@ config DRM_RCAR_VSP
>  config DRM_RCAR_WRITEBACK
>   bool
>   default y if ARM64
> + depends on DRM_RCAR_DU

-- 
Regards,

Laurent Pinchart

Re: Re: [PATCH] media: vsp1: Fix runtime PM imbalance in vsp1_probe

[Laurent Pinchart]

Hi Dianghao,

On Mon, Jun 08, 2020 at 11:03:26AM +0800, dinghao@zju.edu.cn wrote:
> Hi Laurent,
> 
> > > I wonder how many bugs we have today, and how many bugs will keep
> > > appearing in the future, due to this historical design mistake :-( 
> 
> Good question. It's hard to say if this is a design mistake (some use
> of this API does not check its return value and expects it always to
> increment the usage counter). But it does make developers misuse it easier.
> 
> > > This change looks good to me, but we also need a similar change in the
> > > vsp1_device_get() function if I'm not mistaken. Could you combine both
> > > in the same patch ?
> 
> Thank you for your advice! I think you are right and I will fix this in the
> next version of patch. 
> 
> > And actually, after fixing vsp1_device_get(), we should replace the
> > pm_runtime_get_sync() call here with vsp1_device_get(), and the
> > pm_runtime_put_sync() below with vsp1_device_put(), so there would be no
> > need to call pm_runtime_put_sync() manually in the error path here.
> 
> The parameter type of vsp1_device_get() and vsp1_device_put() is "struct 
> vsp1_device". If we want to use these two wrappers, we need to adjust their 
> parameter type to "struct platform_device" or "struct device", which may 
> lead to errors in other callers. Maybe we should leave it as it is.

The vsp1_probe() function has a struct vsp1_device whose dev field is
populated by the time it needs to call pm_runtime_get_sync() and
pm_runtime_get_put(), so I think you can use vsp1_device_get() and
vsp1_device_put() as drop-in replacements without changing the
parameters to these two functions.

-- 
Regards,

Laurent Pinchart

Re: Re: [PATCH] media: vsp1: Fix runtime PM imbalance in vsp1_probe

[dinghao . liu]

Hi Laurent,

> > 
> > I wonder how many bugs we have today, and how many bugs will keep
> > appearing in the future, due to this historical design mistake :-( 
> > 

Good question. It's hard to say if this is a design mistake (some use
of this API does not check its return value and expects it always to
increment the usage counter). But it does make developers misuse it easier.

> > 
> > This change looks good to me, but we also need a similar change in the
> > vsp1_device_get() function if I'm not mistaken. Could you combine both
> > in the same patch ?
> 

Thank you for your advice! I think you are right and I will fix this in the
next version of patch. 

> And actually, after fixing vsp1_device_get(), we should replace the
> pm_runtime_get_sync() call here with vsp1_device_get(), and the
> pm_runtime_put_sync() below with vsp1_device_put(), so there would be no
> need to call pm_runtime_put_sync() manually in the error path here.
> 

The parameter type of vsp1_device_get() and vsp1_device_put() is "struct 
vsp1_device". If we want to use these two wrappers, we need to adjust their 
parameter type to "struct platform_device" or "struct device", which may 
lead to errors in other callers. Maybe we should leave it as it is.

Regards,
Dinghao

Re: [PATCH] f2fs: allow writeback on error status filesystem

[Chao Yu]

On 2020/6/8 5:17, Jaegeuk Kim wrote:
> On 06/05, Chao Yu wrote:
>> 71.07% 0.01%  kworker/u256:1+  [kernel.kallsyms]  [k] wb_writeback
>> |
>>  --71.06%--wb_writeback
>>|
>>|--68.96%--__writeback_inodes_wb
>>|  |
>>|   --68.95%--writeback_sb_inodes
>>| |
>>| 
>> |--65.08%--__writeback_single_inode
>>| |  |
>>| |   
>> --64.35%--do_writepages
>>| | |
>>| | 
>> |--59.83%--f2fs_write_node_pages
>>| | | 
>>  |
>>| | | 
>>   --59.74%--f2fs_sync_node_pages
>>| | | 
>> |
>>| | | 
>> |--27.91%--pagevec_lookup_range_tag
>>| | | 
>> |  |
>>| | | 
>> |   --27.90%--find_get_pages_range_tag
>>
>> If filesystem was injected w/ checkpoint errror, before umount, kworker
>> will always hold one core in order to writeback a large number of node
>> pages, that looks not reasonable, to avoid that, we can allow data/node
>> write in such case, since we can force all data/node writes with OPU mode,
>> and clear recovery flag on node, and checkpoint is not allowed as well,
>> so we don't need to worry about writeback's effect on data/node in
>> previous checkpoint, then with this way, it can decrease memory footprint
>> cost by node/data pages and avoid looping into data/node writeback
>> process.
> 
> This patch breaks fault injection test with filesystem corruption. Please 
> check.

My bad, will check soon.

Thanks,

> 
>>
>> Signed-off-by: Chao Yu 
>> ---
>>  fs/f2fs/data.c | 19 ---
>>  fs/f2fs/node.c |  7 +--
>>  2 files changed, 17 insertions(+), 9 deletions(-)
>>
>> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
>> index 9d40db50cd65..2b3c846181bb 100644
>> --- a/fs/f2fs/data.c
>> +++ b/fs/f2fs/data.c
>> @@ -2519,6 +2519,8 @@ bool f2fs_should_update_outplace(struct inode *inode, 
>> struct f2fs_io_info *fio)
>>  {
>>  struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
>>  
>> +if (unlikely(f2fs_cp_error(sbi)))
>> +return true;
>>  if (f2fs_lfs_mode(sbi))
>>  return true;
>>  if (S_ISDIR(inode->i_mode))
>> @@ -2702,13 +2704,16 @@ int f2fs_write_single_data_page(struct page *page, 
>> int *submitted,
>>  /* we should bypass data pages to proceed the kworkder jobs */
>>  if (unlikely(f2fs_cp_error(sbi))) {
>>  mapping_set_error(page->mapping, -EIO);
>> -/*
>> - * don't drop any dirty dentry pages for keeping lastest
>> - * directory structure.
>> - */
>> -if (S_ISDIR(inode->i_mode))
>> -goto redirty_out;
>> -goto out;
>> +
>> +if (has_not_enough_free_secs(sbi, 0, 0)) {
>> +/*
>> + * don't drop any dirty dentry pages for keeping lastest
>> + * directory structure.
>> + */
>> +if (S_ISDIR(inode->i_mode))
>> +goto redirty_out;
>> +goto out;
>> +}
>>  }
>>  
>>  if (unlikely(is_sbi_flag_set(sbi, SBI_POR_DOING)))
>> diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
>> index 03e24df1c84f..372c04efad38 100644
>> --- a/fs/f2fs/node.c
>> +++ b/fs/f2fs/node.c
>> @@ -1527,7 +1527,10 @@ static int __write_node_page(struct page *page, bool 
>> atomic, bool *submitted,
>>  unlock_page(page);
>>  return 0;
>>  }
>> -goto redirty_out;
>> +if (has_not_enough_free_secs(sbi, 0, 0))
>> +goto redirty_out;
>> +set_fsync_mark(page, 0);
>> +set_dentry_mark(page, 0);
>>  }
>>  
>>  if (unlikely(is_sbi_flag_set(sbi, SBI_POR_DOING)))
>> @@ -1568,7 +1571,7 @@ static int __write_node_page(struct page *page, bool 
>> atomic, bool *submitted,
>>  goto redirty_out;
>>  }
>>  
>> -if (atomic && !test_opt(sbi, NOBARRIER))
>> +if (atomic && !test_opt(sbi, NOBARRIER) && !f2fs_cp_error(sbi))
>>  fio.op_flags |= REQ_PREFLUSH | REQ_FUA;
>>  
>>  /* should add to global list before clearing PAGECACHE status */
>> -- 
>> 2.18.0

Re: [PATCH 0/2] Introduce PCI_FIXUP_IOMMU

[Zhangfei Gao]

Hi, Bjorn

On 2020/6/6 上午7:19, Bjorn Helgaas wrote:

On Thu, Jun 04, 2020 at 09:33:07PM +0800, Zhangfei Gao wrote:

On 2020/6/2 上午1:41, Bjorn Helgaas wrote:

On Thu, May 28, 2020 at 09:33:44AM +0200, Joerg Roedel wrote:

On Wed, May 27, 2020 at 01:18:42PM -0500, Bjorn Helgaas wrote:

Is this slowdown significant?  We already iterate over every device
when applying PCI_FIXUP_FINAL quirks, so if we used the existing
PCI_FIXUP_FINAL, we wouldn't be adding a new loop.  We would only be
adding two more iterations to the loop in pci_do_fixups() that tries
to match quirks against the current device.  I doubt that would be a
measurable slowdown.

I don't know how significant it is, but I remember people complaining
about adding new PCI quirks because it takes too long for them to run
them all. That was in the discussion about the quirk disabling ATS on
AMD Stoney systems.

So it probably depends on how many PCI devices are in the system whether
it causes any measureable slowdown.

I found this [1] from Paul Menzel, which was a slowdown caused by
quirk_usb_early_handoff().  I think the real problem is individual
quirks that take a long time.

The PCI_FIXUP_IOMMU things we're talking about should be fast, and of
course, they're only run for matching devices anyway.  So I'd rather
keep them as PCI_FIXUP_FINAL than add a whole new phase.


Thanks Bjorn for taking time for this.
If so, it would be much simpler.

+++ b/drivers/iommu/iommu.c
@@ -2418,6 +2418,10 @@ int iommu_fwspec_init(struct device *dev, struct
fwnode_handle *iommu_fwnode,
     fwspec->iommu_fwnode = iommu_fwnode;
     fwspec->ops = ops;
     dev_iommu_fwspec_set(dev, fwspec);
+
+   if (dev_is_pci(dev))
+   pci_fixup_device(pci_fixup_final, to_pci_dev(dev));
+

Then pci_fixup_final will be called twice, the first in pci_bus_add_device.
Here in iommu_fwspec_init is the second time, specifically for iommu_fwspec.
Will send this when 5.8-rc1 is open.

Wait, this whole fixup approach seems wrong to me.  No matter how you
do the fixup, it's still a fixup, which means it requires ongoing
maintenance.  Surely we don't want to have to add the Vendor/Device ID
for every new AMBA device that comes along, do we?


Here the fake pci device has standard PCI cfg space, but physical 
implementation is base on AMBA

They can provide pasid feature.
However,
1, does not support tlp since they are not real pci devices.
2. does not support pri, instead support stall (provided by smmu)
And stall is not a pci feature, so it is not described in struct 
pci_dev, but in struct iommu_fwspec.
So we use this fixup to tell pci system that the devices can support 
stall, and hereby support pasid.


Thanks

Re: [PATCH v10 00/10] exynos-ufs: Add support for UFS HCI

[Kishon Vijay Abraham I]

Hi Alim,

On 6/8/2020 8:15 AM, Alim Akhtar wrote:
> 
> 
>> -Original Message-
>> From: Martin K. Petersen 
>> Sent: 03 June 2020 08:02
>> To: r...@kernel.org; Alim Akhtar 
>> Cc: Martin K . Petersen ; k...@kernel.org;
> linux-
>> samsung-...@vger.kernel.org; avri.alt...@wdc.com;
>> stanley@mediatek.com; linux-s...@vger.kernel.org; linux-arm-
>> ker...@lists.infradead.org; c...@codeaurora.org;
> devicet...@vger.kernel.org;
>> kwmad@samsung.com; linux-kernel@vger.kernel.org
>> Subject: Re: [PATCH v10 00/10] exynos-ufs: Add support for UFS HCI
>>
>> On Thu, 28 May 2020 06:46:48 +0530, Alim Akhtar wrote:
>>
>>> This patch-set introduces UFS (Universal Flash Storage) host
>>> controller support for Samsung family SoC. Mostly, it consists of UFS
>>> PHY and host specific driver.
>>> [...]
>>
>> Applied [1,2,3,4,5,9] to 5.9/scsi-queue. The series won't show up in my
> public
>> tree until shortly after -rc1 is released.
>>
> Thanks Martin,
> Hi Rob and Kishon/Vinod
> Can you please pickup dt-bindings and PHY driver respectively?

You might have CC'ed me only for the PHY patch. I don't have the dt-bindings in
my inbox. Care to re-send what's missing again? This will be merged after -rc1
is tagged.

Thanks
Kishon

> 
>> Thanks!
>>
>> --
>> Martin K. Petersen   Oracle Linux Engineering
> 

[PATCH v2] drm/rcar-du: DRM_RCAR_WRITEBACK depends on DRM

[Qian Cai]

There is no need to select DRM_RCAR_WRITEBACK if DRM=n which just make
the generated .config a bit ugly.

 # ARM devices
 #
 # end of ARM devices

 CONFIG_DRM_RCAR_WRITEBACK=y

 #
 # Frame buffer Devices

Let DRM_RCAR_WRITEBACK depend on DRM_RCAR_DU instead.

Signed-off-by: Qian Cai 
---
 drivers/gpu/drm/rcar-du/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
index 0919f1f159a4..3304b41f5611 100644
--- a/drivers/gpu/drm/rcar-du/Kconfig
+++ b/drivers/gpu/drm/rcar-du/Kconfig
@@ -48,3 +48,4 @@ config DRM_RCAR_VSP
 config DRM_RCAR_WRITEBACK
bool
default y if ARM64
+   depends on DRM_RCAR_DU
-- 
2.21.0 (Apple Git-122.2)

RE: [PATCH v14 1/2] media: dt-bindings: media: xilinx: Add Xilinx MIPI CSI-2 Rx Subsystem

[Vishal Sagar]

Hi Laurent,

> -Original Message-
> From: Laurent Pinchart 
> Sent: Sunday, June 7, 2020 7:10 AM
> To: Vishal Sagar 
> Cc: Hyun Kwon ; mche...@kernel.org;
> robh...@kernel.org; mark.rutl...@arm.com; Michal Simek
> ; linux-me...@vger.kernel.org;
> devicet...@vger.kernel.org; hans.verk...@cisco.com; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org; Dinesh Kumar
> ; Sandip Kothari ; Luca Ceresoli
> ; Jacopo Mondi 
> Subject: Re: [PATCH v14 1/2] media: dt-bindings: media: xilinx: Add Xilinx 
> MIPI
> CSI-2 Rx Subsystem
> 
> Hi Vishal,
> 
> On Thu, May 28, 2020 at 07:25:12AM +, Vishal Sagar wrote:
> > On Wednesday, May 27, 2020 9:42 PM, Laurent Pinchart wrote:
> > > On Wed, May 27, 2020 at 07:27:18PM +0530, Vishal Sagar wrote:
> > > > Add bindings documentation for Xilinx MIPI CSI-2 Rx Subsystem.
> > > >
> > > > The Xilinx MIPI CSI-2 Rx Subsystem consists of a CSI-2 Rx
> > > > controller, a D-PHY in Rx mode and a Video Format Bridge.
> > > >
> > > > Signed-off-by: Vishal Sagar 
> > > > Reviewed-by: Hyun Kwon 
> > > > Reviewed-by: Rob Herring 
> > > > Reviewed-by: Luca Ceresoli 
> > > > Reviewed-by: Laurent Pinchart 
> > > > ---
> > > > v14
> > > > - Removed xlnx,csi-pxl-format from required properties
> > > > - Added dependency of xlnx,csi-pxl-format on xlnx,vfb
> > > > - End the yaml file with ...
> > > > - Added Reviewed by Laurent
> > > >
> > > > v13
> > > > - Based on Laurent's suggestions
> > > > - Fixed the datatypes values as minimum and maximum
> > > > - condition added for en-vcx property
> > > >
> > > > v12
> > > > - Moved to yaml format
> > > > - Update CSI-2 and D-PHY
> > > > - Mention that bindings for D-PHY not here
> > > > - reset -> video-reset
> > > >
> > > > v11
> > > > - Modify compatible string from 4.0 to 5.0
> > > >
> > > > v10
> > > > - No changes
> > > >
> > > > v9
> > > > - Fix xlnx,vfb description.
> > > > - s/Optional/Required endpoint property.
> > > > - Move data-lanes description from Ports to endpoint property section.
> > > >
> > > > v8
> > > > - Added reset-gpios optional property to assert video_aresetn
> > > >
> > > > v7
> > > > - Removed the control name from dt bindings
> > > > - Updated the example dt node name to csi2rx
> > > >
> > > > v6
> > > > - Added "control" after V4L2_CID_XILINX_MIPICSISS_ACT_LANES as
> > > > suggested by Luca
> > > > - Added reviewed by Rob Herring
> > > >
> > > > v5
> > > > - Incorporated comments by Luca Cersoli
> > > > - Removed DPHY clock from description and example
> > > > - Removed bayer pattern from device tree MIPI CSI IP
> > > >   doesn't deal with bayer pattern.
> > > >
> > > > v4
> > > > - Added reviewed by Hyun Kwon
> > > >
> > > > v3
> > > > - removed interrupt parent as suggested by Rob
> > > > - removed dphy clock
> > > > - moved vfb to optional properties
> > > > - Added required and optional port properties section
> > > > - Added endpoint property section
> > > >
> > > > v2
> > > > - updated the compatible string to latest version supported
> > > > - removed DPHY related parameters
> > > > - added CSI v2.0 related property (including VCX for supporting upto 16
> > > >   virtual channels).
> > > > - modified csi-pxl-format from string to unsigned int type where the 
> > > > value
> > > >   is as per the CSI specification
> > > > - Defined port 0 and port 1 as sink and source ports.
> > > > - Removed max-lanes property as suggested by Rob and Sakari
> > > >
> > > >  .../bindings/media/xilinx/xlnx,csi2rxss.yaml   | 237
> > > +
> > > >  1 file changed, 237 insertions(+)  create mode 100644
> > > > Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.yaml
> > > >
> > > > diff --git
> > > > a/Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.yam
> > > > l
> > > > b/Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.yam
> > > > l
> > > > new file mode 100644
> > > > index 000..2282231
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss
> > > > +++ .yam
> > > > +++ l
> > > > @@ -0,0 +1,237 @@
> > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML
> > > > +1.2
> > > > +---
> > > > +$id:
> > > > +http://devicetree.org/schemas/media/xilinx/xlnx,csi2rxss.yaml#
> > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > +
> > > > +title: Xilinx MIPI CSI-2 Receiver Subsystem
> > > > +
> > > > +maintainers:
> > > > +  - Vishal Sagar 
> > > > +
> > > > +description: |
> > > > +  The Xilinx MIPI CSI-2 Receiver Subsystem is used to capture
> > > > +MIPI
> > > > +CSI-2
> > > > +  traffic from compliant camera sensors and send the output as
> > > > +AXI4 Stream
> > > > +  video data for image processing.
> > > > +  The subsystem consists of a MIPI D-PHY in slave mode which
> > > > +captures the
> > > > +  data packets. This is passed along the MIPI CSI-2 Rx IP which
> > > > +extracts the
> > > > +  packet data. The optional Video Format Bridge (VFB) converts
> > > > +this data to
> > > >

Re: [PATCH 2/2 v2] f2fs: attach IO flags to the missing cases

[Jaegeuk Kim]

This patch adds another way to attach bio flags to node writes.

Description:   Give a way to attach REQ_META|FUA to node writes
   given temperature-based bits. Now the bits indicate:
   *  REQ_META |  REQ_FUA  |
   *5 |4 |   3 |2 |1 |   0 |
   * Cold | Warm | Hot | Cold | Warm | Hot |

Signed-off-by: Jaegeuk Kim 
---

v2 log:
 - remove redundant code

 Documentation/ABI/testing/sysfs-fs-f2fs |  9 +
 fs/f2fs/data.c  | 24 +++-
 fs/f2fs/f2fs.h  |  1 +
 fs/f2fs/sysfs.c |  2 ++
 4 files changed, 27 insertions(+), 9 deletions(-)

diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs 
b/Documentation/ABI/testing/sysfs-fs-f2fs
index 427f5b45c67f1..4bb93a06d8abc 100644
--- a/Documentation/ABI/testing/sysfs-fs-f2fs
+++ b/Documentation/ABI/testing/sysfs-fs-f2fs
@@ -333,6 +333,15 @@ Description:   Give a way to attach REQ_META|FUA to 
data writes
*5 |4 |   3 |2 |1 |   0 |
* Cold | Warm | Hot | Cold | Warm | Hot |
 
+What:  /sys/fs/f2fs//node_io_flag
+Date:  June 2020
+Contact:   "Jaegeuk Kim" 
+Description:   Give a way to attach REQ_META|FUA to node writes
+   given temperature-based bits. Now the bits indicate:
+   *  REQ_META |  REQ_FUA  |
+   *5 |4 |   3 |2 |1 |   0 |
+   * Cold | Warm | Hot | Cold | Warm | Hot |
+
 What:  /sys/fs/f2fs//iostat_period_ms
 Date:  April 2020
 Contact:   "Daeho Jeong" 
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 703fcb2433269..267b5e76a02b5 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -514,22 +514,28 @@ void f2fs_submit_bio(struct f2fs_sb_info *sbi,
__submit_bio(sbi, bio, type);
 }
 
-static void __attach_data_io_flag(struct f2fs_io_info *fio)
+static void __attach_io_flag(struct f2fs_io_info *fio)
 {
struct f2fs_sb_info *sbi = fio->sbi;
unsigned int temp_mask = (1 << NR_TEMP_TYPE) - 1;
-   unsigned int fua_flag = sbi->data_io_flag & temp_mask;
-   unsigned int meta_flag = (sbi->data_io_flag >> NR_TEMP_TYPE) &
-   temp_mask;
+   unsigned int io_flag, fua_flag, meta_flag;
+
+   if (fio->type == DATA)
+   io_flag = sbi->data_io_flag;
+   else if (fio->type == NODE)
+   io_flag = sbi->node_io_flag;
+   else
+   return;
+
+   fua_flag = io_flag & temp_mask;
+   meta_flag = (io_flag >> NR_TEMP_TYPE) & temp_mask;
+
/*
-* data io flag bits per temp:
+* data/node io flag bits per temp:
 *  REQ_META |  REQ_FUA  |
 *5 |4 |   3 |2 |1 |   0 |
 * Cold | Warm | Hot | Cold | Warm | Hot |
 */
-   if (fio->type != DATA)
-   return;
-
if ((1 << fio->temp) & meta_flag)
fio->op_flags |= REQ_META;
if ((1 << fio->temp) & fua_flag)
@@ -543,7 +549,7 @@ static void __submit_merged_bio(struct f2fs_bio_info *io)
if (!io->bio)
return;
 
-   __attach_data_io_flag(fio);
+   __attach_io_flag(fio);
bio_set_op_attrs(io->bio, fio->op, fio->op_flags);
 
if (is_read_io(fio->op))
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 7794e2f0d6e8a..c812fb8e2d9c7 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -1568,6 +1568,7 @@ struct f2fs_sb_info {
 
/* to attach REQ_META|REQ_FUA flags */
unsigned int data_io_flag;
+   unsigned int node_io_flag;
 
/* For sysfs suppport */
struct kobject s_kobj;
diff --git a/fs/f2fs/sysfs.c b/fs/f2fs/sysfs.c
index a117ae1f9d5f1..fc4a46b689040 100644
--- a/fs/f2fs/sysfs.c
+++ b/fs/f2fs/sysfs.c
@@ -554,6 +554,7 @@ F2FS_RW_ATTR(FAULT_INFO_RATE, f2fs_fault_info, inject_rate, 
inject_rate);
 F2FS_RW_ATTR(FAULT_INFO_TYPE, f2fs_fault_info, inject_type, inject_type);
 #endif
 F2FS_RW_ATTR(F2FS_SBI, f2fs_sb_info, data_io_flag, data_io_flag);
+F2FS_RW_ATTR(F2FS_SBI, f2fs_sb_info, node_io_flag, node_io_flag);
 F2FS_GENERAL_RO_ATTR(dirty_segments);
 F2FS_GENERAL_RO_ATTR(free_segments);
 F2FS_GENERAL_RO_ATTR(lifetime_write_kbytes);
@@ -635,6 +636,7 @@ static struct attribute *f2fs_attrs[] = {
ATTR_LIST(inject_type),
 #endif
ATTR_LIST(data_io_flag),
+   ATTR_LIST(node_io_flag),
ATTR_LIST(dirty_segments),
ATTR_LIST(free_segments),
ATTR_LIST(unusable),
-- 
2.27.0.278.ge193c7cf3a9-goog

Re: [f2fs-dev] [PATCH 2/2] f2fs: use kfree() to free sbi in f2fs_fill_super()

[Chao Yu]

On 2020/6/6 2:15, Denis Efremov wrote:
> Use kfree() instead of kvfree() to free sbi in
> f2fs_fill_super() because the memory is allocated with
> kzalloc() in the function.

Could you fix them in one patch?

In addition, we need to fix them in f2fs_put_super() as well.

Thanks,

> 
> Fixes: 5222595d093e ("f2fs: use kvmalloc, if kmalloc is failed")
> Signed-off-by: Denis Efremov 
> ---
>  fs/f2fs/super.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
> index 9a3c8eba37e2..39b644c7e9d4 100644
> --- a/fs/f2fs/super.c
> +++ b/fs/f2fs/super.c
> @@ -3812,7 +3812,7 @@ static int f2fs_fill_super(struct super_block *sb, void 
> *data, int silent)
>  free_sbi:
>   if (sbi->s_chksum_driver)
>   crypto_free_shash(sbi->s_chksum_driver);
> - kvfree(sbi);
> + kfree(sbi);
>  
>   /* give only one another chance */
>   if (retry_cnt > 0 && skip_recovery) {
> 

[RESEND PATCH] sys_personality: Add optional arch hook arch_check_personality

[Wang ShaoBo]

Currently arm64 personality syscall uses wrapper __arm64_sys_personality
to redirect to __arm64_sys_arm64_personality, it's easily confused,
Whereas using an normal hook arch_check_personality() can reject
additional settings like this for special case of different architectures.

This makes code clean and easier for subsequent modification.

Signed-off-by: Wang ShaoBo 
Reviewed-by: Dominik Brodowski 
---
 arch/arm64/kernel/sys.c  |  7 +++
 include/linux/syscalls.h | 10 --
 kernel/exec_domain.c | 14 +-
 3 files changed, 16 insertions(+), 15 deletions(-)

diff --git a/arch/arm64/kernel/sys.c b/arch/arm64/kernel/sys.c
index d5ffaaab31a7..5c01816d7a77 100644
--- a/arch/arm64/kernel/sys.c
+++ b/arch/arm64/kernel/sys.c
@@ -28,12 +28,13 @@ SYSCALL_DEFINE6(mmap, unsigned long, addr, unsigned long, 
len,
return ksys_mmap_pgoff(addr, len, prot, flags, fd, off >> PAGE_SHIFT);
 }
 
-SYSCALL_DEFINE1(arm64_personality, unsigned int, personality)
+int arch_check_personality(unsigned int personality)
 {
if (personality(personality) == PER_LINUX32 &&
!system_supports_32bit_el0())
return -EINVAL;
-   return ksys_personality(personality);
+
+   return 0;
 }
 
 asmlinkage long sys_ni_syscall(void);
@@ -46,8 +47,6 @@ asmlinkage long __arm64_sys_ni_syscall(const struct pt_regs 
*__unused)
 /*
  * Wrappers to pass the pt_regs argument.
  */
-#define __arm64_sys_personality__arm64_sys_arm64_personality
-
 #undef __SYSCALL
 #define __SYSCALL(nr, sym) asmlinkage long __arm64_##sym(const struct 
pt_regs *);
 #include 
diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
index 1815065d52f3..3dbbad498027 100644
--- a/include/linux/syscalls.h
+++ b/include/linux/syscalls.h
@@ -1393,16 +1393,6 @@ static inline long ksys_truncate(const char __user 
*pathname, loff_t length)
return do_sys_truncate(pathname, length);
 }
 
-static inline unsigned int ksys_personality(unsigned int personality)
-{
-   unsigned int old = current->personality;
-
-   if (personality != 0x)
-   set_personality(personality);
-
-   return old;
-}
-
 /* for __ARCH_WANT_SYS_IPC */
 long ksys_semtimedop(int semid, struct sembuf __user *tsops,
 unsigned int nsops,
diff --git a/kernel/exec_domain.c b/kernel/exec_domain.c
index 33f07c5f2515..f3682f4bf205 100644
--- a/kernel/exec_domain.c
+++ b/kernel/exec_domain.c
@@ -35,9 +35,21 @@ static int __init proc_execdomains_init(void)
 module_init(proc_execdomains_init);
 #endif
 
+int __weak arch_check_personality(unsigned int personality)
+{
+   return 0;
+}
+
 SYSCALL_DEFINE1(personality, unsigned int, personality)
 {
-   unsigned int old = current->personality;
+   int err;
+   unsigned int old;
+
+   err = arch_check_personality(personality);
+   if (err)
+   return err;
+
+   old = current->personality;
 
if (personality != 0x)
set_personality(personality);
-- 
2.17.1

Re: [v1 PATCH 1/2] Refactoring carrying over IMA measuremnet logs over Kexec.

[kernel test robot]

Hi Prakhar,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on arm64/for-next/core]
[also build test ERROR on powerpc/next soc/for-next v5.7 next-20200605]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:
https://github.com/0day-ci/linux/commits/Prakhar-Srivastava/Adding-support-to-carry-IMA-measurement-logs/20200608-073805
base:   https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git 
for-next/core
config: powerpc-allyesconfig (attached as .config)
compiler: powerpc64-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
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=powerpc 

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

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

arch/powerpc/kexec/ima.c:24:5: warning: no previous prototype for 
'arch_ima_add_kexec_buffer' [-Wmissing-prototypes]
24 | int arch_ima_add_kexec_buffer(struct kimage *image, unsigned long 
load_addr,
| ^
arch/powerpc/kexec/ima.c:62:5: warning: no previous prototype for 
'setup_ima_buffer' [-Wmissing-prototypes]
62 | int setup_ima_buffer(const struct kimage *image, void *fdt, int 
chosen_node)
| ^~~~
arch/powerpc/kexec/ima.c: In function 'setup_ima_buffer':
>> arch/powerpc/kexec/ima.c:71:8: error: implicit declaration of function 
>> 'get_addr_size_cells'; did you mean 'fdt_address_cells'? 
>> [-Werror=implicit-function-declaration]
71 |  ret = get_addr_size_cells(&addr_cells, &size_cells);
|^~~
|fdt_address_cells
cc1: some warnings being treated as errors

vim +71 arch/powerpc/kexec/ima.c

ab6b1d1fc4aae6 arch/powerpc/kernel/ima_kexec.c Thiago Jung Bauermann 2016-12-19 
 53  
ab6b1d1fc4aae6 arch/powerpc/kernel/ima_kexec.c Thiago Jung Bauermann 2016-12-19 
 54  /**
ab6b1d1fc4aae6 arch/powerpc/kernel/ima_kexec.c Thiago Jung Bauermann 2016-12-19 
 55   * setup_ima_buffer - add IMA buffer information to the fdt
ab6b1d1fc4aae6 arch/powerpc/kernel/ima_kexec.c Thiago Jung Bauermann 2016-12-19 
 56   * @image: kexec image being loaded.
ab6b1d1fc4aae6 arch/powerpc/kernel/ima_kexec.c Thiago Jung Bauermann 2016-12-19 
 57   * @fdt:   Flattened device tree for the next kernel.
ab6b1d1fc4aae6 arch/powerpc/kernel/ima_kexec.c Thiago Jung Bauermann 2016-12-19 
 58   * @chosen_node:   Offset to the chosen node.
ab6b1d1fc4aae6 arch/powerpc/kernel/ima_kexec.c Thiago Jung Bauermann 2016-12-19 
 59   *
ab6b1d1fc4aae6 arch/powerpc/kernel/ima_kexec.c Thiago Jung Bauermann 2016-12-19 
 60   * Return: 0 on success, or negative errno on error.
ab6b1d1fc4aae6 arch/powerpc/kernel/ima_kexec.c Thiago Jung Bauermann 2016-12-19 
 61   */
ab6b1d1fc4aae6 arch/powerpc/kernel/ima_kexec.c Thiago Jung Bauermann 2016-12-19 
 62  int setup_ima_buffer(const struct kimage *image, void *fdt, int 
chosen_node)
ab6b1d1fc4aae6 arch/powerpc/kernel/ima_kexec.c Thiago Jung Bauermann 2016-12-19 
 63  {
ab6b1d1fc4aae6 arch/powerpc/kernel/ima_kexec.c Thiago Jung Bauermann 2016-12-19 
 64 int ret, addr_cells, size_cells, entry_size;
ab6b1d1fc4aae6 arch/powerpc/kernel/ima_kexec.c Thiago Jung Bauermann 2016-12-19 
 65 u8 value[16];
ab6b1d1fc4aae6 arch/powerpc/kernel/ima_kexec.c Thiago Jung Bauermann 2016-12-19 
 66  
aea659ce44ba07 arch/powerpc/kexec/ima.cPrakhar Srivastava2020-06-07 
 67  // remove_ima_buffer(fdt, chosen_node);
ab6b1d1fc4aae6 arch/powerpc/kernel/ima_kexec.c Thiago Jung Bauermann 2016-12-19 
 68 if (!image->arch.ima_buffer_size)
ab6b1d1fc4aae6 arch/powerpc/kernel/ima_kexec.c Thiago Jung Bauermann 2016-12-19 
 69 return 0;
ab6b1d1fc4aae6 arch/powerpc/kernel/ima_kexec.c Thiago Jung Bauermann 2016-12-19 
 70  
ab6b1d1fc4aae6 arch/powerpc/kernel/ima_kexec.c Thiago Jung Bauermann 2016-12-19 
@71 ret = get_addr_size_cells(&addr_cells, &size_cells);

:: The code at line 71 was first introduced by commit
:: ab6b1d1fc4aae6b8bd6fb1422405568094c9b40f powerpc: ima: send the kexec 
buffer to the next kernel

:: TO: Thiago Jung Bauermann 
:: CC: Linus Torvalds 

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


.config.gz
Description: application/gzip

Re: [f2fs-dev] [PATCH 1/2] f2fs: use kfree() to free super in read_raw_super_block()

[Chao Yu]

On 2020/6/6 2:15, Denis Efremov wrote:
> Use kfree() instead of kvfree() to free super in
> read_raw_super_block() because the memory is allocated with
> kzalloc() in the function.
> 
> Fixes: 5222595d093e ("f2fs: use kvmalloc, if kmalloc is failed")
> Signed-off-by: Denis Efremov 

Reviewed-by: Chao Yu 

Thanks,

Re: [f2fs-dev] [PATCH] f2fs: add F2FS_IOC_TRIM_FILE ioctl

[Chao Yu]

On 2020/6/5 12:27, Daeho Jeong wrote:
> From: Daeho Jeong 
> 
> Added a new ioctl to send discard commands to whole data area of
> a regular file for security reason.

I guess this interface is introduced for security key destruction, if I'm
right, however, IIRC, discard(erase) semantics in eMMC/UFS spec won't
guarantee that data which was discard could be zeroed out, so after discard,
the key still have risk of exposure. So instead, should we use 
sb_issue_zeroout()?

Thanks,

> 
> Signed-off-by: Daeho Jeong 
> ---
>  fs/f2fs/f2fs.h |   1 +
>  fs/f2fs/file.c | 129 +
>  2 files changed, 130 insertions(+)
> 
> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> index c812fb8e2d9c..9ae81d0fefa0 100644
> --- a/fs/f2fs/f2fs.h
> +++ b/fs/f2fs/f2fs.h
> @@ -434,6 +434,7 @@ static inline bool __has_cursum_space(struct f2fs_journal 
> *journal,
>   _IOR(F2FS_IOCTL_MAGIC, 18, __u64)
>  #define F2FS_IOC_RESERVE_COMPRESS_BLOCKS \
>   _IOR(F2FS_IOCTL_MAGIC, 19, __u64)
> +#define F2FS_IOC_TRIM_FILE   _IO(F2FS_IOCTL_MAGIC, 20)
>  
>  #define F2FS_IOC_GET_VOLUME_NAME FS_IOC_GETFSLABEL
>  #define F2FS_IOC_SET_VOLUME_NAME FS_IOC_SETFSLABEL
> diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
> index dfa1ac2d751a..58507bb5649c 100644
> --- a/fs/f2fs/file.c
> +++ b/fs/f2fs/file.c
> @@ -3749,6 +3749,132 @@ static int f2fs_reserve_compress_blocks(struct file 
> *filp, unsigned long arg)
>   return ret;
>  }
>  
> +static int f2fs_trim_file(struct file *filp)
> +{
> + struct inode *inode = file_inode(filp);
> + struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
> + struct address_space *mapping = inode->i_mapping;
> + struct bio *bio = NULL;
> + struct block_device *prev_bdev = NULL;
> + loff_t file_size;
> + pgoff_t index, pg_start = 0, pg_end;
> + block_t prev_block = 0, len = 0;
> + int ret = 0;
> +
> + if (!f2fs_hw_support_discard(sbi))
> + return -EOPNOTSUPP;
> +
> + if (!S_ISREG(inode->i_mode) || f2fs_is_atomic_file(inode) ||
> + f2fs_compressed_file(inode))
> + return -EINVAL;
> +
> + if (f2fs_readonly(sbi->sb))
> + return -EROFS;
> +
> + ret = mnt_want_write_file(filp);
> + if (ret)
> + return ret;
> +
> + inode_lock(inode);
> +
> + file_size = i_size_read(inode);
> + if (!file_size)
> + goto err;
> + pg_end = (pgoff_t)round_up(file_size, PAGE_SIZE) >> PAGE_SHIFT;
> +
> + ret = f2fs_convert_inline_inode(inode);
> + if (ret)
> + goto err;
> +
> + down_write(&F2FS_I(inode)->i_gc_rwsem[WRITE]);
> + down_write(&F2FS_I(inode)->i_mmap_sem);
> +
> + ret = filemap_write_and_wait(mapping);
> + if (ret)
> + goto out;
> +
> + truncate_inode_pages(mapping, 0);
> +
> + for (index = pg_start; index < pg_end;) {
> + struct dnode_of_data dn;
> + unsigned int end_offset;
> +
> + set_new_dnode(&dn, inode, NULL, NULL, 0);
> + ret = f2fs_get_dnode_of_data(&dn, index, LOOKUP_NODE);
> + if (ret)
> + goto out;
> +
> + end_offset = ADDRS_PER_PAGE(dn.node_page, inode);
> + if (pg_end < end_offset + index)
> + end_offset = pg_end - index;
> +
> + for (; dn.ofs_in_node < end_offset;
> + dn.ofs_in_node++, index++) {
> + struct block_device *cur_bdev;
> + block_t blkaddr = f2fs_data_blkaddr(&dn);
> +
> + if (__is_valid_data_blkaddr(blkaddr)) {
> + if (!f2fs_is_valid_blkaddr(F2FS_I_SB(inode),
> + blkaddr, DATA_GENERIC_ENHANCE)) {
> + ret = -EFSCORRUPTED;
> + goto out;
> + }
> + } else
> + continue;
> +
> + cur_bdev = f2fs_target_device(sbi, blkaddr, NULL);
> + if (f2fs_is_multi_device(sbi)) {
> + int i = f2fs_target_device_index(sbi, blkaddr);
> +
> + blkaddr -= FDEV(i).start_blk;
> + }
> +
> + if (len) {
> + if (prev_bdev == cur_bdev &&
> + blkaddr == prev_block + len) {
> + len++;
> + } else {
> + ret = __blkdev_issue_discard(prev_bdev,
> + SECTOR_FROM_BLOCK(prev_block),
> + SECTOR_FROM_BLOCK(len),
> + GFP_NOFS, 0, &bio);
> +

RE: [PATCH v10 00/10] exynos-ufs: Add support for UFS HCI

[Alim Akhtar]

> -Original Message-
> From: Martin K. Petersen 
> Sent: 03 June 2020 08:02
> To: r...@kernel.org; Alim Akhtar 
> Cc: Martin K . Petersen ; k...@kernel.org;
linux-
> samsung-...@vger.kernel.org; avri.alt...@wdc.com;
> stanley@mediatek.com; linux-s...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; c...@codeaurora.org;
devicet...@vger.kernel.org;
> kwmad@samsung.com; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v10 00/10] exynos-ufs: Add support for UFS HCI
> 
> On Thu, 28 May 2020 06:46:48 +0530, Alim Akhtar wrote:
> 
> > This patch-set introduces UFS (Universal Flash Storage) host
> > controller support for Samsung family SoC. Mostly, it consists of UFS
> > PHY and host specific driver.
> > [...]
> 
> Applied [1,2,3,4,5,9] to 5.9/scsi-queue. The series won't show up in my
public
> tree until shortly after -rc1 is released.
> 
Thanks Martin,
Hi Rob and Kishon/Vinod
Can you please pickup dt-bindings and PHY driver respectively?

> Thanks!
> 
> --
> Martin K. PetersenOracle Linux Engineering

Re: [PATCH] drm/rcar-du: DRM_RCAR_WRITEBACK depends on DRM

[Qian Cai]

> On Jun 7, 2020, at 10:02 PM, Laurent Pinchart 
>  wrote:
> 
> How about depending on DRM_RCAR_DU instead, as DRM_RCAR_WRITEBACK is
> used to select compilation of rcar_du_writeback.c that is part of the
> rcar-du driver ?

Sure. I’ll send a v2.

Re: [v1 PATCH 1/2] Refactoring carrying over IMA measuremnet logs over Kexec.

[kernel test robot]

Hi Prakhar,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on arm64/for-next/core]
[also build test WARNING on powerpc/next soc/for-next v5.7 next-20200605]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:
https://github.com/0day-ci/linux/commits/Prakhar-Srivastava/Adding-support-to-carry-IMA-measurement-logs/20200608-073805
base:   https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git 
for-next/core
config: arm64-allyesconfig (attached as .config)
compiler: aarch64-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
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=arm64 

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 <<):

>> security/integrity/ima/ima_kexec.c:59:5: warning: no previous prototype for 
>> 'ima_get_kexec_buffer' [-Wmissing-prototypes]
59 | int ima_get_kexec_buffer(void **addr, size_t *size)
| ^~~~
>> security/integrity/ima/ima_kexec.c:85:5: warning: no previous prototype for 
>> 'delete_fdt_mem_rsv' [-Wmissing-prototypes]
85 | int delete_fdt_mem_rsv(void *fdt, unsigned long start, unsigned long size)
| ^~
>> security/integrity/ima/ima_kexec.c:115:5: warning: no previous prototype for 
>> 'ima_free_kexec_buffer' [-Wmissing-prototypes]
115 | int ima_free_kexec_buffer(void)
| ^
>> security/integrity/ima/ima_kexec.c:144:6: warning: no previous prototype for 
>> 'remove_ima_buffer' [-Wmissing-prototypes]
144 | void remove_ima_buffer(void *fdt, int chosen_node)
|  ^
security/integrity/ima/ima_kexec.c:231:6: warning: no previous prototype for 
'ima_add_kexec_buffer' [-Wmissing-prototypes]
231 | void ima_add_kexec_buffer(struct kimage *image)
|  ^~~~

vim +/ima_get_kexec_buffer +59 security/integrity/ima/ima_kexec.c

51  
52  /**
53   * ima_get_kexec_buffer - get IMA buffer from the previous kernel
54   * @addr:   On successful return, set to point to the buffer 
contents.
55   * @size:   On successful return, set to the buffer size.
56   *
57   * Return: 0 on success, negative errno on error.
58   */
  > 59  int ima_get_kexec_buffer(void **addr, size_t *size)
60  {
61  int ret, len;
62  unsigned long tmp_addr;
63  size_t tmp_size;
64  const void *prop;
65  
66  prop = of_get_property(of_chosen, "linux,ima-kexec-buffer", 
&len);
67  if (!prop)
68  return -ENOENT;
69  
70  ret = do_get_kexec_buffer(prop, len, &tmp_addr, &tmp_size);
71  if (ret)
72  return ret;
73  
74  *addr = __va(tmp_addr);
75  *size = tmp_size;
76  
77  return 0;
78  }
79  
80  /**
81   * delete_fdt_mem_rsv - delete memory reservation with given address 
and size
82   *
83   * Return: 0 on success, or negative errno on error.
84   */
  > 85  int delete_fdt_mem_rsv(void *fdt, unsigned long start, unsigned long 
size)
86  {
87  int i, ret, num_rsvs = fdt_num_mem_rsv(fdt);
88  
89  for (i = 0; i < num_rsvs; i++) {
90  uint64_t rsv_start, rsv_size;
91  
92  ret = fdt_get_mem_rsv(fdt, i, &rsv_start, &rsv_size);
93  if (ret) {
94  pr_err("Malformed device tree.\n");
95  return -EINVAL;
96  }
97  
98  if (rsv_start == start && rsv_size == size) {
99  ret = fdt_del_mem_rsv(fdt, i);
   100  if (ret) {
   101  pr_err("Error deleting device tree 
reservation.\n");
   102  return -EINVAL;
   103  }
   104  
   105  return 0;
   106  }
   107  }
   108  
   109  return -ENOENT;
   110  }
   111  
   112  /**
   113   * ima_free_kexec_buffer - free memory used by the IMA buffer
   114   */
 > 115  int ima_free_kexec_buffer(void)
   116  {
   117  int ret;
   118  unsigned long addr;
   119  size_t size;
   120  struct property *prop;
   121  
   122  prop = of_find_property(of_chosen, "linux,ima-kexec-buffer", 
NULL);
   123  if (!prop)
   124  return -ENOENT;
   125  

FATAL: drivers/phy/intel/phy-intel-emmc: sizeof(struct of_device_id)=200 is not a modulo of the size of section __mod_of___device_table=512.

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   af7b4801030c07637840191c69eb666917e4135d
commit: 9227942383307f97fa6992416f73af4a23ef972c phy: intel-lgm-emmc: Add 
support for eMMC PHY
date:   5 months ago
config: x86_64-randconfig-a011-20200607 (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project 
e429cffd4f228f70c1d9df0e5d77c08590dd9766)
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 x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
git checkout 9227942383307f97fa6992416f73af4a23ef972c
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 

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

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

WARNING: modpost: missing MODULE_LICENSE() in drivers/phy/intel/phy-intel-emmc.o
see include/linux/module.h for more information
>> FATAL: drivers/phy/intel/phy-intel-emmc: sizeof(struct of_device_id)=200 is 
>> not a modulo of the size of section __mod_of___device_table=512.
Fix definition of struct of_device_id in mod_devicetable.h

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


.config.gz
Description: application/gzip

Re: [f2fs-dev] [PATCH 2/2] f2fs: attach IO flags to the missing cases

[Chao Yu]

On 2020/6/5 7:50, Jaegeuk Kim wrote:
> This adds more IOs to attach flags.
> 
> Fixes: d58f2f658159 ("f2fs: add node_io_flag for bio flags likewise 
> data_io_flag")
> Signed-off-by: Jaegeuk Kim 

Reviewed-by: Chao Yu 

Thanks,

Re: [f2fs-dev] [PATCH 1/2] f2fs: add node_io_flag for bio flags likewise data_io_flag

[Chao Yu]

On 2020/6/5 7:50, Jaegeuk Kim wrote:
> This patch adds another way to attach bio flags to node writes.
> 
> Description:   Give a way to attach REQ_META|FUA to node writes
>given temperature-based bits. Now the bits indicate:
>*  REQ_META |  REQ_FUA  |
>*5 |4 |   3 |2 |1 |   0 |
>* Cold | Warm | Hot | Cold | Warm | Hot |
> 
> Signed-off-by: Jaegeuk Kim 
> ---
>  Documentation/ABI/testing/sysfs-fs-f2fs |  9 ++
>  fs/f2fs/data.c  | 39 ++---
>  fs/f2fs/f2fs.h  |  1 +
>  fs/f2fs/sysfs.c |  2 ++
>  4 files changed, 40 insertions(+), 11 deletions(-)
> 
> diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs 
> b/Documentation/ABI/testing/sysfs-fs-f2fs
> index 427f5b45c67f1..4bb93a06d8abc 100644
> --- a/Documentation/ABI/testing/sysfs-fs-f2fs
> +++ b/Documentation/ABI/testing/sysfs-fs-f2fs
> @@ -333,6 +333,15 @@ Description: Give a way to attach REQ_META|FUA to 
> data writes
>   *5 |4 |   3 |2 |1 |   0 |
>   * Cold | Warm | Hot | Cold | Warm | Hot |
>  
> +What:/sys/fs/f2fs//node_io_flag
> +Date:June 2020
> +Contact: "Jaegeuk Kim" 
> +Description: Give a way to attach REQ_META|FUA to node writes
> + given temperature-based bits. Now the bits indicate:
> + *  REQ_META |  REQ_FUA  |
> + *5 |4 |   3 |2 |1 |   0 |
> + * Cold | Warm | Hot | Cold | Warm | Hot |
> +
>  What:/sys/fs/f2fs//iostat_period_ms
>  Date:April 2020
>  Contact: "Daeho Jeong" 
> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
> index a65bfc07ddb97..2f5293eb5e52a 100644
> --- a/fs/f2fs/data.c
> +++ b/fs/f2fs/data.c
> @@ -514,26 +514,43 @@ void f2fs_submit_bio(struct f2fs_sb_info *sbi,
>   __submit_bio(sbi, bio, type);
>  }
>  
> -static void __attach_data_io_flag(struct f2fs_io_info *fio)
> +static void __attach_io_flag(struct f2fs_io_info *fio)
>  {
>   struct f2fs_sb_info *sbi = fio->sbi;
>   unsigned int temp_mask = (1 << NR_TEMP_TYPE) - 1;

Could we avoid duplicated codes as much as possible?

unsigned int flag = fio->type == DATA ? sbi->data_io_flag : sbi->node_io_flag;
unsigned int fua_flag = flag & temp_mask;
unsigned int meta_flag = (flag >> NR_TEMP_TYPE) & temp_mask;

Thanks,

> - unsigned int fua_flag = sbi->data_io_flag & temp_mask;
> - unsigned int meta_flag = (sbi->data_io_flag >> NR_TEMP_TYPE) &
> - temp_mask;
> +
>   /*
>* data io flag bits per temp:
>*  REQ_META |  REQ_FUA  |
>*5 |4 |   3 |2 |1 |   0 |
>* Cold | Warm | Hot | Cold | Warm | Hot |
>*/
> - if (fio->type != DATA)
> - return;
> + if (fio->type == DATA) {
> + unsigned int fua_flag = sbi->data_io_flag & temp_mask;
> + unsigned int meta_flag = (sbi->data_io_flag >> NR_TEMP_TYPE) &
> + temp_mask;
>  
> - if ((1 << fio->temp) & meta_flag)
> - fio->op_flags |= REQ_META;
> - if ((1 << fio->temp) & fua_flag)
> - fio->op_flags |= REQ_FUA;
> + if ((1 << fio->temp) & meta_flag)
> + fio->op_flags |= REQ_META;
> + if ((1 << fio->temp) & fua_flag)
> + fio->op_flags |= REQ_FUA;
> + }
> + /*
> +  * node io flag bits per temp:
> +  *  REQ_META |  REQ_FUA  |
> +  *5 |4 |   3 |2 |1 |   0 |
> +  * Cold | Warm | Hot | Cold | Warm | Hot |
> +  */
> + if (fio->type == NODE) {
> + unsigned int fua_flag = sbi->node_io_flag & temp_mask;
> + unsigned int meta_flag = (sbi->node_io_flag >> NR_TEMP_TYPE) &
> + temp_mask;
> +
> + if ((1 << fio->temp) & meta_flag)
> + fio->op_flags |= REQ_META;
> + if ((1 << fio->temp) & fua_flag)
> + fio->op_flags |= REQ_FUA;
> + }
>  }
>  
>  static void __submit_merged_bio(struct f2fs_bio_info *io)
> @@ -543,7 +560,7 @@ static void __submit_merged_bio(struct f2fs_bio_info *io)
>   if (!io->bio)
>   return;
>  
> - __attach_data_io_flag(fio);
> + __attach_io_flag(fio);
>   bio_set_op_attrs(io->bio, fio->op, fio->op_flags);
>  
>   if (is_read_io(fio->op))
> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> index fb180020e175c..50e6cdf20b733 100644
> --- a/fs/f2fs/f2fs.h
> +++ b/fs/f2fs/f2fs.h
> @@ -1568,6 +1568,7 @@ struct f2fs_sb_info {
>  
>   /* to attach REQ_META|REQ_FUA flags */
>   unsigned int data_io_flag;
> + unsigned int node_io_flag;
>  
>   /* For sysfs suppport */
>   

Re: 82fef0ad811f "x86/mm: unencrypted non-blocking DMA allocations use coherent pools" was Re: next-0519 on thinkpad x60: sound related? window manager crash

[Alex Xu (Hello71)]

Excerpts from David Rientjes's message of June 7, 2020 8:57 pm:
> Thanks for trying it out, Alex.  Would you mind sending your .config and 
> command line?  I assume either mem_encrypt=on or 
> CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT is enabled.
> 
> Could you also give this a try?
> 
> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
> --- a/kernel/dma/direct.c
> +++ b/kernel/dma/direct.c
> @@ -99,10 +99,11 @@ static inline bool dma_should_alloc_from_pool(struct 
> device *dev, gfp_t gfp,
>  static inline bool dma_should_free_from_pool(struct device *dev,
>unsigned long attrs)
>  {
> - if (IS_ENABLED(CONFIG_DMA_COHERENT_POOL))
> + if (!IS_ENABLED(CONFIG_DMA_COHERENT_POOL))
> + return false;
> + if (force_dma_unencrypted(dev))
>   return true;
> - if ((attrs & DMA_ATTR_NO_KERNEL_MAPPING) &&
> - !force_dma_unencrypted(dev))
> + if (attrs & DMA_ATTR_NO_KERNEL_MAPPING)
>   return false;
>   if (IS_ENABLED(CONFIG_DMA_DIRECT_REMAP))
>   return true;
> 

This patch doesn't work for me either. It has since occurred to me that 
while I do have CONFIG_AMD_MEM_ENCYRPT=y, I have 
CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT=n, because it was broken with 
amdgpu (unfortunately a downgrade from radeon in this respect). Tried it 
again just now and it looks like it's now able to enable KMS, but all it 
displays is serious-looking errors.

Sorry for not mentioning that earlier. I'll send you my .config and 
command line off-list.

Thanks,
Alex.

Re: [PATCH] capabilities: Introduce CAP_RESTORE

[Andrei Vagin]

> >
> > I would argue that setting the current process exe file check should just 
> > be reduced to a "can you ptrace a children" check.
> > Here's why: any process can masquerade into another executable with ptrace.
> > One can fork a child, ptrace it, have the child execve("target_exe"), then 
> > replace its memory content with an arbitrary program.
>
> Then it should probably be relaxed to CAP_SYS_PTRACE in the user
> namespace and not CAP_CHECKPOINT_RESTORE. (But apparently you also have
> a way of achieving what you want anyway. Imho, it's not necessarily
> wrong to require a bit more work when you want something like fully
> unprivileged c/r that's a rather special interest group.)
>
> > With CRIU's libcompel parasite mechanism (https://criu.org/Compel) this is 
> > fairly easy to implement.
> > In fact, we could modify CRIU to do just that (but with a fair amount of 
> > efforts due to the way CRIU is written),
> > and not rely on being able to SET_MM_EXE_FILE via prctl(). In turn, that 
> > would give an easy way to masquerade any process
> > into another one, provided that one can ptrace a child.
> >

I think you misunderstand this. In the case of malicious processes,
when only one or two processes must be hidden, they can use this trick
with execve+ptrace and this is relatively simple. But in the case of
CRIU, where we need to restore a process tree with cow memory
mappings, shared mappings, file descriptors and etc, this trick with
execve+ptrace doesn't work at all. We are in a weird situation when
malicious processes can do some operations, but useful tools like CRIU
needed to be running with extra capabilities that actually reduces the
security of the entire system.

Re: [PATCH resend] fs/namei.c: micro-optimize acl_permission_check

[Al Viro]

On Sun, Jun 07, 2020 at 12:48:53PM -0700, Linus Torvalds wrote:

> Rasmus, say the word and I'll mark you for authorship on the first one.
> 
> Comments? Can you find something else wrong here, or some other fixup to do?
> 
> Al, any reaction?

It's correct, but this

> + if (mask & (mode ^ (mode >> 3))) {
> + if (in_group_p(inode->i_gid))
> + mode >>= 3;
> + }
> +
> + /* Bits in 'mode' clear that we require? */
> + return (mask & ~mode) ? -EACCES : 0;

might be easier to follow if we had, from the very beginning done
unsigned int deny = ~inode->i_mode;
and turned that into

// for group the bits 3..5 apply, for others - 0..2
// we only care which to use when they do not
// agree anyway.
if (mask & (deny ^ (deny >> 3))) // mask & deny != mask & (deny >> 3)
if (in_...
deny >>= 3;
return mask & deny ? -EACCES : 0;

Hell knows...

Re: [PATCH] drm/rcar-du: DRM_RCAR_WRITEBACK depends on DRM

[Laurent Pinchart]

Hi Qian,

Thank you for the patch.

On Sun, Jun 07, 2020 at 09:48:18PM -0400, Qian Cai wrote:
> There is no need to select DRM_RCAR_WRITEBACK if DRM=n which just make
> the generated .config a bit ugly.
> 
>  # ARM devices
>  #
>  # end of ARM devices
> 
>  CONFIG_DRM_RCAR_WRITEBACK=y
> 
>  #
>  # Frame buffer Devices
> 
> Signed-off-by: Qian Cai 
> ---
>  drivers/gpu/drm/rcar-du/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
> index 0919f1f159a4..d80696455d3e 100644
> --- a/drivers/gpu/drm/rcar-du/Kconfig
> +++ b/drivers/gpu/drm/rcar-du/Kconfig
> @@ -48,3 +48,4 @@ config DRM_RCAR_VSP
>  config DRM_RCAR_WRITEBACK
>   bool
>   default y if ARM64
> + depends on DRM

How about depending on DRM_RCAR_DU instead, as DRM_RCAR_WRITEBACK is
used to select compilation of rcar_du_writeback.c that is part of the
rcar-du driver ?

-- 
Regards,

Laurent Pinchart

Re: [PATCH] kbuild: make module name conflict fatal error

[Guenter Roeck]

Hi,

On Mon, May 11, 2020 at 01:21:49PM +0900, Masahiro Yamada wrote:
> I think all the warnings have been fixed by now. Make it a fatal error.
> 

Not entirely. With this patch in the tree, I get:

Building sparc64:allmodconfig ... failed
--
Error log:
error: the following would cause module name conflict:
  drivers/char/adi.ko
  drivers/input/joystick/adi.ko
make[1]: *** [modules_check] Error 1
make[1]: *** Waiting for unfinished jobs
make: *** [__sub-make] Error 2

Reverting this patch fixes the problem.

Guenter

Re: [PATCH] media: vsp1: Fix runtime PM imbalance in vsp1_probe

[Laurent Pinchart]

On Mon, Jun 08, 2020 at 04:54:57AM +0300, Laurent Pinchart wrote:
> Hi Dinghao,
> 
> Thank you for the patch.
> 
> On Sat, May 23, 2020 at 07:54:26PM +0800, Dinghao Liu wrote:
> > pm_runtime_get_sync() increments the runtime PM usage counter even
> > when it returns an error code. Thus a pairing decrement is needed on
> > the error handling path to keep the counter balanced.
> 
> I wonder how many bugs we have today, and how many bugs will keep
> appearing in the future, due to this historical design mistake :-( 
> 
> > Signed-off-by: Dinghao Liu 
> > ---
> >  drivers/media/platform/vsp1/vsp1_drv.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/media/platform/vsp1/vsp1_drv.c 
> > b/drivers/media/platform/vsp1/vsp1_drv.c
> > index c650e45bb0ad..017a54f2fdd8 100644
> > --- a/drivers/media/platform/vsp1/vsp1_drv.c
> > +++ b/drivers/media/platform/vsp1/vsp1_drv.c
> > @@ -846,8 +846,10 @@ static int vsp1_probe(struct platform_device *pdev)
> > pm_runtime_enable(&pdev->dev);
> >  
> > ret = pm_runtime_get_sync(&pdev->dev);
> > -   if (ret < 0)
> > +   if (ret < 0) {
> > +   pm_runtime_put_sync(&pdev->dev);
> > goto done;
> > +   }
> 
> This change looks good to me, but we also need a similar change in the
> vsp1_device_get() function if I'm not mistaken. Could you combine both
> in the same patch ?

And actually, after fixing vsp1_device_get(), we should replace the
pm_runtime_get_sync() call here with vsp1_device_get(), and the
pm_runtime_put_sync() below with vsp1_device_put(), so there would be no
need to call pm_runtime_put_sync() manually in the error path here.

> >  
> > vsp1->version = vsp1_read(vsp1, VI6_IP_VERSION);
> > pm_runtime_put_sync(&pdev->dev);

-- 
Regards,

Laurent Pinchart

Re: [PATCH] media: vsp1: Fix runtime PM imbalance in vsp1_probe

[Laurent Pinchart]

Hi Dinghao,

Thank you for the patch.

On Sat, May 23, 2020 at 07:54:26PM +0800, Dinghao Liu wrote:
> pm_runtime_get_sync() increments the runtime PM usage counter even
> when it returns an error code. Thus a pairing decrement is needed on
> the error handling path to keep the counter balanced.

I wonder how many bugs we have today, and how many bugs will keep
appearing in the future, due to this historical design mistake :-( 

> Signed-off-by: Dinghao Liu 
> ---
>  drivers/media/platform/vsp1/vsp1_drv.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/platform/vsp1/vsp1_drv.c 
> b/drivers/media/platform/vsp1/vsp1_drv.c
> index c650e45bb0ad..017a54f2fdd8 100644
> --- a/drivers/media/platform/vsp1/vsp1_drv.c
> +++ b/drivers/media/platform/vsp1/vsp1_drv.c
> @@ -846,8 +846,10 @@ static int vsp1_probe(struct platform_device *pdev)
>   pm_runtime_enable(&pdev->dev);
>  
>   ret = pm_runtime_get_sync(&pdev->dev);
> - if (ret < 0)
> + if (ret < 0) {
> + pm_runtime_put_sync(&pdev->dev);
>   goto done;
> + }

This change looks good to me, but we also need a similar change in the
vsp1_device_get() function if I'm not mistaken. Could you combine both
in the same patch ?

>  
>   vsp1->version = vsp1_read(vsp1, VI6_IP_VERSION);
>   pm_runtime_put_sync(&pdev->dev);

-- 
Regards,

Laurent Pinchart

Re: [v1 PATCH 1/2] Refactoring carrying over IMA measuremnet logs over Kexec.

[kernel test robot]

Hi Prakhar,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on arm64/for-next/core]
[also build test WARNING on powerpc/next soc/for-next v5.7 next-20200605]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:
https://github.com/0day-ci/linux/commits/Prakhar-Srivastava/Adding-support-to-carry-IMA-measurement-logs/20200608-073805
base:   https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git 
for-next/core
config: arm64-randconfig-r012-20200607 (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project 
e429cffd4f228f70c1d9df0e5d77c08590dd9766)
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 arm64 cross compiling tool for clang build
# apt-get install binutils-aarch64-linux-gnu
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64 

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 <<):

>> arch/arm64/kernel/machine_kexec_file.c:50:5: warning: no previous prototype 
>> for function 'arch_ima_add_kexec_buffer' [-Wmissing-prototypes]
int arch_ima_add_kexec_buffer(struct kimage *image, unsigned long load_addr,
^
arch/arm64/kernel/machine_kexec_file.c:50:1: note: declare 'static' if the 
function is not intended to be used outside of this translation unit
int arch_ima_add_kexec_buffer(struct kimage *image, unsigned long load_addr,
^
static
1 warning generated.

vim +/arch_ima_add_kexec_buffer +50 arch/arm64/kernel/machine_kexec_file.c

41  
42  /**
43   * arch_ima_add_kexec_buffer - do arch-specific steps to add the IMA 
buffer
44   *
45   * Architectures should use this function to pass on the IMA buffer
46   * information to the next kernel.
47   *
48   * Return: 0 on success, negative errno on error.
49   */
  > 50  int arch_ima_add_kexec_buffer(struct kimage *image, unsigned long 
load_addr,
51size_t size)
52  {
53  image->arch.ima_buffer_addr = load_addr;
54  image->arch.ima_buffer_size = size;
55  return 0;
56  }
57  

---
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 1/1] fpga: dfl: Fix dead store

[Wu, Hao]

> -Original Message-
> From: linux-fpga-ow...@vger.kernel.org 
> On Behalf Of t...@redhat.com
> Sent: Sunday, June 7, 2020 5:03 AM
> To: m...@kernel.org
> Cc: linux-f...@vger.kernel.org; linux-kernel@vger.kernel.org; Tom Rix
> 
> Subject: [PATCH 1/1] fpga: dfl: Fix dead store
> 

Thanks for this patch, looks good to me, but this patch is not related to
dfl, so please remove dfl from the title to avoid confusion. : )
or maybe it can be split into two patches:
fpga: mgr: xxx
fpga: bridge: xxx

Thanks
Hao

> From: Tom Rix 
> 
> Using clang's scan-build/view this issue was flagged in fpga-mgr.c
> 
>   drivers/fpga/fpga-mgr.c:585:3: warning: Value stored to 'ret' is never read
> [deadcode.DeadStores]
>   ret = id;
> 
> A similar issue was flagged in fpga-bridge.
> 
> So remove the unused stores.
> 
> Signed-off-by: Tom Rix 
> ---
>  drivers/fpga/fpga-bridge.c | 6 ++
>  drivers/fpga/fpga-mgr.c| 4 +---
>  2 files changed, 3 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/fpga/fpga-bridge.c b/drivers/fpga/fpga-bridge.c
> index 4bab9028940a..2deccacc3aa7 100644
> --- a/drivers/fpga/fpga-bridge.c
> +++ b/drivers/fpga/fpga-bridge.c
> @@ -328,7 +328,7 @@ struct fpga_bridge *fpga_bridge_create(struct device
> *dev, const char *name,
>  void *priv)
>  {
>   struct fpga_bridge *bridge;
> - int id, ret = 0;
> + int id, ret;
> 
>   if (!name || !strlen(name)) {
>   dev_err(dev, "Attempt to register with no name!\n");
> @@ -340,10 +340,8 @@ struct fpga_bridge *fpga_bridge_create(struct
> device *dev, const char *name,
>   return NULL;
> 
>   id = ida_simple_get(&fpga_bridge_ida, 0, 0, GFP_KERNEL);
> - if (id < 0) {
> - ret = id;
> + if (id < 0)
>   goto error_kfree;
> - }
> 
>   mutex_init(&bridge->mutex);
>   INIT_LIST_HEAD(&bridge->node);
> diff --git a/drivers/fpga/fpga-mgr.c b/drivers/fpga/fpga-mgr.c
> index e05104f5e40c..f38bab01432e 100644
> --- a/drivers/fpga/fpga-mgr.c
> +++ b/drivers/fpga/fpga-mgr.c
> @@ -581,10 +581,8 @@ struct fpga_manager *fpga_mgr_create(struct
> device *dev, const char *name,
>   return NULL;
> 
>   id = ida_simple_get(&fpga_mgr_ida, 0, 0, GFP_KERNEL);
> - if (id < 0) {
> - ret = id;
> + if (id < 0)
>   goto error_kfree;
> - }
> 
>   mutex_init(&mgr->ref_mutex);
> 
> --
> 2.26.0

Re: [PATCH v3] fs: ocfs2: fix spelling mistake and grammar

[Joseph Qi]

On 2020/6/8 09:48, Keyur Patel wrote:
> ./ocfs2/mmap.c:65: bebongs ==> belonging
> 
> Signed-off-by: Keyur Patel 

Reviewed-by: Joseph Qi 
> ---
>  fs/ocfs2/mmap.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/ocfs2/mmap.c b/fs/ocfs2/mmap.c
> index 3a44e461828a..39a77e903fdf 100644
> --- a/fs/ocfs2/mmap.c
> +++ b/fs/ocfs2/mmap.c
> @@ -62,7 +62,7 @@ static vm_fault_t __ocfs2_page_mkwrite(struct file *file,
>   last_index = (size - 1) >> PAGE_SHIFT;
>  
>   /*
> -  * There are cases that lead to the page no longer bebongs to the
> +  * There are cases that lead to the page no longer belonging to the
>* mapping.
>* 1) pagecache truncates locally due to memory pressure.
>* 2) pagecache truncates when another is taking EX lock against 
> 

[PATCH] drm/msm/dpu: fix error return code in dpu_encoder_init

[Chen Tao]

Fix to return negative error code -ENOMEM with the use of
ERR_PTR from dpu_encoder_init.

Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Signed-off-by: Chen Tao 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index a1b79ee2bd9d..a2f6b688a976 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -2173,7 +2173,7 @@ struct drm_encoder *dpu_encoder_init(struct drm_device 
*dev,
 
dpu_enc = devm_kzalloc(dev->dev, sizeof(*dpu_enc), GFP_KERNEL);
if (!dpu_enc)
-   return ERR_PTR(ENOMEM);
+   return ERR_PTR(-ENOMEM);
 
rc = drm_encoder_init(dev, &dpu_enc->base, &dpu_encoder_funcs,
drm_enc_mode, NULL);
-- 
2.22.0

RE: [PATCH] [v2] PCI: rcar: Fix runtime PM imbalance on error

[Yoshihiro Shimoda]

Hi Dinghao,

> From: Dinghao Liu, Sent: Sunday, June 7, 2020 6:32 PM
> 
> pm_runtime_get_sync() increments the runtime PM usage counter even
> the call returns an error code. Thus a corresponding decrement is
> needed on the error handling path to keep the counter balanced.
> 
> Signed-off-by: Dinghao Liu 

Thank you for your patch! I think we can add Fixes tag like below.

Fixes: 0df6150e7ceb ("PCI: rcar: Use runtime PM to control controller clock")

And, I reviewed this patch. So,

Reviewed-by: Yoshihiro Shimoda 

Best regards,
Yoshihiro Shimoda

> ---
> 
> Changelog:
> 
> v2: - Remove unnecessary 'err_pm_put' label.
>   Refine commit message.
> ---
>  drivers/pci/controller/pcie-rcar.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/pci/controller/pcie-rcar.c 
> b/drivers/pci/controller/pcie-rcar.c
> index 759c6542c5c8..f9595ab54bc4 100644
> --- a/drivers/pci/controller/pcie-rcar.c
> +++ b/drivers/pci/controller/pcie-rcar.c
> @@ -1143,7 +1143,7 @@ static int rcar_pcie_probe(struct platform_device *pdev)
>   err = rcar_pcie_get_resources(pcie);
>   if (err < 0) {
>   dev_err(dev, "failed to request resources: %d\n", err);
> - goto err_pm_put;
> + goto err_pm_disable;
>   }
> 
>   err = clk_prepare_enable(pcie->bus_clk);
> @@ -1206,10 +1206,8 @@ static int rcar_pcie_probe(struct platform_device 
> *pdev)
>   irq_dispose_mapping(pcie->msi.irq2);
>   irq_dispose_mapping(pcie->msi.irq1);
> 
> -err_pm_put:
> - pm_runtime_put(dev);
> -
>  err_pm_disable:
> + pm_runtime_put(dev);
>   pm_runtime_disable(dev);
>   pci_free_resource_list(&pcie->resources);
> 
> --
> 2.17.1

[PATCH v3] fs: ocfs2: fix spelling mistake and grammar

[Keyur Patel]

./ocfs2/mmap.c:65: bebongs ==> belonging

Signed-off-by: Keyur Patel 
---
 fs/ocfs2/mmap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/ocfs2/mmap.c b/fs/ocfs2/mmap.c
index 3a44e461828a..39a77e903fdf 100644
--- a/fs/ocfs2/mmap.c
+++ b/fs/ocfs2/mmap.c
@@ -62,7 +62,7 @@ static vm_fault_t __ocfs2_page_mkwrite(struct file *file,
last_index = (size - 1) >> PAGE_SHIFT;
 
/*
-* There are cases that lead to the page no longer bebongs to the
+* There are cases that lead to the page no longer belonging to the
 * mapping.
 * 1) pagecache truncates locally due to memory pressure.
 * 2) pagecache truncates when another is taking EX lock against 
-- 
2.26.2