[PATCH v4 3/3] iommu/vt-d: Apply per-device dma_ops

[Lu Baolu]

Current Intel IOMMU driver sets the system level dma_ops. This causes
each dma API to go through the IOMMU driver even the devices are using
identity mapped domains. This sets per-device dma_ops only if a device
is using a DMA domain. Otherwise, use the default system level dma_ops
for direct dma.

Signed-off-by: Lu Baolu 
---
 drivers/iommu/intel-iommu.c | 82 -
 1 file changed, 26 insertions(+), 56 deletions(-)

diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index af309e8fa6f5..29d3940847d3 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -2720,17 +2720,6 @@ static int __init si_domain_init(int hw)
return 0;
 }
 
-static int identity_mapping(struct device *dev)
-{
-   struct device_domain_info *info;
-
-   info = dev->archdata.iommu;
-   if (info)
-   return (info->domain == si_domain);
-
-   return 0;
-}
-
 static int domain_add_dev_info(struct dmar_domain *domain, struct device *dev)
 {
struct dmar_domain *ndomain;
@@ -3315,18 +3304,6 @@ static unsigned long intel_alloc_iova(struct device *dev,
return iova_pfn;
 }
 
-/* Check if the dev needs to go through non-identity map and unmap process.*/
-static bool iommu_need_mapping(struct device *dev)
-{
-   if (iommu_dummy(dev))
-   return false;
-
-   if (unlikely(attach_deferred(dev)))
-   do_deferred_attach(dev);
-
-   return !identity_mapping(dev);
-}
-
 static dma_addr_t __intel_map_single(struct device *dev, phys_addr_t paddr,
 size_t size, int dir, u64 dma_mask)
 {
@@ -3340,6 +3317,9 @@ static dma_addr_t __intel_map_single(struct device *dev, 
phys_addr_t paddr,
 
BUG_ON(dir == DMA_NONE);
 
+   if (unlikely(attach_deferred(dev)))
+   do_deferred_attach(dev);
+
domain = find_domain(dev);
if (!domain)
return DMA_MAPPING_ERROR;
@@ -3391,20 +3371,15 @@ static dma_addr_t intel_map_page(struct device *dev, 
struct page *page,
 enum dma_data_direction dir,
 unsigned long attrs)
 {
-   if (iommu_need_mapping(dev))
-   return __intel_map_single(dev, page_to_phys(page) + offset,
-   size, dir, *dev->dma_mask);
-   return dma_direct_map_page(dev, page, offset, size, dir, attrs);
+   return __intel_map_single(dev, page_to_phys(page) + offset,
+ size, dir, *dev->dma_mask);
 }
 
 static dma_addr_t intel_map_resource(struct device *dev, phys_addr_t phys_addr,
 size_t size, enum dma_data_direction dir,
 unsigned long attrs)
 {
-   if (iommu_need_mapping(dev))
-   return __intel_map_single(dev, phys_addr, size, dir,
-   *dev->dma_mask);
-   return dma_direct_map_resource(dev, phys_addr, size, dir, attrs);
+   return __intel_map_single(dev, phys_addr, size, dir, *dev->dma_mask);
 }
 
 static void intel_unmap(struct device *dev, dma_addr_t dev_addr, size_t size)
@@ -3455,17 +3430,13 @@ static void intel_unmap_page(struct device *dev, 
dma_addr_t dev_addr,
 size_t size, enum dma_data_direction dir,
 unsigned long attrs)
 {
-   if (iommu_need_mapping(dev))
-   intel_unmap(dev, dev_addr, size);
-   else
-   dma_direct_unmap_page(dev, dev_addr, size, dir, attrs);
+   intel_unmap(dev, dev_addr, size);
 }
 
 static void intel_unmap_resource(struct device *dev, dma_addr_t dev_addr,
size_t size, enum dma_data_direction dir, unsigned long attrs)
 {
-   if (iommu_need_mapping(dev))
-   intel_unmap(dev, dev_addr, size);
+   intel_unmap(dev, dev_addr, size);
 }
 
 static void *intel_alloc_coherent(struct device *dev, size_t size,
@@ -3475,8 +3446,8 @@ static void *intel_alloc_coherent(struct device *dev, 
size_t size,
struct page *page = NULL;
int order;
 
-   if (!iommu_need_mapping(dev))
-   return dma_direct_alloc(dev, size, dma_handle, flags, attrs);
+   if (unlikely(attach_deferred(dev)))
+   do_deferred_attach(dev);
 
size = PAGE_ALIGN(size);
order = get_order(size);
@@ -3511,9 +3482,6 @@ static void intel_free_coherent(struct device *dev, 
size_t size, void *vaddr,
int order;
struct page *page = virt_to_page(vaddr);
 
-   if (!iommu_need_mapping(dev))
-   return dma_direct_free(dev, size, vaddr, dma_handle, attrs);
-
size = PAGE_ALIGN(size);
order = get_order(size);
 
@@ -3531,9 +3499,6 @@ static void intel_unmap_sg(struct device *dev, struct 
scatterlist *sglist,
struct scatterlist *sg;
int i;
 
-   if (!iommu_need_mapping(dev))
-   return dma_direct_unmap_sg(dev, sglist, 

[rcu:tglx.2020.05.05a 48/140] arch/um/include/asm/irqflags.h:5: Error: no such instruction: `extern int get_signals(void)'

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git 
tglx.2020.05.05a
head:   e6d36eed49b863bbe393e3c07cae737cd9c475e3
commit: 1af1a839cb2f00c8d7533102ece276ac315ecef2 [48/140] x86/entry/64: Check 
IF in __preempt_enable_notrace() thunk
config: um-x86_64_defconfig (attached as .config)
compiler: gcc-7 (Ubuntu 7.5.0-6ubuntu2) 7.5.0
reproduce:
git checkout 1af1a839cb2f00c8d7533102ece276ac315ecef2
# save the attached .config to linux build tree
make ARCH=um SUBARCH=x86_64

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

All errors (new ones prefixed by >>):

   arch/um/include/asm/irqflags.h: Assembler messages:
>> arch/um/include/asm/irqflags.h:5: Error: no such instruction: `extern int 
>> get_signals(void)'
>> arch/um/include/asm/irqflags.h:6: Error: no such instruction: `extern int 
>> set_signals(int enable)'
>> arch/um/include/asm/irqflags.h:7: Error: no such instruction: `extern void 
>> block_signals(void)'
>> arch/um/include/asm/irqflags.h:8: Error: no such instruction: `extern void 
>> unblock_signals(void)'
>> arch/um/include/asm/irqflags.h:11: Error: no such instruction: `static 
>> inline unsigned long arch_local_save_flags(void)'
>> arch/um/include/asm/irqflags.h:12: Error: no such instruction: `{'
>> arch/um/include/asm/irqflags.h:13: Error: no such instruction: `return 
>> get_signals()'
>> arch/um/include/asm/irqflags.h:14: Error: junk at end of line, first 
>> unrecognized character is `}'
>> arch/um/include/asm/irqflags.h:17: Error: no such instruction: `static 
>> inline void arch_local_irq_restore(unsigned long flags)'
   arch/um/include/asm/irqflags.h:18: Error: no such instruction: `{'
>> arch/um/include/asm/irqflags.h:19: Error: invalid character '(' in mnemonic
   arch/um/include/asm/irqflags.h:20: Error: junk at end of line, first 
unrecognized character is `}'
>> arch/um/include/asm/irqflags.h:23: Error: no such instruction: `static 
>> inline void arch_local_irq_enable(void)'
   arch/um/include/asm/irqflags.h:24: Error: no such instruction: `{'
   arch/um/include/asm/irqflags.h:25: Error: invalid character '(' in mnemonic
   arch/um/include/asm/irqflags.h:26: Error: junk at end of line, first 
unrecognized character is `}'
>> arch/um/include/asm/irqflags.h:29: Error: no such instruction: `static 
>> inline void arch_local_irq_disable(void)'
   arch/um/include/asm/irqflags.h:30: Error: no such instruction: `{'
   arch/um/include/asm/irqflags.h:31: Error: invalid character '(' in mnemonic
   arch/um/include/asm/irqflags.h:32: Error: junk at end of line, first 
unrecognized character is `}'
>> include/asm-generic/irqflags.h:26: Error: no such instruction: `static 
>> inline unsigned long arch_local_irq_save(void)'
>> include/asm-generic/irqflags.h:27: Error: no such instruction: `{'
>> include/asm-generic/irqflags.h:28: Error: no such instruction: `unsigned 
>> long flags'
>> include/asm-generic/irqflags.h:29: Error: junk at end of line, first 
>> unrecognized character is `('
>> include/asm-generic/irqflags.h:30: Error: no such instruction: 
>> `arch_local_irq_restore(0)'
>> include/asm-generic/irqflags.h:31: Error: no such instruction: `return flags'
>> include/asm-generic/irqflags.h:32: Error: junk at end of line, first 
>> unrecognized character is `}'
>> include/asm-generic/irqflags.h:37: Error: no such instruction: `static 
>> inline int arch_irqs_disabled_flags(unsigned long flags)'
   include/asm-generic/irqflags.h:38: Error: no such instruction: `{'
   include/asm-generic/irqflags.h:39: Error: no such instruction: `return 
flags==0'
   include/asm-generic/irqflags.h:40: Error: junk at end of line, first 
unrecognized character is `}'
   include/asm-generic/irqflags.h:61: Error: no such instruction: `static 
inline int arch_irqs_disabled(void)'
   include/asm-generic/irqflags.h:62: Error: no such instruction: `{'
   include/asm-generic/irqflags.h:63: Error: no such instruction: `return 
arch_irqs_disabled_flags(arch_local_save_flags())'
   include/asm-generic/irqflags.h:64: Error: junk at end of line, first 
unrecognized character is `}'

vim +5 arch/um/include/asm/irqflags.h

65e62974a8a615 include/asm-um/irqflags.h  Jeff Dike 2006-06-04   4  
a34978cbd977ab arch/um/include/asm/irqflags.h Al Viro   2011-08-18  @5  
extern int get_signals(void);
a34978cbd977ab arch/um/include/asm/irqflags.h Al Viro   2011-08-18  @6  
extern int set_signals(int enable);
a34978cbd977ab arch/um/include/asm/irqflags.h Al Viro   2011-08-18  @7  
extern void block_signals(void);
a34978cbd977ab arch/um/include/asm/irqflags.h Al Viro   2011-08-18  @8  
extern void unblock_signals(void);
a34978cbd977ab arch/um/include/asm/irqflags.h Al Viro   2011-08-18   9  
3e938957357459 arch/um/include/asm/irqflags.h Daniel Wagner 2016-06-12  10  
#define arch_local_save_flags arch_local_save_flags
a34978cbd977ab arch/um/include/asm/irqflags.h Al Viro   2011-08-18 @11  
static inline 

[PATCH v4 0/3] Replace private domain with per-group default domain

[Lu Baolu]

Some devices are required to use a specific type (identity or dma) of
default domain when they are used with a vendor iommu. When the system
level default domain type is different from it, the vendor iommu driver
has to request a new default domain with either
iommu_request_dma_domain_for_dev() or iommu_request_dm_for_dev() in the
add_dev() callback. Unfortunately, these two helpers only work when the
group hasn't been assigned to any other devices, hence, some vendor iommu
driver has to use a private domain if it fails to request a new default
one.

Joerg proposed an on-going proposal which makes the default domain
framework to support configuring per-group default domain during boot
process.

https://lkml.org/lkml/2020/4/14/616
[This has been applied in iommu/next.]

Hence, there is no need to keep the private domain implementation
in the Intel IOMMU driver. This patch series aims to remove it.

Best regards,
baolu

Change log:
v3->v4:
 - Make the commit message of the first patch more comprehensive.

v2->v3:
 - Port necessary patches on the top of Joerg's new proposal.
   https://lkml.org/lkml/2020/4/14/616
   The per-group default domain proposed previously in this series
   will be deprecated due to a race concern between domain switching
   and device driver probing.

v1->v2:
 - Rename the iommu ops callback to def_domain_type

Lu Baolu (3):
  iommu/vt-d: Allow 32bit devices to uses DMA domain
  iommu/vt-d: Allow PCI sub-hierarchy to use DMA domain
  iommu/vt-d: Apply per-device dma_ops

 drivers/iommu/intel-iommu.c | 396 +++-
 1 file changed, 26 insertions(+), 370 deletions(-)

-- 
2.17.1

Re: [f2fs-dev] [PATCH] f2fs: get parent inode when recovering pino

[Gao Xiang]

On Tue, May 05, 2020 at 06:24:28PM -0700, Eric Biggers wrote:
> On Wed, May 06, 2020 at 08:14:07AM +0800, Gao Xiang wrote:
> > >
> > > Actually, I think this is wrong because the fsync can be done via a file
> > > descriptor that was opened to a now-deleted link to the file.
> > 
> > I'm still confused about this...
> > 
> > I don't know what's wrong with this version from my limited knowledge?
> >  inode itself is locked when fsyncing, so
> > 
> >if the fsync inode->i_nlink == 1, this inode has only one hard link
> >(not deleted yet) and should belong to a single directory; and
> > 
> >the only one parent directory would not go away (not deleted as well)
> >since there are some dirents in it (not empty).
> > 
> > Could kindly explain more so I would learn more about this scenario?
> > Thanks a lot!
> 
> i_nlink == 1 just means that there is one non-deleted link.  There can be 
> links
> that have since been deleted, and file descriptors can still be open to them.

Thanks for your inspiration. You are right, thanks.

Correct my words... I didn't check f2fs code just now, it seems f2fs doesn't
take inode_lock as some other fs like __generic_file_fsync or ubifs_fsync.

And i_sem locks nlink / try_to_fix_pino similarly in some extent. It seems
no race by using d_find_alias here. Thanks again.

Thanks,
Gao Xiang

> 
> > 
> > >
> > > We need to find the dentry whose parent directory is still exists, i.e. 
> > > the
> > > parent directory that is counting towards 'inode->i_nlink == 1'.
> > 
> > directory counting towards 'inode->i_nlink == 1', what's happening?
> 
> The non-deleted link is the one counted in i_nlink.
> 
> > 
> > >
> > > I think d_find_alias() is what we're looking for.
> > 
> > It may be simply dentry->d_parent (stable/positive as you said before, and 
> > it's
> > not empty). why need to d_find_alias()?
> 
> Because we need to get the dentry that hasn't been deleted yet, which isn't
> necessarily the one associated with the file descriptor being fsync()'ed.
> 
> > And what is the original problem? I could not get some clue from the 
> > original
> > patch description (I only saw some extra igrab/iput because of some unknown
> > reasons), it there some backtrace related to the problem?
> 
> The problem is that i_pino gets set incorrectly.  I just noticed this while
> reviewing the code.  It's not hard to reproduce, e.g.:
> 
> #include 
> #include 
> #include 
> 
> int main()
> {
> int fd;
> 
> mkdir("dir1", 0700);
> mkdir("dir2", 0700);
> mknod("dir1/file", S_IFREG|0600, 0);
> link("dir1/file", "dir2/file");
> fd = open("dir2/file", O_WRONLY);
> unlink("dir2/file");
> write(fd, "X", 1);
> fsync(fd);
> }
> 
> Then:
> 
> sync
> echo N | dump.f2fs -i $(stat -c %i dir1/file) /dev/vdb | grep 'i_pino'
> echo "dir1 (correct): $(stat -c %i dir1)"
> echo "dir2 (wrong): $(stat -c %i dir2)"
> 
> i_pino will point to dir2 rather than dir1 as expected.
> 
> - Eric
> 
> 
> ___
> Linux-f2fs-devel mailing list
> linux-f2fs-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

[PATCH v3] scripts: headers_install: Exit with error on config leak

[Siddharth Gupta]

Misuse of CONFIG_* in UAPI headers should result in an error. These config
options can be set in userspace by the user application which includes
these headers to control the APIs and structures being used in a kernel
which supports multiple targets.

Signed-off-by: Siddharth Gupta 
---
 scripts/headers_install.sh | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/scripts/headers_install.sh b/scripts/headers_install.sh
index a07668a..94a8335 100755
--- a/scripts/headers_install.sh
+++ b/scripts/headers_install.sh
@@ -64,7 +64,7 @@ configs=$(sed -e '
d
 ' $OUTFILE)
 
-# The entries in the following list are not warned.
+# The entries in the following list do not result in an error.
 # Please do not add a new entry. This list is only for existing ones.
 # The list will be reduced gradually, and deleted eventually. (hopefully)
 #
@@ -98,18 +98,19 @@ include/uapi/linux/raw.h:CONFIG_MAX_RAW_DEVS
 
 for c in $configs
 do
-   warn=1
+   leak_error=1
 
for ignore in $config_leak_ignores
do
if echo "$INFILE:$c" | grep -q "$ignore$"; then
-   warn=
+   leak_error=
break
fi
done
 
-   if [ "$warn" = 1 ]; then
-   echo "warning: $INFILE: leak $c to user-space" >&2
+   if [ "$leak_error" = 1 ]; then
+   echo "error: $INFILE: leak $c to user-space" >&2
+   exit 1
fi
 done
 
-- 
Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: cgroup pointed by sock is leaked on mode switch

[Yang Yingliang]

+cc lize...@huawei.com

On 2020/5/6 0:06, Tejun Heo wrote:

Hello, Yang.

On Sat, May 02, 2020 at 06:27:21PM +0800, Yang Yingliang wrote:

I find the number nr_dying_descendants is increasing:
linux-dVpNUK:~ # find /sys/fs/cgroup/ -name cgroup.stat -exec grep
'^nr_dying_descendants [^0]'  {} +
/sys/fs/cgroup/unified/cgroup.stat:nr_dying_descendants 80
/sys/fs/cgroup/unified/system.slice/cgroup.stat:nr_dying_descendants 1
/sys/fs/cgroup/unified/system.slice/system-hostos.slice/cgroup.stat:nr_dying_descendants
1
/sys/fs/cgroup/unified/lxc/cgroup.stat:nr_dying_descendants 79
/sys/fs/cgroup/unified/lxc/5f1fdb8c54fa40c3e599613dab6e4815058b76ebada8a27bc1fe80c0d4801764/cgroup.stat:nr_dying_descendants
78
/sys/fs/cgroup/unified/lxc/5f1fdb8c54fa40c3e599613dab6e4815058b76ebada8a27bc1fe80c0d4801764/system.slice/cgroup.stat:nr_dying_descendants
78

Those numbers are nowhere close to causing oom issues. There are some
aspects of page and other cache draining which is being improved but unless
you're seeing numbers multiple orders of magnitude higher, this isn't the
source of your problem.


The situation is as same as the commit bd1060a1d671 ("sock, cgroup: add
sock->sk_cgroup") describes.
"On mode switch, cgroup references which are already being pointed to by
socks may be leaked."

I'm doubtful that you're hitting that issue. Mode switching means memcg
being switched between cgroup1 and cgroup2 hierarchies, which is unlikely to
be what's happening when you're launching docker containers.

The first step would be identifying where memory is going and finding out
whether memcg is actually being switched between cgroup1 and 2 - look at the
hierarchy number in /proc/cgroups, if that's switching between 0 and
someting not zero, it is switching.

Thanks.

Re: [PATCH v2] scripts: headers_install: Exit with error on config leak

[Siddharth Gupta]

On 5/4/2020 12:18 AM, Masahiro Yamada wrote:

On Sun, May 3, 2020 at 12:29 PM Siddharth Gupta  wrote:

Misuse of CONFIG_* in UAPI headers should result in an error as it exposes
configuration of different targets to userspace.


Sorry, I missed to point out this.

This statement is not precious; it does not expose the kernel
configuration at all.

include/generated/autoconf.h is not available from userspace.
So, all the CONFIG options are undefined.

Could you reword the commit somehow?

Sure. I just meant that if a CONFIG_* is present in the UAPI header it 
can be set in a
userspace application that includes the header to manipulate the control 
flow in a

kernel that might support multiple targets.

I'll update the commit text and send out an updated patch.

Thanks,
Siddharth






Signed-off-by: Siddharth Gupta 
---
  scripts/headers_install.sh | 11 ++-
  1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/scripts/headers_install.sh b/scripts/headers_install.sh
index a07668a..94a8335 100755
--- a/scripts/headers_install.sh
+++ b/scripts/headers_install.sh
@@ -64,7 +64,7 @@ configs=$(sed -e '
 d
  ' $OUTFILE)

-# The entries in the following list are not warned.
+# The entries in the following list do not result in an error.
  # Please do not add a new entry. This list is only for existing ones.
  # The list will be reduced gradually, and deleted eventually. (hopefully)
  #
@@ -98,18 +98,19 @@ include/uapi/linux/raw.h:CONFIG_MAX_RAW_DEVS

  for c in $configs
  do
-   warn=1
+   leak_error=1

 for ignore in $config_leak_ignores
 do
 if echo "$INFILE:$c" | grep -q "$ignore$"; then
-   warn=
+   leak_error=
 break
 fi
 done

-   if [ "$warn" = 1 ]; then
-   echo "warning: $INFILE: leak $c to user-space" >&2
+   if [ "$leak_error" = 1 ]; then
+   echo "error: $INFILE: leak $c to user-space" >&2
+   exit 1
 fi
  done

--
Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] selftests/ftrace: mark irqsoff_tracer.tc test as unresolved if the test module does not exist

[Po-Hsu Lin]

On Tue, May 5, 2020 at 9:09 PM Steven Rostedt  wrote:
>
>
> You keep forgetting to Cc Shuah's other email.
Thanks!
I got the recipients list from the get_mainter.pl.

>
> On Tue,  5 May 2020 18:14:45 +0800
> Po-Hsu Lin  wrote:
>
> > The UNRESOLVED state is much more apporiate than the UNSUPPORTED state
> > for the absence of the test module, as it matches "test was set up
> > incorrectly" situation in the README file.
> >
> > A possible scenario is that the function was enabled (supported by the
> > kernel) but the module was not installed properly, in this case we
> > cannot call this as UNSUPPORTED.
> >
> > This change also make it consistent with other module-related tests
> > in ftrace.
>
> Acked-by: Steven Rostedt (VMware) 
>
> Shuah,
>
> Can you take this after Masami gives his ack (if he does that is).
>
> Thanks,
>
> -- Steve
>
> >
> > Signed-off-by: Po-Hsu Lin 
> > ---
> >  .../testing/selftests/ftrace/test.d/preemptirq/irqsoff_tracer.tc | 9 
> > -
> >  1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git 
> > a/tools/testing/selftests/ftrace/test.d/preemptirq/irqsoff_tracer.tc 
> > b/tools/testing/selftests/ftrace/test.d/preemptirq/irqsoff_tracer.tc
> > index cbd1743..2b82c80e 100644
> > --- a/tools/testing/selftests/ftrace/test.d/preemptirq/irqsoff_tracer.tc
> > +++ b/tools/testing/selftests/ftrace/test.d/preemptirq/irqsoff_tracer.tc
> > @@ -17,7 +17,14 @@ unsup() { #msg
> >  exit_unsupported
> >  }
> >
> > -modprobe $MOD || unsup "$MOD module not available"
> > +unres() { #msg
> > +reset_tracer
> > +rmmod $MOD || true
> > +echo $1
> > +exit_unresolved
> > +}
> > +
> > +modprobe $MOD || unres "$MOD module not available"
> >  rmmod $MOD
> >
> >  grep -q "preemptoff" available_tracers || unsup "preemptoff tracer not 
> > enabled"
>

[PATCH] spi: sun6i: Add support for GPIO chip select lines

[Alistair Francis]

Add a setup function that can be used to support using generic GPIO
lines for the chip select.

Signed-off-by: Alistair Francis 
---
 drivers/spi/spi-sun6i.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/drivers/spi/spi-sun6i.c b/drivers/spi/spi-sun6i.c
index ec7967be9e2f..fd4e19434942 100644
--- a/drivers/spi/spi-sun6i.c
+++ b/drivers/spi/spi-sun6i.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -171,6 +172,31 @@ static inline void sun6i_spi_fill_fifo(struct sun6i_spi 
*sspi, int len)
}
 }
 
+static int sun6i_spi_setup(struct spi_device *spi)
+{
+   int ret;
+
+   /* sanity check for native cs */
+   if (spi->mode & SPI_NO_CS)
+   return 0;
+   if (gpio_is_valid(spi->cs_gpio)) {
+   /* with gpio-cs set the GPIO to the correct level
+* and as output (in case the dt has the gpio not configured
+* as output but native cs)
+*/
+   ret = gpio_direction_output(spi->cs_gpio,
+   (spi->mode & SPI_CS_HIGH) ? 0 : 1);
+   if (ret)
+   dev_err(>dev,
+   "could not set gpio %i as output: %i\n",
+   spi->cs_gpio, ret);
+
+   return ret;
+   }
+
+   return 0;
+}
+
 static void sun6i_spi_set_cs(struct spi_device *spi, bool enable)
 {
struct sun6i_spi *sspi = spi_master_get_devdata(spi->master);
@@ -470,6 +496,7 @@ static int sun6i_spi_probe(struct platform_device *pdev)
 
master->max_speed_hz = 100 * 1000 * 1000;
master->min_speed_hz = 3 * 1000;
+   master->setup = sun6i_spi_setup;
master->set_cs = sun6i_spi_set_cs;
master->transfer_one = sun6i_spi_transfer_one;
master->num_chipselect = 4;
-- 
2.26.2

Re: INFO: task hung in linkwatch_event (2)

[Yunsheng Lin]

On 2020/4/29 17:59, syzbot wrote:
> Hello,
> 
> syzbot found the following crash on:
> 
> HEAD commit:b4f63322 Merge branch 'for-linus' of git://git.kernel.org/..
> git tree:   upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1558936fe0
> kernel config:  https://syzkaller.appspot.com/x/.config?x=b7a70e992f2f9b68
> dashboard link: https://syzkaller.appspot.com/bug?extid=96ff6cfc4551fcc29342
> compiler:   gcc (GCC) 9.0.0 20181231 (experimental)
> syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=14a5782810
> 
> The bug was bisected to:
> 
> commit 386d4716fd91869e07c731657f2cde5a33086516
> Author: Luo bin 
> Date:   Thu Feb 27 06:34:44 2020 +
> 
> hinic: fix a bug of rss configuration

The above patch does not seem to be the cause of the crash.

>From the below call trace, it seems the blocking is caused by
the tun_detach() which need to flush the all the pending work
for each online cpu, it is the linkwatch_work that need to be
flushed in this crash case. But the linkwatch_work() need to take
RTNL lock, which is already taken by the tun_detach(), and that is
where the blocking is happening.

Possible way to fix or avoid this:
1. Call flush_all_backlogs() without holding the RTNL lock, I am not
   sure it is safe to do this.
2. Disabling adding link event to the unregisterring netdev, and flush
   all the pending link event without taking RTNL lock before calling
   unregister_netdevice() in tun_detach().

Any better suggestion? Thanks.

> 
> bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=16626fcfe0
> final crash:https://syzkaller.appspot.com/x/report.txt?x=15626fcfe0
> console output: https://syzkaller.appspot.com/x/log.txt?x=11626fcfe0
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+96ff6cfc4551fcc29...@syzkaller.appspotmail.com
> Fixes: 386d4716fd91 ("hinic: fix a bug of rss configuration")
> 
> INFO: task kworker/1:5:2724 blocked for more than 143 seconds.
>   Not tainted 5.7.0-rc2-syzkaller #0
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> kworker/1:5 D27416  2724  2 0x80004000
> Workqueue: events linkwatch_event
> Call Trace:
>  schedule+0xd0/0x2a0 kernel/sched/core.c:4163
>  schedule_preempt_disabled+0xf/0x20 kernel/sched/core.c:4222
>  __mutex_lock_common kernel/locking/mutex.c:1033 [inline]
>  __mutex_lock+0x7ab/0x13c0 kernel/locking/mutex.c:1103
>  linkwatch_event+0xb/0x60 net/core/link_watch.c:242
>  process_one_work+0x965/0x16a0 kernel/workqueue.c:2268
>  worker_thread+0x96/0xe20 kernel/workqueue.c:2414
>  kthread+0x388/0x470 kernel/kthread.c:268
>  ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
> INFO: task syz-executor.0:7053 blocked for more than 143 seconds.
>   Not tainted 5.7.0-rc2-syzkaller #0
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> syz-executor.0  D23512  7053  1 0x80004006
> Call Trace:
>  schedule+0xd0/0x2a0 kernel/sched/core.c:4163
>  schedule_timeout+0x55b/0x850 kernel/time/timer.c:1874
>  do_wait_for_common kernel/sched/completion.c:85 [inline]
>  __wait_for_common kernel/sched/completion.c:106 [inline]
>  wait_for_common kernel/sched/completion.c:117 [inline]
>  wait_for_completion+0x16a/0x270 kernel/sched/completion.c:138
>  __flush_work+0x4fd/0xa80 kernel/workqueue.c:3045
>  flush_all_backlogs net/core/dev.c:5527 [inline]
>  rollback_registered_many+0x562/0xe70 net/core/dev.c:8813
>  rollback_registered+0xf2/0x1c0 net/core/dev.c:8873
>  unregister_netdevice_queue net/core/dev.c:9969 [inline]
>  unregister_netdevice_queue+0x1d7/0x2b0 net/core/dev.c:9962
>  unregister_netdevice include/linux/netdevice.h:2725 [inline]
>  __tun_detach+0xe42/0x1110 drivers/net/tun.c:690
>  tun_detach drivers/net/tun.c:707 [inline]
>  tun_chr_close+0xd9/0x180 drivers/net/tun.c:3413
>  __fput+0x33e/0x880 fs/file_table.c:280
>  task_work_run+0xf4/0x1b0 kernel/task_work.c:123
>  exit_task_work include/linux/task_work.h:22 [inline]
>  do_exit+0xb34/0x2dd0 kernel/exit.c:795
>  do_group_exit+0x125/0x340 kernel/exit.c:893
>  get_signal+0x47b/0x24e0 kernel/signal.c:2739
>  do_signal+0x81/0x2240 arch/x86/kernel/signal.c:784
>  exit_to_usermode_loop+0x26c/0x360 arch/x86/entry/common.c:161
>  prepare_exit_to_usermode arch/x86/entry/common.c:196 [inline]
>  syscall_return_slowpath arch/x86/entry/common.c:279 [inline]
>  do_syscall_64+0x6b1/0x7d0 arch/x86/entry/common.c:305
>  entry_SYSCALL_64_after_hwframe+0x49/0xb3
> RIP: 0033:0x4166ca
> Code: Bad RIP value.
> RSP: 002b:7ffd4022d478 EFLAGS: 0246 ORIG_RAX: 003d
> RAX: fe00 RBX: 01d60940 RCX: 004166ca
> RDX: 4000 RSI: 7ffd4022d4b0 RDI: 
> RBP: 2996 R08: 0001 R09: 0001
> R10:  R11: 0246 R12: 0003
> R13: 7ffd4022d4b0 R14: 01d6099b R15: 7ffd4022d4c0
> 
> Showing all 

RE: [PATCH] ASoC: Intel: sst: ipc command timeout

[Lu, Brent]

> 
> Hi,
> 
> That's why I would suggest trying with readq, it should also generate one
> instruction read x86_64 platforms, I looked a bit more and there is fallback 
> to
> generate two 32 bit reads on 32bit platforms, so my previous concern about
> having to write separate handling for those platforms was unneeded. So I
> would recommend checking using it.
Hi,

The readq/writeq works. Code is optimized unlike memcpy_fromio/memcpy_toio
and the defect is not able to reproduce.

(gdb) disas sst_shim32_read64
Dump of assembler code for function sst_shim32_read64:
   0x096c <+0>: call   0x971 
   0x0971 <+5>: push   rbp
   0x0972 <+6>: movrbp,rsp
   0x0975 <+9>: moveax,esi
   0x0977 <+11>:movrax,QWORD PTR [rdi+rax*1]
   0x097b <+15>:poprbp
   0x097c <+16>:ret
End of assembler dump.
(gdb) disas sst_shim32_write64
Dump of assembler code for function sst_shim32_write64:
   0x095b <+0>: call   0x960 
   0x0960 <+5>: push   rbp
   0x0961 <+6>: movrbp,rsp
   0x0964 <+9>: moveax,esi
   0x0966 <+11>:movQWORD PTR [rdi+rax*1],rdx
   0x096a <+15>:poprbp
   0x096b <+16>:ret
End of assembler dump.


Regards,
Brent

> 
> diff --git a/sound/soc/intel/common/sst-dsp.c
> b/sound/soc/intel/common/sst-dsp.c
> index ec66be269b69..e96f636387d9 100644
> --- a/sound/soc/intel/common/sst-dsp.c
> +++ b/sound/soc/intel/common/sst-dsp.c
> @@ -34,16 +34,13 @@ EXPORT_SYMBOL_GPL(sst_shim32_read);
> 
>   void sst_shim32_write64(void __iomem *addr, u32 offset, u64 value)
>   {
> -   memcpy_toio(addr + offset, , sizeof(value));
> +   writeq(value, addr + offset);
>   }
>   EXPORT_SYMBOL_GPL(sst_shim32_write64);
> 
>   u64 sst_shim32_read64(void __iomem *addr, u32 offset)
>   {
> -   u64 val;
> -
> -   memcpy_fromio(, addr + offset, sizeof(val));
> -   return val;
> +   return readq(addr + offset);
>   }
>   EXPORT_SYMBOL_GPL(sst_shim32_read64);
> 
> 
> Thanks,
> Amadeusz

Re: [PATCH v4 1/2] powerpc/uaccess: Implement unsafe_put_user() using 'asm goto'

[Michael Ellerman]

Segher Boessenkool  writes:
> On Tue, May 05, 2020 at 05:40:21PM +0200, Christophe Leroy wrote:
>> >>+#define __put_user_asm_goto(x, addr, label, op)   \
>> >>+  asm volatile goto(  \
>> >>+  "1: " op "%U1%X1 %0,%1  # put_user\n"   \
>> >>+  EX_TABLE(1b, %l2)   \
>> >>+  :   \
>> >>+  : "r" (x), "m<>" (*addr)\
>> >
>> >The "m<>" here is breaking GCC 4.6.3, which we allegedly still support.
>> >
>> >Plain "m" works, how much does the "<>" affect code gen in practice?
>> >
>> >A quick diff here shows no difference from removing "<>".
>> 
>> It was recommended by Segher, there has been some discussion about it on 
>> v1 of this patch, see 
>> https://patchwork.ozlabs.org/project/linuxppc-dev/patch/4fdc2aba6f5e51887d1cd0fee94be0989eada2cd.1586942312.git.christophe.le...@c-s.fr/
>> 
>> As far as I understood that's mandatory on recent gcc to get the 
>> pre-update form of the instruction. With older versions "m" was doing 
>> the same, but not anymore.
>
> Yes.  How much that matters depends on the asm.  On older CPUs (6xx/7xx,
> say) the update form was just as fast as the non-update form.  On newer
> or bigger CPUs it is usually executed just the same as an add followed
> by the memory access, so it just saves a bit of code size.

The update-forms are stdux, sthux etc. right?

I don't see any change in the number of those with or without the
constraint. That's using GCC 9.3.0.

>> Should we ifdef the "m<>" or "m" based on GCC 
>> version ?
>
> That will be a lot of churn.  Just make 4.8 minimum?

As I said in my other mail that's not really up to us. We could mandate
a higher minimum for powerpc, but I'd rather not.

I think for now I'm inclined to just drop the "<>", and we can revisit
in a release or two when hopefully GCC 4.8 has become the minimum.

cheers

Re: [PATCH 2/4] mm/swap: use SECTORS_PER_PAGE_SHIFT to clean up code

[Leizhen (ThunderTown)]

On 2020/5/6 1:25, Matthew Wilcox wrote:
> On Tue, May 05, 2020 at 07:55:41PM +0800, Zhen Lei wrote:
>> +++ b/mm/swapfile.c
>> @@ -177,8 +177,8 @@ static int discard_swap(struct swap_info_struct *si)
>>  
>>  /* Do not discard the swap header page! */
>>  se = first_se(si);
>> -start_block = (se->start_block + 1) << (PAGE_SHIFT - 9);
>> -nr_blocks = ((sector_t)se->nr_pages - 1) << (PAGE_SHIFT - 9);
>> +start_block = (se->start_block + 1) << SECTORS_PER_PAGE_SHIFT;
>> +nr_blocks = ((sector_t)se->nr_pages - 1) << SECTORS_PER_PAGE_SHIFT;
> 
> Thinking about this some more, wouldn't this look better?
> 
>   start_block = page_sectors(se->start_block + 1);
>   nr_block = page_sectors(se->nr_pages - 1);
> 

OK，That's fine, it's clearer. And in this way, there won't be more than 80 
columns.

> 
> .
> 

Re: [PATCH 1/1] selftests/bpf: add cls_redirect classifier

[Alexei Starovoitov]

On Tue, May 5, 2020 at 6:37 AM Daniel Borkmann  wrote:
>
> On 5/5/20 1:48 AM, Alexei Starovoitov wrote:
> > On Sat, May 02, 2020 at 01:48:51AM +0200, Daniel Borkmann wrote:
> >> On 4/27/20 11:45 AM, Lorenz Bauer wrote:
> >>> On Sun, 26 Apr 2020 at 18:33, Alexei Starovoitov
> >>>  wrote:
> >> [...]
> > +/* Linux packet pointers are either aligned to NET_IP_ALIGN (aka 2 
> > bytes),
> > + * or not aligned if the arch supports efficient unaligned access.
> > + *
> > + * Since the verifier ensures that eBPF packet accesses follow these 
> > rules,
> > + * we can tell LLVM to emit code as if we always had a larger 
> > alignment.
> > + * It will yell at us if we end up on a platform where this is not 
> > valid.
> > + */
> > +typedef uint8_t *net_ptr __attribute__((align_value(8)));
> 
>  Wow. I didn't know about this attribute.
>  I wonder whether it can help Daniel's memcpy hack.
> >>>
> >>> Yes, I think so.
> >>
> >> Just for some more context [0]. I think the problem is a bit more complex 
> >> in
> >> general. Generally, _any_ kind of pointer to some data (except for the 
> >> stack)
> >> is currently treated as byte-by-byte copy from __builtin_memcpy() and other
> >> similarly available __builtin_*() helpers on BPF backend since the backend
> >> cannot make any assumptions about the data's alignment and whether 
> >> unaligned
> >> access from the underlying arch is ok & efficient (the latter the verifier
> >> does judge for us however). So it's definitely not just limited to 
> >> xdp->data.
> >> There is also the issue that while access to any non-stack data can be
> >> unaligned, access to the stack however cannot. I've discussed a while back
> >> with Yonghong about potential solutions. One would be to add a small patch
> >> to the BPF backend to enable __builtin_*() helpers to allow for unaligned
> >> access which could then be opt-ed in e.g. via -mattr from llc for the case
> >> when we know that the compiled program only runs on archs with efficient
> >> unaligned access anyway. However, this still potentially breaks with the 
> >> BPF
> >> stack for the case when objects are, for example, larger than size 8 but 
> >> with
> >> a natural alignment smaller than 8 where __builtin_memcpy() would then 
> >> decide
> >> to emit dw-typed load/stores. But for these cases could then be annotated 
> >> via
> >> __aligned(8) on stack. So this is basically what we do right now as a 
> >> generic
> >> workaround in Cilium [0], meaning, our own memcpy/memset with optimal 
> >> number
> >> of instructions and __aligned(8) where needed; most of the time this 
> >> __aligned(8)
> >> is not needed, so it's really just a few places, and we also have a cocci
> >> scripts to catch these during development if needed. Anyway, real thing 
> >> would
> >> be to allow the BPF stack for unaligned access as well and then BPF backend
> >> could nicely solve this in a native way w/o any workarounds, but that is 
> >> tbd.
> >>
> >> Thanks,
> >> Daniel
> >>
> >>[0] 
> >> https://github.com/cilium/cilium/blob/master/bpf/include/bpf/builtins.h
> >
> > Daniel,
> > do you mind adding such memcpy to libbpf ?
>
> We could do that, yeah. Is there a way from BPF C code when compiling with 
> clang to
> get to the actual underlying architecture (x86-64, arm64, ppc, etc) when 
> compiling
> with `-target bpf` so that we can always fall back to __builtin_*() for those 
> where
> verifier would bail out on unaligned access? Keep in mind the __bpf_memcpy() 
> and
> __bpf_memzero() from [0] are fully compile time resolved and I did the 
> implementation
> for sizes of 1,2,4,..., 96 where the latter is in two' increments, so no odd 
> buffer
> sizes as we don't need them in our code. If someone does hit such an odd 
> case, then
> I'm currently throwing a compilation error via __throw_build_bug(). Latter is 
> a nice
> way to be able to guarantee that a switch/case or if condition is never hit 
> during
> compilation time. It resolves to __builtin_trap() which is not implemented in 
> the
> BPF backend and therefore yells to the developer when built into the code 
> (this has
> a nice property which wouldn't work with BUILD_BUG_ON() for example). Anyway, 
> what
> I'm saying is that either we'd need the full thing with all sizes or document 
> that
> unsupported size would be hit when __builtin_trap() assertion is seen.

I think it would be fine to simply document it.
Most structures have at least one 'int' and don't have 'packed',
so they are multiple of 4 typically. Multiple of 2 limitation should be
acceptable for most cases.

Re: [PATCH v3] mm: Add kvfree_sensitive() for freeing sensitive data objects

[Waiman Long]

On 5/5/20 4:35 PM, Andrew Morton wrote:

On Tue, 07 Apr 2020 21:21:57 +0100 David Howells  wrote:


David Howells  wrote:


if (unlikely(key_data))
-   __kvzfree(key_data, key_data_len);
+   kvfree_sensitive(key_data, key_data_len);

I think the if-statement is redundant.

Ah - I see that you explicitly wanted to keep it.

Why's that?


There is a comment above it:

                /*
 * The key may change (unlikely) in between 2 consecutive
 * __keyctl_read_key() calls. In this case, we reallocate
 * a larger buffer and redo the key read when
 * key_data_len < ret <= buflen.
 */
    if (ret > key_data_len) {
    if (unlikely(key_data))
    __kvzfree(key_data, key_data_len);

key_data will be defined only if the unlikely case that the key increase 
in length between the 2 consecutive __keyctl_read_key() call and we have 
to enlarge the buffer and read the key again. I want to keep the 
unlikely() macro to emphasize the fact that this condition should not 
happen.



There's a good chance it'll get janitored at some point.

Indeed.  Perhaps add a few little comments to explain the reasoning and
to keep the janitorial fingers away?

I can reword the comment to make it more explicit and send a v4 if you 
think the current comment is not clear enough.


Cheers,
Longman

Re: [PATCH v3 11/14] remoteproc: Deal with synchronisation when changing FW image

[Bjorn Andersson]

On Fri 24 Apr 13:01 PDT 2020, Mathieu Poirier wrote:

> This patch prevents the firmware image from being displayed or changed
> when the remoteproc core is synchronising with a remote processor. This
> is needed since there is no guarantee about the nature of the firmware
> image that is loaded by the external entity.
> 
> Signed-off-by: Mathieu Poirier 
> ---
>  drivers/remoteproc/remoteproc_sysfs.c | 24 +++-
>  1 file changed, 23 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/remoteproc/remoteproc_sysfs.c 
> b/drivers/remoteproc/remoteproc_sysfs.c
> index 7f8536b73295..cdd322a6ecfa 100644
> --- a/drivers/remoteproc/remoteproc_sysfs.c
> +++ b/drivers/remoteproc/remoteproc_sysfs.c
> @@ -13,9 +13,20 @@
>  static ssize_t firmware_show(struct device *dev, struct device_attribute 
> *attr,
> char *buf)
>  {
> + ssize_t ret;
>   struct rproc *rproc = to_rproc(dev);
>  
> - return sprintf(buf, "%s\n", rproc->firmware);
> + /*
> +  * In most instances there is no guarantee about the firmware
> +  * that was loaded by the external entity.  As such simply don't
> +  * print anything.

Not only "in most instances", we have no idea what firmware is running,
so this can be shortened.

However, this does implicate that on_init = true, after_crash = false,
this will read blank, but a future rproc_report_crash() will indeed load
and boot rproc->firmware.

> +  */
> + if (rproc_needs_syncing(rproc))
> + ret = sprintf(buf, "\n");
> + else
> + ret = sprintf(buf, "%s\n", rproc->firmware);
> +
> + return ret;
>  }
>  
>  /* Change firmware name via sysfs */
> @@ -39,6 +50,17 @@ static ssize_t firmware_store(struct device *dev,
>   goto out;
>   }
>  
> + /*
> +  * There is no point in trying to change the firmware if loading the
> +  * image of the remote processor is done by another entity.
> +  */
> + if (rproc_needs_syncing(rproc)) {
> + dev_err(dev,
> + "can't change firmware while synchronising with MCU\n");

The conditional checks for a future event, but the error message
indicates an ongoing event. How about "can't change firmware on remote
controlled remote processor"? "externally controlled"?

Regards,
Bjorn

> + err = -EBUSY;
> + goto out;
> + }
> +
>   len = strcspn(buf, "\n");
>   if (!len) {
>   dev_err(dev, "can't provide a NULL firmware\n");
> -- 
> 2.20.1
> 

Re: [f2fs-dev] [PATCH] f2fs: get parent inode when recovering pino

[Eric Biggers]

On Wed, May 06, 2020 at 08:14:07AM +0800, Gao Xiang wrote:
> >
> > Actually, I think this is wrong because the fsync can be done via a file
> > descriptor that was opened to a now-deleted link to the file.
> 
> I'm still confused about this...
> 
> I don't know what's wrong with this version from my limited knowledge?
>  inode itself is locked when fsyncing, so
> 
>if the fsync inode->i_nlink == 1, this inode has only one hard link
>(not deleted yet) and should belong to a single directory; and
> 
>the only one parent directory would not go away (not deleted as well)
>since there are some dirents in it (not empty).
> 
> Could kindly explain more so I would learn more about this scenario?
> Thanks a lot!

i_nlink == 1 just means that there is one non-deleted link.  There can be links
that have since been deleted, and file descriptors can still be open to them.

> 
> >
> > We need to find the dentry whose parent directory is still exists, i.e. the
> > parent directory that is counting towards 'inode->i_nlink == 1'.
> 
> directory counting towards 'inode->i_nlink == 1', what's happening?

The non-deleted link is the one counted in i_nlink.

> 
> >
> > I think d_find_alias() is what we're looking for.
> 
> It may be simply dentry->d_parent (stable/positive as you said before, and 
> it's
> not empty). why need to d_find_alias()?

Because we need to get the dentry that hasn't been deleted yet, which isn't
necessarily the one associated with the file descriptor being fsync()'ed.

> And what is the original problem? I could not get some clue from the original
> patch description (I only saw some extra igrab/iput because of some unknown
> reasons), it there some backtrace related to the problem?

The problem is that i_pino gets set incorrectly.  I just noticed this while
reviewing the code.  It's not hard to reproduce, e.g.:

#include 
#include 
#include 

int main()
{
int fd;

mkdir("dir1", 0700);
mkdir("dir2", 0700);
mknod("dir1/file", S_IFREG|0600, 0);
link("dir1/file", "dir2/file");
fd = open("dir2/file", O_WRONLY);
unlink("dir2/file");
write(fd, "X", 1);
fsync(fd);
}

Then:

sync
echo N | dump.f2fs -i $(stat -c %i dir1/file) /dev/vdb | grep 'i_pino'
echo "dir1 (correct): $(stat -c %i dir1)"
echo "dir2 (wrong): $(stat -c %i dir2)"

i_pino will point to dir2 rather than dir1 as expected.

- Eric

Re: [RFC v1 0/6] block: add error handling for *add_disk*()

[Bart Van Assche]

On 2020-04-29 00:48, Luis Chamberlain wrote:
> While working on some blktrace races I noticed that we don't do
> error handling on *add_disk*() and friends. This is my initial
> work on that.
> 
> This is based on linux-next tag next-20200428, you can also get this
> on my branch 20200428-block-fixes [0].
> 
> Let me know what you think.
Hi Luis,

Thank you for having done this work. Since triggering error paths can be
challenging, how about adding fault injection capabilities that make it
possible to trigger all modified error paths and how about adding
blktests that trigger these paths? That is the strategy that I followed
myself recently to fix an error path in blk_mq_realloc_hw_ctxs().

Thanks,

Bart.

Re: [PATCH] securityfs: Add missing d_delete() call on removal

[Al Viro]

On Tue, May 05, 2020 at 04:40:35PM -0700, Kees Cook wrote:
> After using simple_unlink(), a call to d_delete() is needed in addition
> to dput().
> 
> Signed-off-by: Kees Cook 
> ---
> Is this correct? I went looking around and there are a lot of variations
> on the simple_unlink() pattern...
> 
> Many using explicit locking and combinations of d_drop(), __d_drop(), etc.

Quite a few of those should switch to simple_recursive_removal().  As for
securityfs...  d_drop() is _probably_ a saner variant, but looking at the
callers of that thing... at least IMA ones seem to be garbage.

They _might_ work since nobody else is around that early to screw them over,
but... I'm not too optimistic about that.  And the lack of d_delete()/d_drop()
here is the least of the problems, really - look at e.g. the bulk of those
suckers in ima_fs_init().  And check the callchain - it'll lead you to this
if (error && strcmp(hash_algo_name[ima_hash_algo],
CONFIG_IMA_DEFAULT_HASH) != 0) {
pr_info("Allocating %s failed, going to use default hash 
algorithm %s\n",
hash_algo_name[ima_hash_algo], CONFIG_IMA_DEFAULT_HASH);
hash_setup_done = 0;
hash_setup(CONFIG_IMA_DEFAULT_HASH);
error = ima_init();
}

error = register_blocking_lsm_notifier(_lsm_policy_notifier);

And the other IMA caller (in ima_release_policy()) is... misguided, to put it
politely.  This kind of "unlink on final close" makes no sense - if nothing
else, it can be looked up until that very point.  Moreover, this
inode->i_mode &= ~S_IWUSR;
is obviously racy wrt permission(), and there's no damn reason to do it there.
These checks belong in ->open() and they shouldn't rely upon the damn thing
disappearing from directory or permission() failing, etc..

And looking at their ->open()... ouch.  ->f_flags & O_ACCMODE is almost
never the right thing to check.  It should be looking at ->f_mode &
FMODE_{READ,WRITE}.

I hadn't looked into details for EVM, but at the first glance it's similar
to IMA failure handling.  And probably relies upon nobody being able to
open that stuff while the things are being set up.  There seems to be
something in TPM as well - and by the look of it they are trying to work
around the use of unsuitable primitive, and none too well, at that.
I mean,
int err;
struct seq_file *seq;
struct tpm_chip_seqops *chip_seqops;
const struct seq_operations *seqops;
struct tpm_chip *chip;

inode_lock(inode);
if (!inode->i_private) {
inode_unlock(inode);
return -ENODEV;
}
chip_seqops = (struct tpm_chip_seqops *)inode->i_private;
seqops = chip_seqops->seqops;
chip = chip_seqops->chip;
get_device(>dev);
inode_unlock(inode);

/* now register seq file */
err = seq_open(file, seqops);
if (!err) {
seq = file->private_data;
seq->private = chip;
}

return err;
doesn't look sane - late error would appear to leak >dev...

Re: [PATCH] KVM: x86: fix DR6 delivery for emulated hardware breakpoint

[kbuild test robot]

Hi Paolo,

I love your patch! Yet something to improve:

[auto build test ERROR on kvm/linux-next]
[also build test ERROR on tip/auto-latest linus/master v5.7-rc4 next-20200505]
[cannot apply to linux/master]
[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/Paolo-Bonzini/KVM-x86-fix-DR6-delivery-for-emulated-hardware-breakpoint/20200506-043817
base:   https://git.kernel.org/pub/scm/virt/kvm/kvm.git linux-next
config: i386-allyesconfig (attached as .config)
compiler: gcc-7 (Ubuntu 7.5.0-6ubuntu2) 7.5.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

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

All error/warnings (new ones prefixed by >>):

   arch/x86/kvm/x86.c: In function 'kvm_deliver_exception_payload':
>> arch/x86/kvm/x86.c:472:3: error: implicit declaration of function 
>> 'kvm_update_dr6'; did you mean 'kvm_update_cpuid'? 
>> [-Werror=implicit-function-declaration]
  kvm_update_dr6(vcpu);
  ^~
  kvm_update_cpuid
   arch/x86/kvm/x86.c: At top level:
>> arch/x86/kvm/x86.c:1071:13: warning: conflicting types for 'kvm_update_dr6'
static void kvm_update_dr6(struct kvm_vcpu *vcpu)
^~
>> arch/x86/kvm/x86.c:1071:13: error: static declaration of 'kvm_update_dr6' 
>> follows non-static declaration
   arch/x86/kvm/x86.c:472:3: note: previous implicit declaration of 
'kvm_update_dr6' was here
  kvm_update_dr6(vcpu);
  ^~
   cc1: some warnings being treated as errors

vim +472 arch/x86/kvm/x86.c

   432  
   433  void kvm_deliver_exception_payload(struct kvm_vcpu *vcpu)
   434  {
   435  unsigned nr = vcpu->arch.exception.nr;
   436  bool has_payload = vcpu->arch.exception.has_payload;
   437  unsigned long payload = vcpu->arch.exception.payload;
   438  
   439  if (!has_payload)
   440  return;
   441  
   442  switch (nr) {
   443  case DB_VECTOR:
   444  /*
   445   * "Certain debug exceptions may clear bit 0-3.  The
   446   * remaining contents of the DR6 register are never
   447   * cleared by the processor".
   448   */
   449  vcpu->arch.dr6 &= ~DR_TRAP_BITS;
   450  /*
   451   * DR6.RTM is set by all #DB exceptions that don't 
clear it.
   452   */
   453  vcpu->arch.dr6 |= DR6_RTM;
   454  vcpu->arch.dr6 |= payload;
   455  /*
   456   * Bit 16 should be set in the payload whenever the #DB
   457   * exception should clear DR6.RTM. This makes the 
payload
   458   * compatible with the pending debug exceptions under 
VMX.
   459   * Though not currently documented in the SDM, this also
   460   * makes the payload compatible with the exit 
qualification
   461   * for #DB exceptions under VMX.
   462   */
   463  vcpu->arch.dr6 ^= payload & DR6_RTM;
   464  
   465  /*
   466   * The #DB payload is defined as compatible with the 
'pending
   467   * debug exceptions' field under VMX, not DR6. While 
bit 12 is
   468   * defined in the 'pending debug exceptions' field 
(enabled
   469   * breakpoint), it is reserved and must be zero in DR6.
   470   */
   471  vcpu->arch.dr6 &= ~BIT(12);
 > 472  kvm_update_dr6(vcpu);
   473  break;
   474  case PF_VECTOR:
   475  vcpu->arch.cr2 = payload;
   476  break;
   477  }
   478  
   479  vcpu->arch.exception.has_payload = false;
   480  vcpu->arch.exception.payload = 0;
   481  }
   482  EXPORT_SYMBOL_GPL(kvm_deliver_exception_payload);
   483  

---
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 v3 10/14] remoteproc: Deal with synchronisation when shutting down

[Bjorn Andersson]

On Fri 24 Apr 13:01 PDT 2020, Mathieu Poirier wrote:

> The remoteproc core must not allow function rproc_shutdown() to
> proceed if currently synchronising with a remote processor and
> the synchronisation operations of that remote processor does not
> support it.  Also part of the process is to set the synchronisation
> flag so that the remoteproc core can make the right decisions when
> restarting the system.
> 
> Signed-off-by: Mathieu Poirier 
> ---
>  drivers/remoteproc/remoteproc_core.c | 32 
>  drivers/remoteproc/remoteproc_internal.h |  7 ++
>  2 files changed, 39 insertions(+)
> 
> diff --git a/drivers/remoteproc/remoteproc_core.c 
> b/drivers/remoteproc/remoteproc_core.c
> index 3a84a38ba37b..48afa1f80a8f 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -1849,6 +1849,27 @@ int rproc_boot(struct rproc *rproc)
>  }
>  EXPORT_SYMBOL(rproc_boot);
>  
> +static bool rproc_can_shutdown(struct rproc *rproc)
> +{
> + /*
> +  * The remoteproc core is the lifecycle manager, no problem
> +  * calling for a shutdown.
> +  */
> + if (!rproc_needs_syncing(rproc))
> + return true;
> +
> + /*
> +  * The remoteproc has been loaded by another entity (as per above
> +  * condition) and the platform code has given us the capability
> +  * of stopping it.
> +  */
> + if (rproc->sync_ops->stop)
> + return true;
> +
> + /* Any other condition should not be allowed */
> + return false;
> +}
> +
>  /**
>   * rproc_shutdown() - power off the remote processor
>   * @rproc: the remote processor
> @@ -1879,6 +1900,9 @@ void rproc_shutdown(struct rproc *rproc)
>   return;
>   }
>  
> + if (!rproc_can_shutdown(rproc))
> + goto out;

There's been a request mentioned of it being possible to shut down Linux
and having the remote processor keep running.

By skipping the rest of shutdown we will not stop or unprepare
subdevices, so presumably the remote processor won't know that
virtio/rpmsg is down. Is that ok?

> +
>   /* if the remote proc is still needed, bail out */
>   if (!atomic_dec_and_test(>power))
>   goto out;
> @@ -1898,6 +1922,14 @@ void rproc_shutdown(struct rproc *rproc)
>   kfree(rproc->cached_table);
>   rproc->cached_table = NULL;
>   rproc->table_ptr = NULL;
> +
> + /*
> +  * The remote processor has been switched off - tell the core what
> +  * operation to use from hereon, i.e whether an external entity will
> +  * reboot the remote processor or it is now the remoteproc core's
> +  * responsability.
> +  */
> + rproc_set_sync_flag(rproc, RPROC_SYNC_STATE_SHUTDOWN);

As asked on a previous patch, what would it mean if after_stop is true?

It seems like this state would be similar to the "already-booted" state
that we might encounter at probe time.

Regards,
Bjorn

>  out:
>   mutex_unlock(>lock);
>  }
> diff --git a/drivers/remoteproc/remoteproc_internal.h 
> b/drivers/remoteproc/remoteproc_internal.h
> index 61500981155c..7dcc0a26892b 100644
> --- a/drivers/remoteproc/remoteproc_internal.h
> +++ b/drivers/remoteproc/remoteproc_internal.h
> @@ -27,6 +27,9 @@ struct rproc_debug_trace {
>  /*
>   * enum rproc_sync_states - remote processsor sync states
>   *
> + * @RPROC_SYNC_STATE_SHUTDOWNstate to use after the remoteproc core
> + *   has shutdown (rproc_shutdown()) the
> + *   remote processor.
>   * @RPROC_SYNC_STATE_CRASHED state to use after the remote processor
>   *   has crashed but has not been recovered by
>   *   the remoteproc core yet.
> @@ -36,6 +39,7 @@ struct rproc_debug_trace {
>   * operation to use.
>   */
>  enum rproc_sync_states {
> + RPROC_SYNC_STATE_SHUTDOWN,
>   RPROC_SYNC_STATE_CRASHED,
>  };
>  
> @@ -43,6 +47,9 @@ static inline void rproc_set_sync_flag(struct rproc *rproc,
>  enum rproc_sync_states state)
>  {
>   switch (state) {
> + case RPROC_SYNC_STATE_SHUTDOWN:
> + rproc->sync_with_rproc = rproc->sync_flags.after_stop;
> + break;
>   case RPROC_SYNC_STATE_CRASHED:
>   rproc->sync_with_rproc = rproc->sync_flags.after_crash;
>   break;
> -- 
> 2.20.1
> 

[PATCH v12 1/2] dt-bindings: proximity: provide vcnl3020 device tree binding document

[Ivan Mikhaylov]

Mostly standard i2c driver with some additional led-current option
for vcnl3020.

Signed-off-by: Ivan Mikhaylov 
---
 .../iio/proximity/vishay,vcnl3020.yaml| 65 +++
 1 file changed, 65 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/iio/proximity/vishay,vcnl3020.yaml

diff --git 
a/Documentation/devicetree/bindings/iio/proximity/vishay,vcnl3020.yaml 
b/Documentation/devicetree/bindings/iio/proximity/vishay,vcnl3020.yaml
new file mode 100644
index ..408dee17cdf5
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/proximity/vishay,vcnl3020.yaml
@@ -0,0 +1,65 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/proximity/vcnl3020.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Integrated Proximity Sensor With Infrared Emitter
+
+maintainers:
+  - Ivan Mikhaylov 
+
+description: |
+  The VCNL3020 is a fully integrated proximity sensor. Fully integrated means
+  that the infrared emitter is included in the package. It has 16-bit
+  resolution. It includes a signal processing IC and features standard I2C
+  communication interface. It features an interrupt function.
+
+  Specifications about the devices can be found at:
+  https://www.vishay.com/docs/84150/vcnl3020.pdf
+
+properties:
+  compatible:
+enum:
+  - vishay,vcnl3020
+
+  reg:
+maxItems: 1
+
+  interrupts:
+maxItems: 1
+
+  vdd-supply:
+description: Regulator that provides power to the sensor
+
+  vddio-supply:
+description: Regulator that provides power to the bus
+
+  vishay,led-current-microamp:
+description:
+  IR LED current value with valid Range = 0 to 20d. e.g. 0 = 0 mA,
+  1 = 10 mA, 20 = 200 mA. LED Current is limited to 200 mA for values
+  higher than decimal 20. The drive current for the LED used in proximity
+  sensing.
+enum: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9,
+  10, 11, 12, 13, 14, 15, 16, 17,
+  18, 19, 20]
+default: 2
+
+required:
+  - compatible
+  - reg
+
+examples:
+  - |
+i2c {
+
+#address-cells = <1>;
+#size-cells = <0>;
+
+proximity@13 {
+  compatible = "vishay,vcnl3020";
+  reg = <0x13>;
+  vishay,led-current-microamp = <20>;
+};
+};
-- 
2.21.1

[PATCH v12 0/2] iio: proximity: driver for vcnl3020

[Ivan Mikhaylov]

Add proximity sensor driver for Vishay vcnl3020. Only on-demand
measurement is supported for now.

Changes from v11:
   1. minor changes to yaml.

Changes from v10:
   1. add vcnl3020_property struct for optional properties.

Changes from v9:
   1. minor changes.
   2. pass microamps from dts, not register value.

Changes from v8:
   1. add vcnl3020 prefix into get_and_apply_property function.
   2. add bsd license into yaml.
   3. vishay,led-current-milliamp -> vishay,led-current-microamp.
   4. add default value into vishay,led-current-microamp and change
  register values into microamps.

Changes from v7:
   1. forgot to add Reviewed-by tag.

Changes from v6:
   1. minor changes
 1.1 remove VCNL_DRV_NAME
 1.2 add braces in get_and_apply_property

Changes from v5:
   1. add get_and_apply_property function for optional parameters.
   2. minor changes.

Changes from v4:
   1. add vdd-supply,vddio-supply,interrupts properties into yaml.
   2. led-current -> vishay,led-current-milliamp in yaml.
   3. add possible values enum list.
   4. add bulk_read for result hi/lo registers.
   5. add description of vcnl3020_data structure.
   6. vcnl3020 id table is removed.
   7. make "vishay,led-current-milliamp" optional in yaml and code.

Changes from v3:
   1. minor changes.
   2. add i2c block to fix dts section in yaml.

Changes from v2:
   1. using regmap_read_poll_timeout instead of do-while in measurement
  function.
   2. change struct i2client* in vcnl3020_data to struct dev*
   3. enable REGMAP_I2C in Kconfig

Changes from v1:
   1. using regmap interface instead of i2c_smbus_* calls.
   2. switch from probe to probe_new.
   3. s32/int32_t -> int

Ivan Mikhaylov (2):
  dt-bindings: proximity: provide vcnl3020 device tree binding document
  iio: proximity: Add driver support for vcnl3020 proximity sensor

 .../iio/proximity/vishay,vcnl3020.yaml|  65 +
 drivers/iio/proximity/Kconfig |  11 +
 drivers/iio/proximity/Makefile|   1 +
 drivers/iio/proximity/vcnl3020.c  | 258 ++
 4 files changed, 335 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/iio/proximity/vishay,vcnl3020.yaml
 create mode 100644 drivers/iio/proximity/vcnl3020.c

-- 
2.21.1

[PATCH v12 2/2] iio: proximity: Add driver support for vcnl3020 proximity sensor

[Ivan Mikhaylov]

Proximity sensor driver based on light/vcnl4000.c code.
For now supports only the single on-demand measurement.

The VCNL3020 is a fully integrated proximity sensor. Fully
integrated means that the infrared emitter is included in the
package. It has 16-bit resolution. It includes a signal
processing IC and features standard I2C communication
interface. It features an interrupt function.

Datasheet: http://www.vishay.com/docs/84150/vcnl3020.pdf
Signed-off-by: Ivan Mikhaylov 
Reviewed-by: Andy Shevchenko 
---
 drivers/iio/proximity/Kconfig|  11 ++
 drivers/iio/proximity/Makefile   |   1 +
 drivers/iio/proximity/vcnl3020.c | 258 +++
 3 files changed, 270 insertions(+)
 create mode 100644 drivers/iio/proximity/vcnl3020.c

diff --git a/drivers/iio/proximity/Kconfig b/drivers/iio/proximity/Kconfig
index d53601447da4..b8d2b17e60ac 100644
--- a/drivers/iio/proximity/Kconfig
+++ b/drivers/iio/proximity/Kconfig
@@ -112,6 +112,17 @@ config SRF08
  To compile this driver as a module, choose M here: the
  module will be called srf08.
 
+config VCNL3020
+   tristate "VCNL3020 proximity sensor"
+   select REGMAP_I2C
+   depends on I2C
+   help
+ Say Y here if you want to build a driver for the Vishay VCNL3020
+ proximity sensor.
+
+ To compile this driver as a module, choose M here: the
+ module will be called vcnl3020.
+
 config VL53L0X_I2C
tristate "STMicroelectronics VL53L0X ToF ranger sensor (I2C)"
depends on I2C
diff --git a/drivers/iio/proximity/Makefile b/drivers/iio/proximity/Makefile
index 0bb5f9de13d6..8245978ced30 100644
--- a/drivers/iio/proximity/Makefile
+++ b/drivers/iio/proximity/Makefile
@@ -12,5 +12,6 @@ obj-$(CONFIG_RFD77402)+= rfd77402.o
 obj-$(CONFIG_SRF04)+= srf04.o
 obj-$(CONFIG_SRF08)+= srf08.o
 obj-$(CONFIG_SX9500)   += sx9500.o
+obj-$(CONFIG_VCNL3020) += vcnl3020.o
 obj-$(CONFIG_VL53L0X_I2C)  += vl53l0x-i2c.o
 
diff --git a/drivers/iio/proximity/vcnl3020.c b/drivers/iio/proximity/vcnl3020.c
new file mode 100644
index ..9ff1a164c2e6
--- /dev/null
+++ b/drivers/iio/proximity/vcnl3020.c
@@ -0,0 +1,258 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Support for Vishay VCNL3020 proximity sensor on i2c bus.
+ * Based on Vishay VCNL4000 driver code.
+ *
+ * TODO: interrupts.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#define VCNL3020_PROD_ID   0x21
+
+#define VCNL_COMMAND   0x80 /* Command register */
+#define VCNL_PROD_REV  0x81 /* Product ID and Revision ID */
+#define VCNL_PROXIMITY_RATE0x82 /* Rate of Proximity Measurement */
+#define VCNL_LED_CURRENT   0x83 /* IR LED current for proximity mode */
+#define VCNL_PS_RESULT_HI  0x87 /* Proximity result register, MSB */
+#define VCNL_PS_RESULT_LO  0x88 /* Proximity result register, LSB */
+#define VCNL_PS_ICR0x89 /* Interrupt Control Register */
+#define VCNL_PS_LO_THR_HI  0x8a /* High byte of low threshold value */
+#define VCNL_PS_LO_THR_LO  0x8b /* Low byte of low threshold value */
+#define VCNL_PS_HI_THR_HI  0x8c /* High byte of high threshold value */
+#define VCNL_PS_HI_THR_LO  0x8d /* Low byte of high threshold value */
+#define VCNL_ISR   0x8e /* Interrupt Status Register */
+#define VCNL_PS_MOD_ADJ0x8f /* Proximity Modulator Timing 
Adjustment */
+
+/* Bit masks for COMMAND register */
+#define VCNL_PS_RDYBIT(5) /* proximity data ready? */
+#define VCNL_PS_OD BIT(3) /* start on-demand proximity
+   * measurement
+   */
+
+#define VCNL_ON_DEMAND_TIMEOUT_US  10
+#define VCNL_POLL_US   2
+
+/**
+ * struct vcnl3020_data - vcnl3020 specific data.
+ * @regmap:device register map.
+ * @dev:   vcnl3020 device.
+ * @rev:   revision id.
+ * @lock:  lock for protecting access to device hardware registers.
+ */
+struct vcnl3020_data {
+   struct regmap *regmap;
+   struct device *dev;
+   u8 rev;
+   struct mutex lock;
+};
+
+/**
+ * struct vcnl3020_property - vcnl3020 property.
+ * @name:  property name.
+ * @reg:   i2c register offset.
+ * @conversion_func:   conversion function.
+ */
+struct vcnl3020_property {
+   const char *name;
+   u32 reg;
+   u32 (*conversion_func)(u32 *val);
+};
+
+static u32 microamp_to_reg(u32 *val)
+{
+   /*
+* An example of conversion from uA to reg val:
+* 20 uA == 200 mA == 20
+*/
+   return *val /= 1;
+};
+
+static struct vcnl3020_property vcnl3020_led_current_property = {
+   .name = "vishay,led-current-microamp",
+   .reg = VCNL_LED_CURRENT,
+   .conversion_func = microamp_to_reg,
+};
+
+static int vcnl3020_get_and_apply_property(struct vcnl3020_data *data,
+   

Re: [PATCH v3 09/14] remoteproc: Deal with synchronisation when crashing

[Bjorn Andersson]

On Fri 24 Apr 13:01 PDT 2020, Mathieu Poirier wrote:

> Refactor function rproc_trigger_recovery() in order to avoid
> reloading the firmware image when synchronising with a remote
> processor rather than booting it.  Also part of the process,
> properly set the synchronisation flag in order to properly
> recover the system.
> 
> Signed-off-by: Mathieu Poirier 
> ---
>  drivers/remoteproc/remoteproc_core.c | 23 ++--
>  drivers/remoteproc/remoteproc_internal.h | 27 
>  2 files changed, 43 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/remoteproc/remoteproc_core.c 
> b/drivers/remoteproc/remoteproc_core.c
> index ef88d3e84bfb..3a84a38ba37b 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -1697,7 +1697,7 @@ static void rproc_coredump(struct rproc *rproc)
>   */
>  int rproc_trigger_recovery(struct rproc *rproc)
>  {
> - const struct firmware *firmware_p;
> + const struct firmware *firmware_p = NULL;
>   struct device *dev = >dev;
>   int ret;
>  
> @@ -1718,14 +1718,16 @@ int rproc_trigger_recovery(struct rproc *rproc)
>   /* generate coredump */
>   rproc_coredump(rproc);
>  
> - /* load firmware */
> - ret = request_firmware(_p, rproc->firmware, dev);
> - if (ret < 0) {
> - dev_err(dev, "request_firmware failed: %d\n", ret);
> - goto unlock_mutex;
> + /* load firmware if need be */
> + if (!rproc_needs_syncing(rproc)) {
> + ret = request_firmware(_p, rproc->firmware, dev);
> + if (ret < 0) {
> + dev_err(dev, "request_firmware failed: %d\n", ret);
> + goto unlock_mutex;
> + }
>   }
>  
> - /* boot the remote processor up again */
> + /* boot up or synchronise with the remote processor again */
>   ret = rproc_start(rproc, firmware_p);
>  
>   release_firmware(firmware_p);
> @@ -1761,6 +1763,13 @@ static void rproc_crash_handler_work(struct 
> work_struct *work)
>   dev_err(dev, "handling crash #%u in %s\n", ++rproc->crash_cnt,
>   rproc->name);
>  
> + /*
> +  * The remote processor has crashed - tell the core what operation
> +  * to use from hereon, i.e whether an external entity will reboot
> +  * the MCU or it is now the remoteproc core's responsability.
> +  */
> + rproc_set_sync_flag(rproc, RPROC_SYNC_STATE_CRASHED);

If I follow the logic correctly, you're essentially using
rproc->sync_with_rproc to pass an additional parameter down through
rproc_trigger_recovery() to tell everyone below to "load firmware and
boot the core or not".

And given that the comment alludes to some unknown logic determining the
continuation I think it would be much preferable to essentially just
pass rproc->sync_flags.after_crash down through these functions.


And per my comment on a previous patch, is there any synchronization
with the remote controller when this happens?

Regards,
Bjorn

> +
>   mutex_unlock(>lock);
>  
>   if (!rproc->recovery_disabled)
> diff --git a/drivers/remoteproc/remoteproc_internal.h 
> b/drivers/remoteproc/remoteproc_internal.h
> index 3985c084b184..61500981155c 100644
> --- a/drivers/remoteproc/remoteproc_internal.h
> +++ b/drivers/remoteproc/remoteproc_internal.h
> @@ -24,6 +24,33 @@ struct rproc_debug_trace {
>   struct rproc_mem_entry trace_mem;
>  };
>  
> +/*
> + * enum rproc_sync_states - remote processsor sync states
> + *
> + * @RPROC_SYNC_STATE_CRASHED state to use after the remote processor
> + *   has crashed but has not been recovered by
> + *   the remoteproc core yet.
> + *
> + * Keeping these separate from the enum rproc_state in order to avoid
> + * introducing coupling between the state of the MCU and the synchronisation
> + * operation to use.
> + */
> +enum rproc_sync_states {
> + RPROC_SYNC_STATE_CRASHED,
> +};
> +
> +static inline void rproc_set_sync_flag(struct rproc *rproc,
> +enum rproc_sync_states state)
> +{
> + switch (state) {
> + case RPROC_SYNC_STATE_CRASHED:
> + rproc->sync_with_rproc = rproc->sync_flags.after_crash;
> + break;
> + default:
> + break;
> + }
> +}
> +
>  /* from remoteproc_core.c */
>  void rproc_release(struct kref *kref);
>  irqreturn_t rproc_vq_interrupt(struct rproc *rproc, int vq_id);
> -- 
> 2.20.1
> 

Re: [PATCH v4 1/2] powerpc/uaccess: Implement unsafe_put_user() using 'asm goto'

[Michael Ellerman]

Segher Boessenkool  writes:
> Hi!
>
> On Wed, May 06, 2020 at 12:27:58AM +1000, Michael Ellerman wrote:
>> Christophe Leroy  writes:
>> > unsafe_put_user() is designed to take benefit of 'asm goto'.
>> >
>> > Instead of using the standard __put_user() approach and branch
>> > based on the returned error, use 'asm goto' and make the
>> > exception code branch directly to the error label. There is
>> > no code anymore in the fixup section.
>> >
>> > This change significantly simplifies functions using
>> > unsafe_put_user()
>> >
>> ...
>> >
>> > Signed-off-by: Christophe Leroy 
>> > ---
>> >  arch/powerpc/include/asm/uaccess.h | 61 +-
>> >  1 file changed, 52 insertions(+), 9 deletions(-)
>> >
>> > diff --git a/arch/powerpc/include/asm/uaccess.h 
>> > b/arch/powerpc/include/asm/uaccess.h
>> > index 9cc9c106ae2a..9365b59495a2 100644
>> > --- a/arch/powerpc/include/asm/uaccess.h
>> > +++ b/arch/powerpc/include/asm/uaccess.h
>> > @@ -196,6 +193,52 @@ do {  
>> > \
>> >  })
>> >  
>> >  
>> > +#define __put_user_asm_goto(x, addr, label, op)   \
>> > +  asm volatile goto(  \
>> > +  "1: " op "%U1%X1 %0,%1  # put_user\n"   \
>> > +  EX_TABLE(1b, %l2)   \
>> > +  :   \
>> > +  : "r" (x), "m<>" (*addr)\
>> 
>> The "m<>" here is breaking GCC 4.6.3, which we allegedly still support.
>
> [ You shouldn't use 4.6.3, there has been 4.6.4 since a while.  And 4.6
>   is nine years old now.  Most projects do not support < 4.8 anymore, on
>   any architecture.  ]

Moving up to 4.6.4 wouldn't actually help with this though would it?

Also I have 4.6.3 compilers already built, I don't really have time to
rebuild them for 4.6.4.

The kernel has a top-level minimum version, which I'm not in charge of, see:

https://www.kernel.org/doc/html/latest/process/changes.html?highlight=gcc


There were discussions about making 4.8 the minimum, but I'm not sure
where they got to.

>> Plain "m" works, how much does the "<>" affect code gen in practice?
>> 
>> A quick diff here shows no difference from removing "<>".
>
> It will make it impossible to use update-form instructions here.  That
> probably does not matter much at all, in this case.
>
> If you remove the "<>" constraints, also remove the "%Un" output modifier?

So like this?

diff --git a/arch/powerpc/include/asm/uaccess.h 
b/arch/powerpc/include/asm/uaccess.h
index 62cc8d7640ec..ca847aed8e45 100644
--- a/arch/powerpc/include/asm/uaccess.h
+++ b/arch/powerpc/include/asm/uaccess.h
@@ -207,10 +207,10 @@ do {  
\
 
 #define __put_user_asm_goto(x, addr, label, op)\
asm volatile goto(  \
-   "1: " op "%U1%X1 %0,%1  # put_user\n"   \
+   "1: " op "%X1 %0,%1 # put_user\n"   \
EX_TABLE(1b, %l2)   \
:   \
-   : "r" (x), "m<>" (*addr)\
+   : "r" (x), "m" (*addr)  \
:   \
: label)
 


cheers

Re: [PATCH v2] security: disable FORTIFY_SOURCE on clang

[Nick Desaulniers]

On Tue, May 5, 2020 at 5:15 PM Jason A. Donenfeld  wrote:
>
> clang-10 has a broken optimization stage that doesn't allow the
> compiler to prove at compile time that certain memcpys are within
> bounds, and thus the outline memcpy is always called, resulting in
> horrific performance, and in some cases, excessive stack frame growth.
> Here's a simple reproducer:
>
> typedef unsigned long size_t;
> void *c(void *dest, const void *src, size_t n) __asm__("memcpy");
> extern inline __attribute__((gnu_inline)) void *memcpy(void *dest, const 
> void *src, size_t n) { return c(dest, src, n); }
> void blah(char *a)
> {
>   unsigned long long b[10], c[10];
>   int i;
>
>   memcpy(b, a, sizeof(b));
>   for (i = 0; i < 10; ++i)
> c[i] = b[i] ^ b[9 - i];
>   for (i = 0; i < 10; ++i)
> b[i] = c[i] ^ a[i];
>   memcpy(a, b, sizeof(b));
> }
>
> Compile this with clang-9 and clang-10 and observe:
>
> zx2c4@thinkpad /tmp/curve25519-hacl64-stack-frame-size-test $ clang-10 
> -Wframe-larger-than=0 -O3 -c b.c -o c10.o
> b.c:5:6: warning: stack frame size of 104 bytes in function 'blah' 
> [-Wframe-larger-than=]
> void blah(char *a)
>  ^
> 1 warning generated.
> zx2c4@thinkpad /tmp/curve25519-hacl64-stack-frame-size-test $ clang-9 
> -Wframe-larger-than=0 -O3 -c b.c -o c9.o
>
> Looking at the disassembly of c10.o and c9.o, one can see that c9.o is
> properly optimized in the obvious way one would expect, while c10.o has
> blown up and includes extern calls to memcpy.
>
> But actually, for versions of clang earlier than 10, fortify source
> mostly does nothing. So, between being broken and doing nothing, it
> probably doesn't make sense to pretend to offer this option. So, this
> commit just disables it entirely when compiling with clang.
>
> Cc: Arnd Bergmann 
> Cc: LKML 
> Cc: clang-built-linux 
> Cc: Kees Cook 
> Cc: George Burgess 
> Cc: Nick Desaulniers 
> Link: https://bugs.llvm.org/show_bug.cgi?id=45802
> Signed-off-by: Jason A. Donenfeld 

Acked-by: Nick Desaulniers 

> ---
>  security/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/security/Kconfig b/security/Kconfig
> index cd3cc7da3a55..76bcfb3eb16f 100644
> --- a/security/Kconfig
> +++ b/security/Kconfig
> @@ -191,6 +191,7 @@ config HARDENED_USERCOPY_PAGESPAN
>  config FORTIFY_SOURCE
> bool "Harden common str/mem functions against buffer overflows"
> depends on ARCH_HAS_FORTIFY_SOURCE
> +   depends on !CC_IS_CLANG
> help
>   Detect overflows of buffers in common string and memory functions
>   where the compiler can determine and validate the buffer sizes.
> --
> 2.26.2
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Clang Built Linux" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clang-built-linux+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/clang-built-linux/20200506001453.764332-1-Jason%40zx2c4.com.



-- 
Thanks,
~Nick Desaulniers

Re: [PATCH -next] cpupower: Remove unneeded semicolon

[Samuel Zou]

Hi Shuah,

I run with the below command, and get the output report.

[local-host linux-next]# make coccicheck MODE=report 
M=tools/power/cpupower/utils


Please check for false positives in the output before submitting a patch.
When using "patch" mode, carefully review the patch before submitting it.

tools/power/cpupower/utils/idle_monitor/cpuidle_sysfs.c:175:2-3: 
Unneeded semicolon
tools/power/cpupower/utils/idle_monitor/cpuidle_sysfs.c:56:2-3: Unneeded 
semicolon
tools/power/cpupower/utils/idle_monitor/cpuidle_sysfs.c:75:2-3: Unneeded 
semicolon
tools/power/cpupower/utils/idle_monitor/snb_idle.c:80:2-3: Unneeded 
semicolon

tools/power/cpupower/utils/cpupower-set.c:75:2-3: Unneeded semicolon
tools/power/cpupower/utils/idle_monitor/hsw_ext_idle.c:82:2-3: Unneeded 
semicolon
tools/power/cpupower/utils/idle_monitor/amd_fam14h_idle.c:120:2-3: 
Unneeded semicolon
tools/power/cpupower/utils/idle_monitor/nhm_idle.c:94:2-3: Unneeded 
semicolon

tools/power/cpupower/utils/cpupower-info.c:65:2-3: Unneeded semicolon

On 2020/5/2 1:07, shuah wrote:

Hi Zou Wei,

On 4/28/20 3:43 AM, Zou Wei wrote:

Fixes coccicheck warnings:


I am not finding these in my coccicheck run. Can you send me the options
you are using?



tools/power/cpupower/utils/cpupower-info.c:65:2-3: Unneeded semicolon
tools/power/cpupower/utils/cpupower-set.c:75:2-3: Unneeded semicolon
tools/power/cpupower/utils/idle_monitor/amd_fam14h_idle.c:120:2-3: 
Unneeded semicolon
tools/power/cpupower/utils/idle_monitor/cpuidle_sysfs.c:175:2-3: 
Unneeded semicolon
tools/power/cpupower/utils/idle_monitor/cpuidle_sysfs.c:56:2-3: 
Unneeded semicolon
tools/power/cpupower/utils/idle_monitor/cpuidle_sysfs.c:75:2-3: 
Unneeded semicolon
tools/power/cpupower/utils/idle_monitor/hsw_ext_idle.c:82:2-3: 
Unneeded semicolon
tools/power/cpupower/utils/idle_monitor/nhm_idle.c:94:2-3: Unneeded 
semicolon
tools/power/cpupower/utils/idle_monitor/snb_idle.c:80:2-3: Unneeded 
semicolon


Reported-by: Hulk Robot 
Signed-off-by: Zou Wei 
---
  tools/power/cpupower/utils/cpupower-info.c    | 2 +-
  tools/power/cpupower/utils/cpupower-set.c | 2 +-
  tools/power/cpupower/utils/idle_monitor/amd_fam14h_idle.c | 2 +-
  tools/power/cpupower/utils/idle_monitor/cpuidle_sysfs.c   | 6 +++---
  tools/power/cpupower/utils/idle_monitor/hsw_ext_idle.c    | 2 +-
  tools/power/cpupower/utils/idle_monitor/nhm_idle.c    | 2 +-
  tools/power/cpupower/utils/idle_monitor/snb_idle.c    | 2 +-
  7 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/tools/power/cpupower/utils/cpupower-info.c 
b/tools/power/cpupower/utils/cpupower-info.c

index d3755ea..0ba61a2 100644
--- a/tools/power/cpupower/utils/cpupower-info.c
+++ b/tools/power/cpupower/utils/cpupower-info.c
@@ -62,7 +62,7 @@ int cmd_info(int argc, char **argv)
  default:
  print_wrong_arg_exit();
  }
-    };
+    }


The patch itself is fine.

thanks,
-- Shuah

.

Re: AVIC related warning in enable_irq_window

[Suravee Suthikulpanit]

On 5/5/20 7:12 PM, Paolo Bonzini wrote:

On 05/05/20 09:55, Suravee Suthikulpanit wrote:

On the other hand, would be it useful to implement
kvm_make_all_cpus_request_but_self(),
which sends request to all other vcpus excluding itself?


Yes, that's also a possibility.  It's not too much extra complication if
we add a new argument to kvm_make_vcpus_request_mask, like this:

diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 74bdb7bf3295..8f9dadb1ef42 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -258,7 +258,7 @@ static inline bool kvm_kick_many_cpus(const struct cpumask 
*cpus, bool wait)
return true;
  }
  
-bool kvm_make_vcpus_request_mask(struct kvm *kvm, unsigned int req,

+bool kvm_make_vcpus_request_mask(struct kvm *kvm, unsigned int req, struct 
kvm_vcpu *except,
 unsigned long *vcpu_bitmap, cpumask_var_t tmp)
  {
int i, cpu, me;
@@ -270,6 +270,8 @@ bool kvm_make_vcpus_request_mask(struct kvm *kvm, unsigned 
int req,
kvm_for_each_vcpu(i, vcpu, kvm) {
if (vcpu_bitmap && !test_bit(i, vcpu_bitmap))
continue;
+   if (vcpu == except)
+   continue;
  
  		kvm_make_request(req, vcpu);

cpu = vcpu->cpu;


Paolo



Sounds good. I'll take care of this today.

Suravee

Re: [PATCH v3 07/14] remoteproc: Introducting new start and stop functions

[Bjorn Andersson]

On Fri 24 Apr 13:01 PDT 2020, Mathieu Poirier wrote:

> Add new functions to replace direct calling of rproc->ops->start() and
> rproc->ops->stop().  That way different behaviour can be played out
> when booting a remote processor or synchronising with it.
> 

Reviewed-by: Bjorn Andersson 

PS. But I do wonder if we should just inline the struct rproc_ops in
struct rproc, rather than allocate a separate object for it. But after
adding all your accessors changing this would be quite succinct.

Regards,
Bjorn

> Signed-off-by: Mathieu Poirier 
> ---
>  drivers/remoteproc/remoteproc_core.c |  6 +++---
>  drivers/remoteproc/remoteproc_internal.h | 16 
>  2 files changed, 19 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/remoteproc/remoteproc_core.c 
> b/drivers/remoteproc/remoteproc_core.c
> index 9de0e2b7ca2b..ef88d3e84bfb 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -1339,7 +1339,7 @@ static int rproc_start(struct rproc *rproc, const 
> struct firmware *fw)
>   }
>  
>   /* power up the remote processor */
> - ret = rproc->ops->start(rproc);
> + ret = rproc_start_device(rproc);
>   if (ret) {
>   dev_err(dev, "can't start rproc %s: %d\n", rproc->name, ret);
>   goto unprepare_subdevices;
> @@ -1360,7 +1360,7 @@ static int rproc_start(struct rproc *rproc, const 
> struct firmware *fw)
>   return 0;
>  
>  stop_rproc:
> - rproc->ops->stop(rproc);
> + rproc_stop_device(rproc);
>  unprepare_subdevices:
>   rproc_unprepare_subdevices(rproc);
>  reset_table_ptr:
> @@ -1493,7 +1493,7 @@ static int rproc_stop(struct rproc *rproc, bool crashed)
>   rproc->table_ptr = rproc->cached_table;
>  
>   /* power off the remote processor */
> - ret = rproc->ops->stop(rproc);
> + ret = rproc_stop_device(rproc);
>   if (ret) {
>   dev_err(dev, "can't stop rproc: %d\n", ret);
>   return ret;
> diff --git a/drivers/remoteproc/remoteproc_internal.h 
> b/drivers/remoteproc/remoteproc_internal.h
> index 47b500e40dd9..dda7044c4b3e 100644
> --- a/drivers/remoteproc/remoteproc_internal.h
> +++ b/drivers/remoteproc/remoteproc_internal.h
> @@ -125,6 +125,22 @@ struct resource_table 
> *rproc_find_loaded_rsc_table(struct rproc *rproc,
>   return NULL;
>  }
>  
> +static inline int rproc_start_device(struct rproc *rproc)
> +{
> + if (rproc->ops && rproc->ops->start)
> + return rproc->ops->start(rproc);
> +
> + return 0;
> +}
> +
> +static inline int rproc_stop_device(struct rproc *rproc)
> +{
> + if (rproc->ops && rproc->ops->stop)
> + return rproc->ops->stop(rproc);
> +
> + return 0;
> +}
> +
>  static inline
>  bool rproc_u64_fit_in_size_t(u64 val)
>  {
> -- 
> 2.20.1
> 

Re: [PATCH -next] vdpasim: remove unused variable 'ret'

[Michael S. Tsirkin]

On Fri, Apr 10, 2020 at 07:54:22PM +0800, YueHaibing wrote:
> drivers/vdpa/vdpa_sim/vdpa_sim.c:92:6: warning:
>  variable ‘ret’ set but not used [-Wunused-but-set-variable]
> 
> Signed-off-by: YueHaibing 
> ---

Either this, or BUG_ON.  Jason?

>  drivers/vdpa/vdpa_sim/vdpa_sim.c | 15 +++
>  1 file changed, 7 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c 
> b/drivers/vdpa/vdpa_sim/vdpa_sim.c
> index 7957d2d41fc4..01c456f7c1f7 100644
> --- a/drivers/vdpa/vdpa_sim/vdpa_sim.c
> +++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c
> @@ -89,15 +89,14 @@ static struct vdpasim *dev_to_sim(struct device *dev)
>  static void vdpasim_queue_ready(struct vdpasim *vdpasim, unsigned int idx)
>  {
>   struct vdpasim_virtqueue *vq = >vqs[idx];
> - int ret;
>  
> - ret = vringh_init_iotlb(>vring, vdpasim_features,
> - VDPASIM_QUEUE_MAX, false,
> - (struct vring_desc *)(uintptr_t)vq->desc_addr,
> - (struct vring_avail *)
> - (uintptr_t)vq->driver_addr,
> - (struct vring_used *)
> - (uintptr_t)vq->device_addr);
> + vringh_init_iotlb(>vring, vdpasim_features,
> +   VDPASIM_QUEUE_MAX, false,
> +   (struct vring_desc *)(uintptr_t)vq->desc_addr,
> +   (struct vring_avail *)
> +   (uintptr_t)vq->driver_addr,
> +   (struct vring_used *)
> +   (uintptr_t)vq->device_addr);
>  }
>  
>  static void vdpasim_vq_reset(struct vdpasim_virtqueue *vq)
> -- 
> 2.17.1
> 

Re: [PATCH v6 8/8] bus: mhi: core: Ensure non-zero session or sequence ID values are used

[Jeffrey Hugo]

On 5/5/2020 4:47 PM, Bhaumik Bhatt wrote:

While writing any sequence or session identifiers, it is possible that
the host could write a zero value, whereas only non-zero values should
be supported writes to those registers. Ensure that the host does not
write a non-zero value for them and also log them in debug messages.

Signed-off-by: Bhaumik Bhatt 
---


Reviewed-by: Jeffrey Hugo 

--
Jeffrey Hugo
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: [PATCH v3 05/14] remoteproc: Refactor function rproc_fw_boot()

[Bjorn Andersson]

On Fri 24 Apr 13:01 PDT 2020, Mathieu Poirier wrote:

> Refactor function rproc_fw_boot() in order to better reflect the work
> that is done when supporting scenarios where the remoteproc core is
> synchronising with a remote processor.
> 
> Signed-off-by: Mathieu Poirier 
> ---
>  drivers/remoteproc/remoteproc_core.c | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/remoteproc/remoteproc_core.c 
> b/drivers/remoteproc/remoteproc_core.c
> index a02593b75bec..e90a21de9de1 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -1370,9 +1370,9 @@ static int rproc_start(struct rproc *rproc, const 
> struct firmware *fw)
>  }
>  
>  /*
> - * take a firmware and boot a remote processor with it.
> + * boot or synchronise with a remote processor.
>   */
> -static int rproc_fw_boot(struct rproc *rproc, const struct firmware *fw)
> +static int rproc_actuate_device(struct rproc *rproc, const struct firmware 
> *fw)

Per patch 4 this function will if rproc_needs_syncing() be called with
fw == NULL, it's not obvious to me that the various operations on "fw"
in this function are valid anymore.

>  {
>   struct device *dev = >dev;
>   const char *name = rproc->firmware;
> @@ -1382,7 +1382,9 @@ static int rproc_fw_boot(struct rproc *rproc, const 
> struct firmware *fw)
>   if (ret)
>   return ret;
>  
> - dev_info(dev, "Booting fw image %s, size %zd\n", name, fw->size);
> + if (!rproc_needs_syncing(rproc))

Can't we make this check on fw, to make the relationship "if we where
passed a firmware object, we're going to load and boot that firmware"?

Regards,
Bjorn

> + dev_info(dev, "Booting fw image %s, size %zd\n",
> +  name, fw->size);
>  
>   /*
>* if enabling an IOMMU isn't relevant for this rproc, this is
> @@ -1818,7 +1820,7 @@ int rproc_boot(struct rproc *rproc)
>   }
>   }
>  
> - ret = rproc_fw_boot(rproc, firmware_p);
> + ret = rproc_actuate_device(rproc, firmware_p);
>  
>   release_firmware(firmware_p);
>  
> -- 
> 2.20.1
> 

Re: [PATCH v3 -next] drm/mediatek: Fix Kconfig warning

[Chun-Kuang Hu]

Hi, YueHaibing:

Chun-Kuang Hu  於 2020年4月29日 週三 下午10:15寫道：
>
> Hi, YueHaibing:
>
> YueHaibing  於 2020年4月29日 週三 下午3:14寫道：
> >
> > WARNING: unmet direct dependencies detected for MTK_MMSYS
> >   Depends on [n]: (ARCH_MEDIATEK [=y] || COMPILE_TEST [=n]) && 
> > COMMON_CLK_MT8173_MMSYS [=n]
> >   Selected by [y]:
> >   - DRM_MEDIATEK [=y] && HAS_IOMEM [=y] && DRM [=y] && (ARCH_MEDIATEK [=y] 
> > || ARM && COMPILE_TEST [=n]) && COMMON_CLK [=y] && HAVE_ARM_SMCCC [=y] && 
> > OF [=y]
> >
> > Make DRM_MEDIATEK depend on MTK_MMSYS to fix this.
>
> Reviewed-by: Chun-Kuang Hu 
>

Applied to mediatek-drm-next [1], thanks.

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next

Regards,
Chun-Kuang.

> >
> > Fixes: 2c758e301ed9 ("soc / drm: mediatek: Move routing control to mmsys 
> > device")
> > Signed-off-by: YueHaibing 
> > ---
> > v3: make DRM_MEDIATEK depends on MTK_MMSYS
> > v2: select COMMON_CLK_MT8173_MMSYS instead of adding DRM_MEDIATEK dependency
> > ---
> >  drivers/gpu/drm/mediatek/Kconfig | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/mediatek/Kconfig 
> > b/drivers/gpu/drm/mediatek/Kconfig
> > index c420f5a3d33b..aa74aac3cbcc 100644
> > --- a/drivers/gpu/drm/mediatek/Kconfig
> > +++ b/drivers/gpu/drm/mediatek/Kconfig
> > @@ -6,12 +6,12 @@ config DRM_MEDIATEK
> > depends on COMMON_CLK
> > depends on HAVE_ARM_SMCCC
> > depends on OF
> > +   depends on MTK_MMSYS
> > select DRM_GEM_CMA_HELPER
> > select DRM_KMS_HELPER
> > select DRM_MIPI_DSI
> > select DRM_PANEL
> > select MEMORY
> > -   select MTK_MMSYS
> > select MTK_SMI
> > select VIDEOMODE_HELPERS
> > help
> > --
> > 2.17.1
> >
> >

Re: [PATCH v5] iommu/virtio: Use page size bitmap supported by endpoint

[Michael S. Tsirkin]

On Tue, May 05, 2020 at 03:00:04PM +0530, Bharat Bhushan wrote:
> Different endpoint can support different page size, probe
> endpoint if it supports specific page size otherwise use
> global page sizes.
> 
> Signed-off-by: Bharat Bhushan 
> ---
> v4->v5:
>  - Rebase to Linux v5.7-rc4
> 
> v3->v4:
>  - Fix whitespace error
> 
> v2->v3:
>  - Fixed error return for incompatible endpoint
>  - __u64 changed to __le64 in header file
> 
>  drivers/iommu/virtio-iommu.c  | 48 ---
>  include/uapi/linux/virtio_iommu.h |  7 +
>  2 files changed, 51 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c
> index d5cac4f46ca5..9513d2ab819e 100644
> --- a/drivers/iommu/virtio-iommu.c
> +++ b/drivers/iommu/virtio-iommu.c
> @@ -78,6 +78,7 @@ struct viommu_endpoint {
>   struct viommu_dev   *viommu;
>   struct viommu_domain*vdomain;
>   struct list_headresv_regions;
> + u64 pgsize_bitmap;
>  };
>  
>  struct viommu_request {
> @@ -415,6 +416,19 @@ static int viommu_replay_mappings(struct viommu_domain 
> *vdomain)
>   return ret;
>  }
>  
> +static int viommu_set_pgsize_bitmap(struct viommu_endpoint *vdev,
> + struct virtio_iommu_probe_pgsize_mask *mask,
> + size_t len)
> +{
> + u64 pgsize_bitmap = le64_to_cpu(mask->pgsize_bitmap);
> +
> + if (len < sizeof(*mask))

This is too late to validate length, you have dereferenced it already.
do it before the read pls.

> + return -EINVAL;

OK but note that guest will then just proceed to ignore the
property. Is that really OK? Wouldn't host want to know?


> +
> + vdev->pgsize_bitmap = pgsize_bitmap;

what if bitmap is 0? Is that a valid size? I see a bunch of
BUG_ON with that value ...

I also see a bunch of code like e.g. this:

pg_size = 1UL << __ffs(pgsize_bitmap);

which probably won't DTRT on a 32 bit guest if the bitmap has bits
set in the high word.



> + return 0;
> +}
> +
>  static int viommu_add_resv_mem(struct viommu_endpoint *vdev,
>  struct virtio_iommu_probe_resv_mem *mem,
>  size_t len)
> @@ -499,6 +513,9 @@ static int viommu_probe_endpoint(struct viommu_dev 
> *viommu, struct device *dev)
>   case VIRTIO_IOMMU_PROBE_T_RESV_MEM:
>   ret = viommu_add_resv_mem(vdev, (void *)prop, len);
>   break;
> + case VIRTIO_IOMMU_PROBE_T_PAGE_SIZE_MASK:
> + ret = viommu_set_pgsize_bitmap(vdev, (void *)prop, len);
> + break;
>   default:
>   dev_err(dev, "unknown viommu prop 0x%x\n", type);
>   }
> @@ -630,7 +647,7 @@ static int viommu_domain_finalise(struct viommu_endpoint 
> *vdev,
>  
>   vdomain->id = (unsigned int)ret;
>  
> - domain->pgsize_bitmap   = viommu->pgsize_bitmap;
> + domain->pgsize_bitmap   = vdev->pgsize_bitmap;
>   domain->geometry= viommu->geometry;
>  
>   vdomain->map_flags  = viommu->map_flags;
> @@ -654,6 +671,29 @@ static void viommu_domain_free(struct iommu_domain 
> *domain)
>   kfree(vdomain);
>  }
>  
> +/*
> + * Check whether the endpoint's capabilities are compatible with other
> + * endpoints in the domain. Report any inconsistency.
> + */
> +static bool viommu_endpoint_is_compatible(struct viommu_endpoint *vdev,
> +   struct viommu_domain *vdomain)
> +{
> + struct device *dev = vdev->dev;
> +
> + if (vdomain->viommu != vdev->viommu) {
> + dev_err(dev, "cannot attach to foreign vIOMMU\n");
> + return false;
> + }
> +
> + if (vdomain->domain.pgsize_bitmap != vdev->pgsize_bitmap) {
> + dev_err(dev, "incompatible domain bitmap 0x%lx != 0x%llx\n",
> + vdomain->domain.pgsize_bitmap, vdev->pgsize_bitmap);
> + return false;
> + }

I'm confused by this. So let's assume host supports pages sizes
of 4k, 2M, 1G. It signals this in the properties. Nice.
Now domain supports 4k, 2M and that's all. Why is that a problem?
Just don't use 1G ...


> +
> + return true;
> +}
> +
>  static int viommu_attach_dev(struct iommu_domain *domain, struct device *dev)
>  {
>   int i;
> @@ -670,9 +710,8 @@ static int viommu_attach_dev(struct iommu_domain *domain, 
> struct device *dev)
>* owns it.
>*/
>   ret = viommu_domain_finalise(vdev, domain);
> - } else if (vdomain->viommu != vdev->viommu) {
> - dev_err(dev, "cannot attach to foreign vIOMMU\n");
> - ret = -EXDEV;
> + } else if (!viommu_endpoint_is_compatible(vdev, vdomain)) {
> + ret = -EINVAL;
>   }
>   mutex_unlock(>mutex);
>  
> @@ -886,6 +925,7 @@ static int 

Re: [PATCH v3 03/14] remoteproc: Add new operation and flags for synchronistation

[Bjorn Andersson]

On Fri 24 Apr 13:01 PDT 2020, Mathieu Poirier wrote:

> Add a new sync_ops to support use cases where the remoteproc
> core is synchronising with the remote processor.  Exactly when to use
> the synchronisation operations is directed by the flags in structure
> rproc_sync_flags.
> 

I'm sorry, but no matter how many times I read these patches I have to
translate "synchronising" to "remote controlled", and given the number
of comments clarifying this makes me feel that we could perhaps come up
with a better name?

> Signed-off-by: Mathieu Poirier 
> ---
>  include/linux/remoteproc.h | 24 
>  1 file changed, 24 insertions(+)
> 
> diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
> index ac4082f12e8b..ceb3b2bba824 100644
> --- a/include/linux/remoteproc.h
> +++ b/include/linux/remoteproc.h
> @@ -353,6 +353,23 @@ enum rsc_handling_status {
>   RSC_IGNORED = 1,
>  };
>  
> +/**
> + * struct rproc_sync_flags - platform specific flags indicating which
> + * rproc_ops to use at specific times during
> + * the rproc lifecycle.
> + * @on_init: true if synchronising with the remote processor at
> + *initialisation time
> + * @after_stop: true if synchronising with the remote processor after it was
> + *   stopped from the cmmand line
> + * @after_crash: true if synchronising with the remote processor after
> + *it has crashed
> + */
> +struct rproc_sync_flags {
> + bool on_init;

This indirectly splits the RPROC_OFFLINE state in an "offline" and
"already-booted" state. Wouldn't it be clearer to represent this with a
new RPROC_ALREADY_BOOTED state?

> + bool after_stop;

What does it mean when this is true? That Linux can shut the remote core
down, but someone else will start it?

> + bool after_crash;

Similarly what is the expected steps to be taken by the core when this
is true? Should rproc_report_crash() simply stop/start the subdevices
and upon one of the ops somehow tell the remote controller that it can
proceed with the recovery?

> +};
> +
>  /**
>   * struct rproc_ops - platform-specific device handlers
>   * @start:   power on the device and boot it
> @@ -459,6 +476,9 @@ struct rproc_dump_segment {
>   * @firmware: name of firmware file to be loaded
>   * @priv: private data which belongs to the platform-specific rproc module
>   * @ops: platform-specific start/stop rproc handlers
> + * @sync_ops: platform-specific start/stop rproc handlers when
> + * synchronising with a remote processor.
> + * @sync_flags: Determine the rproc_ops to choose in specific states.
>   * @dev: virtual device for refcounting and common remoteproc behavior
>   * @power: refcount of users who need this rproc powered up
>   * @state: state of the device
> @@ -482,6 +502,7 @@ struct rproc_dump_segment {
>   * @table_sz: size of @cached_table
>   * @has_iommu: flag to indicate if remote processor is behind an MMU
>   * @auto_boot: flag to indicate if remote processor should be auto-started
> + * @sync_with_rproc: true if currently synchronising with the rproc
>   * @dump_segments: list of segments in the firmware
>   * @nb_vdev: number of vdev currently handled by rproc
>   */
> @@ -492,6 +513,8 @@ struct rproc {
>   const char *firmware;
>   void *priv;
>   struct rproc_ops *ops;
> + struct rproc_ops *sync_ops;

Do we really need two rproc_ops, given that both are coming from the
platform driver and the sync_flags will define which one to look at?

Can't the platform driver just provide an ops table that works with the
flags it passes?

Regards,
Bjorn

> + struct rproc_sync_flags sync_flags;
>   struct device dev;
>   atomic_t power;
>   unsigned int state;
> @@ -515,6 +538,7 @@ struct rproc {
>   size_t table_sz;
>   bool has_iommu;
>   bool auto_boot;
> + bool sync_with_rproc;
>   struct list_head dump_segments;
>   int nb_vdev;
>   u8 elf_class;
> -- 
> 2.20.1
> 

Re: [PATCH] drm/bridge: ti-sn65dsi86: Implement lane reordering + polarity

[Doug Anderson]

Hi,

On Tue, May 5, 2020 at 2:24 PM Doug Anderson  wrote:
>
> Hi,
>
> On Tue, May 5, 2020 at 2:14 PM Laurent Pinchart
>  wrote:
> >
> > > I'll add this documentation into the comments of the yaml, but I'm not
> > > going to try to implement enforcement at the yaml level.
> >
> > Why not ? :-)
>
> Because trying to describe anything in the yaml bindings that doesn't
> fit in the exact pattern of things that the yaml bindings are designed
> to check is like constructing the empire state building with only
> toothpicks.
>
> If you want to suggest some syntax that would actually make this
> doable without blowing out the yaml bindings then I'm happy to add it.
> Me being naive would assume that we'd need to do an exhaustive list of
> the OK combinations.  That would be fine for the 1-land and 2-lane
> cases, but for 4 lanes that means adding 256 entries to the bindings.
>
> I think the correct way to do this would require adding code in the
>  project but that's
> really only done for generic subsystem-level concepts and not for a
> single driver.

OK.  Looked at your review of the .yaml and the "uniqueItems" is
probably the bit I didn't think of.  With that I can limit this but
it's still a little awkward.  I still haven't figured out how to force
data-lanes and lane-polarities to have the same number of items, too.
I'll add this as an add-on patch to my v2 and folks can decide if they
like it or hate it.

# See ../../media/video-interface.txt for details.
data-lanes:
  oneOf:
- minItems: 1
  maxItems: 1
  uniqueItems: true
  items:
enum:
  - 0
  - 1
  description:
If you have 1 logical lane it can go to either physical
port 0 or port 1.  Port 0 is suggested.

- minItems: 2
  maxItems: 2
  uniqueItems: true
  items:
enum:
  - 0
  - 1
  description:
If you have 2 logical lanes they can be reordered on
physical ports 0 and 1.

- minItems: 4
  maxItems: 4
  uniqueItems: true
  items:
enum:
  - 0
  - 1
  - 2
  - 3
  description:
If you have 4 logical lanes they can be reordered on
in any way.

-Doug

Re: [PATCH] RISC-V: Remove unused code from STRICT_KERNEL_RWX

[Atish Patra]

On Tue, May 5, 2020 at 5:03 PM Palmer Dabbelt  wrote:
>
> On Tue, 05 May 2020 17:00:05 PDT (-0700), ati...@atishpatra.org wrote:
> > On Tue, May 5, 2020 at 4:55 PM Palmer Dabbelt  wrote:
> >>
> >> On Sun, 03 May 2020 21:03:19 PDT (-0700), Atish Patra wrote:
> >> > This patch removes the unused functions set_kernel_text_rw/ro.
> >> > Currently, it is not being invoked from anywhere and no other 
> >> > architecture
> >> > (except arm) uses this code. Even in ARM, these functions are not invoked
> >> > from anywhere currently.
> >> >
> >> > Fixes: d27c3c90817e ("riscv: add STRICT_KERNEL_RWX support")
> >> >
> >> > Signed-off-by: Atish Patra 
> >> > ---
> >> >  arch/riscv/mm/init.c | 16 
> >> >  1 file changed, 16 deletions(-)
> >> >
> >> > diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
> >> > index b55be44ff9bd..ba60a581e9b6 100644
> >> > --- a/arch/riscv/mm/init.c
> >> > +++ b/arch/riscv/mm/init.c
> >> > @@ -501,22 +501,6 @@ static inline void setup_vm_final(void)
> >> >  #endif /* CONFIG_MMU */
> >> >
> >> >  #ifdef CONFIG_STRICT_KERNEL_RWX
> >> > -void set_kernel_text_rw(void)
> >> > -{
> >> > - unsigned long text_start = (unsigned long)_text;
> >> > - unsigned long text_end = (unsigned long)_etext;
> >> > -
> >> > - set_memory_rw(text_start, (text_end - text_start) >> PAGE_SHIFT);
> >> > -}
> >> > -
> >> > -void set_kernel_text_ro(void)
> >> > -{
> >> > - unsigned long text_start = (unsigned long)_text;
> >> > - unsigned long text_end = (unsigned long)_etext;
> >> > -
> >> > - set_memory_ro(text_start, (text_end - text_start) >> PAGE_SHIFT);
> >> > -}
> >> > -
> >> >  void mark_rodata_ro(void)
> >> >  {
> >> >   unsigned long text_start = (unsigned long)_text;
> >>
> >> Thanks, this is on fixes.  Are you going to remove the ARM code as well?
> >>
> >
> > Yeah and also I realized that I forgot to remove the declarations from
> > the header file.
> > My bad. I will send out a v2. Please drop this one and take v2.
>
> I just fixed it up
>

Thanks. I was going over the code again and found one usage for
set_kernel_text_rw for ARM.
It is used in kexec while set_kernel_text_ro is not invoked anywhere.
I am not sure if it is required
for kexec implementation for RISC-V.

@nick: Can you please comment ?

> commit 73cb8e2a5863ccc5215660f5123db621bd57dff7
> gpg: Signature made Tue 05 May 2020 05:02:17 PM PDT
> gpg:using RSA key 2B3C3747446843B24A943A7A2E1319F35FBB1889
> gpg:issuer "pal...@dabbelt.com"
> gpg: Good signature from "Palmer Dabbelt " [ultimate]
> gpg: aka "Palmer Dabbelt " 
> [ultimate]
> Author: Atish Patra 
> Date:   Sun May 3 21:03:19 2020 -0700
>
> RISC-V: Remove unused code from STRICT_KERNEL_RWX
>
> This patch removes the unused functions set_kernel_text_rw/ro.
> Currently, it is not being invoked from anywhere and no other architecture
> (except arm) uses this code. Even in ARM, these functions are not invoked
> from anywhere currently.
>
> Fixes: d27c3c90817e ("riscv: add STRICT_KERNEL_RWX support")
> Signed-off-by: Atish Patra 
> Reviewed-by: Zong Li 
> Signed-off-by: Palmer Dabbelt 
>
> diff --git a/arch/riscv/include/asm/set_memory.h 
> b/arch/riscv/include/asm/set_memory.h
> index c38df4771c09..4c5bae7ca01c 100644
> --- a/arch/riscv/include/asm/set_memory.h
> +++ b/arch/riscv/include/asm/set_memory.h
> @@ -22,14 +22,6 @@ static inline int set_memory_x(unsigned long addr, int 
> numpages) { return 0; }
>  static inline int set_memory_nx(unsigned long addr, int numpages) { return 
> 0; }
>  #endif
>
> -#ifdef CONFIG_STRICT_KERNEL_RWX
> -void set_kernel_text_ro(void);
> -void set_kernel_text_rw(void);
> -#else
> -static inline void set_kernel_text_ro(void) { }
> -static inline void set_kernel_text_rw(void) { }
> -#endif
> -
>  int set_direct_map_invalid_noflush(struct page *page);
>  int set_direct_map_default_noflush(struct page *page);
>
> diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
> index 5b813532db59..27a334106708 100644
> --- a/arch/riscv/mm/init.c
> +++ b/arch/riscv/mm/init.c
> @@ -502,22 +502,6 @@ static inline void setup_vm_final(void)
>  #endif /* CONFIG_MMU */
>
>  #ifdef CONFIG_STRICT_KERNEL_RWX
> -void set_kernel_text_rw(void)
> -{
> -   unsigned long text_start = (unsigned long)_text;
> -   unsigned long text_end = (unsigned long)_etext;
> -
> -   set_memory_rw(text_start, (text_end - text_start) >> PAGE_SHIFT);
> -}
> -
> -void set_kernel_text_ro(void)
> -{
> -   unsigned long text_start = (unsigned long)_text;
> -   unsigned long text_end = (unsigned long)_etext;
> -
> -   set_memory_ro(text_start, (text_end - text_start) >> PAGE_SHIFT);
> -}
> -
>  void mark_rodata_ro(void)
>  {
> unsigned long text_start = (unsigned long)_text;
>


-- 
Regards,
Atish

[PATCH v2] security: disable FORTIFY_SOURCE on clang

[Jason A. Donenfeld]

clang-10 has a broken optimization stage that doesn't allow the
compiler to prove at compile time that certain memcpys are within
bounds, and thus the outline memcpy is always called, resulting in
horrific performance, and in some cases, excessive stack frame growth.
Here's a simple reproducer:

typedef unsigned long size_t;
void *c(void *dest, const void *src, size_t n) __asm__("memcpy");
extern inline __attribute__((gnu_inline)) void *memcpy(void *dest, const 
void *src, size_t n) { return c(dest, src, n); }
void blah(char *a)
{
  unsigned long long b[10], c[10];
  int i;

  memcpy(b, a, sizeof(b));
  for (i = 0; i < 10; ++i)
c[i] = b[i] ^ b[9 - i];
  for (i = 0; i < 10; ++i)
b[i] = c[i] ^ a[i];
  memcpy(a, b, sizeof(b));
}

Compile this with clang-9 and clang-10 and observe:

zx2c4@thinkpad /tmp/curve25519-hacl64-stack-frame-size-test $ clang-10 
-Wframe-larger-than=0 -O3 -c b.c -o c10.o
b.c:5:6: warning: stack frame size of 104 bytes in function 'blah' 
[-Wframe-larger-than=]
void blah(char *a)
 ^
1 warning generated.
zx2c4@thinkpad /tmp/curve25519-hacl64-stack-frame-size-test $ clang-9 
-Wframe-larger-than=0 -O3 -c b.c -o c9.o

Looking at the disassembly of c10.o and c9.o, one can see that c9.o is
properly optimized in the obvious way one would expect, while c10.o has
blown up and includes extern calls to memcpy.

But actually, for versions of clang earlier than 10, fortify source
mostly does nothing. So, between being broken and doing nothing, it
probably doesn't make sense to pretend to offer this option. So, this
commit just disables it entirely when compiling with clang.

Cc: Arnd Bergmann 
Cc: LKML 
Cc: clang-built-linux 
Cc: Kees Cook 
Cc: George Burgess 
Cc: Nick Desaulniers 
Link: https://bugs.llvm.org/show_bug.cgi?id=45802
Signed-off-by: Jason A. Donenfeld 
---
 security/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/security/Kconfig b/security/Kconfig
index cd3cc7da3a55..76bcfb3eb16f 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -191,6 +191,7 @@ config HARDENED_USERCOPY_PAGESPAN
 config FORTIFY_SOURCE
bool "Harden common str/mem functions against buffer overflows"
depends on ARCH_HAS_FORTIFY_SOURCE
+   depends on !CC_IS_CLANG
help
  Detect overflows of buffers in common string and memory functions
  where the compiler can determine and validate the buffer sizes.
-- 
2.26.2

Re: [f2fs-dev] [PATCH] f2fs: get parent inode when recovering pino

[Gao Xiang]

Hi Eric,

On Tue, May 05, 2020 at 11:19:41AM -0700, Eric Biggers wrote:
> On Tue, May 05, 2020 at 11:13:23AM -0700, Jaegeuk Kim wrote:

...

> >
> > -static int get_parent_ino(struct inode *inode, nid_t *pino)
> > -{
> > -   struct dentry *dentry;
> > -
> > -   inode = igrab(inode);
> > -   dentry = d_find_any_alias(inode);
> > -   iput(inode);
> > -   if (!dentry)
> > -   return 0;
> > -
> > -   *pino = parent_ino(dentry);
> > -   dput(dentry);
> > -   return 1;
> > -}
> > -
> >  static inline enum cp_reason_type need_do_checkpoint(struct inode *inode)
> >  {
> > struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
> > @@ -223,14 +208,15 @@ static bool need_inode_page_update(struct 
> > f2fs_sb_info *sbi, nid_t ino)
> > return ret;
> >  }
> >
> > -static void try_to_fix_pino(struct inode *inode)
> > +static void try_to_fix_pino(struct dentry *dentry)
> >  {
> > +   struct inode *inode = d_inode(dentry);
> > struct f2fs_inode_info *fi = F2FS_I(inode);
> > -   nid_t pino;
> >
> > down_write(>i_sem);
> > -   if (file_wrong_pino(inode) && inode->i_nlink == 1 &&
> > -   get_parent_ino(inode, )) {
> > +   if (file_wrong_pino(inode) && inode->i_nlink == 1) {
> > +   nid_t pino = parent_ino(dentry);
> > +
> > f2fs_i_pino_write(inode, pino);
> > file_got_pino(inode);
> > }
> > @@ -310,7 +296,7 @@ static int f2fs_do_sync_file(struct file *file, loff_t 
> > start, loff_t end,
> >  * We've secured consistency through sync_fs. Following pino
> >  * will be used only for fsynced inodes after checkpoint.
> >  */
> > -   try_to_fix_pino(inode);
> > +   try_to_fix_pino(file_dentry(file));
> > clear_inode_flag(inode, FI_APPEND_WRITE);
> > clear_inode_flag(inode, FI_UPDATE_WRITE);
> > goto out;
>
> Actually, I think this is wrong because the fsync can be done via a file
> descriptor that was opened to a now-deleted link to the file.

I'm still confused about this...

I don't know what's wrong with this version from my limited knowledge?
 inode itself is locked when fsyncing, so

   if the fsync inode->i_nlink == 1, this inode has only one hard link
   (not deleted yet) and should belong to a single directory; and

   the only one parent directory would not go away (not deleted as well)
   since there are some dirents in it (not empty).

Could kindly explain more so I would learn more about this scenario?
Thanks a lot!

>
> We need to find the dentry whose parent directory is still exists, i.e. the
> parent directory that is counting towards 'inode->i_nlink == 1'.

directory counting towards 'inode->i_nlink == 1', what's happening?

>
> I think d_find_alias() is what we're looking for.

It may be simply dentry->d_parent (stable/positive as you said before, and it's
not empty). why need to d_find_alias()?


And what is the original problem? I could not get some clue from the original
patch description (I only saw some extra igrab/iput because of some unknown
reasons), it there some backtrace related to the problem?

Thanks,
Gao Xiang

>
> diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
> index 6ab8f621a3c5..855f27468baa 100644
> --- a/fs/f2fs/file.c
> +++ b/fs/f2fs/file.c
> @@ -165,13 +165,13 @@ static int get_parent_ino(struct inode *inode, nid_t 
> *pino)
>  {
> struct dentry *dentry;
>
> -   inode = igrab(inode);
> -   dentry = d_find_any_alias(inode);
> -   iput(inode);
> +   dentry = d_find_alias(inode);
> if (!dentry)
> return 0;
>
>
>
> ___
> Linux-f2fs-devel mailing list
> linux-f2fs-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

[PATCH v3 1/1] vfio-ccw: Enable transparent CCW IPL from DASD

[Jared Rossi]

Remove the explicit prefetch check when using vfio-ccw devices.
This check does not trigger in practice as all Linux channel programs
are intended to use prefetch.

It is expected that all ORBs issued by Linux will request prefetch.
Although non-prefetching ORBs are not rejected, they will prefetch
nonetheless. A warning is issued up to once per 5 seconds when a
forced prefetch occurs.

A non-prefetch ORB does not necessarily result in an error, however
frequent encounters with non-prefetch ORBs indicate that channel
programs are being executed in a way that is inconsistent with what
the guest is requesting. While there is currently no known case of an
error caused by forced prefetch, it is possible in theory that forced
prefetch could result in an error if applied to a channel program that
is dependent on non-prefetch.

Signed-off-by: Jared Rossi 
---
 Documentation/s390/vfio-ccw.rst |  6 ++
 drivers/s390/cio/vfio_ccw_cp.c  | 19 ---
 2 files changed, 18 insertions(+), 7 deletions(-)

diff --git a/Documentation/s390/vfio-ccw.rst b/Documentation/s390/vfio-ccw.rst
index fca9c4f5bd9c..23e7d136f8b4 100644
--- a/Documentation/s390/vfio-ccw.rst
+++ b/Documentation/s390/vfio-ccw.rst
@@ -335,6 +335,12 @@ device.
 The current code allows the guest to start channel programs via
 START SUBCHANNEL, and to issue HALT SUBCHANNEL and CLEAR SUBCHANNEL.
 
+Currently all channel programs are prefetched, regardless of the
+p-bit setting in the ORB.  As a result, self modifying channel
+programs are not supported.  For this reason, IPL has to be handled as
+a special case by a userspace/guest program; this has been implemented
+in QEMU's s390-ccw bios as of QEMU 4.1.
+
 vfio-ccw supports classic (command mode) channel I/O only. Transport
 mode (HPF) is not supported.
 
diff --git a/drivers/s390/cio/vfio_ccw_cp.c b/drivers/s390/cio/vfio_ccw_cp.c
index 3645d1720c4b..d423ca934779 100644
--- a/drivers/s390/cio/vfio_ccw_cp.c
+++ b/drivers/s390/cio/vfio_ccw_cp.c
@@ -8,6 +8,7 @@
  *Xiao Feng Ren 
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -625,23 +626,27 @@ static int ccwchain_fetch_one(struct ccwchain *chain,
  * the target channel program from @orb->cmd.iova to the new ccwchain(s).
  *
  * Limitations:
- * 1. Supports only prefetch enabled mode.
- * 2. Supports idal(c64) ccw chaining.
- * 3. Supports 4k idaw.
+ * 1. Supports idal(c64) ccw chaining.
+ * 2. Supports 4k idaw.
  *
  * Returns:
  *   %0 on success and a negative error value on failure.
  */
 int cp_init(struct channel_program *cp, struct device *mdev, union orb *orb)
 {
+   static DEFINE_RATELIMIT_STATE(ratelimit_state, 5 * HZ, 1);
int ret;
 
/*
-* XXX:
-* Only support prefetch enable mode now.
+* We only support prefetching the channel program. We assume all 
channel
+* programs executed by supported guests (i.e. Linux) likewise support
+* prefetching. Even if prefetching is not specified the channel program
+* is still executed using prefetch. Executing a channel program that
+* does not specify prefetching will typically not cause an error, but a
+* warning is issued to help identify the problem if something does 
break.
 */
-   if (!orb->cmd.pfch)
-   return -EOPNOTSUPP;
+   if (!orb->cmd.pfch && __ratelimit(_state))
+   dev_warn(mdev, "executing channel program with prefetch, but 
prefetch isn't specified");
 
INIT_LIST_HEAD(>ccwchain_list);
memcpy(>orb, orb, sizeof(*orb));
-- 
2.17.0

[PATCH v3 0/1] vfio-ccw: Enable transparent CCW IPL from DASD

[Jared Rossi]

Remove the explicit prefetch check when using vfio-ccw devices.
This check does not trigger in practice as all Linux channel programs
are intended to use prefetch.

Version 3 improves logging by including the UUID of the vfio device
that triggers the warning.  A custom rate limit is used because
the generic rate limit of 10 per 5 seconds will still result in
multiple warnings during IPL. The warning message has been clarfied
to reflect that a channel program will be executed using prefetch
even though prefetch was not specified.

The text of warning itself does not explicitly refer to non-prefetching
channel programs as unsupported because it will trigger during IPL,
which is a normal and expected sequence.  Likewise, because we expect
the message to appear during IPL, the warning also does not explicitly
alert to the potential of an error, rather it simply notes that a
channel program is being executed in a way other than specified.

Verson 3 also makes some word choice changes to the documentation.

Jared Rossi (1):
  vfio-ccw: Enable transparent CCW IPL from DASD

 Documentation/s390/vfio-ccw.rst |  6 ++
 drivers/s390/cio/vfio_ccw_cp.c  | 19 ---
 2 files changed, 18 insertions(+), 7 deletions(-)

-- 
2.17.0

Re: [PATCH] input: lm8333: update contact email

[Dmitry Torokhov]

On Sat, May 02, 2020 at 04:26:39PM +0200, Wolfram Sang wrote:
> The 'pengutronix' address is defunct for years. Use the proper contact
> address.
> 
> Signed-off-by: Wolfram Sang 

Applied, thank you.

> ---
>  include/linux/input/lm8333.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/linux/input/lm8333.h b/include/linux/input/lm8333.h
> index 79f918c6e8c5..906da5fc06e0 100644
> --- a/include/linux/input/lm8333.h
> +++ b/include/linux/input/lm8333.h
> @@ -1,6 +1,6 @@
>  /*
>   * public include for LM8333 keypad driver - same license as driver
> - * Copyright (C) 2012 Wolfram Sang, Pengutronix 
> + * Copyright (C) 2012 Wolfram Sang, Pengutronix 
>   */
>  
>  #ifndef _LM8333_H
> -- 
> 2.20.1
> 

-- 
Dmitry

Re: [PATCH 1/2] dt-bindings: input: Add Dell Wyse 3020 Power Button binding

[Dmitry Torokhov]

Hi Lubomir,

On Sun, May 03, 2020 at 10:12:36PM +0200, Lubomir Rintel wrote:
> Add binding document for the Dell Wyse 3020 a.k.a. "Ariel" Power Button.
> 
> Signed-off-by: Lubomir Rintel 

Are there any changes compared to the version Rob has acked?

Thanks.

-- 
Dmitry

Re: [net-next PATCH v3 1/5] net: phy: Introduce phy related fwnode functions

[kbuild test robot]

Hi Calvin,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on net-next/master]
[also build test ERROR on linus/master v5.7-rc4 next-20200505]
[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/Calvin-Johnson/Introduce-new-fwnode-based-APIs-to-support-phylink-and-phy-layers/20200506-051400
base:   https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git 
3e1853e4e1137ba0a4d314521d153852dbf4aff5
config: m68k-m5475evb_defconfig (attached as .config)
compiler: m68k-linux-gcc (GCC) 9.3.0
reproduce:
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 GCC_VERSION=9.3.0 make.cross ARCH=m68k 

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

All errors (new ones prefixed by >>):

   m68k-linux-ld: drivers/base/property.o: in function `fwnode_get_phy_node':
>> property.c:(.text+0xd4e): multiple definition of `fwnode_get_phy_node'; 
>> arch/m68k/coldfire/device.o:device.c:(.text+0x0): first defined here

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


.config.gz
Description: application/gzip

[PATCH bpf-next 1/4] bpf, riscv: Enable missing verifier_zext optimizations on RV64

[Luke Nelson]

Commit 66d0d5a854a6 ("riscv: bpf: eliminate zero extension code-gen")
added support for the verifier zero-extension optimization on RV64 and
commit 46dd3d7d287b ("bpf, riscv: Enable zext optimization for more
RV64G ALU ops") enabled it for more instruction cases.

However, BPF_LSH BPF_X and BPF_{LSH,RSH,ARSH} BPF_K are still missing
the optimization.

This patch enables the zero-extension optimization for these remaining
cases.

Co-developed-by: Xi Wang 
Signed-off-by: Xi Wang 
Signed-off-by: Luke Nelson 
---
 arch/riscv/net/bpf_jit_comp64.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/riscv/net/bpf_jit_comp64.c b/arch/riscv/net/bpf_jit_comp64.c
index d208a9fd6c52..e2636902a74e 100644
--- a/arch/riscv/net/bpf_jit_comp64.c
+++ b/arch/riscv/net/bpf_jit_comp64.c
@@ -515,7 +515,7 @@ int bpf_jit_emit_insn(const struct bpf_insn *insn, struct 
rv_jit_context *ctx,
case BPF_ALU | BPF_LSH | BPF_X:
case BPF_ALU64 | BPF_LSH | BPF_X:
emit(is64 ? rv_sll(rd, rd, rs) : rv_sllw(rd, rd, rs), ctx);
-   if (!is64)
+   if (!is64 && !aux->verifier_zext)
emit_zext_32(rd, ctx);
break;
case BPF_ALU | BPF_RSH | BPF_X:
@@ -692,19 +692,19 @@ int bpf_jit_emit_insn(const struct bpf_insn *insn, struct 
rv_jit_context *ctx,
case BPF_ALU | BPF_LSH | BPF_K:
case BPF_ALU64 | BPF_LSH | BPF_K:
emit(is64 ? rv_slli(rd, rd, imm) : rv_slliw(rd, rd, imm), ctx);
-   if (!is64)
+   if (!is64 && !aux->verifier_zext)
emit_zext_32(rd, ctx);
break;
case BPF_ALU | BPF_RSH | BPF_K:
case BPF_ALU64 | BPF_RSH | BPF_K:
emit(is64 ? rv_srli(rd, rd, imm) : rv_srliw(rd, rd, imm), ctx);
-   if (!is64)
+   if (!is64 && !aux->verifier_zext)
emit_zext_32(rd, ctx);
break;
case BPF_ALU | BPF_ARSH | BPF_K:
case BPF_ALU64 | BPF_ARSH | BPF_K:
emit(is64 ? rv_srai(rd, rd, imm) : rv_sraiw(rd, rd, imm), ctx);
-   if (!is64)
+   if (!is64 && !aux->verifier_zext)
emit_zext_32(rd, ctx);
break;
 
-- 
2.17.1

[PATCH bpf-next 3/4] bpf, riscv: Optimize BPF_JMP BPF_K when imm == 0 on RV64

[Luke Nelson]

This patch adds an optimization to BPF_JMP (32- and 64-bit) BPF_K for
when the BPF immediate is zero.

When the immediate is zero, the code can directly use the RISC-V zero
register instead of loading a zero immediate to a temporary register
first.

Co-developed-by: Xi Wang 
Signed-off-by: Xi Wang 
Signed-off-by: Luke Nelson 
---
 arch/riscv/net/bpf_jit_comp64.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/arch/riscv/net/bpf_jit_comp64.c b/arch/riscv/net/bpf_jit_comp64.c
index c3ce9a911b66..b07cef952019 100644
--- a/arch/riscv/net/bpf_jit_comp64.c
+++ b/arch/riscv/net/bpf_jit_comp64.c
@@ -796,7 +796,13 @@ int bpf_jit_emit_insn(const struct bpf_insn *insn, struct 
rv_jit_context *ctx,
case BPF_JMP32 | BPF_JSET | BPF_K:
rvoff = rv_offset(i, off, ctx);
s = ctx->ninsns;
-   emit_imm(RV_REG_T1, imm, ctx);
+   if (imm) {
+   emit_imm(RV_REG_T1, imm, ctx);
+   rs = RV_REG_T1;
+   } else {
+   /* If imm is 0, simply use zero register. */
+   rs = RV_REG_ZERO;
+   }
if (!is64) {
if (is_signed_bpf_cond(BPF_OP(code)))
emit_sext_32_rd(, ctx);
@@ -811,11 +817,10 @@ int bpf_jit_emit_insn(const struct bpf_insn *insn, struct 
rv_jit_context *ctx,
if (BPF_OP(code) == BPF_JSET) {
/* Adjust for and */
rvoff -= 4;
-   emit(rv_and(RV_REG_T1, rd, RV_REG_T1), ctx);
-   emit_branch(BPF_JNE, RV_REG_T1, RV_REG_ZERO, rvoff,
-   ctx);
+   emit(rv_and(rs, rd, rs), ctx);
+   emit_branch(BPF_JNE, rs, RV_REG_ZERO, rvoff, ctx);
} else {
-   emit_branch(BPF_OP(code), rd, RV_REG_T1, rvoff, ctx);
+   emit_branch(BPF_OP(code), rd, rs, rvoff, ctx);
}
break;
 
-- 
2.17.1

[PATCH bpf-next 2/4] bpf, riscv: Optimize FROM_LE using verifier_zext on RV64

[Luke Nelson]

This patch adds two optimizations for BPF_ALU BPF_END BPF_FROM_LE in
the RV64 BPF JIT.

First, it enables the verifier zero-extension optimization to avoid zero
extension when imm == 32. Second, it avoids generating code for imm ==
64, since it is equivalent to a no-op.

Co-developed-by: Xi Wang 
Signed-off-by: Xi Wang 
Signed-off-by: Luke Nelson 
---
 arch/riscv/net/bpf_jit_comp64.c | 20 ++--
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/arch/riscv/net/bpf_jit_comp64.c b/arch/riscv/net/bpf_jit_comp64.c
index e2636902a74e..c3ce9a911b66 100644
--- a/arch/riscv/net/bpf_jit_comp64.c
+++ b/arch/riscv/net/bpf_jit_comp64.c
@@ -542,13 +542,21 @@ int bpf_jit_emit_insn(const struct bpf_insn *insn, struct 
rv_jit_context *ctx,
 
/* dst = BSWAP##imm(dst) */
case BPF_ALU | BPF_END | BPF_FROM_LE:
-   {
-   int shift = 64 - imm;
-
-   emit(rv_slli(rd, rd, shift), ctx);
-   emit(rv_srli(rd, rd, shift), ctx);
+   switch (imm) {
+   case 16:
+   emit(rv_slli(rd, rd, 48), ctx);
+   emit(rv_srli(rd, rd, 48), ctx);
+   break;
+   case 32:
+   if (!aux->verifier_zext)
+   emit_zext_32(rd, ctx);
+   break;
+   case 64:
+   /* Do nothing */
+   break;
+   }
break;
-   }
+
case BPF_ALU | BPF_END | BPF_FROM_BE:
emit(rv_addi(RV_REG_T2, RV_REG_ZERO, 0), ctx);
 
-- 
2.17.1

[PATCH bpf-next 4/4] bpf, riscv: Optimize BPF_JSET BPF_K using andi on RV64

[Luke Nelson]

This patch optimizes BPF_JSET BPF_K by using a RISC-V andi instruction
when the BPF immediate fits in 12 bits, instead of first loading the
immediate to a temporary register.

Examples of generated code with and without this optimization:

BPF_JMP_IMM(BPF_JSET, R1, 2, 1) without optimization:

  20: lit1,2
  24: and   t1,a0,t1
  28: bnez  t1,0x30

BPF_JMP_IMM(BPF_JSET, R1, 2, 1) with optimization:

  20: andi  t1,a0,2
  24: bnez  t1,0x2c

BPF_JMP32_IMM(BPF_JSET, R1, 2, 1) without optimization:

  20: lit1,2
  24: mvt2,a0
  28: slli  t2,t2,0x20
  2c: srli  t2,t2,0x20
  30: slli  t1,t1,0x20
  34: srli  t1,t1,0x20
  38: and   t1,t2,t1
  3c: bnez  t1,0x44

BPF_JMP32_IMM(BPF_JSET, R1, 2, 1) with optimization:

  20: andi  t1,a0,2
  24: bnez  t1,0x2c

In these examples, because the upper 32 bits of the sign-extended
immediate are 0, BPF_JMP BPF_JSET and BPF_JMP32 BPF_JSET are equivalent
and therefore the JIT produces identical code for them.

Co-developed-by: Xi Wang 
Signed-off-by: Xi Wang 
Signed-off-by: Luke Nelson 
---
 arch/riscv/net/bpf_jit_comp64.c | 27 +++
 1 file changed, 19 insertions(+), 8 deletions(-)

diff --git a/arch/riscv/net/bpf_jit_comp64.c b/arch/riscv/net/bpf_jit_comp64.c
index b07cef952019..6cfd164cbe88 100644
--- a/arch/riscv/net/bpf_jit_comp64.c
+++ b/arch/riscv/net/bpf_jit_comp64.c
@@ -792,8 +792,6 @@ int bpf_jit_emit_insn(const struct bpf_insn *insn, struct 
rv_jit_context *ctx,
case BPF_JMP32 | BPF_JSGE | BPF_K:
case BPF_JMP | BPF_JSLE | BPF_K:
case BPF_JMP32 | BPF_JSLE | BPF_K:
-   case BPF_JMP | BPF_JSET | BPF_K:
-   case BPF_JMP32 | BPF_JSET | BPF_K:
rvoff = rv_offset(i, off, ctx);
s = ctx->ninsns;
if (imm) {
@@ -813,15 +811,28 @@ int bpf_jit_emit_insn(const struct bpf_insn *insn, struct 
rv_jit_context *ctx,
 
/* Adjust for extra insns */
rvoff -= (e - s) << 2;
+   emit_branch(BPF_OP(code), rd, rs, rvoff, ctx);
+   break;
 
-   if (BPF_OP(code) == BPF_JSET) {
-   /* Adjust for and */
-   rvoff -= 4;
-   emit(rv_and(rs, rd, rs), ctx);
-   emit_branch(BPF_JNE, rs, RV_REG_ZERO, rvoff, ctx);
+   case BPF_JMP | BPF_JSET | BPF_K:
+   case BPF_JMP32 | BPF_JSET | BPF_K:
+   rvoff = rv_offset(i, off, ctx);
+   s = ctx->ninsns;
+   if (is_12b_int(imm)) {
+   emit(rv_andi(RV_REG_T1, rd, imm), ctx);
} else {
-   emit_branch(BPF_OP(code), rd, rs, rvoff, ctx);
+   emit_imm(RV_REG_T1, imm, ctx);
+   emit(rv_and(RV_REG_T1, rd, RV_REG_T1), ctx);
}
+   /* For jset32, we should clear the upper 32 bits of t1, but
+* sign-extension is sufficient here and saves one instruction,
+* as t1 is used only in comparison against zero.
+*/
+   if (!is64 && imm < 0)
+   emit(rv_addiw(RV_REG_T1, RV_REG_T1, 0), ctx);
+   e = ctx->ninsns;
+   rvoff -= (e - s) << 2;
+   emit_branch(BPF_JNE, RV_REG_T1, RV_REG_ZERO, rvoff, ctx);
break;
 
/* function call */
-- 
2.17.1

Re: [PATCH] RISC-V: Remove unused code from STRICT_KERNEL_RWX

[Palmer Dabbelt]

On Tue, 05 May 2020 17:00:05 PDT (-0700), ati...@atishpatra.org wrote:

On Tue, May 5, 2020 at 4:55 PM Palmer Dabbelt  wrote:


On Sun, 03 May 2020 21:03:19 PDT (-0700), Atish Patra wrote:
> This patch removes the unused functions set_kernel_text_rw/ro.
> Currently, it is not being invoked from anywhere and no other architecture
> (except arm) uses this code. Even in ARM, these functions are not invoked
> from anywhere currently.
>
> Fixes: d27c3c90817e ("riscv: add STRICT_KERNEL_RWX support")
>
> Signed-off-by: Atish Patra 
> ---
>  arch/riscv/mm/init.c | 16 
>  1 file changed, 16 deletions(-)
>
> diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
> index b55be44ff9bd..ba60a581e9b6 100644
> --- a/arch/riscv/mm/init.c
> +++ b/arch/riscv/mm/init.c
> @@ -501,22 +501,6 @@ static inline void setup_vm_final(void)
>  #endif /* CONFIG_MMU */
>
>  #ifdef CONFIG_STRICT_KERNEL_RWX
> -void set_kernel_text_rw(void)
> -{
> - unsigned long text_start = (unsigned long)_text;
> - unsigned long text_end = (unsigned long)_etext;
> -
> - set_memory_rw(text_start, (text_end - text_start) >> PAGE_SHIFT);
> -}
> -
> -void set_kernel_text_ro(void)
> -{
> - unsigned long text_start = (unsigned long)_text;
> - unsigned long text_end = (unsigned long)_etext;
> -
> - set_memory_ro(text_start, (text_end - text_start) >> PAGE_SHIFT);
> -}
> -
>  void mark_rodata_ro(void)
>  {
>   unsigned long text_start = (unsigned long)_text;

Thanks, this is on fixes.  Are you going to remove the ARM code as well?



Yeah and also I realized that I forgot to remove the declarations from
the header file.
My bad. I will send out a v2. Please drop this one and take v2.


I just fixed it up

commit 73cb8e2a5863ccc5215660f5123db621bd57dff7
gpg: Signature made Tue 05 May 2020 05:02:17 PM PDT
gpg:using RSA key 2B3C3747446843B24A943A7A2E1319F35FBB1889
gpg:issuer "pal...@dabbelt.com"
gpg: Good signature from "Palmer Dabbelt " [ultimate]
gpg: aka "Palmer Dabbelt " [ultimate]
Author: Atish Patra 
Date:   Sun May 3 21:03:19 2020 -0700

   RISC-V: Remove unused code from STRICT_KERNEL_RWX
   
   This patch removes the unused functions set_kernel_text_rw/ro.

   Currently, it is not being invoked from anywhere and no other architecture
   (except arm) uses this code. Even in ARM, these functions are not invoked
   from anywhere currently.
   
   Fixes: d27c3c90817e ("riscv: add STRICT_KERNEL_RWX support")

   Signed-off-by: Atish Patra 
   Reviewed-by: Zong Li 
   Signed-off-by: Palmer Dabbelt 

diff --git a/arch/riscv/include/asm/set_memory.h 
b/arch/riscv/include/asm/set_memory.h
index c38df4771c09..4c5bae7ca01c 100644
--- a/arch/riscv/include/asm/set_memory.h
+++ b/arch/riscv/include/asm/set_memory.h
@@ -22,14 +22,6 @@ static inline int set_memory_x(unsigned long addr, int 
numpages) { return 0; }
static inline int set_memory_nx(unsigned long addr, int numpages) { return 0; }
#endif

-#ifdef CONFIG_STRICT_KERNEL_RWX
-void set_kernel_text_ro(void);
-void set_kernel_text_rw(void);
-#else
-static inline void set_kernel_text_ro(void) { }
-static inline void set_kernel_text_rw(void) { }
-#endif
-
int set_direct_map_invalid_noflush(struct page *page);
int set_direct_map_default_noflush(struct page *page);

diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
index 5b813532db59..27a334106708 100644
--- a/arch/riscv/mm/init.c
+++ b/arch/riscv/mm/init.c
@@ -502,22 +502,6 @@ static inline void setup_vm_final(void)
#endif /* CONFIG_MMU */

#ifdef CONFIG_STRICT_KERNEL_RWX
-void set_kernel_text_rw(void)
-{
-   unsigned long text_start = (unsigned long)_text;
-   unsigned long text_end = (unsigned long)_etext;
-
-   set_memory_rw(text_start, (text_end - text_start) >> PAGE_SHIFT);
-}
-
-void set_kernel_text_ro(void)
-{
-   unsigned long text_start = (unsigned long)_text;
-   unsigned long text_end = (unsigned long)_etext;
-
-   set_memory_ro(text_start, (text_end - text_start) >> PAGE_SHIFT);
-}
-
void mark_rodata_ro(void)
{
unsigned long text_start = (unsigned long)_text;

[PATCH bpf-next 0/4] RV64 BPF JIT Optimizations

[Luke Nelson]

This patch series introduces a set of optimizations to the BPF JIT
on RV64. The optimizations are related to the verifier zero-extension
optimization and BPF_JMP BPF_K.

We tested the optimizations on a QEMU riscv64 virt machine, using
lib/test_bpf and test_verifier, and formally verified their correctness
using Serval.

Luke Nelson (4):
  bpf, riscv: Enable missing verifier_zext optimizations on RV64
  bpf, riscv: Optimize FROM_LE using verifier_zext on RV64
  bpf, riscv: Optimize BPF_JMP BPF_K when imm == 0 on RV64
  bpf, riscv: Optimize BPF_JSET BPF_K using andi on RV64

 arch/riscv/net/bpf_jit_comp64.c | 64 ++---
 1 file changed, 44 insertions(+), 20 deletions(-)

Cc: Xi Wang 

-- 
2.17.1

[PATCH] virtio_net: fix lockdep warning on 32 bit

[Michael S. Tsirkin]

When we fill up a receive VQ, try_fill_recv currently tries to count
kicks using a 64 bit stats counter. Turns out, on a 32 bit kernel that
uses a seqcount. sequence counts are "lock" constructs where you need to
make sure that writers are serialized.

In turn, this means that we mustn't run two try_fill_recv concurrently.
Which of course we don't. We do run try_fill_recv sometimes from a fully
preemptible context and sometimes from a softirq (napi) context.

However, when it comes to the seqcount, lockdep is trying to enforce
the rule that the same lock isn't accessed from preemptible
and softirq context. This causes a false-positive warning:

WARNING: inconsistent lock state
...
inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.

As a work around, shut down the warning by switching
to u64_stats_update_begin_irqsave - that works by disabling
interrupts on 32 bit only, is a NOP on 64 bit.

Reported-by: Thomas Gleixner 
Suggested-by: Eric Dumazet 
Signed-off-by: Michael S. Tsirkin 
---

I'm not thrilled about this but this seems the best we can do for now.

Completely untested.


Thomas, can you pls let me know the config I need to trigger the warning
in question?


 drivers/net/virtio_net.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 6594aab4910e..95393b61187f 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -1243,9 +1243,11 @@ static bool try_fill_recv(struct virtnet_info *vi, 
struct receive_queue *rq,
break;
} while (rq->vq->num_free);
if (virtqueue_kick_prepare(rq->vq) && virtqueue_notify(rq->vq)) {
-   u64_stats_update_begin(>stats.syncp);
+   unsigned long flags;
+
+   flags = u64_stats_update_begin_irqsave(>stats.syncp);
rq->stats.kicks++;
-   u64_stats_update_end(>stats.syncp);
+   u64_stats_update_end_irqrestore(>stats.syncp);
}
 
return !oom;
-- 
MST

Re: [PATCH] RISC-V: Remove unused code from STRICT_KERNEL_RWX

[Atish Patra]

On Tue, May 5, 2020 at 4:55 PM Palmer Dabbelt  wrote:
>
> On Sun, 03 May 2020 21:03:19 PDT (-0700), Atish Patra wrote:
> > This patch removes the unused functions set_kernel_text_rw/ro.
> > Currently, it is not being invoked from anywhere and no other architecture
> > (except arm) uses this code. Even in ARM, these functions are not invoked
> > from anywhere currently.
> >
> > Fixes: d27c3c90817e ("riscv: add STRICT_KERNEL_RWX support")
> >
> > Signed-off-by: Atish Patra 
> > ---
> >  arch/riscv/mm/init.c | 16 
> >  1 file changed, 16 deletions(-)
> >
> > diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
> > index b55be44ff9bd..ba60a581e9b6 100644
> > --- a/arch/riscv/mm/init.c
> > +++ b/arch/riscv/mm/init.c
> > @@ -501,22 +501,6 @@ static inline void setup_vm_final(void)
> >  #endif /* CONFIG_MMU */
> >
> >  #ifdef CONFIG_STRICT_KERNEL_RWX
> > -void set_kernel_text_rw(void)
> > -{
> > - unsigned long text_start = (unsigned long)_text;
> > - unsigned long text_end = (unsigned long)_etext;
> > -
> > - set_memory_rw(text_start, (text_end - text_start) >> PAGE_SHIFT);
> > -}
> > -
> > -void set_kernel_text_ro(void)
> > -{
> > - unsigned long text_start = (unsigned long)_text;
> > - unsigned long text_end = (unsigned long)_etext;
> > -
> > - set_memory_ro(text_start, (text_end - text_start) >> PAGE_SHIFT);
> > -}
> > -
> >  void mark_rodata_ro(void)
> >  {
> >   unsigned long text_start = (unsigned long)_text;
>
> Thanks, this is on fixes.  Are you going to remove the ARM code as well?
>

Yeah and also I realized that I forgot to remove the declarations from
the header file.
My bad. I will send out a v2. Please drop this one and take v2.

-- 
Regards,
Atish

Re: [PATCH] Bluetooth: Terminate the link if pairing is cancelled

[Luiz Augusto von Dentz]

Hi Manish, Marcel,

On Tue, Apr 28, 2020 at 2:38 AM Marcel Holtmann  wrote:
>
> Hi Manish,
>
> > If user decides to cancel ongoing pairing process (e.g. by clicking
> > the cancel button on the pairing/passkey window), abort any ongoing
> > pairing and then terminate the link.
> >
> > Signed-off-by: Manish Mandlik 
> > ---
> > Hello Linux-Bluetooth,
> >
> >  This patch aborts any ongoing pairing and then terminates the link
> >  by calling hci_abort_conn() in cancel_pair_device() function.
> >
> >  However, I'm not very sure if hci_abort_conn() should be called here
> >  in cancel_pair_device() or in smp for example to terminate the link
> >  after it had sent the pairing failed PDU.
> >

Id recommend leaving the hci_abort_conn out since that is a policy
decision the userspace should be in charge to decide if the link
should be disconnected or not.

> >  Please share your thoughts on this.
>
> I am look into this. Just bare with me for a bit to verify the call chain.
>
> Regards
>
> Marcel
>


-- 
Luiz Augusto von Dentz

Re: [PATCH] bpf: Tweak BPF jump table optimizations for objtool compatibility

[Alexei Starovoitov]

On Tue, May 05, 2020 at 03:28:23PM -0500, Josh Poimboeuf wrote:
> On Tue, May 05, 2020 at 12:53:20PM -0700, Alexei Starovoitov wrote:
> > On Tue, May 05, 2020 at 01:11:08PM -0500, Josh Poimboeuf wrote:
> > > On Tue, May 05, 2020 at 10:43:00AM -0700, Alexei Starovoitov wrote:
> > > > > Or, if you want to minimize the patch's impact on other arches, and 
> > > > > keep
> > > > > the current patch the way it is (with bug fixed and changed patch
> > > > > description), that's fine too.  I can change the patch description
> > > > > accordingly.
> > > > > 
> > > > > Or if you want me to measure the performance impact of the +40% code
> > > > > growth, and *then* decide what to do, that's also fine.  But you'd 
> > > > > need
> > > > > to tell me what tests to run.
> > > > 
> > > > I'd like to minimize the risk and avoid code churn,
> > > > so how about we step back and debug it first?
> > > > Which version of gcc are you using and what .config?
> > > > I've tried:
> > > > Linux version 5.7.0-rc2 (gcc version 10.0.1 20200505 (prerelease) (GCC)
> > > > CONFIG_UNWINDER_ORC=y
> > > > # CONFIG_RETPOLINE is not set
> > > > 
> > > > and objtool didn't complain.
> > > > I would like to reproduce it first before making any changes.
> > > 
> > > Revert
> > > 
> > >   3193c0836f20 ("bpf: Disable GCC -fgcse optimization for 
> > > ___bpf_prog_run()")
> > > 
> > > and compile with retpolines off (and either ORC or FP, doesn't matter).
> > > 
> > > I'm using GCC 9.3.1:
> > > 
> > >   kernel/bpf/core.o: warning: objtool: ___bpf_prog_run()+0x8dc: sibling 
> > > call from callable instruction with modified stack frame
> > > 
> > > That's the original issue described in that commit.
> > 
> > I see something different.
> > With gcc 8, 9, and 10 and CCONFIG_UNWINDER_FRAME_POINTER=y
> > I see:
> > kernel/bpf/core.o: warning: objtool: ___bpf_prog_run()+0x4837: call without 
> > frame pointer save/setup
> > and sure enough assembly code for ___bpf_prog_run does not countain frame 
> > setup
> > though -fno-omit-frame-pointer flag was passed at command line.
> > Then I did:
> > static u64 /*__no_fgcse*/ ___bpf_prog_run(u64 *regs, const struct bpf_insn 
> > *insn, u64 *stack)
> > and the assembly had proper frame, but objtool wasn't happy:
> > kernel/bpf/core.o: warning: objtool: ___bpf_prog_run()+0x480a: sibling call 
> > from callable instruction with modified stack frame
> > 
> > gcc 6.3 doesn't have objtool warning with and without -fno-gcse.
> > 
> > Looks like we have two issues here.
> > First gcc 8, 9 and 10 have a severe bug with __attribute__((optimize("")))
> > In this particular case passing -fno-gcse somehow overruled 
> > -fno-omit-frame-pointer
> > which is serious issue. powerpc is using __nostackprotector. I don't 
> > understand
> > how it can keep working with newer gcc-s. May be got lucky.
> > Plenty of other projects use various __attribute__((optimize("")))
> > they all have to double check that their vesion of GCC produces correct 
> > code.
> > Can somebody reach out to gcc folks for explanation?
> 
> Right.  I've mentioned this several times now.  That's why my patch
> reverts 3193c0836f20.  I don't see any other way around it.  The GCC
> manual even says this attribute should not be used in production code.

What you mentioned in commit log is:
"It doesn't append options to the command-line arguments.  Instead
it starts from a blank slate.  And according to recent GCC documentation
it's not recommended for production use."

I don't think anyone could have guessed from such description that it kills
-fno-omit-frame-pointer but it doesn't reduce optimization level to -O0
and it doesn't kill -D, -m, -I, -std= and other flags.

As far as workaround I prefer the following:
>From 94bbc27c5a70d78846a5cb675df4cf8732883564 Mon Sep 17 00:00:00 2001
From: Alexei Starovoitov 
Date: Tue, 5 May 2020 16:52:41 -0700
Subject: [PATCH] bpf,objtool: tweak interpreter compilation flags to help 
objtool

tbd

Fixes: 3193c0836f20 ("bpf: Disable GCC -fgcse optimization for 
___bpf_prog_run()")
Reported-by: Randy Dunlap 
Reported-by: Arnd Bergmann 
Signed-off-by: Alexei Starovoitov 
---
 include/linux/compiler-gcc.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
index d7ee4c6bad48..05104c3cc033 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -171,4 +171,4 @@
 #define __diag_GCC_8(s)
 #endif

-#define __no_fgcse __attribute__((optimize("-fno-gcse")))
+#define __no_fgcse 
__attribute__((optimize("-fno-gcse,-fno-omit-frame-pointer")))
--
2.23.0

I've tested it with gcc 8,9,10 and clang 11 with FP=y and with ORC=y.
All works.
I think it's safer to go with frame pointers even for ORC=y considering
all the pain this issue had caused. Even if objtool gets confused again
in the future __bpf_prog_run() will have frame pointers and kernel stack
unwinding can fall back from ORC to FP for that frame.
wdyt?

Re: [GIT PULL] platform-drivers-x86 for 5.7-2

[pr-tracker-bot]

The pull request you sent on Tue, 5 May 2020 20:21:04 +0300:

> git://git.infradead.org/linux-platform-drivers-x86.git 
> tags/platform-drivers-x86-v5.7-2

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/dc56c5acd8505e1e7f776d62650f3850ad2ce8e7

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

Re: [PATCH v3 6/7] misc: bcm-vk: add Broadcom VK driver

[Scott Branden]

All the kbuild and sparse issues should be resolved in PATCH v4.

On 2020-04-22 4:17 a.m., kbuild test robot wrote:

Hi Scott,

I love your patch! Perhaps something to improve:

[auto build test WARNING on driver-core/driver-core-testing]
[also build test WARNING on next-20200421]
[cannot apply to char-misc/char-misc-testing kselftest/next linus/master 
v5.7-rc2]
[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/Scott-Branden/firmware-add-partial-read-support-in-request_firmware_into_buf/20200422-114528
base:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git 
55623260bb33e2ab849af76edf2253bc04cb241f
reproduce:
 # apt-get install sparse
 # sparse version: v0.6.1-191-gc51a0382-dirty
 make ARCH=x86_64 allmodconfig
 make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'

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


sparse warnings: (new ones prefixed by >>)


drivers/misc/bcm-vk/bcm_vk_dev.c:189:15: sparse: sparse: incorrect type in 
assignment (different address spaces) @@expected struct bcm_vk_peer_log 
*p_ctl @@got struct bcm_vk_peer_log *p_ctl @@
drivers/misc/bcm-vk/bcm_vk_dev.c:189:15: sparse:expected struct 
bcm_vk_peer_log *p_ctl
drivers/misc/bcm-vk/bcm_vk_dev.c:189:15: sparse:got void [noderef]  *
drivers/misc/bcm-vk/bcm_vk_dev.c:685:36: sparse: sparse: incorrect type in argument 2 
(different address spaces) @@expected void const [noderef]  *from @@
got oderef]  *from @@
drivers/misc/bcm-vk/bcm_vk_dev.c:685:36: sparse:expected void const [noderef] 
 *from
drivers/misc/bcm-vk/bcm_vk_dev.c:685:36: sparse:got struct vk_image *arg

drivers/misc/bcm-vk/bcm_vk_dev.c:780:36: sparse: sparse: incorrect type in argument 2 
(different address spaces) @@expected void const [noderef]  *from @@
got oderef]  *from @@
drivers/misc/bcm-vk/bcm_vk_dev.c:780:36: sparse:expected void const [noderef] 
 *from

drivers/misc/bcm-vk/bcm_vk_dev.c:780:36: sparse:got struct vk_reset *arg
drivers/misc/bcm-vk/bcm_vk_dev.c:858:45: sparse: sparse: incorrect type in 
argument 2 (different address spaces) @@expected struct vk_image *arg @@
got void [nstruct vk_image *arg @@
drivers/misc/bcm-vk/bcm_vk_dev.c:858:45: sparse:expected struct vk_image 
*arg
drivers/misc/bcm-vk/bcm_vk_dev.c:858:45: sparse:got void [noderef]  
*argp
drivers/misc/bcm-vk/bcm_vk_dev.c:862:40: sparse: sparse: incorrect type in 
argument 2 (different address spaces) @@expected struct vk_reset *arg @@
got void [nstruct vk_reset *arg @@
drivers/misc/bcm-vk/bcm_vk_dev.c:862:40: sparse:expected struct vk_reset 
*arg

drivers/misc/bcm-vk/bcm_vk_dev.c:862:40: sparse:got void [noderef] 
 *argp
--

drivers/misc/bcm-vk/bcm_vk_msg.c:507:17: sparse: sparse: cast removes address space 
'' of expression

drivers/misc/bcm-vk/bcm_vk_msg.c:707:15: sparse: sparse: cast removes address 
space '' of expression
drivers/misc/bcm-vk/bcm_vk_msg.c:715:23: sparse: sparse: cast removes address 
space '' of expression
drivers/misc/bcm-vk/bcm_vk_msg.c:871:31: sparse: sparse: cast removes address 
space '' of expression
drivers/misc/bcm-vk/bcm_vk_msg.c:899:47: sparse: sparse: cast removes address 
space '' of expression

vim +189 drivers/misc/bcm-vk/bcm_vk_dev.c

180 
181 static void bcm_vk_dump_peer_log(struct bcm_vk *vk)
182 {
183 struct bcm_vk_peer_log log, *p_ctl;
184 char loc_buf[BCM_VK_PEER_LOG_LINE_MAX];
185 int cnt;
186 struct device *dev = >pdev->dev;
187 uint data_offset;
188 
  > 189  p_ctl = vk->bar[BAR_2] + vk->peerlog_off;
190 log = *p_ctl;
191 /* do a rmb() to make sure log is updated */
192 rmb();
193 
194 dev_dbg(dev, "Peer PANIC: Size 0x%x(0x%x), [Rd Wr] = [%d %d]\n",
195 log.buf_size, log.mask, log.rd_idx, log.wr_idx);
196 
197 cnt = 0;
198 data_offset = vk->peerlog_off + sizeof(struct bcm_vk_peer_log);
199 while (log.rd_idx != log.wr_idx) {
200 loc_buf[cnt] = vkread8(vk, BAR_2, data_offset + 
log.rd_idx);
201 
202 if ((loc_buf[cnt] == '\0') ||
203 (cnt == (BCM_VK_PEER_LOG_LINE_MAX - 1))) {
204 dev_err(dev, "%s", loc_buf);
205 cnt = 0;
206 } else {
207 cnt++;
208 }
209 log.rd_idx = (log.rd_idx + 1) & log.mask;
210 }
211 /* update rd idx at the end */
212 vkwrite32(vk, log.rd_idx, BAR_2, 

Re: [PATCH] samples: fix binderfs sample

[Masahiro Yamada]

Hi Arnd,


On Wed, Apr 29, 2020 at 6:26 AM Arnd Bergmann  wrote:
>
> A routine check for misspelled Kconfig symbols showed on instance
> from last year, the correct symbol name is CONFIG_ANDROID_BINDERFS,
> not CONFIG_CONFIG_ANDROID_BINDERFS, so the extra prefix must
> be removed in the Kconfig file to allow enabling the sample.
>
> As the actual sample fails to build as a kernel module, change the
> Makefile enough to get to build as a hostprog instead.
>
> Fixes: 9762dc1432e1 ("samples: add binderfs sample program")
> Signed-off-by: Arnd Bergmann 
> ---
>  samples/Kconfig   | 2 +-
>  samples/binderfs/Makefile | 6 +-
>  2 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/samples/Kconfig b/samples/Kconfig
> index 5c31971a5745..e0b747cc90c9 100644
> --- a/samples/Kconfig
> +++ b/samples/Kconfig
> @@ -171,7 +171,7 @@ config SAMPLE_VFIO_MDEV_MBOCHS
>
>  config SAMPLE_ANDROID_BINDERFS
> bool "Build Android binderfs example"
> -   depends on CONFIG_ANDROID_BINDERFS
> +   depends on ANDROID_BINDERFS
> help
>   Builds a sample program to illustrate the use of the Android 
> binderfs
>   filesystem.
> diff --git a/samples/binderfs/Makefile b/samples/binderfs/Makefile
> index ea4c93d36256..a3ac5476338a 100644
> --- a/samples/binderfs/Makefile
> +++ b/samples/binderfs/Makefile
> @@ -1,2 +1,6 @@
>  # SPDX-License-Identifier: GPL-2.0-only
> -obj-$(CONFIG_SAMPLE_ANDROID_BINDERFS) += binderfs_example.o
> +ifndef CROSS_COMPILE
> +ifdef CONFIG_SAMPLE_ANDROID_BINDERFS
> +hostprogs := binderfs_example
> +endif
> +endif
> --
> 2.26.0
>


binderfs_example.c includes .

This uapi header is very new.

include/uapi/linux/android/binderfs.h was added by
commit c13295ad219d8bb0e47942d4cfc8251de449a67e
i.e. Linux  5.0


If this sample is compiled by a compiler with kernel headers
older than Linux 5.0, it will fail to build.


Documentation/process/changes.rst defines the minumal
GCC version, but the minimal kernel header version
is undefined.

Is there any criteria when to add
'-I usr/include' ?


At least, this is this case, I think.

--
Best Regards
Masahiro Yamada

Re: [PATCH] RISC-V: Remove unused code from STRICT_KERNEL_RWX

[Palmer Dabbelt]

On Sun, 03 May 2020 21:03:19 PDT (-0700), Atish Patra wrote:

This patch removes the unused functions set_kernel_text_rw/ro.
Currently, it is not being invoked from anywhere and no other architecture
(except arm) uses this code. Even in ARM, these functions are not invoked
from anywhere currently.

Fixes: d27c3c90817e ("riscv: add STRICT_KERNEL_RWX support")

Signed-off-by: Atish Patra 
---
 arch/riscv/mm/init.c | 16 
 1 file changed, 16 deletions(-)

diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
index b55be44ff9bd..ba60a581e9b6 100644
--- a/arch/riscv/mm/init.c
+++ b/arch/riscv/mm/init.c
@@ -501,22 +501,6 @@ static inline void setup_vm_final(void)
 #endif /* CONFIG_MMU */

 #ifdef CONFIG_STRICT_KERNEL_RWX
-void set_kernel_text_rw(void)
-{
-   unsigned long text_start = (unsigned long)_text;
-   unsigned long text_end = (unsigned long)_etext;
-
-   set_memory_rw(text_start, (text_end - text_start) >> PAGE_SHIFT);
-}
-
-void set_kernel_text_ro(void)
-{
-   unsigned long text_start = (unsigned long)_text;
-   unsigned long text_end = (unsigned long)_etext;
-
-   set_memory_ro(text_start, (text_end - text_start) >> PAGE_SHIFT);
-}
-
 void mark_rodata_ro(void)
 {
unsigned long text_start = (unsigned long)_text;


Thanks, this is on fixes.  Are you going to remove the ARM code as well?

[PATCH][next] rndis_wlan: Remove logically dead code

[Gustavo A. R. Silva]

caps_buf is always of size sizeof(*caps) because
sizeof(caps->auth_encr_pair) * 16 is always zero. Notice
that when using zero-length arrays, sizeof evaluates to zero[1].

So, the code introduced by 
commit 0308383f9591 ("rndis_wlan: get max_num_pmkids from device")
is logically dead, hence is never executed and can be removed. As a
consequence, the rest of the related code can be refactored a bit.

Notice that this code has been out there since March 2010.

[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
Signed-off-by: Gustavo A. R. Silva 
---
In case this is actually a 10-year old bug, then we might want
calculate the size of caps_buf through the use of the struct_size
helper:

struct_size(caps, auth_encr_pair, 16);

and we might also want to allocate dynamic memory instead, as we
cannot do u8 caps_buf[struct_size(caps, auth_encr_pair, 16)];
due to -Wvla.

Thanks
--
Gustavo

 drivers/net/wireless/rndis_wlan.c | 24 
 1 file changed, 8 insertions(+), 16 deletions(-)

diff --git a/drivers/net/wireless/rndis_wlan.c 
b/drivers/net/wireless/rndis_wlan.c
index 52375f3e430a..8852a1832951 100644
--- a/drivers/net/wireless/rndis_wlan.c
+++ b/drivers/net/wireless/rndis_wlan.c
@@ -312,17 +312,11 @@ struct ndis_80211_assoc_info {
__le32 offset_resp_ies;
 } __packed;
 
-struct ndis_80211_auth_encr_pair {
-   __le32 auth_mode;
-   __le32 encr_mode;
-} __packed;
-
 struct ndis_80211_capability {
__le32 length;
__le32 version;
__le32 num_pmkids;
__le32 num_auth_encr_pair;
-   struct ndis_80211_auth_encr_pair auth_encr_pair[0];
 } __packed;
 
 struct ndis_80211_bssid_info {
@@ -3109,8 +3103,7 @@ static int rndis_wlan_get_caps(struct usbnet *usbdev, 
struct wiphy *wiphy)
__le32  num_items;
__le32  items[8];
} networks_supported;
-   struct ndis_80211_capability *caps;
-   u8 caps_buf[sizeof(*caps) + sizeof(caps->auth_encr_pair) * 16];
+   struct ndis_80211_capability caps;
int len, retval, i, n;
struct rndis_wlan_private *priv = get_rndis_wlan_priv(usbdev);
 
@@ -3140,19 +3133,18 @@ static int rndis_wlan_get_caps(struct usbnet *usbdev, 
struct wiphy *wiphy)
}
 
/* get device 802.11 capabilities, number of PMKIDs */
-   caps = (struct ndis_80211_capability *)caps_buf;
-   len = sizeof(caps_buf);
+   len = sizeof(caps);
retval = rndis_query_oid(usbdev,
 RNDIS_OID_802_11_CAPABILITY,
-caps, );
+, );
if (retval >= 0) {
netdev_dbg(usbdev->net, "RNDIS_OID_802_11_CAPABILITY -> len %d, 
"
"ver %d, pmkids %d, auth-encr-pairs %d\n",
-   le32_to_cpu(caps->length),
-   le32_to_cpu(caps->version),
-   le32_to_cpu(caps->num_pmkids),
-   le32_to_cpu(caps->num_auth_encr_pair));
-   wiphy->max_num_pmkids = le32_to_cpu(caps->num_pmkids);
+   le32_to_cpu(caps.length),
+   le32_to_cpu(caps.version),
+   le32_to_cpu(caps.num_pmkids),
+   le32_to_cpu(caps.num_auth_encr_pair));
+   wiphy->max_num_pmkids = le32_to_cpu(caps.num_pmkids);
} else
wiphy->max_num_pmkids = 0;
 
-- 
2.26.2

linux-next: no release today

[Stephen Rothwell]

Normal service should resume tomorrow.

-- 
Cheers,
Stephen Rothwell


pgpacv1ec0XRA.pgp
Description: OpenPGP digital signature

[PATCH] securityfs: Add missing d_delete() call on removal

[Kees Cook]

After using simple_unlink(), a call to d_delete() is needed in addition
to dput().

Signed-off-by: Kees Cook 
---
Is this correct? I went looking around and there are a lot of variations
on the simple_unlink() pattern...

Many using explicit locking and combinations of d_drop(), __d_drop(), etc.


Some missing d_delete()?

security/inode.c:   simple_unlink(dir, dentry);
security/inode.c-   d_delete(dentry);
security/inode.c-   dput(dentry);
--
arch/powerpc/platforms/cell/spufs/inode.c:  
simple_unlink(d_inode(dir), dentry);
arch/powerpc/platforms/cell/spufs/inode.c-  /* XXX: what 
was dcache_lock protecting here? Other
arch/powerpc/platforms/cell/spufs/inode.c-   * filesystems 
(IB, configfs) release dcache_lock
arch/powerpc/platforms/cell/spufs/inode.c-   * before 
unlink */
arch/powerpc/platforms/cell/spufs/inode.c-  dput(dentry);

Should use d_delete() instead of d_drop()?

arch/s390/hypfs/inode.c:simple_unlink(d_inode(parent), 
dentry);
arch/s390/hypfs/inode.c-}
arch/s390/hypfs/inode.c-d_drop(dentry);
arch/s390/hypfs/inode.c-dput(dentry);
arch/s390/hypfs/inode.c-inode_unlock(d_inode(parent));
arch/s390/hypfs/inode.c-}

Correct?

drivers/android/binderfs.c: simple_unlink(parent_inode, dentry);
drivers/android/binderfs.c- d_delete(dentry);
drivers/android/binderfs.c- dput(dentry);
--
fs/nfsd/nfsctl.c:   ret = simple_unlink(dir, dentry);
fs/nfsd/nfsctl.c-   d_delete(dentry);
fs/nfsd/nfsctl.c-   dput(dentry);
--
net/sunrpc/rpc_pipe.c:  ret = simple_unlink(dir, dentry);
net/sunrpc/rpc_pipe.c-  if (!ret)
net/sunrpc/rpc_pipe.c-  fsnotify_unlink(dir, dentry);
net/sunrpc/rpc_pipe.c-  d_delete(dentry);
net/sunrpc/rpc_pipe.c-  dput(dentry);
--
security/apparmor/apparmorfs.c: simple_unlink(dir, dentry);
security/apparmor/apparmorfs.c- d_delete(dentry);
security/apparmor/apparmorfs.c- dput(dentry);

---
 security/inode.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/security/inode.c b/security/inode.c
index 6c326939750d..606f390d21d2 100644
--- a/security/inode.c
+++ b/security/inode.c
@@ -306,6 +306,7 @@ void securityfs_remove(struct dentry *dentry)
simple_rmdir(dir, dentry);
else
simple_unlink(dir, dentry);
+   d_delete(dentry);
dput(dentry);
}
inode_unlock(dir);
-- 
2.20.1


-- 
Kees Cook

Re: [net-next PATCH v3 1/5] net: phy: Introduce phy related fwnode functions

[Russell King - ARM Linux admin]

On Tue, May 05, 2020 at 06:59:01PM +0530, Calvin Johnson wrote:
> +static inline struct phy_device *device_phy_find_device(struct device *dev)
> +{
> + return NULL;
> +}
> +
> +struct fwnode_handle *fwnode_get_phy_node(struct fwnode_handle *fwnode)
> +{
> + return NULL;
> +}

This wants to be "static inline" to avoid the issue the 0-day robot
found.

Thanks.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up

Re: [PATCH] Kbuild: disable FORTIFY_SOURCE on clang-10

[Nick Desaulniers]

On Tue, May 5, 2020 at 4:22 PM Jason A. Donenfeld  wrote:
>
> On Tue, May 5, 2020 at 5:19 PM Kees Cook  wrote:
> >
> > (Though as was mentioned, it's likely that FORTIFY_SOURCE isn't working
> > _at all_ under Clang, so I may still send a patch to depend on !clang
> > just to avoid surprises until it's fixed, but I haven't had time to
> > chase down a solution yet.)

Not good.  If it's completely broken, turn it off, and we'll prioritize fixing.

> That might be the most coherent thing to do, at least so that people
> don't get some false sense of mitigation.

Do we have a better test for "this is working as intended" or not
other than excessive stack usage, since that doesn't repro for
clang-9?
-- 
Thanks,
~Nick Desaulniers

Re: [PATCH] ARM: dts: omap3: Migrate AES from hwmods to sysc-omap2

[Tony Lindgren]

* Adam Ford  [200505 21:18]:
> On Tue, May 5, 2020 at 1:42 PM Tony Lindgren  wrote:
> >
> > * Adam Ford  [200504 16:02]:
> > > Various OMAP3 boards have two AES blocks, but only one is currently
> > > available, because the hwmods are only configured for one.
> > >
> > > This patch migrates the hwmods for the AES engine to sysc-omap2
> > > which allows the second AES crypto engine to become available.
> > >
> > >   omap-aes 480a6000.aes1: OMAP AES hw accel rev: 2.6
> > >   omap-aes 480a6000.aes1: will run requests pump with realtime priority
> > >   omap-aes 480c5000.aes2: OMAP AES hw accel rev: 2.6
> > >   omap-aes 480c5000.aes2: will run requests pump with realtime priority
> >
> > Great :) Looks like I'm getting the following though:
> >
> > DTC arch/arm/boot/dts/am3517-craneboard.dtb
> > arch/arm/boot/dts/omap3.dtsi:160.39-184.5: ERROR (phandle_references):
> > /ocp@6800/target-module@480a6000:
> > Reference to non-existent node or label "aes1_ick"
> >
> > Is this patch maybe missing a change for am3717 for the aes1_ick?
> 
> I am guessing it's the same issue that plagues the am3517 with a note
> in the hwmods that stated noone seems to know which am3517's support
> it and which don't.  The RNG was disabled on the 3517, so I am
> guessing I'll do the same for AES.

OK, I have no idea what modules might be there on am3517.

> I should have posted it as an RFC, because I don't have the proper IRQ
> setup for the newly supported AES engine.  The interrupts that are
> used for the original AES are listed as 'Resereved' in the AM3517 TRM.
> I assume the second engine uses different interrupts.  I don't suppose
> anyone know what it should be?

Sorry no idea, usually the secure accelerator documentation is just
left out it seems. My guess the values are the same as on omap3.

Regards,

Tony

RE: [PATCH v8 1/3] serial: samsung: Replace rd_regb/wr_regb with rd_reg/wr_reg

[Hyunki Koo]

On Tuesday, May 5, 2020 at 2020 11:23:00 PM +0900, Greg Kroah-Hartman wrote:
> On Mon, Apr 20, 2020 at 10:32:56AM +0900, Hyunki Koo wrote:
> > This patch change the name of macro for general usage.
> >
> > Signed-off-by: Hyunki Koo 
> 
> This patch series creates the following build error, which is not
> allowed:
> 
>   CC [M]  drivers/tty/serial/samsung_tty.o
> drivers/tty/serial/samsung_tty.c:186:13: warning: ‘wr_reg_barrier’
> defined but not used [-Wunused-function]
>   186 | static void wr_reg_barrier(struct uart_port *port, u32 reg, u32 val)
>   | ^~
> 
> Please fix up and resend.  Always make sure you keep the reviewed-by
> tags from others as well.
> 
> greg k-h

I tested on latest kernel today one more time, there is no error and warning on 
my side, not only patch 1/3 and patch 3/3
Line 1735:   CC  drivers/tty/serial/samsung_tty.o
Line 343:   CC  drivers/tty/serial/samsung_tty.o

wr_reg_barrier is not defined in patch 1/3, 
and wr_reg_barrier is define and used in patch3/3
it might be no warning.

RE: [PATCH 1/2] riscv: defconfig: enable spi nor on Hifive Unleashed A00 board.

[Palmer Dabbelt]

On Tue, 05 May 2020 00:18:45 PDT (-0700), sagar.ka...@sifive.com wrote:

Hello Palmer,


-Original Message-
From: Palmer Dabbelt 
Sent: Tuesday, May 5, 2020 3:40 AM
To: Sagar Kadam 
Cc: tudor.amba...@microchip.com; miquel.ray...@bootlin.com;
rich...@nod.at; vigne...@ti.com; Paul Walmsley
; linux-ri...@lists.infradead.org; linux-
ker...@vger.kernel.org; linux-...@lists.infradead.org; Sagar Kadam

Subject: Re: [PATCH 1/2] riscv: defconfig: enable spi nor on Hifive Unleashed
A00 board.

[External Email] Do not click links or attachments unless you recognize the
sender and know the content is safe

On Thu, 30 Apr 2020 02:58:51 PDT (-0700), sagar.ka...@sifive.com wrote:
> Enable MTD based SPI-NOR framework in order to use spi flash available
> on HiFive Unleashed A00 board.
>
> Signed-off-by: Sagar Shrikant Kadam 
> ---
>  arch/riscv/configs/defconfig | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/arch/riscv/configs/defconfig
> b/arch/riscv/configs/defconfig index 4da4886..970580b 100644
> --- a/arch/riscv/configs/defconfig
> +++ b/arch/riscv/configs/defconfig
> @@ -80,6 +80,8 @@ CONFIG_USB_STORAGE=y  CONFIG_USB_UAS=y
CONFIG_MMC=y
> CONFIG_MMC_SPI=y
> +CONFIG_MTD=y
> +CONFIG_MTD_SPI_NOR=y
>  CONFIG_RTC_CLASS=y
>  CONFIG_VIRTIO_PCI=y
>  CONFIG_VIRTIO_BALLOON=y

From the second patch's description I'm assuming that MTD still functions
correctly without that change?


Yes Palmer, the second patch is to enable QUAD write to nor flash..
MTD  function's correctly without second patch.

Using the character interface (/dev/mtd0) mtd_utils (mtd_debug : 
erase/read/write) work fine.
We might require CONFIG_MTD_BLOCK, CONFIG_MTD_CMDLINE_PARTS  in order to use 
MTD partitioning.
IMHO it can be at user's choice weather to use flash partitions or not, so I have not enabled. Please let me 
know if I should enable these features as well.


Looks like arm64 has these:

arch/arm64/configs/defconfig:CONFIG_MTD=y
arch/arm64/configs/defconfig:CONFIG_MTD_BLOCK=y
arch/arm64/configs/defconfig:CONFIG_MTD_CFI=y
arch/arm64/configs/defconfig:CONFIG_MTD_CFI_ADV_OPTIONS=y
arch/arm64/configs/defconfig:CONFIG_MTD_CFI_INTELEXT=y
arch/arm64/configs/defconfig:CONFIG_MTD_CFI_AMDSTD=y
arch/arm64/configs/defconfig:CONFIG_MTD_CFI_STAA=y
arch/arm64/configs/defconfig:CONFIG_MTD_PHYSMAP=y
arch/arm64/configs/defconfig:CONFIG_MTD_PHYSMAP_OF=y
arch/arm64/configs/defconfig:CONFIG_MTD_DATAFLASH=y
arch/arm64/configs/defconfig:CONFIG_MTD_SST25L=y
arch/arm64/configs/defconfig:CONFIG_MTD_RAW_NAND=y
arch/arm64/configs/defconfig:CONFIG_MTD_NAND_DENALI_DT=y
arch/arm64/configs/defconfig:CONFIG_MTD_NAND_MARVELL=y
arch/arm64/configs/defconfig:CONFIG_MTD_NAND_FSL_IFC=y
arch/arm64/configs/defconfig:CONFIG_MTD_NAND_QCOM=y
arch/arm64/configs/defconfig:CONFIG_MTD_SPI_NOR=y

so I think we're good with just what you have here: MTD_BLOCK doesn't seem that
useful, and the rest are drivers.  That said, these (along with SPI and
SPI_SIFIVE) should really be in Kconfig.socs rather than defconfig.  Can you
send a patch that does that?



To demonstrate a bit more with linux 5.7-rc3 


Specify on U-boot prompt:
# setenv bootargs "root=/dev/ram rw console=ttySIF0 
mtdparts=spi0.0:1024k(loader1),4096K(loader2),26M(rootfs)"

After booting linux will enumerate mtd partitions:
# cat /proc/mtd
dev:size   erasesize  name
mtd0: 0010 1000 "loader1"
mtd1: 0040 1000 "loader2"
mtd2: 01a0 1000 "rootfs"

# cat /proc/partitions
major minor  #blocks  name
  310   1024 mtdblock0
  311   4096 mtdblock1
  312  26624 mtdblock2

#Format mtdblock2 with mkfs.ext3/4 and mount results in
# mkfs.ext3 /dev/mtdblock2
mke2fs 1.44.5 (15-Dec-2018)
/dev/mtdblock2 contains a ext3 file system
last mounted on /mnt on Thu Jan  1 00:00:14 1970
Proceed anyway? (y,N) y
Creating filesystem with 26624 1k blocks and 6656 inodes
Filesystem UUID: 1b09252d-e313-430c-9ecb-79b0cef003ca
Superblock backups stored on blocks:
8193, 24577

Allocating group tables: done
Writing inode tables: done
Creating journal (1024 blocks): done
Writing superblocks and filesystem accounting information: done

# mount
none on / type rootfs (rw)
proc on /proc type proc (rw,relatime)
devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620,ptmxmode=666)
tmpfs on /dev/shm type tmpfs (rw,relatime,mode=777)
tmpfs on /tmp type tmpfs (rw,relatime)
tmpfs on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755)
sysfs on /sys type sysfs (rw,relatime)
/dev/mtdblock2 on /mnt type ext3 (rw,relatime)

Thanks & BR,
Sagar Kadam

Re: [PATCH] sysctl: Make sure proc handlers can't expose heap memory

[Kees Cook]

On Tue, May 05, 2020 at 10:03:27PM +, Luis Chamberlain wrote:
> On Tue, May 05, 2020 at 01:41:44PM -0700, Kees Cook wrote:
> > Right -- while it'd be nice if the developer noticed it, it is _usually_
> > an unsuspecting end user (or fuzzer), in which case we absolutely want a
> > WARN (and not a BUG![1]) and have the situations handled gracefully, so
> > it can be reported and fixed.
> 
> I've been using WARN*() for this exact purpose before, so I am as
> surprised as you are bout these concerns. However if we have folks

I don't see any mismatch here: it's not user-reachable, which is what
Greg said. WARN is for non-user-reachable "impossible situations". We
want to know if those can be hit (via bad API usage, races, etc). If
it's reachable from userspace, then it can't be a WARN() any more and
needs to be pr_warn().

> shipping with panic-on-warn this would be rather detrimental to our
> goals.
> 
> Greg, are you aware of folks shipping with panic-on-warn on some products?

People shipping with panic_on_warn are expecting to panic for WARNs like
this. :P

-- 
Kees Cook

Re: [PATCH] Kbuild: disable FORTIFY_SOURCE on clang-10

[Jason A. Donenfeld]

On Tue, May 5, 2020 at 5:22 PM Jason A. Donenfeld  wrote:
>
> On Tue, May 5, 2020 at 5:19 PM Kees Cook  wrote:
> >
> > On Tue, May 05, 2020 at 04:37:38PM -0600, Jason A. Donenfeld wrote:
> > > On Tue, May 5, 2020 at 4:25 PM Nathan Chancellor
> > >  wrote:
> > > > I believe these issues are one in the same. I did a reverse bisect with
> > > > Arnd's test case and converged on George's first patch:
> > > >
> > > > https://github.com/llvm/llvm-project/commit/2dd17ff08165e6118e70f00e22b2c36d2d4e0a9a
> > > >
> > > > I think that in lieu of this patch, we should have that patch and its
> > > > follow-up fix merged into 10.0.1.
> > >
> > > If this is fixed in 10.0.1, do we even need to patch the kernel at
> > > all? Or can we just leave it be, considering most organizations using
> > > clang know what they're getting into? I'd personally prefer the
> > > latter, so that we don't clutter things.
> >
> > I agree: I'd rather this was fixed in 10.0.1 (but if we do want a
> > kernel-side work-around for 10.0.0, I would suggest doing the version
> > check in the Kconfig for FORTIFY_SOURCE instead of in the Makefile,
> > as that's where these things are supposed to live these days).
>
> Indeed this belongs in the Makefile. I can send a patch adjusting

er, Kconfig, is what I meant to type.

Re: [PATCH v4 7/8] powerpc/vdso32: implement clock_getres entirely

[Aurelien Jarno]

Hi,

On 2019-12-02 07:57, Christophe Leroy wrote:
> clock_getres returns hrtimer_res for all clocks but coarse ones
> for which it returns KTIME_LOW_RES.
> 
> return EINVAL for unknown clocks.
> 
> Signed-off-by: Christophe Leroy 
> ---
>  arch/powerpc/kernel/asm-offsets.c |  3 +++
>  arch/powerpc/kernel/vdso32/gettimeofday.S | 19 +++
>  2 files changed, 14 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/powerpc/kernel/asm-offsets.c 
> b/arch/powerpc/kernel/asm-offsets.c
> index 0013197d89a6..90e53d432f2e 100644
> --- a/arch/powerpc/kernel/asm-offsets.c
> +++ b/arch/powerpc/kernel/asm-offsets.c
> @@ -413,7 +413,10 @@ int main(void)
>   DEFINE(CLOCK_MONOTONIC, CLOCK_MONOTONIC);
>   DEFINE(CLOCK_REALTIME_COARSE, CLOCK_REALTIME_COARSE);
>   DEFINE(CLOCK_MONOTONIC_COARSE, CLOCK_MONOTONIC_COARSE);
> + DEFINE(CLOCK_MAX, CLOCK_TAI);
>   DEFINE(NSEC_PER_SEC, NSEC_PER_SEC);
> + DEFINE(EINVAL, EINVAL);
> + DEFINE(KTIME_LOW_RES, KTIME_LOW_RES);
>  
>  #ifdef CONFIG_BUG
>   DEFINE(BUG_ENTRY_SIZE, sizeof(struct bug_entry));
> diff --git a/arch/powerpc/kernel/vdso32/gettimeofday.S 
> b/arch/powerpc/kernel/vdso32/gettimeofday.S
> index 9aafacea9c4a..20ae38f3a5a3 100644
> --- a/arch/powerpc/kernel/vdso32/gettimeofday.S
> +++ b/arch/powerpc/kernel/vdso32/gettimeofday.S
> @@ -196,17 +196,20 @@ V_FUNCTION_END(__kernel_clock_gettime)
>  V_FUNCTION_BEGIN(__kernel_clock_getres)
>.cfi_startproc
>   /* Check for supported clock IDs */
> - cmpwi   cr0,r3,CLOCK_REALTIME
> - cmpwi   cr1,r3,CLOCK_MONOTONIC
> - crorcr0*4+eq,cr0*4+eq,cr1*4+eq
> - bne cr0,99f
> + cmplwi  cr0, r3, CLOCK_MAX
> + cmpwi   cr1, r3, CLOCK_REALTIME_COARSE
> + cmpwi   cr7, r3, CLOCK_MONOTONIC_COARSE
> + bgt cr0, 99f
> + LOAD_REG_IMMEDIATE(r5, KTIME_LOW_RES)
> + beq cr1, 1f
> + beq cr7, 1f
>  
>   mflrr12
>.cfi_register lr,r12
>   get_datapager3, r0
>   lwz r5, CLOCK_HRTIMER_RES(r3)
>   mtlrr12
> - li  r3,0
> +1:   li  r3,0
>   cmpli   cr0,r4,0
>   crclr   cr0*4+so
>   beqlr
> @@ -215,11 +218,11 @@ V_FUNCTION_BEGIN(__kernel_clock_getres)
>   blr
>  
>   /*
> -  * syscall fallback
> +  * invalid clock
>*/
>  99:
> - li  r0,__NR_clock_getres
> - sc
> + li  r3, EINVAL
> + crset   so
>   blr
>.cfi_endproc
>  V_FUNCTION_END(__kernel_clock_getres)

Removing the syscall fallback looks wrong, and broke access to
per-processes clocks. With this change a few glibc tests now fail.

This can be reproduced by the simple code below:

| #include 
| #include 
| #include 
| #include 
| #include 
| #include 
| 
| int main()
| {
| struct timespec res;
| clockid_t ci;
| int e;
|
| e = clock_getcpuclockid(getpid(), );
| if (e) {
| printf("clock_getcpuclockid returned %d\n", e);
| return e;
| }
| e = clock_getres (ci, );
| printf("clock_getres returned %d\n", e);
| if (e) {
| printf("  errno: %d, %s\n", errno, strerror(errno));
| }
|
| return e;
| }

Without this patch or with -m64, it returns:

| clock_getres returned 0

With this patch with -m32 it returns:

| clock_getres returned -1
|   errno: 22, Invalid argument

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Re: [PATCH] Kbuild: disable FORTIFY_SOURCE on clang-10

[Jason A. Donenfeld]

On Tue, May 5, 2020 at 5:19 PM Kees Cook  wrote:
>
> On Tue, May 05, 2020 at 04:37:38PM -0600, Jason A. Donenfeld wrote:
> > On Tue, May 5, 2020 at 4:25 PM Nathan Chancellor
> >  wrote:
> > > I believe these issues are one in the same. I did a reverse bisect with
> > > Arnd's test case and converged on George's first patch:
> > >
> > > https://github.com/llvm/llvm-project/commit/2dd17ff08165e6118e70f00e22b2c36d2d4e0a9a
> > >
> > > I think that in lieu of this patch, we should have that patch and its
> > > follow-up fix merged into 10.0.1.
> >
> > If this is fixed in 10.0.1, do we even need to patch the kernel at
> > all? Or can we just leave it be, considering most organizations using
> > clang know what they're getting into? I'd personally prefer the
> > latter, so that we don't clutter things.
>
> I agree: I'd rather this was fixed in 10.0.1 (but if we do want a
> kernel-side work-around for 10.0.0, I would suggest doing the version
> check in the Kconfig for FORTIFY_SOURCE instead of in the Makefile,
> as that's where these things are supposed to live these days).

Indeed this belongs in the Makefile. I can send a patch adjusting
that, if you want, but I think I'd rather do nothing and have a fix be
rolled out in 10.0.1. Clang users should know what to expect in that
regard.

> (Though as was mentioned, it's likely that FORTIFY_SOURCE isn't working
> _at all_ under Clang, so I may still send a patch to depend on !clang
> just to avoid surprises until it's fixed, but I haven't had time to
> chase down a solution yet.)

That might be the most coherent thing to do, at least so that people
don't get some false sense of mitigation.

Jason

Re: [net-next PATCH v3 1/5] net: phy: Introduce phy related fwnode functions

[kbuild test robot]

Hi Calvin,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on net-next/master]
[also build test ERROR on linus/master v5.7-rc4 next-20200505]
[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/Calvin-Johnson/Introduce-new-fwnode-based-APIs-to-support-phylink-and-phy-layers/20200506-051400
base:   https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git 
3e1853e4e1137ba0a4d314521d153852dbf4aff5
config: sh-allnoconfig (attached as .config)
compiler: sh4-linux-gcc (GCC) 9.3.0
reproduce:
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 GCC_VERSION=9.3.0 make.cross ARCH=sh 

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

All errors (new ones prefixed by >>):

   sh4-linux-ld: drivers/base/property.o: in function `fwnode_get_phy_node':
>> property.c:(.text+0xf4): multiple definition of `fwnode_get_phy_node'; 
>> arch/sh/kernel/cpu/sh2/setup-sh7619.o:setup-sh7619.c:(.text+0x0): first 
>> defined here

---
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 v2 0/2] soc: ti: add k3 platforms chipid module driver

[santosh . shilimkar]

On 5/5/20 12:34 PM, Grygorii Strashko wrote:

Hi All,

This series introduces TI K3 Multicore SoC platforms chipid module driver
which provides identification support of the TI K3 SoCs (family, revision)
and register this information with the SoC bus. It is available under
/sys/devices/soc0/ for user space, and can be checked, where needed,
in Kernel using soc_device_match().
It is also required for introducing support for new revisions of
K3 AM65x/J721E SoCs.

Example J721E:
   # cat /sys/devices/soc0/{machine,family,revision}
   Texas Instruments K3 J721E SoC
   J721E
   SR1.0

Example AM65x:
   # cat /sys/devices/soc0/{machine,family,revision}
   Texas Instruments AM654 Base Board
   AM65X
   SR1.0

Changes in v2:
  - pr_debug() replaced with pr_info() to show SoC info on init
  - minor format change
  - split series on driver and platform changes
  - add Reviewed-by: Lokesh Vutla 

v1: https://lwn.net/Articles/818577/

Grygorii Strashko (2):
   dt-bindings: soc: ti: add binding for k3 platforms chipid module
   soc: ti: add k3 platforms chipid module driver


Need ack from DT maintainers on bindings.

Regards,
Santosh

Re: [PATCH] Kbuild: disable FORTIFY_SOURCE on clang-10

[Kees Cook]

On Tue, May 05, 2020 at 04:37:38PM -0600, Jason A. Donenfeld wrote:
> On Tue, May 5, 2020 at 4:25 PM Nathan Chancellor
>  wrote:
> > I believe these issues are one in the same. I did a reverse bisect with
> > Arnd's test case and converged on George's first patch:
> >
> > https://github.com/llvm/llvm-project/commit/2dd17ff08165e6118e70f00e22b2c36d2d4e0a9a
> >
> > I think that in lieu of this patch, we should have that patch and its
> > follow-up fix merged into 10.0.1.
> 
> If this is fixed in 10.0.1, do we even need to patch the kernel at
> all? Or can we just leave it be, considering most organizations using
> clang know what they're getting into? I'd personally prefer the
> latter, so that we don't clutter things.

I agree: I'd rather this was fixed in 10.0.1 (but if we do want a
kernel-side work-around for 10.0.0, I would suggest doing the version
check in the Kconfig for FORTIFY_SOURCE instead of in the Makefile,
as that's where these things are supposed to live these days).

(Though as was mentioned, it's likely that FORTIFY_SOURCE isn't working
_at all_ under Clang, so I may still send a patch to depend on !clang
just to avoid surprises until it's fixed, but I haven't had time to
chase down a solution yet.)

-- 
Kees Cook

Re: [PATCH v2 3/5] pstore/ram: in ramoops_platform_data convert dump_oops to max_reason

[Kees Cook]

On Tue, May 05, 2020 at 11:45:08AM -0400, Pavel Tatashin wrote:
> Now, that pstore_register() can correctly pass max_reason to kmesg dump
> facility, use it instead of dump_oops boolean.
> 
> Replace in ramoops_platform_data dump_oops with max_reason. When dump_oops
> was enabled set max_reason to KMSG_DUMP_OOPS, otherwise set it to
> KMSG_DUMP_PANIC.
> 
> Remove filtering logic from ramoops_pstore_write(), as that is not needed
> anymore, only dmesges specified by max_reason are passed to
> ramoops_pstore_write(). Also, because of this, we can remove
> cxt->dump_oops.

This is all looking good. I think I'd like to see patch 3 and 4 merged,
though. I'd like to make the dump_oops/max_reason conversion in one
patch. Noted below...

> 
> Signed-off-by: Pavel Tatashin 
> ---
>  Documentation/admin-guide/ramoops.rst | 11 ++
>  drivers/platform/chrome/chromeos_pstore.c |  2 +-
>  fs/pstore/ram.c   | 26 +++
>  include/linux/pstore_ram.h|  2 +-
>  4 files changed, 17 insertions(+), 24 deletions(-)
> 
> diff --git a/Documentation/admin-guide/ramoops.rst 
> b/Documentation/admin-guide/ramoops.rst
> index 6dbcc5481000..a296e1aa1617 100644
> --- a/Documentation/admin-guide/ramoops.rst
> +++ b/Documentation/admin-guide/ramoops.rst
> @@ -32,11 +32,14 @@ memory to be mapped strongly ordered, and atomic 
> operations on strongly ordered
>  memory are implementation defined, and won't work on many ARMs such as omaps.
>  
>  The memory area is divided into ``record_size`` chunks (also rounded down to
> -power of two) and each oops/panic writes a ``record_size`` chunk of
> +power of two) and each kmesg dump writes a ``record_size`` chunk of
>  information.
>  
> -Dumping both oopses and panics can be done by setting 1 in the ``dump_oops``
> -variable while setting 0 in that variable dumps only the panics.
> +Dumping reasons can be set via max_reason value, as defined in
> +include/linux/kmsg_dump.h: kmsg_dump_reason. For example, to
> +dump for both oopses and panics reasons, max_reason should be set to 2
> +(KMSG_DUMP_OOPS), to dump panics only max_reason should be set to 1
> +(KMSG_DUMP_PANIC).
>  
>  The module uses a counter to record multiple dumps but the counter gets reset
>  on restart (i.e. new dumps after the restart will overwrite old ones).
> @@ -90,7 +93,7 @@ Setting the ramoops parameters can be done in several 
> different manners:
>  .mem_address= <...>,
>  .mem_type   = <...>,
>  .record_size= <...>,
> -.dump_oops  = <...>,
> +.max_reason = <...>,
>  .ecc= <...>,
>};

Good, yes, dump_oops should be removed from the platform data structure
since that's an entirely internal API.

>  
> diff --git a/drivers/platform/chrome/chromeos_pstore.c 
> b/drivers/platform/chrome/chromeos_pstore.c
> index d13770785fb5..fa51153688b4 100644
> --- a/drivers/platform/chrome/chromeos_pstore.c
> +++ b/drivers/platform/chrome/chromeos_pstore.c
> @@ -57,7 +57,7 @@ static struct ramoops_platform_data chromeos_ramoops_data = 
> {
>   .record_size= 0x4,
>   .console_size   = 0x2,
>   .ftrace_size= 0x2,
> - .dump_oops  = 1,
> + .max_reason = KMSG_DUMP_OOPS,
>  };
>  
>  static struct platform_device chromeos_ramoops = {
> diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
> index 795622190c01..223581aeea96 100644
> --- a/fs/pstore/ram.c
> +++ b/fs/pstore/ram.c
> @@ -81,7 +81,6 @@ struct ramoops_context {
>   size_t console_size;
>   size_t ftrace_size;
>   size_t pmsg_size;
> - int dump_oops;
>   u32 flags;
>   struct persistent_ram_ecc_info ecc_info;
>   unsigned int max_dump_cnt;
> @@ -381,18 +380,6 @@ static int notrace ramoops_pstore_write(struct 
> pstore_record *record)
>   if (record->type != PSTORE_TYPE_DMESG)
>   return -EINVAL;
>  
> - /*
> -  * Out of the various dmesg dump types, ramoops is currently designed
> -  * to only store crash logs, rather than storing general kernel logs.
> -  */
> - if (record->reason != KMSG_DUMP_OOPS &&
> - record->reason != KMSG_DUMP_PANIC)
> - return -EINVAL;
> -
> - /* Skip Oopes when configured to do so. */
> - if (record->reason == KMSG_DUMP_OOPS && !cxt->dump_oops)
> - return -EINVAL;
> -
>   /*
>* Explicitly only take the first part of any new crash.
>* If our buffer is larger than kmsg_bytes, this can never happen,
> @@ -687,7 +674,7 @@ static int ramoops_parse_dt(struct platform_device *pdev,
>   pdata->mem_size = resource_size(res);
>   pdata->mem_address = res->start;
>   pdata->mem_type = of_property_read_bool(of_node, "unbuffered");
> - pdata->dump_oops = !of_property_read_bool(of_node, "no-dump-oops");
> + dump_oops = !of_property_read_bool(of_node, "no-dump-oops");
:
Is this setting the 

Re: x86/uv cleanups

[Thomas Gleixner]

Dimitri Sivanich  writes:
> Yes, we do see a need to clean up old code where it exists, but we would like
> to assume this responsibility ourselves in order to ensure functional 
> continuity
> with externally available open-sourced modules that our customers rely on.  
> This
> code supports current Superdome Flex systems, as well as forthcoming platforms
> based on Intel Cooper Lake and Sapphire Rapids processors.  Some cleanup is
> already being included as part of a forthcoming patchset in support of the
> upcoming Sapphire Rapids platform.

That's a completely bogus argument.

 1) You could have cleaned up that code long ago

 2) The rule for code which is unused in the mainline kernel is that it
can be removed during spring cleaning unless there is a compelling
reason. I can't see one here.

 3) Out of tree modules are not supported independent of the license.
It's not our problem that you have code out of tree which you could
have upstreamed long ago.

Look at the history of platform/uv code. All we see from you guys is:

 - Drops of adding support for new platforms

 - Occasional fixes when we managed to break UV or you found some bug in
   your precious code.

> Nacked-by: Dimitri Sivanich 

I'm happy to add that tag when merging this cleanup.

Thanks,

tglx

Re: [PATCH v4 5/6] media: venus: core: Add support for opp tables/perf voting

[Matthias Kaehlcke]

Hi Rajendra,

On Sun, May 03, 2020 at 05:34:28PM +0530, Rajendra Nayak wrote:
> Add support to add OPP tables and perf voting on the OPP powerdomain.
> This is needed so venus votes on the corresponding performance state
> for the OPP powerdomain along with setting the core clock rate.
> 
> Signed-off-by: Rajendra Nayak 
> Cc: Stanimir Varbanov 
> Cc: linux-me...@vger.kernel.org
> ---
>  drivers/media/platform/qcom/venus/core.c   | 28 +
>  drivers/media/platform/qcom/venus/core.h   |  5 +++
>  drivers/media/platform/qcom/venus/pm_helpers.c | 54 
> --
>  3 files changed, 83 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/media/platform/qcom/venus/core.c 
> b/drivers/media/platform/qcom/venus/core.c
> index 194b10b9..6f72e99 100644
> --- a/drivers/media/platform/qcom/venus/core.c
> +++ b/drivers/media/platform/qcom/venus/core.c
> @@ -12,6 +12,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -214,6 +215,20 @@ static int venus_probe(struct platform_device *pdev)
>   if (!core->pm_ops)
>   return -ENODEV;
>  
> + core->opp_table = dev_pm_opp_set_clkname(dev, "core");
> + if (IS_ERR(core->opp_table))
> + return PTR_ERR(core->opp_table);
> +
> + if (core->res->opp_pmdomain) {
> + ret = dev_pm_opp_of_add_table(dev);
> + if (!ret) {
> + core->has_opp_table = true;
> + } else if (ret != -ENODEV) {
> + dev_err(dev, "invalid OPP table in device tree\n");

dev_pm_opp_put_clkname(core->opp_table);

this and removing the OPP table is also needed in other error paths below,
which currently return directly. Looks like you want to add another label
to the unwind path.

> + return ret;
> + }
> + }
> +
>   if (core->pm_ops->core_get) {
>   ret = core->pm_ops->core_get(dev);
>   if (ret)
> @@ -301,6 +316,9 @@ static int venus_probe(struct platform_device *pdev)
>  err_venus_shutdown:
>   venus_shutdown(core);
>  err_runtime_disable:
> + if (core->has_opp_table)
> + dev_pm_opp_of_remove_table(dev);
> + dev_pm_opp_put_clkname(core->opp_table);

move this after hfi_destroy(core), to do unwinding in reverse order, it
also allows to add the new jump label mentioned above.

>   pm_runtime_set_suspended(dev);
>   pm_runtime_disable(dev);
>   hfi_destroy(core);
> @@ -326,6 +344,10 @@ static int venus_remove(struct platform_device *pdev)
>  
>   venus_firmware_deinit(core);
>  
> + if (core->has_opp_table)
> + dev_pm_opp_of_remove_table(dev);
> + dev_pm_opp_put_clkname(core->opp_table);
> +
>   pm_runtime_put_sync(dev);
>   pm_runtime_disable(dev);
>  
> @@ -350,6 +372,10 @@ static __maybe_unused int venus_runtime_suspend(struct 
> device *dev)
>   if (ret)
>   return ret;
>  
> + /* Drop the performance state vote */
> + if (core->opp_pmdomain)
> + dev_pm_opp_set_rate(dev, 0);
> +
>   if (pm_ops->core_power)
>   ret = pm_ops->core_power(dev, POWER_OFF);
>  
> @@ -511,6 +537,7 @@ static const struct venus_resources sdm845_res_v2 = {
>   .vcodec_clks_num = 2,
>   .vcodec_pmdomains = { "venus", "vcodec0", "vcodec1" },
>   .vcodec_pmdomains_num = 3,
> + .opp_pmdomain = (const char *[]) { "opp-pd", NULL },
>   .vcodec_num = 2,
>   .max_load = 3110400,/* 4096x2160@90 */
>   .hfi_version = HFI_VERSION_4XX,
> @@ -556,6 +583,7 @@ static const struct venus_resources sc7180_res = {
>   .vcodec_clks_num = 2,
>   .vcodec_pmdomains = { "venus", "vcodec0" },
>   .vcodec_pmdomains_num = 2,
> + .opp_pmdomain = (const char *[]) { "opp-pd", NULL },

The new power domain needs to be added to the SDM845 and SC7180 bindings.

>   .vcodec_num = 1,
>   .hfi_version = HFI_VERSION_4XX,
>   .vmem_id = VIDC_RESOURCE_NONE,
> diff --git a/drivers/media/platform/qcom/venus/core.h 
> b/drivers/media/platform/qcom/venus/core.h
> index bd3ac6a..cc1d511 100644
> --- a/drivers/media/platform/qcom/venus/core.h
> +++ b/drivers/media/platform/qcom/venus/core.h
> @@ -62,6 +62,7 @@ struct venus_resources {
>   unsigned int vcodec_clks_num;
>   const char * const vcodec_pmdomains[VIDC_PMDOMAINS_NUM_MAX];
>   unsigned int vcodec_pmdomains_num;
> + const char **opp_pmdomain;
>   unsigned int vcodec_num;
>   enum hfi_version hfi_version;
>   u32 max_load;
> @@ -144,8 +145,12 @@ struct venus_core {
>   struct clk *vcodec1_clks[VIDC_VCODEC_CLKS_NUM_MAX];
>   struct icc_path *video_path;
>   struct icc_path *cpucfg_path;
> + struct opp_table *opp_table;
> + bool has_opp_table;
>   struct device_link *pd_dl_venus;
>   struct device *pmdomains[VIDC_PMDOMAINS_NUM_MAX];
> + struct device_link *opp_dl_venus;
> + struct device *opp_pmdomain;
>   

Re: [f2fs-dev] [PATCH] f2fs: change maximum zstd compression buffer size

[Jaegeuk Kim]

On 05/05, Chao Yu wrote:
> On 2020-5-4 22:30, Jaegeuk Kim wrote:
> > From: Daeho Jeong 
> > 
> > Current zstd compression buffer size is one page and header size less
> > than cluster size. By this, zstd compression always succeeds even if
> > the real compression data is failed to fit into the buffer size, and
> > eventually reading the cluster returns I/O error with the corrupted
> > compression data.
> 
> What's the root cause of this issue? I didn't get it.
> 
> > 
> > Signed-off-by: Daeho Jeong 
> > ---
> >  fs/f2fs/compress.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/fs/f2fs/compress.c b/fs/f2fs/compress.c
> > index 4c7eaeee52336..a9fa8049b295f 100644
> > --- a/fs/f2fs/compress.c
> > +++ b/fs/f2fs/compress.c
> > @@ -313,7 +313,7 @@ static int zstd_init_compress_ctx(struct compress_ctx 
> > *cc)
> > cc->private = workspace;
> > cc->private2 = stream;
> > 
> > -   cc->clen = cc->rlen - PAGE_SIZE - COMPRESS_HEADER_SIZE;
> > +   cc->clen = ZSTD_compressBound(PAGE_SIZE << cc->log_cluster_size);
> 
> In my machine, the value is 66572 which is much larger than size of dst
> buffer, so, in where we can tell the real size of dst buffer to zstd
> compressor? Otherwise, if compressed data size is larger than dst buffer
> size, when we flush compressed data into dst buffer, we may suffer overflow.

Could you give it a try compress_log_size=2 and check decompression works?

> 
> > return 0;
> >  }
> > 
> > @@ -330,7 +330,7 @@ static int zstd_compress_pages(struct compress_ctx *cc)
> > ZSTD_inBuffer inbuf;
> > ZSTD_outBuffer outbuf;
> > int src_size = cc->rlen;
> > -   int dst_size = src_size - PAGE_SIZE - COMPRESS_HEADER_SIZE;
> > +   int dst_size = cc->clen;
> > int ret;
> > 
> > inbuf.pos = 0;
> > 

[RFC PATCH net-next v2 1/3] xfrm: bail early on slave pass over skb

[Jarod Wilson]

This is prep work for initial support of bonding hardware encryption
pass-through support. The bonding driver will fill in the slave_dev
pointer, and we use that to know not to skb_push() again on a given
skb that was already processed on the bond device.

CC: Jay Vosburgh 
CC: Veaceslav Falico 
CC: Andy Gospodarek 
CC: "David S. Miller" 
CC: Jeff Kirsher 
CC: Jakub Kicinski 
CC: Steffen Klassert 
CC: Herbert Xu 
CC: net...@vger.kernel.org
CC: intel-wired-...@lists.osuosl.org
Signed-off-by: Jarod Wilson 
---
 include/net/xfrm.h |  1 +
 net/xfrm/xfrm_device.c | 34 +-
 2 files changed, 18 insertions(+), 17 deletions(-)

diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index 8f71c111e65a..a6ec341cd9f0 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -127,6 +127,7 @@ struct xfrm_state_walk {
 
 struct xfrm_state_offload {
struct net_device   *dev;
+   struct net_device   *slave_dev;
unsigned long   offload_handle;
unsigned intnum_exthdrs;
u8  flags;
diff --git a/net/xfrm/xfrm_device.c b/net/xfrm/xfrm_device.c
index 6cc7f7f1dd68..1cd31dcf59da 100644
--- a/net/xfrm/xfrm_device.c
+++ b/net/xfrm/xfrm_device.c
@@ -108,6 +108,7 @@ struct sk_buff *validate_xmit_xfrm(struct sk_buff *skb, 
netdev_features_t featur
struct sk_buff *skb2, *nskb, *pskb = NULL;
netdev_features_t esp_features = features;
struct xfrm_offload *xo = xfrm_offload(skb);
+   struct net_device *dev = skb->dev;
struct sec_path *sp;
 
if (!xo)
@@ -121,6 +122,10 @@ struct sk_buff *validate_xmit_xfrm(struct sk_buff *skb, 
netdev_features_t featur
if (xo->flags & XFRM_GRO || x->xso.flags & XFRM_OFFLOAD_INBOUND)
return skb;
 
+   /* This skb was already validated on the master dev */
+   if ((x->xso.dev != dev) && (x->xso.slave_dev == dev))
+   return skb;
+
local_irq_save(flags);
sd = this_cpu_ptr(_data);
err = !skb_queue_empty(>xfrm_backlog);
@@ -131,25 +136,20 @@ struct sk_buff *validate_xmit_xfrm(struct sk_buff *skb, 
netdev_features_t featur
return skb;
}
 
-   if (skb_is_gso(skb)) {
-   struct net_device *dev = skb->dev;
-
-   if (unlikely(x->xso.dev != dev)) {
-   struct sk_buff *segs;
+   if (skb_is_gso(skb) && unlikely(x->xso.dev != dev)) {
+   struct sk_buff *segs;
 
-   /* Packet got rerouted, fixup features and segment it. 
*/
-   esp_features = esp_features & ~(NETIF_F_HW_ESP
-   | NETIF_F_GSO_ESP);
+   /* Packet got rerouted, fixup features and segment it. */
+   esp_features = esp_features & ~(NETIF_F_HW_ESP | 
NETIF_F_GSO_ESP);
 
-   segs = skb_gso_segment(skb, esp_features);
-   if (IS_ERR(segs)) {
-   kfree_skb(skb);
-   atomic_long_inc(>tx_dropped);
-   return NULL;
-   } else {
-   consume_skb(skb);
-   skb = segs;
-   }
+   segs = skb_gso_segment(skb, esp_features);
+   if (IS_ERR(segs)) {
+   kfree_skb(skb);
+   atomic_long_inc(>tx_dropped);
+   return NULL;
+   } else {
+   consume_skb(skb);
+   skb = segs;
}
}
 
-- 
2.20.1

[RFC PATCH net-next v2 2/3] ixgbe_ipsec: become aware of when running as a bonding slave

[Jarod Wilson]

Slave devices in a bond doing hardware encryption also need to be aware
that they're slaves, so we operate on the slave instead of the bonding
master to do the actual hardware encryption offload bits.

CC: Jay Vosburgh 
CC: Veaceslav Falico 
CC: Andy Gospodarek 
CC: "David S. Miller" 
CC: Jeff Kirsher 
CC: Jakub Kicinski 
CC: Steffen Klassert 
CC: Herbert Xu 
CC: net...@vger.kernel.org
CC: intel-wired-...@lists.osuosl.org
Signed-off-by: Jarod Wilson 
---
 .../net/ethernet/intel/ixgbe/ixgbe_ipsec.c| 39 +++
 1 file changed, 31 insertions(+), 8 deletions(-)

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c 
b/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
index 113f6087c7c9..26b0a58a064d 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
@@ -432,6 +432,9 @@ static int ixgbe_ipsec_parse_proto_keys(struct xfrm_state 
*xs,
char *alg_name = NULL;
int key_len;
 
+   if (xs->xso.slave_dev)
+   dev = xs->xso.slave_dev;
+
if (!xs->aead) {
netdev_err(dev, "Unsupported IPsec algorithm\n");
return -EINVAL;
@@ -478,8 +481,8 @@ static int ixgbe_ipsec_parse_proto_keys(struct xfrm_state 
*xs,
 static int ixgbe_ipsec_check_mgmt_ip(struct xfrm_state *xs)
 {
struct net_device *dev = xs->xso.dev;
-   struct ixgbe_adapter *adapter = netdev_priv(dev);
-   struct ixgbe_hw *hw = >hw;
+   struct ixgbe_adapter *adapter;
+   struct ixgbe_hw *hw;
u32 mfval, manc, reg;
int num_filters = 4;
bool manc_ipv4;
@@ -497,6 +500,12 @@ static int ixgbe_ipsec_check_mgmt_ip(struct xfrm_state *xs)
 #define BMCIP_V6 0x3
 #define BMCIP_MASK   0x3
 
+   if (xs->xso.slave_dev)
+   dev = xs->xso.slave_dev;
+
+   adapter = netdev_priv(dev);
+   hw = >hw;
+
manc = IXGBE_READ_REG(hw, IXGBE_MANC);
manc_ipv4 = !!(manc & MANC_EN_IPV4_FILTER);
mfval = IXGBE_READ_REG(hw, IXGBE_MFVAL);
@@ -561,14 +570,21 @@ static int ixgbe_ipsec_check_mgmt_ip(struct xfrm_state 
*xs)
 static int ixgbe_ipsec_add_sa(struct xfrm_state *xs)
 {
struct net_device *dev = xs->xso.dev;
-   struct ixgbe_adapter *adapter = netdev_priv(dev);
-   struct ixgbe_ipsec *ipsec = adapter->ipsec;
-   struct ixgbe_hw *hw = >hw;
+   struct ixgbe_adapter *adapter;
+   struct ixgbe_ipsec *ipsec;
+   struct ixgbe_hw *hw;
int checked, match, first;
u16 sa_idx;
int ret;
int i;
 
+   if (xs->xso.slave_dev)
+   dev = xs->xso.slave_dev;
+
+   adapter = netdev_priv(dev);
+   ipsec = adapter->ipsec;
+   hw = >hw;
+
if (xs->id.proto != IPPROTO_ESP && xs->id.proto != IPPROTO_AH) {
netdev_err(dev, "Unsupported protocol 0x%04x for ipsec 
offload\n",
   xs->id.proto);
@@ -746,12 +762,19 @@ static int ixgbe_ipsec_add_sa(struct xfrm_state *xs)
 static void ixgbe_ipsec_del_sa(struct xfrm_state *xs)
 {
struct net_device *dev = xs->xso.dev;
-   struct ixgbe_adapter *adapter = netdev_priv(dev);
-   struct ixgbe_ipsec *ipsec = adapter->ipsec;
-   struct ixgbe_hw *hw = >hw;
+   struct ixgbe_adapter *adapter;
+   struct ixgbe_ipsec *ipsec;
+   struct ixgbe_hw *hw;
u32 zerobuf[4] = {0, 0, 0, 0};
u16 sa_idx;
 
+   if (xs->xso.slave_dev)
+   dev = xs->xso.slave_dev;
+
+   adapter = netdev_priv(dev);
+   ipsec = adapter->ipsec;
+   hw = >hw;
+
if (xs->xso.flags & XFRM_OFFLOAD_INBOUND) {
struct rx_sa *rsa;
u8 ipi;
-- 
2.20.1

[RFC PATCH net-next v2 3/3] bonding: support hardware encryption offload to slaves

[Jarod Wilson]

Currently, this support is limited to active-backup mode, as I'm not sure
about the feasilibity of mapping an xfrm_state's offload handle to
multiple hardware devices simultaneously, and we rely on being able to
pass some hints to both the xfrm and NIC driver about whether or not
they're operating on a slave device.

I've tested this atop an Intel x520 device (ixgbe) using libreswan in
transport mode, succesfully achieving ~4.3Gbps throughput with netperf
(more or less identical to throughput on a bare NIC in this system),
as well as successful failover and recovery mid-netperf.

v2: rebase on latest net-next and wrap with #ifdef CONFIG_XFRM_OFFLOAD

CC: Jay Vosburgh 
CC: Veaceslav Falico 
CC: Andy Gospodarek 
CC: "David S. Miller" 
CC: Jeff Kirsher 
CC: Jakub Kicinski 
CC: Steffen Klassert 
CC: Herbert Xu 
CC: net...@vger.kernel.org
CC: intel-wired-...@lists.osuosl.org
Signed-off-by: Jarod Wilson 

Signed-off-by: Jarod Wilson 
---
 drivers/net/bonding/bond_main.c | 111 +++-
 include/net/bonding.h   |   3 +
 2 files changed, 111 insertions(+), 3 deletions(-)

diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index baa93191dfdd..b90a86029df5 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -79,6 +79,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -278,8 +279,6 @@ const char *bond_mode_name(int mode)
return names[mode];
 }
 
-/*-- VLAN ---*/
-
 /**
  * bond_dev_queue_xmit - Prepare skb for xmit.
  *
@@ -302,6 +301,8 @@ void bond_dev_queue_xmit(struct bonding *bond, struct 
sk_buff *skb,
dev_queue_xmit(skb);
 }
 
+/*-- VLAN ---*/
+
 /* In the following 2 functions, bond_vlan_rx_add_vid and 
bond_vlan_rx_kill_vid,
  * We don't protect the slave list iteration with a lock because:
  * a. This operation is performed in IOCTL context,
@@ -372,6 +373,84 @@ static int bond_vlan_rx_kill_vid(struct net_device 
*bond_dev,
return 0;
 }
 
+/*-- XFRM ---*/
+
+#ifdef CONFIG_XFRM_OFFLOAD
+/**
+ * bond_ipsec_add_sa - program device with a security association
+ * @xs: pointer to transformer state struct
+ **/
+static int bond_ipsec_add_sa(struct xfrm_state *xs)
+{
+   struct net_device *bond_dev = xs->xso.dev;
+   struct bonding *bond = netdev_priv(bond_dev);
+   struct slave *slave = rtnl_dereference(bond->curr_active_slave);
+
+   xs->xso.slave_dev = slave->dev;
+   bond->xs = xs;
+
+   if (!(slave->dev->xfrmdev_ops
+ && slave->dev->xfrmdev_ops->xdo_dev_state_add)) {
+   slave_warn(bond_dev, slave->dev, "Slave does not support ipsec 
offload\n");
+   return -EINVAL;
+   }
+
+   return slave->dev->xfrmdev_ops->xdo_dev_state_add(xs);
+}
+
+/**
+ * bond_ipsec_del_sa - clear out this specific SA
+ * @xs: pointer to transformer state struct
+ **/
+static void bond_ipsec_del_sa(struct xfrm_state *xs)
+{
+   struct net_device *bond_dev = xs->xso.dev;
+   struct bonding *bond = netdev_priv(bond_dev);
+   struct slave *slave = rtnl_dereference(bond->curr_active_slave);
+
+   if (!slave)
+   return;
+
+   xs->xso.slave_dev = slave->dev;
+
+   if (!(slave->dev->xfrmdev_ops
+ && slave->dev->xfrmdev_ops->xdo_dev_state_delete)) {
+   slave_warn(bond_dev, slave->dev, "%s: no slave 
xdo_dev_state_delete\n", __func__);
+   return;
+   }
+
+   slave->dev->xfrmdev_ops->xdo_dev_state_delete(xs);
+}
+
+/**
+ * bond_ipsec_offload_ok - can this packet use the xfrm hw offload
+ * @skb: current data packet
+ * @xs: pointer to transformer state struct
+ **/
+static bool bond_ipsec_offload_ok(struct sk_buff *skb, struct xfrm_state *xs)
+{
+   struct net_device *bond_dev = xs->xso.dev;
+   struct bonding *bond = netdev_priv(bond_dev);
+   struct slave *curr_active = rtnl_dereference(bond->curr_active_slave);
+   struct net_device *slave_dev = curr_active->dev;
+
+   if (!(slave_dev->xfrmdev_ops
+ && slave_dev->xfrmdev_ops->xdo_dev_offload_ok)) {
+   slave_warn(bond_dev, slave_dev, "%s: no slave 
xdo_dev_offload_ok\n", __func__);
+   return false;
+   }
+
+   xs->xso.slave_dev = slave_dev;
+   return slave_dev->xfrmdev_ops->xdo_dev_offload_ok(skb, xs);
+}
+
+static const struct xfrmdev_ops bond_xfrmdev_ops = {
+   .xdo_dev_state_add = bond_ipsec_add_sa,
+   .xdo_dev_state_delete = bond_ipsec_del_sa,
+   .xdo_dev_offload_ok = bond_ipsec_offload_ok,
+};
+#endif /* CONFIG_XFRM_OFFLOAD */
+
 /*--- Link status ---*/
 
 /* Set the carrier state for the master according to the state of its
@@ -878,6 +957,11 @@ void 

[RFC PATCH net-next v2 0/3] bonding: support hardware crypto offload

[Jarod Wilson]

This is an initial "proof of concept" functional implementation for doing
pass-through of hardware encryption from bonding device to capable slaves.
This was tested using an ixgbe-driven Intel x520 NIC with libreswan and a
transport mode connection, on top of an active-backup bond, using netperf
and downing an interface during. Failover takes a moment, but does work,
and overall performance is right on par with offload when running on a
bare interface.

Caveats: this is ONLY enabled for active-backup, because I'm not sure
how one would manage multiple offload handles for different devices all
running at the same time in the same xfrm, and it relies on some minor
changes to both the xfrm code and slave device driver code to get things
to behave, and I don't have immediate access to any other hardware that
could function similarly to update driver code accordingly.

I'm hoping folks with more of an idea about xfrm have some thoughts on
ways to make this cleaner, and possibly support more bonding modes, but
I'm reasonably happy I've made it this far. :)

v2: fix build with CONFIG_XFRM_OFFLOAD disabled and rebase on latest
net-next tree bonding changes

CC: Jay Vosburgh 
CC: Veaceslav Falico 
CC: Andy Gospodarek 
CC: "David S. Miller" 
CC: Jeff Kirsher 
CC: Jakub Kicinski 
CC: Steffen Klassert 
CC: Herbert Xu 
CC: net...@vger.kernel.org
CC: intel-wired-...@lists.osuosl.org

Jarod Wilson (3):
  xfrm: bail early on slave pass over skb
  ixgbe_ipsec: become aware of when running as a bonding slave
  bonding: support hardware encryption offload to slaves

 drivers/net/bonding/bond_main.c   | 111 +-
 .../net/ethernet/intel/ixgbe/ixgbe_ipsec.c|  39 --
 include/net/bonding.h |   3 +
 include/net/xfrm.h|   1 +
 net/xfrm/xfrm_device.c|  34 +++---
 5 files changed, 160 insertions(+), 28 deletions(-)

-- 
2.20.1

Re: [PATCH v8 04/18] KVM: SVM: Add support for KVM_SEV_RECEIVE_START command

[Venu Busireddy]

On 2020-05-05 21:15:40 +, Ashish Kalra wrote:
> From: Brijesh Singh 
> 
> The command is used to create the encryption context for an incoming
> SEV guest. The encryption context can be later used by the hypervisor
> to import the incoming data into the SEV guest memory space.
> 
> Cc: Thomas Gleixner 
> Cc: Ingo Molnar 
> Cc: "H. Peter Anvin" 
> Cc: Paolo Bonzini 
> Cc: "Radim Krčmář" 
> Cc: Joerg Roedel 
> Cc: Borislav Petkov 
> Cc: Tom Lendacky 
> Cc: x...@kernel.org
> Cc: k...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Reviewed-by: Steve Rutherford 
> Signed-off-by: Brijesh Singh 
> Signed-off-by: Ashish Kalra 

Reviewed-by: Venu Busireddy 

> ---
>  .../virt/kvm/amd-memory-encryption.rst| 29 +++
>  arch/x86/kvm/svm/sev.c| 81 +++
>  include/uapi/linux/kvm.h  |  9 +++
>  3 files changed, 119 insertions(+)
> 
> diff --git a/Documentation/virt/kvm/amd-memory-encryption.rst 
> b/Documentation/virt/kvm/amd-memory-encryption.rst
> index 93884ec8918e..337bf6a8a3ee 100644
> --- a/Documentation/virt/kvm/amd-memory-encryption.rst
> +++ b/Documentation/virt/kvm/amd-memory-encryption.rst
> @@ -322,6 +322,35 @@ issued by the hypervisor to delete the encryption 
> context.
>  
>  Returns: 0 on success, -negative on error
>  
> +13. KVM_SEV_RECEIVE_START
> +
> +
> +The KVM_SEV_RECEIVE_START command is used for creating the memory encryption
> +context for an incoming SEV guest. To create the encryption context, the 
> user must
> +provide a guest policy, the platform public Diffie-Hellman (PDH) key and 
> session
> +information.
> +
> +Parameters: struct  kvm_sev_receive_start (in/out)
> +
> +Returns: 0 on success, -negative on error
> +
> +::
> +
> +struct kvm_sev_receive_start {
> +__u32 handle;   /* if zero then firmware creates a 
> new handle */
> +__u32 policy;   /* guest's policy */
> +
> +__u64 pdh_uaddr;/* userspace address pointing to the 
> PDH key */
> +__u32 pdh_len;
> +
> +__u64 session_uaddr;/* userspace address which points to 
> the guest session information */
> +__u32 session_len;
> +};
> +
> +On success, the 'handle' field contains a new handle and on error, a 
> negative value.
> +
> +For more details, see SEV spec Section 6.12.
> +
>  References
>  ==
>  
> diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
> index 4d3031c9fdcf..b575aa8e27af 100644
> --- a/arch/x86/kvm/svm/sev.c
> +++ b/arch/x86/kvm/svm/sev.c
> @@ -1173,6 +1173,84 @@ static int sev_send_finish(struct kvm *kvm, struct 
> kvm_sev_cmd *argp)
>   return ret;
>  }
>  
> +static int sev_receive_start(struct kvm *kvm, struct kvm_sev_cmd *argp)
> +{
> + struct kvm_sev_info *sev = _kvm_svm(kvm)->sev_info;
> + struct sev_data_receive_start *start;
> + struct kvm_sev_receive_start params;
> + int *error = >error;
> + void *session_data;
> + void *pdh_data;
> + int ret;
> +
> + if (!sev_guest(kvm))
> + return -ENOTTY;
> +
> + /* Get parameter from the userspace */
> + if (copy_from_user(, (void __user *)(uintptr_t)argp->data,
> + sizeof(struct kvm_sev_receive_start)))
> + return -EFAULT;
> +
> + /* some sanity checks */
> + if (!params.pdh_uaddr || !params.pdh_len ||
> + !params.session_uaddr || !params.session_len)
> + return -EINVAL;
> +
> + pdh_data = psp_copy_user_blob(params.pdh_uaddr, params.pdh_len);
> + if (IS_ERR(pdh_data))
> + return PTR_ERR(pdh_data);
> +
> + session_data = psp_copy_user_blob(params.session_uaddr,
> + params.session_len);
> + if (IS_ERR(session_data)) {
> + ret = PTR_ERR(session_data);
> + goto e_free_pdh;
> + }
> +
> + ret = -ENOMEM;
> + start = kzalloc(sizeof(*start), GFP_KERNEL);
> + if (!start)
> + goto e_free_session;
> +
> + start->handle = params.handle;
> + start->policy = params.policy;
> + start->pdh_cert_address = __psp_pa(pdh_data);
> + start->pdh_cert_len = params.pdh_len;
> + start->session_address = __psp_pa(session_data);
> + start->session_len = params.session_len;
> +
> + /* create memory encryption context */
> + ret = __sev_issue_cmd(argp->sev_fd, SEV_CMD_RECEIVE_START, start,
> + error);
> + if (ret)
> + goto e_free;
> +
> + /* Bind ASID to this guest */
> + ret = sev_bind_asid(kvm, start->handle, error);
> + if (ret)
> + goto e_free;
> +
> + params.handle = start->handle;
> + if (copy_to_user((void __user *)(uintptr_t)argp->data,
> +  , sizeof(struct kvm_sev_receive_start))) {
> + ret = -EFAULT;
> + sev_unbind_asid(kvm, start->handle);
> + goto e_free;
> 

Re: [PATCH v12 2/2] media: v4l: xilinx: Add Xilinx MIPI CSI-2 Rx Subsystem driver

[Laurent Pinchart]

Hi Vishal,

Thank you for the patch.

On Thu, Apr 23, 2020 at 09:00:38PM +0530, Vishal Sagar wrote:
> The Xilinx MIPI CSI-2 Rx Subsystem soft IP is used to capture images
> from MIPI CSI-2 camera sensors and output AXI4-Stream video data ready
> for image processing. Please refer to PG232 for details.
> 
> The CSI2 Rx controller filters out all packets except for the packets
> with data type fixed in hardware. RAW8 packets are always allowed to
> pass through.
> 
> It is also used to setup and handle interrupts and enable the core. It
> logs all the events in respective counters between streaming on and off.
> 
> The driver supports only the video format bridge enabled configuration.
> Some data types like YUV 422 10bpc, RAW16, RAW20 are supported when the
> CSI v2.0 feature is enabled in design. When the VCX feature is enabled,
> the maximum number of virtual channels becomes 16 from 4.
> 
> Signed-off-by: Vishal Sagar 
> Reviewed-by: Hyun Kwon 
> ---
> v12
> - Changes done as suggested by Laurent Pinchart and Luca Ceresoli
> - Removed unused macros
> - No local storage of supported formats
> - Dropped init mbus fmts and removed xcsi2rxss_init_mbus_fmts()
> - XCSI_GET_BITSET_STR removed
> - Add data type and mbus LUT
>   - Added xcsi2rxss_get_nth_mbus() and xcsi2rxss_get_dt()
> - Replaced all core->dev with dev in dev_dbg() and related debug prints
> - Replaced xcsi2rxss_log_ipconfig() with single line
> - Removed small functions to enable/disable interrupts and core
> - Now save remote subdev in state struct before streaming on
> - Made xcsi2rxss_reset as soft_reset()
> - Added hard reset using video-reset gpio
>   - 2 modes one with delay and another sleep
> - Instead of reset-gpios it is not video-reset-gpios
> - In irq handler
>   - Moved clearing of ISR up
>   - Dump / empty short packet fifo
>   - Irq handler is now threaded 
> - Added init_cfg pad ops and removed open()
> - Updated xcsi2rxss_set_format(), xcsi2rxss_enum_mbus_code() to use the dt 
> mbus lut
> - xcsi2rxss_set_default_format() updated
> - Moved mutex_init()
> - Updated graph handling
> - Removed unnecessary prints
> - Use devm_platform_ioremap_resource() and platform_get_irq()
> - Update KConfig description
> 
> v11
> - Fixed changes as suggested by Sakari Ailus
> - Removed VIDEO_XILINX from KConfig
> - Minor formatting
> - Start / Stop upstream sub-device in xcsi2rxss_start_stream()
>   and xcsi2rxss_stop_stream()
> - Added v4l2_subdev_link_validate_default() in v4l2_subdev_pad_ops()
> - Use fwnode_graph_get_endpoint_by_id() instead of parsing by self
> - Set bus type as V4L2_MBUS_CSI2_DPHY in struct v4l2_fwnode_endpoint
> - Remove num_clks from core. Instead use ARRAY_SIZE()
> - Fixed SPDX header to GPL-2.0
> - Update copyright year to 2020
> 
> v10
> - Removed all V4L2 controls and events based on Sakari's comments.
> - Now stop_stream() before toggling rst_gpio
> - Updated init_mbus() to throw error on array out of bound access
> - Make events and vcx_events as counters instead of structures
> - Minor fixes in set_format() enum_mbus_code() as suggested by Sakari
> 
> v9
> - Moved all controls and events to xilinx-csi2rxss.h
> - Updated name and description of controls and events
> - Get control base address from v4l2-controls.h (0x10c0)
> - Fix KConfig for dependency on VIDEO_XILINX
> - Added enum_mbus_code() support
> - Added default format to be returned on open()
> - Mark variables are const
> - Remove references to short packet in comments
> - Add check for streaming before setting active lanes control
> - strlcpy -> strscpy
> - Fix xcsi2rxss_set_format()
> 
> v8
> - Use clk_bulk* APIs
> - Add gpio reset for asserting video_aresetn when stream line buffer occurs
> - Removed short packet related events and irq handling
>   - V4L2_EVENT_XLNXCSIRX_SPKT and V4L2_EVENT_XLNXCSIRX_SPKT_OVF removed
> - Removed frame counter control V4L2_CID_XILINX_MIPICSISS_FRAME_COUNTER
>   and xcsi2rxss_g_volatile_ctrl()
> - Minor formatting fixes
> 
> v7
> - No change
> 
> v6
> - No change
> 
> v5
> - Removed bayer and updated related parts like set default format based
>   on Luca Cersoli's comments.
> - Added correct YUV422 10bpc media bus format
> 
> v4
> - Removed irq member from core structure
> - Consolidated IP config prints in xcsi2rxss_log_ipconfig()
> - Return -EINVAL in case of invalid ioctl
> - Code formatting
> - Added reviewed by Hyun Kwon
> 
> v3
> - Fixed comments given by Hyun.
> - Removed DPHY 200 MHz clock. This will be controlled by DPHY driver
> - Minor code formatting
> - en_csi_v20 and vfb members removed from struct and made local to dt parsing
> - lock description updated
> - changed to ratelimited type for all dev prints in irq handler
> - Removed YUV 422 10bpc media format
> 
> v2
> - Fixed comments given by Hyun and Sakari.
> - Made all bitmask using BIT() and GENMASK()
> - Removed unused definitions
> - Removed DPHY access. This will be done by separate DPHY PHY driver.
> - Added support for CSI v2.0 for YUV 422 

Re: [PATCH v8 02/18] KVM: SVM: Add KVM_SEND_UPDATE_DATA command

[Venu Busireddy]

On 2020-05-05 21:14:54 +, Ashish Kalra wrote:
> From: Brijesh Singh 
> 
> The command is used for encrypting the guest memory region using the 
> encryption
> context created with KVM_SEV_SEND_START.
> 
> Cc: Thomas Gleixner 
> Cc: Ingo Molnar 
> Cc: "H. Peter Anvin" 
> Cc: Paolo Bonzini 
> Cc: "Radim Krčmář" 
> Cc: Joerg Roedel 
> Cc: Borislav Petkov 
> Cc: Tom Lendacky 
> Cc: x...@kernel.org
> Cc: k...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Reviewed-by : Steve Rutherford 
> Signed-off-by: Brijesh Singh 
> Signed-off-by: Ashish Kalra 

Reviewed-by: Venu Busireddy 

> ---
>  .../virt/kvm/amd-memory-encryption.rst|  24 
>  arch/x86/kvm/svm/sev.c| 135 +-
>  include/uapi/linux/kvm.h  |   9 ++
>  3 files changed, 164 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/virt/kvm/amd-memory-encryption.rst 
> b/Documentation/virt/kvm/amd-memory-encryption.rst
> index 59cb59bd4675..d0dfa5b54e4f 100644
> --- a/Documentation/virt/kvm/amd-memory-encryption.rst
> +++ b/Documentation/virt/kvm/amd-memory-encryption.rst
> @@ -290,6 +290,30 @@ Returns: 0 on success, -negative on error
>  __u32 session_len;
>  };
>  
> +11. KVM_SEV_SEND_UPDATE_DATA
> +
> +
> +The KVM_SEV_SEND_UPDATE_DATA command can be used by the hypervisor to 
> encrypt the
> +outgoing guest memory region with the encryption context creating using
> +KVM_SEV_SEND_START.
> +
> +Parameters (in): struct kvm_sev_send_update_data
> +
> +Returns: 0 on success, -negative on error
> +
> +::
> +
> +struct kvm_sev_launch_send_update_data {
> +__u64 hdr_uaddr;/* userspace address containing the 
> packet header */
> +__u32 hdr_len;
> +
> +__u64 guest_uaddr;  /* the source memory region to be 
> encrypted */
> +__u32 guest_len;
> +
> +__u64 trans_uaddr;  /* the destition memory region  */
> +__u32 trans_len;
> +};
> +
>  References
>  ==
>  
> diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
> index 5a15b43b4349..7031b660f64d 100644
> --- a/arch/x86/kvm/svm/sev.c
> +++ b/arch/x86/kvm/svm/sev.c
> @@ -23,6 +23,7 @@ static DECLARE_RWSEM(sev_deactivate_lock);
>  static DEFINE_MUTEX(sev_bitmap_lock);
>  unsigned int max_sev_asid;
>  static unsigned int min_sev_asid;
> +static unsigned long sev_me_mask;
>  static unsigned long *sev_asid_bitmap;
>  static unsigned long *sev_reclaim_asid_bitmap;
>  #define __sme_page_pa(x) __sme_set(page_to_pfn(x) << PAGE_SHIFT)
> @@ -1035,6 +1036,123 @@ static int sev_send_start(struct kvm *kvm, struct 
> kvm_sev_cmd *argp)
>   return ret;
>  }
>  
> +/* Userspace wants to query either header or trans length. */
> +static int
> +__sev_send_update_data_query_lengths(struct kvm *kvm, struct kvm_sev_cmd 
> *argp,
> +  struct kvm_sev_send_update_data *params)
> +{
> + struct kvm_sev_info *sev = _kvm_svm(kvm)->sev_info;
> + struct sev_data_send_update_data *data;
> + int ret;
> +
> + data = kzalloc(sizeof(*data), GFP_KERNEL_ACCOUNT);
> + if (!data)
> + return -ENOMEM;
> +
> + data->handle = sev->handle;
> + ret = sev_issue_cmd(kvm, SEV_CMD_SEND_UPDATE_DATA, data, >error);
> +
> + params->hdr_len = data->hdr_len;
> + params->trans_len = data->trans_len;
> +
> + if (copy_to_user((void __user *)(uintptr_t)argp->data, params,
> +  sizeof(struct kvm_sev_send_update_data)))
> + ret = -EFAULT;
> +
> + kfree(data);
> + return ret;
> +}
> +
> +static int sev_send_update_data(struct kvm *kvm, struct kvm_sev_cmd *argp)
> +{
> + struct kvm_sev_info *sev = _kvm_svm(kvm)->sev_info;
> + struct sev_data_send_update_data *data;
> + struct kvm_sev_send_update_data params;
> + void *hdr, *trans_data;
> + struct page **guest_page;
> + unsigned long n;
> + int ret, offset;
> +
> + if (!sev_guest(kvm))
> + return -ENOTTY;
> +
> + if (copy_from_user(, (void __user *)(uintptr_t)argp->data,
> + sizeof(struct kvm_sev_send_update_data)))
> + return -EFAULT;
> +
> + /* userspace wants to query either header or trans length */
> + if (!params.trans_len || !params.hdr_len)
> + return __sev_send_update_data_query_lengths(kvm, argp, );
> +
> + if (!params.trans_uaddr || !params.guest_uaddr ||
> + !params.guest_len || !params.hdr_uaddr)
> + return -EINVAL;
> +
> + /* Check if we are crossing the page boundary */
> + offset = params.guest_uaddr & (PAGE_SIZE - 1);
> + if ((params.guest_len + offset > PAGE_SIZE))
> + return -EINVAL;
> +
> + /* Pin guest memory */
> + guest_page = sev_pin_memory(kvm, params.guest_uaddr & PAGE_MASK,
> + PAGE_SIZE, , 0);
> + if (!guest_page)

Re: [PATCH v8 03/18] KVM: SVM: Add KVM_SEV_SEND_FINISH command

[Venu Busireddy]

On 2020-05-05 21:15:11 +, Ashish Kalra wrote:
> From: Brijesh Singh 
> 
> The command is used to finailize the encryption context created with
> KVM_SEV_SEND_START command.
> 
> Cc: Thomas Gleixner 
> Cc: Ingo Molnar 
> Cc: "H. Peter Anvin" 
> Cc: Paolo Bonzini 
> Cc: "Radim Krčmář" 
> Cc: Joerg Roedel 
> Cc: Borislav Petkov 
> Cc: Tom Lendacky 
> Cc: x...@kernel.org
> Cc: k...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Reviewed-by: Steve Rutherford 
> Signed-off-by: Brijesh Singh 
> Signed-off-by: Ashish Kalra 

Reviewed-by: Venu Busireddy 

> ---
>  .../virt/kvm/amd-memory-encryption.rst|  8 +++
>  arch/x86/kvm/svm/sev.c| 23 +++
>  2 files changed, 31 insertions(+)
> 
> diff --git a/Documentation/virt/kvm/amd-memory-encryption.rst 
> b/Documentation/virt/kvm/amd-memory-encryption.rst
> index d0dfa5b54e4f..93884ec8918e 100644
> --- a/Documentation/virt/kvm/amd-memory-encryption.rst
> +++ b/Documentation/virt/kvm/amd-memory-encryption.rst
> @@ -314,6 +314,14 @@ Returns: 0 on success, -negative on error
>  __u32 trans_len;
>  };
>  
> +12. KVM_SEV_SEND_FINISH
> +
> +
> +After completion of the migration flow, the KVM_SEV_SEND_FINISH command can 
> be
> +issued by the hypervisor to delete the encryption context.
> +
> +Returns: 0 on success, -negative on error
> +
>  References
>  ==
>  
> diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
> index 7031b660f64d..4d3031c9fdcf 100644
> --- a/arch/x86/kvm/svm/sev.c
> +++ b/arch/x86/kvm/svm/sev.c
> @@ -1153,6 +1153,26 @@ static int sev_send_update_data(struct kvm *kvm, 
> struct kvm_sev_cmd *argp)
>   return ret;
>  }
>  
> +static int sev_send_finish(struct kvm *kvm, struct kvm_sev_cmd *argp)
> +{
> + struct kvm_sev_info *sev = _kvm_svm(kvm)->sev_info;
> + struct sev_data_send_finish *data;
> + int ret;
> +
> + if (!sev_guest(kvm))
> + return -ENOTTY;
> +
> + data = kzalloc(sizeof(*data), GFP_KERNEL);
> + if (!data)
> + return -ENOMEM;
> +
> + data->handle = sev->handle;
> + ret = sev_issue_cmd(kvm, SEV_CMD_SEND_FINISH, data, >error);
> +
> + kfree(data);
> + return ret;
> +}
> +
>  int svm_mem_enc_op(struct kvm *kvm, void __user *argp)
>  {
>   struct kvm_sev_cmd sev_cmd;
> @@ -1203,6 +1223,9 @@ int svm_mem_enc_op(struct kvm *kvm, void __user *argp)
>   case KVM_SEV_SEND_UPDATE_DATA:
>   r = sev_send_update_data(kvm, _cmd);
>   break;
> + case KVM_SEV_SEND_FINISH:
> + r = sev_send_finish(kvm, _cmd);
> + break;
>   default:
>   r = -EINVAL;
>   goto out;
> -- 
> 2.17.1
> 

[PATCH v6 2/8] bus: mhi: core: Cache intmod from mhi event to mhi channel

[Bhaumik Bhatt]

From: Hemant Kumar 

Driver is using zero initialized intmod value from mhi channel when
configuring TRE for bei field. This prevents interrupt moderation to
take effect in case it is supported by an event ring. Fix this by
copying intmod value from associated event ring to mhi channel upon
registering mhi controller.

Signed-off-by: Hemant Kumar 
Signed-off-by: Bhaumik Bhatt 
Reviewed-by: Jeffrey Hugo 
---
 drivers/bus/mhi/core/init.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/bus/mhi/core/init.c b/drivers/bus/mhi/core/init.c
index eb2ab05..1a93d24 100644
--- a/drivers/bus/mhi/core/init.c
+++ b/drivers/bus/mhi/core/init.c
@@ -863,6 +863,10 @@ int mhi_register_controller(struct mhi_controller 
*mhi_cntrl,
mutex_init(_chan->mutex);
init_completion(_chan->completion);
rwlock_init(_chan->lock);
+
+   /* used in setting bei field of TRE */
+   mhi_event = _cntrl->mhi_event[mhi_chan->er_index];
+   mhi_chan->intmod = mhi_event->intmod;
}
 
if (mhi_cntrl->bounce_buf) {
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v6 3/8] bus: mhi: core: Add range check for channel id received in event ring

[Bhaumik Bhatt]

From: Hemant Kumar 

MHI data completion handler function reads channel id from event
ring element. Value is under the control of MHI devices and can be
any value between 0 and 255. In order to prevent out of bound access
add a bound check against the max channel supported by controller
and skip processing of that event ring element.

Signed-off-by: Hemant Kumar 
Signed-off-by: Bhaumik Bhatt 
Reviewed-by: Jeffrey Hugo 
---
 drivers/bus/mhi/core/main.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c
index 605640c..e60ab21 100644
--- a/drivers/bus/mhi/core/main.c
+++ b/drivers/bus/mhi/core/main.c
@@ -776,6 +776,9 @@ int mhi_process_ctrl_ev_ring(struct mhi_controller 
*mhi_cntrl,
case MHI_PKT_TYPE_TX_EVENT:
chan = MHI_TRE_GET_EV_CHID(local_rp);
mhi_chan = _cntrl->mhi_chan[chan];
+   if (WARN_ON(chan >= mhi_cntrl->max_chan))
+   goto next_event;
+
parse_xfer_event(mhi_cntrl, local_rp, mhi_chan);
event_quota--;
break;
@@ -784,6 +787,7 @@ int mhi_process_ctrl_ev_ring(struct mhi_controller 
*mhi_cntrl,
break;
}
 
+next_event:
mhi_recycle_ev_ring_element(mhi_cntrl, ev_ring);
local_rp = ev_ring->rp;
dev_rp = mhi_to_virtual(ev_ring, er_ctxt->rp);
@@ -820,6 +824,9 @@ int mhi_process_data_event_ring(struct mhi_controller 
*mhi_cntrl,
enum mhi_pkt_type type = MHI_TRE_GET_EV_TYPE(local_rp);
 
chan = MHI_TRE_GET_EV_CHID(local_rp);
+   if (WARN_ON(chan >= mhi_cntrl->max_chan))
+   goto next_event;
+
mhi_chan = _cntrl->mhi_chan[chan];
 
if (likely(type == MHI_PKT_TYPE_TX_EVENT)) {
@@ -830,6 +837,7 @@ int mhi_process_data_event_ring(struct mhi_controller 
*mhi_cntrl,
event_quota--;
}
 
+next_event:
mhi_recycle_ev_ring_element(mhi_cntrl, ev_ring);
local_rp = ev_ring->rp;
dev_rp = mhi_to_virtual(ev_ring, er_ctxt->rp);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v6 7/8] bus: mhi: core: Improve debug logs for loading firmware

[Bhaumik Bhatt]

Add log messages to track boot flow errors and timeouts in SBL or AMSS
firmware loading to aid in debug.

Signed-off-by: Bhaumik Bhatt 
Reviewed-by: Jeffrey Hugo 
---
 drivers/bus/mhi/core/boot.c | 21 ++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/drivers/bus/mhi/core/boot.c b/drivers/bus/mhi/core/boot.c
index 05627fe..e5fcde1 100644
--- a/drivers/bus/mhi/core/boot.c
+++ b/drivers/bus/mhi/core/boot.c
@@ -121,7 +121,8 @@ static int __mhi_download_rddm_in_panic(struct 
mhi_controller *mhi_cntrl)
ee = mhi_get_exec_env(mhi_cntrl);
}
 
-   dev_dbg(dev, "Waiting for image download completion, current EE: %s\n",
+   dev_dbg(dev,
+   "Waiting for RDDM image download via BHIe, current EE:%s\n",
TO_MHI_EXEC_STR(ee));
 
while (retry--) {
@@ -152,11 +153,14 @@ static int __mhi_download_rddm_in_panic(struct 
mhi_controller *mhi_cntrl)
 int mhi_download_rddm_img(struct mhi_controller *mhi_cntrl, bool in_panic)
 {
void __iomem *base = mhi_cntrl->bhie;
+   struct device *dev = _cntrl->mhi_dev->dev;
u32 rx_status;
 
if (in_panic)
return __mhi_download_rddm_in_panic(mhi_cntrl);
 
+   dev_dbg(dev, "Waiting for RDDM image download via BHIe\n");
+
/* Wait for the image download to complete */
wait_event_timeout(mhi_cntrl->state_event,
   mhi_read_reg_field(mhi_cntrl, base,
@@ -174,6 +178,7 @@ static int mhi_fw_load_amss(struct mhi_controller 
*mhi_cntrl,
const struct mhi_buf *mhi_buf)
 {
void __iomem *base = mhi_cntrl->bhie;
+   struct device *dev = _cntrl->mhi_dev->dev;
rwlock_t *pm_lock = _cntrl->pm_lock;
u32 tx_status, sequence_id;
int ret;
@@ -184,6 +189,7 @@ static int mhi_fw_load_amss(struct mhi_controller 
*mhi_cntrl,
return -EIO;
}
 
+   dev_dbg(dev, "Starting AMSS download via BHIe\n");
mhi_write_reg(mhi_cntrl, base, BHIE_TXVECADDR_HIGH_OFFS,
  upper_32_bits(mhi_buf->dma_addr));
 
@@ -435,7 +441,12 @@ void mhi_fw_load_handler(struct mhi_controller *mhi_cntrl)
release_firmware(firmware);
 
/* Error or in EDL mode, we're done */
-   if (ret || mhi_cntrl->ee == MHI_EE_EDL)
+   if (ret) {
+   dev_err(dev, "MHI did not load SBL, ret:%d\n", ret);
+   return;
+   }
+
+   if (mhi_cntrl->ee == MHI_EE_EDL)
return;
 
write_lock_irq(_cntrl->pm_lock);
@@ -463,8 +474,10 @@ void mhi_fw_load_handler(struct mhi_controller *mhi_cntrl)
if (!mhi_cntrl->fbc_download)
return;
 
-   if (ret)
+   if (ret) {
+   dev_err(dev, "MHI did not enter READY state\n");
goto error_read;
+   }
 
/* Wait for the SBL event */
ret = wait_event_timeout(mhi_cntrl->state_event,
@@ -482,6 +495,8 @@ void mhi_fw_load_handler(struct mhi_controller *mhi_cntrl)
ret = mhi_fw_load_amss(mhi_cntrl,
   /* Vector table is the last entry */
   _info->mhi_buf[image_info->entries - 1]);
+   if (ret)
+   dev_err(dev, "MHI did not load AMSS, ret:%d\n", ret);
 
release_firmware(firmware);
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v6 8/8] bus: mhi: core: Ensure non-zero session or sequence ID values are used

[Bhaumik Bhatt]

While writing any sequence or session identifiers, it is possible that
the host could write a zero value, whereas only non-zero values should
be supported writes to those registers. Ensure that the host does not
write a non-zero value for them and also log them in debug messages.

Signed-off-by: Bhaumik Bhatt 
---
 drivers/bus/mhi/core/boot.c | 15 +++
 drivers/bus/mhi/core/internal.h |  1 +
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/bus/mhi/core/boot.c b/drivers/bus/mhi/core/boot.c
index e5fcde1..7b9b561 100644
--- a/drivers/bus/mhi/core/boot.c
+++ b/drivers/bus/mhi/core/boot.c
@@ -43,10 +43,7 @@ void mhi_rddm_prepare(struct mhi_controller *mhi_cntrl,
  lower_32_bits(mhi_buf->dma_addr));
 
mhi_write_reg(mhi_cntrl, base, BHIE_RXVECSIZE_OFFS, mhi_buf->len);
-   sequence_id = prandom_u32() & BHIE_RXVECSTATUS_SEQNUM_BMSK;
-
-   if (unlikely(!sequence_id))
-   sequence_id = 1;
+   sequence_id = MHI_RANDOM_U32_NONZERO(BHIE_RXVECSTATUS_SEQNUM_BMSK);
 
mhi_write_reg_field(mhi_cntrl, base, BHIE_RXVECDB_OFFS,
BHIE_RXVECDB_SEQNUM_BMSK, BHIE_RXVECDB_SEQNUM_SHFT,
@@ -189,7 +186,9 @@ static int mhi_fw_load_amss(struct mhi_controller 
*mhi_cntrl,
return -EIO;
}
 
-   dev_dbg(dev, "Starting AMSS download via BHIe\n");
+   sequence_id = MHI_RANDOM_U32_NONZERO(BHIE_TXVECSTATUS_SEQNUM_BMSK);
+   dev_dbg(dev, "Starting AMSS download via BHIe. Sequence ID:%u\n",
+   sequence_id);
mhi_write_reg(mhi_cntrl, base, BHIE_TXVECADDR_HIGH_OFFS,
  upper_32_bits(mhi_buf->dma_addr));
 
@@ -198,7 +197,6 @@ static int mhi_fw_load_amss(struct mhi_controller 
*mhi_cntrl,
 
mhi_write_reg(mhi_cntrl, base, BHIE_TXVECSIZE_OFFS, mhi_buf->len);
 
-   sequence_id = prandom_u32() & BHIE_TXVECSTATUS_SEQNUM_BMSK;
mhi_write_reg_field(mhi_cntrl, base, BHIE_TXVECDB_OFFS,
BHIE_TXVECDB_SEQNUM_BMSK, BHIE_TXVECDB_SEQNUM_SHFT,
sequence_id);
@@ -246,14 +244,15 @@ static int mhi_fw_load_sbl(struct mhi_controller 
*mhi_cntrl,
goto invalid_pm_state;
}
 
-   dev_dbg(dev, "Starting SBL download via BHI\n");
+   session_id = MHI_RANDOM_U32_NONZERO(BHI_TXDB_SEQNUM_BMSK);
+   dev_dbg(dev, "Starting SBL download via BHI. Session ID:%u\n",
+   session_id);
mhi_write_reg(mhi_cntrl, base, BHI_STATUS, 0);
mhi_write_reg(mhi_cntrl, base, BHI_IMGADDR_HIGH,
  upper_32_bits(dma_addr));
mhi_write_reg(mhi_cntrl, base, BHI_IMGADDR_LOW,
  lower_32_bits(dma_addr));
mhi_write_reg(mhi_cntrl, base, BHI_IMGSIZE, size);
-   session_id = prandom_u32() & BHI_TXDB_SEQNUM_BMSK;
mhi_write_reg(mhi_cntrl, base, BHI_IMGTXDB, session_id);
read_unlock_bh(pm_lock);
 
diff --git a/drivers/bus/mhi/core/internal.h b/drivers/bus/mhi/core/internal.h
index 0965ca3..80b32c2 100644
--- a/drivers/bus/mhi/core/internal.h
+++ b/drivers/bus/mhi/core/internal.h
@@ -452,6 +452,7 @@ enum mhi_pm_state {
 #define PRIMARY_CMD_RING   0
 #define MHI_DEV_WAKE_DB127
 #define MHI_MAX_MTU0x
+#define MHI_RANDOM_U32_NONZERO(bmsk)   (prandom_u32_max(bmsk) + 1)
 
 enum mhi_er_type {
MHI_ER_TYPE_INVALID = 0x0,
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v6 4/8] bus: mhi: core: Read transfer length from an event properly

[Bhaumik Bhatt]

From: Hemant Kumar 

When MHI Driver receives an EOT event, it reads xfer_len from the
event in the last TRE. The value is under control of the MHI device
and never validated by Host MHI driver. The value should never be
larger than the real size of the buffer but a malicious device can
set the value 0x as maximum. This causes driver to memory
overflow (both read or write). Fix this issue by reading minimum of
transfer length from event and the buffer length provided.

Signed-off-by: Hemant Kumar 
Signed-off-by: Bhaumik Bhatt 
Reviewed-by: Jeffrey Hugo 
---
 drivers/bus/mhi/core/main.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c
index e60ab21..159732e 100644
--- a/drivers/bus/mhi/core/main.c
+++ b/drivers/bus/mhi/core/main.c
@@ -514,7 +514,10 @@ static int parse_xfer_event(struct mhi_controller 
*mhi_cntrl,
mhi_cntrl->unmap_single(mhi_cntrl, buf_info);
 
result.buf_addr = buf_info->cb_buf;
-   result.bytes_xferd = xfer_len;
+
+   /* truncate to buf len if xfer_len is larger */
+   result.bytes_xferd =
+   min_t(u16, xfer_len, buf_info->len);
mhi_del_ring_element(mhi_cntrl, buf_ring);
mhi_del_ring_element(mhi_cntrl, tre_ring);
local_rp = tre_ring->rp;
@@ -598,7 +601,9 @@ static int parse_rsc_event(struct mhi_controller *mhi_cntrl,
 
result.transaction_status = (ev_code == MHI_EV_CC_OVERFLOW) ?
-EOVERFLOW : 0;
-   result.bytes_xferd = xfer_len;
+
+   /* truncate to buf len if xfer_len is larger */
+   result.bytes_xferd = min_t(u16, xfer_len, buf_info->len);
result.buf_addr = buf_info->cb_buf;
result.dir = mhi_chan->dir;
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v6 0/8] Bug fixes and improved logging in MHI

[Bhaumik Bhatt]

A set of patches for bug fixes and improved logging in mhi/core/boot.c.
Verified on x86 and arm64 platforms.

v6:
-Updated the MHI_RANDOM_U32_NONZERO to only give a random number upto the
supplied bitmask

v5:
-Updated the macro MHI_RANDOM_U32_NONZERO to take a bitmask as the input
parameter and output a non-zero value between 1 and U32_MAX

v4:
-Dropped the change: bus: mhi: core: WARN_ON for malformed vector table
-Updated bus: mhi: core: Read transfer length from an event properly to include
parse rsc events
-Use prandom_u32_max() instead of prandom_u32 to avoid if check in
bus: mhi: core: Ensure non-zero session or sequence ID values are used

v3:
-Fixed signed-off-by tags
-Add a refactor patch for MHI queue APIs
-Commit text fix in bus: mhi: core: Read transfer length from an event properly
-Fix channel ID range check for ctrl and data event rings processing

v2:
-Fix channel ID range check potential infinite loop
-Add appropriate signed-off-by tags

Bhaumik Bhatt (4):
  bus: mhi: core: Handle firmware load using state worker
  bus: mhi: core: Return appropriate error codes for AMSS load failure
  bus: mhi: core: Improve debug logs for loading firmware
  bus: mhi: core: Ensure non-zero session or sequence ID values are used

Hemant Kumar (4):
  bus: mhi: core: Refactor mhi queue APIs
  bus: mhi: core: Cache intmod from mhi event to mhi channel
  bus: mhi: core: Add range check for channel id received in event ring
  bus: mhi: core: Read transfer length from an event properly

 drivers/bus/mhi/core/boot.c |  75 
 drivers/bus/mhi/core/init.c |   5 +-
 drivers/bus/mhi/core/internal.h |   5 +-
 drivers/bus/mhi/core/main.c | 124 
 drivers/bus/mhi/core/pm.c   |   6 +-
 include/linux/mhi.h |   2 -
 6 files changed, 108 insertions(+), 109 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v6 6/8] bus: mhi: core: Return appropriate error codes for AMSS load failure

[Bhaumik Bhatt]

When loading AMSS firmware using BHIe protocol, return -ETIMEDOUT if no
response is received within the timeout or return -EIO in case of a
protocol returned failure or an MHI error state.

Signed-off-by: Bhaumik Bhatt 
Reviewed-by: Jeffrey Hugo 
---
 drivers/bus/mhi/core/boot.c | 23 ---
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/drivers/bus/mhi/core/boot.c b/drivers/bus/mhi/core/boot.c
index 17c636b..05627fe 100644
--- a/drivers/bus/mhi/core/boot.c
+++ b/drivers/bus/mhi/core/boot.c
@@ -176,6 +176,7 @@ static int mhi_fw_load_amss(struct mhi_controller 
*mhi_cntrl,
void __iomem *base = mhi_cntrl->bhie;
rwlock_t *pm_lock = _cntrl->pm_lock;
u32 tx_status, sequence_id;
+   int ret;
 
read_lock_bh(pm_lock);
if (!MHI_REG_ACCESS_VALID(mhi_cntrl->pm_state)) {
@@ -198,19 +199,19 @@ static int mhi_fw_load_amss(struct mhi_controller 
*mhi_cntrl,
read_unlock_bh(pm_lock);
 
/* Wait for the image download to complete */
-   wait_event_timeout(mhi_cntrl->state_event,
-  MHI_PM_IN_ERROR_STATE(mhi_cntrl->pm_state) ||
-  mhi_read_reg_field(mhi_cntrl, base,
- BHIE_TXVECSTATUS_OFFS,
- BHIE_TXVECSTATUS_STATUS_BMSK,
- BHIE_TXVECSTATUS_STATUS_SHFT,
- _status) || tx_status,
-  msecs_to_jiffies(mhi_cntrl->timeout_ms));
-
-   if (MHI_PM_IN_ERROR_STATE(mhi_cntrl->pm_state))
+   ret = wait_event_timeout(mhi_cntrl->state_event,
+MHI_PM_IN_ERROR_STATE(mhi_cntrl->pm_state) ||
+mhi_read_reg_field(mhi_cntrl, base,
+   BHIE_TXVECSTATUS_OFFS,
+  BHIE_TXVECSTATUS_STATUS_BMSK,
+  BHIE_TXVECSTATUS_STATUS_SHFT,
+   _status) || tx_status,
+msecs_to_jiffies(mhi_cntrl->timeout_ms));
+   if (MHI_PM_IN_ERROR_STATE(mhi_cntrl->pm_state) ||
+   tx_status != BHIE_TXVECSTATUS_STATUS_XFER_COMPL)
return -EIO;
 
-   return (tx_status == BHIE_TXVECSTATUS_STATUS_XFER_COMPL) ? 0 : -EIO;
+   return (!ret) ? -ETIMEDOUT : 0;
 }
 
 static int mhi_fw_load_sbl(struct mhi_controller *mhi_cntrl,
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v6 1/8] bus: mhi: core: Refactor mhi queue APIs

[Bhaumik Bhatt]

From: Hemant Kumar 

Move all the common code to generate TRE from mhi_queue_buf,
mhi_queue_dma and mhi_queue_skb to mhi_gen_tre. This helps
to centralize the TRE generation code which makes any future
bug fixing easier to manage in these APIs.

Suggested-by: Jeffrey Hugo 
Signed-off-by: Hemant Kumar 
Signed-off-by: Bhaumik Bhatt 
Reviewed-by: Jeffrey Hugo 
---
 drivers/bus/mhi/core/internal.h |   3 +-
 drivers/bus/mhi/core/main.c | 107 +---
 2 files changed, 47 insertions(+), 63 deletions(-)

diff --git a/drivers/bus/mhi/core/internal.h b/drivers/bus/mhi/core/internal.h
index 095d95b..40c47f9 100644
--- a/drivers/bus/mhi/core/internal.h
+++ b/drivers/bus/mhi/core/internal.h
@@ -670,8 +670,7 @@ int mhi_process_ctrl_ev_ring(struct mhi_controller 
*mhi_cntrl,
 irqreturn_t mhi_intvec_handler(int irq_number, void *dev);
 
 int mhi_gen_tre(struct mhi_controller *mhi_cntrl, struct mhi_chan *mhi_chan,
-   void *buf, void *cb, size_t buf_len, enum mhi_flags flags);
-
+   struct mhi_buf_info *info, enum mhi_flags flags);
 int mhi_map_single_no_bb(struct mhi_controller *mhi_cntrl,
 struct mhi_buf_info *buf_info);
 int mhi_map_single_use_bb(struct mhi_controller *mhi_cntrl,
diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c
index c26eed0..605640c 100644
--- a/drivers/bus/mhi/core/main.c
+++ b/drivers/bus/mhi/core/main.c
@@ -919,9 +919,7 @@ int mhi_queue_skb(struct mhi_device *mhi_dev, enum 
dma_data_direction dir,
struct mhi_chan *mhi_chan = (dir == DMA_TO_DEVICE) ? mhi_dev->ul_chan :
 mhi_dev->dl_chan;
struct mhi_ring *tre_ring = _chan->tre_ring;
-   struct mhi_ring *buf_ring = _chan->buf_ring;
-   struct mhi_buf_info *buf_info;
-   struct mhi_tre *mhi_tre;
+   struct mhi_buf_info buf_info = { };
int ret;
 
/* If MHI host pre-allocates buffers then client drivers cannot queue */
@@ -946,27 +944,15 @@ int mhi_queue_skb(struct mhi_device *mhi_dev, enum 
dma_data_direction dir,
/* Toggle wake to exit out of M2 */
mhi_cntrl->wake_toggle(mhi_cntrl);
 
-   /* Generate the TRE */
-   buf_info = buf_ring->wp;
-
-   buf_info->v_addr = skb->data;
-   buf_info->cb_buf = skb;
-   buf_info->wp = tre_ring->wp;
-   buf_info->dir = mhi_chan->dir;
-   buf_info->len = len;
-   ret = mhi_cntrl->map_single(mhi_cntrl, buf_info);
-   if (ret)
-   goto map_error;
-
-   mhi_tre = tre_ring->wp;
-
-   mhi_tre->ptr = MHI_TRE_DATA_PTR(buf_info->p_addr);
-   mhi_tre->dword[0] = MHI_TRE_DATA_DWORD0(buf_info->len);
-   mhi_tre->dword[1] = MHI_TRE_DATA_DWORD1(1, 1, 0, 0);
+   buf_info.v_addr = skb->data;
+   buf_info.cb_buf = skb;
+   buf_info.len = len;
 
-   /* increment WP */
-   mhi_add_ring_element(mhi_cntrl, tre_ring);
-   mhi_add_ring_element(mhi_cntrl, buf_ring);
+   ret = mhi_gen_tre(mhi_cntrl, mhi_chan, _info, mflags);
+   if (unlikely(ret)) {
+   read_unlock_bh(_cntrl->pm_lock);
+   return ret;
+   }
 
if (mhi_chan->dir == DMA_TO_DEVICE)
atomic_inc(_cntrl->pending_pkts);
@@ -980,11 +966,6 @@ int mhi_queue_skb(struct mhi_device *mhi_dev, enum 
dma_data_direction dir,
read_unlock_bh(_cntrl->pm_lock);
 
return 0;
-
-map_error:
-   read_unlock_bh(_cntrl->pm_lock);
-
-   return ret;
 }
 EXPORT_SYMBOL_GPL(mhi_queue_skb);
 
@@ -996,9 +977,8 @@ int mhi_queue_dma(struct mhi_device *mhi_dev, enum 
dma_data_direction dir,
 mhi_dev->dl_chan;
struct device *dev = _cntrl->mhi_dev->dev;
struct mhi_ring *tre_ring = _chan->tre_ring;
-   struct mhi_ring *buf_ring = _chan->buf_ring;
-   struct mhi_buf_info *buf_info;
-   struct mhi_tre *mhi_tre;
+   struct mhi_buf_info buf_info = { };
+   int ret;
 
/* If MHI host pre-allocates buffers then client drivers cannot queue */
if (mhi_chan->pre_alloc)
@@ -1025,25 +1005,16 @@ int mhi_queue_dma(struct mhi_device *mhi_dev, enum 
dma_data_direction dir,
/* Toggle wake to exit out of M2 */
mhi_cntrl->wake_toggle(mhi_cntrl);
 
-   /* Generate the TRE */
-   buf_info = buf_ring->wp;
-   WARN_ON(buf_info->used);
-   buf_info->p_addr = mhi_buf->dma_addr;
-   buf_info->pre_mapped = true;
-   buf_info->cb_buf = mhi_buf;
-   buf_info->wp = tre_ring->wp;
-   buf_info->dir = mhi_chan->dir;
-   buf_info->len = len;
-
-   mhi_tre = tre_ring->wp;
-
-   mhi_tre->ptr = MHI_TRE_DATA_PTR(buf_info->p_addr);
-   mhi_tre->dword[0] = MHI_TRE_DATA_DWORD0(buf_info->len);
-   mhi_tre->dword[1] = MHI_TRE_DATA_DWORD1(1, 1, 0, 0);
+   buf_info.p_addr = mhi_buf->dma_addr;
+   buf_info.cb_buf = mhi_buf;
+   buf_info.pre_mapped = true;
+   buf_info.len = 

[PATCH v6 5/8] bus: mhi: core: Handle firmware load using state worker

[Bhaumik Bhatt]

Upon power up, driver queues firmware worker thread if the execution
environment is PBL. Firmware worker is blocked with a timeout until
state worker gets a chance to run and unblock firmware worker. An
endpoint power up failure can be seen if state worker gets a chance to
run after firmware worker has timed out. Remove this dependency and
handle firmware load directly using state worker thread.

Signed-off-by: Bhaumik Bhatt 
Reviewed-by: Jeffrey Hugo 
---
 drivers/bus/mhi/core/boot.c | 18 +++---
 drivers/bus/mhi/core/init.c |  1 -
 drivers/bus/mhi/core/internal.h |  1 +
 drivers/bus/mhi/core/pm.c   |  6 +-
 include/linux/mhi.h |  2 --
 5 files changed, 5 insertions(+), 23 deletions(-)

diff --git a/drivers/bus/mhi/core/boot.c b/drivers/bus/mhi/core/boot.c
index ebad5eb..17c636b 100644
--- a/drivers/bus/mhi/core/boot.c
+++ b/drivers/bus/mhi/core/boot.c
@@ -377,30 +377,18 @@ static void mhi_firmware_copy(struct mhi_controller 
*mhi_cntrl,
}
 }
 
-void mhi_fw_load_worker(struct work_struct *work)
+void mhi_fw_load_handler(struct mhi_controller *mhi_cntrl)
 {
-   struct mhi_controller *mhi_cntrl;
const struct firmware *firmware = NULL;
struct image_info *image_info;
-   struct device *dev;
+   struct device *dev = _cntrl->mhi_dev->dev;
const char *fw_name;
void *buf;
dma_addr_t dma_addr;
size_t size;
int ret;
 
-   mhi_cntrl = container_of(work, struct mhi_controller, fw_worker);
-   dev = _cntrl->mhi_dev->dev;
-
-   dev_dbg(dev, "Waiting for device to enter PBL from: %s\n",
-   TO_MHI_EXEC_STR(mhi_cntrl->ee));
-
-   ret = wait_event_timeout(mhi_cntrl->state_event,
-MHI_IN_PBL(mhi_cntrl->ee) ||
-MHI_PM_IN_ERROR_STATE(mhi_cntrl->pm_state),
-msecs_to_jiffies(mhi_cntrl->timeout_ms));
-
-   if (!ret || MHI_PM_IN_ERROR_STATE(mhi_cntrl->pm_state)) {
+   if (MHI_PM_IN_ERROR_STATE(mhi_cntrl->pm_state)) {
dev_err(dev, "Device MHI is not in valid state\n");
return;
}
diff --git a/drivers/bus/mhi/core/init.c b/drivers/bus/mhi/core/init.c
index 1a93d24..6882206 100644
--- a/drivers/bus/mhi/core/init.c
+++ b/drivers/bus/mhi/core/init.c
@@ -835,7 +835,6 @@ int mhi_register_controller(struct mhi_controller 
*mhi_cntrl,
spin_lock_init(_cntrl->wlock);
INIT_WORK(_cntrl->st_worker, mhi_pm_st_worker);
INIT_WORK(_cntrl->syserr_worker, mhi_pm_sys_err_worker);
-   INIT_WORK(_cntrl->fw_worker, mhi_fw_load_worker);
init_waitqueue_head(_cntrl->state_event);
 
mhi_cmd = mhi_cntrl->mhi_cmd;
diff --git a/drivers/bus/mhi/core/internal.h b/drivers/bus/mhi/core/internal.h
index 40c47f9..0965ca3 100644
--- a/drivers/bus/mhi/core/internal.h
+++ b/drivers/bus/mhi/core/internal.h
@@ -627,6 +627,7 @@ void mhi_ring_chan_db(struct mhi_controller *mhi_cntrl,
 void mhi_deinit_free_irq(struct mhi_controller *mhi_cntrl);
 void mhi_rddm_prepare(struct mhi_controller *mhi_cntrl,
  struct image_info *img_info);
+void mhi_fw_load_handler(struct mhi_controller *mhi_cntrl);
 int mhi_prepare_channel(struct mhi_controller *mhi_cntrl,
struct mhi_chan *mhi_chan);
 int mhi_init_chan_ctxt(struct mhi_controller *mhi_cntrl,
diff --git a/drivers/bus/mhi/core/pm.c b/drivers/bus/mhi/core/pm.c
index e7c8318..3cc238a 100644
--- a/drivers/bus/mhi/core/pm.c
+++ b/drivers/bus/mhi/core/pm.c
@@ -528,7 +528,6 @@ static void mhi_pm_disable_transition(struct mhi_controller 
*mhi_cntrl,
dev_dbg(dev, "Waiting for all pending threads to complete\n");
wake_up_all(_cntrl->state_event);
flush_work(_cntrl->st_worker);
-   flush_work(_cntrl->fw_worker);
 
dev_dbg(dev, "Reset all active channels and remove MHI devices\n");
device_for_each_child(mhi_cntrl->cntrl_dev, NULL, mhi_destroy_device);
@@ -643,7 +642,7 @@ void mhi_pm_st_worker(struct work_struct *work)
mhi_cntrl->ee = mhi_get_exec_env(mhi_cntrl);
write_unlock_irq(_cntrl->pm_lock);
if (MHI_IN_PBL(mhi_cntrl->ee))
-   wake_up_all(_cntrl->state_event);
+   mhi_fw_load_handler(mhi_cntrl);
break;
case DEV_ST_TRANSITION_SBL:
write_lock_irq(_cntrl->pm_lock);
@@ -976,9 +975,6 @@ int mhi_async_power_up(struct mhi_controller *mhi_cntrl)
next_state = MHI_IN_PBL(current_ee) ?
DEV_ST_TRANSITION_PBL : DEV_ST_TRANSITION_READY;
 
-   if (next_state == DEV_ST_TRANSITION_PBL)
-   schedule_work(_cntrl->fw_worker);
-
mhi_queue_state_transition(mhi_cntrl, next_state);
 
mutex_unlock(_cntrl->pm_mutex);
diff --git a/include/linux/mhi.h b/include/linux/mhi.h
index e909b8f..2b20b9c 100644

Re: [PATCH for-5.7] splice: move f_mode checks to do_{splice,tee}()

[Clay Harris]

On Tue, May 05 2020 at 17:00:32 -0500, Clay Harris quoth thus:

> On Wed, May 06 2020 at 00:38:05 +0300, Pavel Begunkov quoth thus:
> 
> > On 06/05/2020 00:10, Clay Harris wrote:
> > > On Mon, May 04 2020 at 22:39:35 +0300, Pavel Begunkov quoth thus:
> > > 
> > >> do_splice() is used by io_uring, as will be do_tee(). Move f_mode
> > >> checks from sys_{splice,tee}() to do_{splice,tee}(), so they're
> > >> enforced for io_uring as well.
> > > 
> > > I'm not seeing any check against splicing a pipe to itself in the
> > > io_uring path, although maybe I just missed it.  As the comment
> > > below says: /* Splicing to self would be fun, but... */ .
> > 
> > io_uring just forwards a request to do_splice(), which do the check at the 
> > exact
> > place you mentioned. The similar story is with do_tee().
> 
> Okay.  I'd been thinking that since you were moving the file mode
> checks into io_uring that the previous place they were called wasn't
> on the path.  Evidently, you're just moving the mode checks earlier.

My bad.  I meant to say *later*.  (After the syscall entry, at the spot
io_uring would call.)

Thanks for looking at it!

> > > 
> > >> Fixes: 7d67af2c0134 ("io_uring: add splice(2) support")
> > >> Reported-by: Jann Horn 
> > >> Signed-off-by: Pavel Begunkov 
> > >> ---
> > >>  fs/splice.c | 45 ++---
> > >>  1 file changed, 18 insertions(+), 27 deletions(-)
> > >>
> > >> diff --git a/fs/splice.c b/fs/splice.c
> > >> index 4735defc46ee..fd0a1e7e5959 100644
> > >> --- a/fs/splice.c
> > >> +++ b/fs/splice.c
> > >> @@ -1118,6 +1118,10 @@ long do_splice(struct file *in, loff_t __user 
> > >> *off_in,
> > >>  loff_t offset;
> > >>  long ret;
> > >>  
> > >> +if (unlikely(!(in->f_mode & FMODE_READ) ||
> > >> + !(out->f_mode & FMODE_WRITE)))
> > >> +return -EBADF;
> > >> +
> > >>  ipipe = get_pipe_info(in);
> > >>  opipe = get_pipe_info(out);
> > >>  
> > >> @@ -1125,12 +1129,6 @@ long do_splice(struct file *in, loff_t __user 
> > >> *off_in,
> > >>  if (off_in || off_out)
> > >>  return -ESPIPE;
> > >>  
> > >> -if (!(in->f_mode & FMODE_READ))
> > >> -return -EBADF;
> > >> -
> > >> -if (!(out->f_mode & FMODE_WRITE))
> > >> -return -EBADF;
> > >> -
> > >>  /* Splicing to self would be fun, but... */
> > >>  if (ipipe == opipe)
> > >>  return -EINVAL;
> > >> @@ -1153,9 +1151,6 @@ long do_splice(struct file *in, loff_t __user 
> > >> *off_in,
> > >>  offset = out->f_pos;
> > >>  }
> > >>  
> > >> -if (unlikely(!(out->f_mode & FMODE_WRITE)))
> > >> -return -EBADF;
> > >> -
> > >>  if (unlikely(out->f_flags & O_APPEND))
> > >>  return -EINVAL;
> > >>  
> > >> @@ -1440,15 +1435,11 @@ SYSCALL_DEFINE6(splice, int, fd_in, loff_t 
> > >> __user *, off_in,
> > >>  error = -EBADF;
> > >>  in = fdget(fd_in);
> > >>  if (in.file) {
> > >> -if (in.file->f_mode & FMODE_READ) {
> > >> -out = fdget(fd_out);
> > >> -if (out.file) {
> > >> -if (out.file->f_mode & FMODE_WRITE)
> > >> -error = do_splice(in.file, 
> > >> off_in,
> > >> -  out.file, 
> > >> off_out,
> > >> -  len, flags);
> > >> -fdput(out);
> > >> -}
> > >> +out = fdget(fd_out);
> > >> +if (out.file) {
> > >> +error = do_splice(in.file, off_in, out.file, 
> > >> off_out,
> > >> +  len, flags);
> > >> +fdput(out);
> > >>  }
> > >>  fdput(in);
> > >>  }
> > >> @@ -1770,6 +1761,10 @@ static long do_tee(struct file *in, struct file 
> > >> *out, size_t len,
> > >>  struct pipe_inode_info *opipe = get_pipe_info(out);
> > >>  int ret = -EINVAL;
> > >>  
> > >> +if (unlikely(!(in->f_mode & FMODE_READ) ||
> > >> + !(out->f_mode & FMODE_WRITE)))
> > >> +return -EBADF;
> > >> +
> > >>  /*
> > >>   * Duplicate the contents of ipipe to opipe without actually
> > >>   * copying the data.
> > >> @@ -1795,7 +1790,7 @@ static long do_tee(struct file *in, struct file 
> > >> *out, size_t len,
> > >>  
> > >>  SYSCALL_DEFINE4(tee, int, fdin, int, fdout, size_t, len, unsigned int, 
> > >> flags)
> > >>  {
> > >> -struct fd in;
> > >> +struct fd in, out;
> > >>  int error;
> > >>  
> > >>

Re: [PATCH] docs: s390: Fix wrong label Guest2 instead of Guest3

[Vitor Massaru Iha]

On Tue, 2020-05-05 at 09:46 -0600, Jonathan Corbet wrote:
> On Thu, 30 Apr 2020 19:12:38 -0300
> Vitor Massaru Iha  wrote:
> 
> > This fixes:
> > 
> > Documentation/s390/vfio-ap.rst:488: WARNING: duplicate label
> > s390/vfio-ap:guest2, other instance in
> > /home/iha/sdb/opensource/lkmp/linux_doc/Documentation/s390/vfio-
> > ap.rst
> > 
> > Signed-off-by: Vitor Massaru Iha 
> > ---
> >  Documentation/s390/vfio-ap.rst | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/Documentation/s390/vfio-ap.rst
> > b/Documentation/s390/vfio-ap.rst
> > index b5c51f7c748d..367e27ec3c50 100644
> > --- a/Documentation/s390/vfio-ap.rst
> > +++ b/Documentation/s390/vfio-ap.rst
> > @@ -484,7 +484,7 @@ CARD.DOMAIN TYPE  MODE
> >  05.00ff CEX5A Accelerator
> >  === = 
> >  
> > -Guest2
> > +Guest3
> >  --
> >  === = 
> >  CARD.DOMAIN TYPE  MODE
> 
> Applied, thanks.
> 
> Note, though, that while the patch does "fix" the warning, what it
> really
> fixes is (as suggested in the subject) an incorrect heading; the
> warning
> was just a symptom.

Thanks Jon, I will be careful about that.
> 
> jon

Re: [PATCH] Kbuild: disable FORTIFY_SOURCE on clang-10

[George Burgess IV]

This code generated by Clang here is the unfortunate side-effect of a
bug introduced during Clang-10's development phase. From discussion
with Kees on the links Nick mentioned, I surmise that FORTIFY in the
kernel never worked as well for Clang as it does for GCC today. In
many cases, it'd compile into nothing, but with the aforementioned
Clang bug, it would turn into very suboptimal code.

Kees sounded interested in getting a FORTIFY that plays more nicely
with Clang into the kernel. Until that happens, we'll be in a world
where an unpatched Clang-10 generates suboptimal code, and where a
patched Clang-10 only FORTIFYs a subset of the kernel's `mem*`/`str*`
functions. (I haven't checked assembly, but I assume that not every
FORTIFY'ed function gets compiled into 'nothingness').

I don't have sufficient context to be opinionated on whether it's
"better" to prefer a subset of opportune checks vs better codegen on
unpatched versions of clang.

If we do turn it off, it'd be nice to have some idea of when it can be
turned back on (do we need a modified implementation as mentioned
earlier? N months after clang's next point release is released,
provided the fixes land in it?)

> I can file an upstream PR for Tom to take a look out later tonight.

Thank you for the bisection and for handling the merge :)





On Tue, May 5, 2020 at 3:25 PM Nathan Chancellor
 wrote:
>
> On Tue, May 05, 2020 at 03:02:16PM -0700, 'Nick Desaulniers' via Clang Built 
> Linux wrote:
> > On Tue, May 5, 2020 at 2:55 PM Jason A. Donenfeld  wrote:
> > >
> > > clang-10 has a broken optimization stage that doesn't enable the
> > > compiler to prove at compile time that certain memcpys are within
> > > bounds, and thus the outline memcpy is always called, resulting in
> > > horrific performance, and in some cases, excessive stack frame growth.
> > > Here's a simple reproducer:
> > >
> > > typedef unsigned long size_t;
> > > void *c(void *dest, const void *src, size_t n) __asm__("memcpy");
> > > extern inline __attribute__((gnu_inline)) void *memcpy(void *dest, 
> > > const void *src, size_t n) { return c(dest, src, n); }
> > > void blah(char *a)
> > > {
> > >   unsigned long long b[10], c[10];
> > >   int i;
> > >
> > >   memcpy(b, a, sizeof(b));
> > >   for (i = 0; i < 10; ++i)
> > > c[i] = b[i] ^ b[9 - i];
> > >   for (i = 0; i < 10; ++i)
> > > b[i] = c[i] ^ a[i];
> > >   memcpy(a, b, sizeof(b));
> > > }
> > >
> > > Compile this with clang-9 and clang-10 and observe:
> > >
> > > zx2c4@thinkpad /tmp/curve25519-hacl64-stack-frame-size-test $ clang-10 
> > > -Wframe-larger-than=0 -O3 -c b.c -o c10.o
> > > b.c:5:6: warning: stack frame size of 104 bytes in function 'blah' 
> > > [-Wframe-larger-than=]
> > > void blah(char *a)
> > >  ^
> > > 1 warning generated.
> > > zx2c4@thinkpad /tmp/curve25519-hacl64-stack-frame-size-test $ clang-9 
> > > -Wframe-larger-than=0 -O3 -c b.c -o c9.o
> > >
> > > Looking at the disassembly of c10.o and c9.o, one can see that c9.o is
> > > properly optimized in the obvious way one would expect, while c10.o has
> > > blown up and includes extern calls to memcpy.
> > >
> > > This is present on the most trivial bits of code. Thus, for clang-10, we
> > > just set __NO_FORTIFY globally, so that this issue won't be incurred.
> > >
> > > Cc: Arnd Bergmann 
> > > Cc: LKML 
> > > Cc: clang-built-linux 
> > > Cc: Kees Cook 
> > > Cc: George Burgess 
> > > Cc: Nick Desaulniers 
> > > Link: https://bugs.llvm.org/show_bug.cgi?id=45802
> > > Signed-off-by: Jason A. Donenfeld 
> >
> > I'm going to request this not be merged until careful comment from
> > George and Kees. My hands are quite full at the moment with other
> > regressions.  I suspect these threads may be relevant, though I
> > haven't had time to read through them myself.
> > https://github.com/ClangBuiltLinux/linux/issues/979
> > https://github.com/ClangBuiltLinux/linux/pull/980
>
> I believe these issues are one in the same. I did a reverse bisect with
> Arnd's test case and converged on George's first patch:
>
> https://github.com/llvm/llvm-project/commit/2dd17ff08165e6118e70f00e22b2c36d2d4e0a9a
>
> I think that in lieu of this patch, we should have that patch and its
> follow-up fix merged into 10.0.1.
>
> I can file an upstream PR for Tom to take a look out later tonight.
>
> Cheers,
> Nathan
>
> > > ---
> > >  Makefile | 7 +++
> > >  1 file changed, 7 insertions(+)
> > >
> > > diff --git a/Makefile b/Makefile
> > > index 49b2709ff44e..f022f077591d 100644
> > > --- a/Makefile
> > > +++ b/Makefile
> > > @@ -768,6 +768,13 @@ KBUILD_CFLAGS += -Wno-gnu
> > >  # source of a reference will be _MergedGlobals and not on of the 
> > > whitelisted names.
> > >  # See modpost pattern 2
> > >  KBUILD_CFLAGS += -mno-global-merge
> > > +
> > > +# clang-10 has a broken optimization stage that causes memcpy to always 
> > > be
> > > +# outline, resulting in excessive stack frame growth and poor 
> > > 

Re: [PATCH] Kbuild: disable FORTIFY_SOURCE on clang-10

[Jason A. Donenfeld]

On Tue, May 5, 2020 at 4:25 PM Nathan Chancellor
 wrote:
> I believe these issues are one in the same. I did a reverse bisect with
> Arnd's test case and converged on George's first patch:
>
> https://github.com/llvm/llvm-project/commit/2dd17ff08165e6118e70f00e22b2c36d2d4e0a9a
>
> I think that in lieu of this patch, we should have that patch and its
> follow-up fix merged into 10.0.1.

If this is fixed in 10.0.1, do we even need to patch the kernel at
all? Or can we just leave it be, considering most organizations using
clang know what they're getting into? I'd personally prefer the
latter, so that we don't clutter things.

[PATCH V2 5/7] x86/resctrl: Maintain MBM counter width per resource

[Reinette Chatre]

The original Memory Bandwidth Monitoring (MBM) architectural
definition defines counters of up to 62 bits in the IA32_QM_CTR MSR,
and the first-generation MBM implementation uses 24 bit counters.
Software is required to poll at 1 second or faster to ensure that
data is retrieved before a counter rollover occurs more than once
under worst conditions.

As system bandwidths scale the software requirement is maintained with
the introduction of a per-resource enumerable MBM counter width.

In preparation for supporting hardware with an enumerable MBM counter
width the current globally static MBM counter width is moved to a
per-resource MBM counter width. Currently initialized to 24 always
to result in no functional change.

In essence there is one function, mbm_overflow_count() that needs to
know the counter width to handle rollovers. The static value
used within mbm_overflow_count() will be replaced with a value
discovered from the hardware. Support for learning the MBM counter
width from hardware is added in the change that follows.

Signed-off-by: Reinette Chatre 
---
 arch/x86/kernel/cpu/resctrl/ctrlmondata.c |  8 +---
 arch/x86/kernel/cpu/resctrl/internal.h|  7 +--
 arch/x86/kernel/cpu/resctrl/monitor.c | 21 +
 arch/x86/kernel/cpu/resctrl/rdtgroup.c|  2 +-
 4 files changed, 24 insertions(+), 14 deletions(-)

diff --git a/arch/x86/kernel/cpu/resctrl/ctrlmondata.c 
b/arch/x86/kernel/cpu/resctrl/ctrlmondata.c
index 055c8613b531..934c8fb8a64a 100644
--- a/arch/x86/kernel/cpu/resctrl/ctrlmondata.c
+++ b/arch/x86/kernel/cpu/resctrl/ctrlmondata.c
@@ -495,14 +495,16 @@ int rdtgroup_schemata_show(struct kernfs_open_file *of,
return ret;
 }
 
-void mon_event_read(struct rmid_read *rr, struct rdt_domain *d,
-   struct rdtgroup *rdtgrp, int evtid, int first)
+void mon_event_read(struct rmid_read *rr, struct rdt_resource *r,
+   struct rdt_domain *d, struct rdtgroup *rdtgrp,
+   int evtid, int first)
 {
/*
 * setup the parameters to send to the IPI to read the data.
 */
rr->rgrp = rdtgrp;
rr->evtid = evtid;
+   rr->r = r;
rr->d = d;
rr->val = 0;
rr->first = first;
@@ -539,7 +541,7 @@ int rdtgroup_mondata_show(struct seq_file *m, void *arg)
goto out;
}
 
-   mon_event_read(, d, rdtgrp, evtid, false);
+   mon_event_read(, r, d, rdtgrp, evtid, false);
 
if (rr.val & RMID_VAL_ERROR)
seq_puts(m, "Error\n");
diff --git a/arch/x86/kernel/cpu/resctrl/internal.h 
b/arch/x86/kernel/cpu/resctrl/internal.h
index 3dd13f3a8b23..58b002c31655 100644
--- a/arch/x86/kernel/cpu/resctrl/internal.h
+++ b/arch/x86/kernel/cpu/resctrl/internal.h
@@ -87,6 +87,7 @@ union mon_data_bits {
 
 struct rmid_read {
struct rdtgroup *rgrp;
+   struct rdt_resource *r;
struct rdt_domain   *d;
int evtid;
boolfirst;
@@ -460,6 +461,7 @@ struct rdt_resource {
struct list_headevt_list;
int num_rmid;
unsigned intmon_scale;
+   unsigned intmbm_width;
unsigned long   fflags;
 };
 
@@ -587,8 +589,9 @@ void rmdir_mondata_subdir_allrdtgrp(struct rdt_resource *r,
unsigned int dom_id);
 void mkdir_mondata_subdir_allrdtgrp(struct rdt_resource *r,
struct rdt_domain *d);
-void mon_event_read(struct rmid_read *rr, struct rdt_domain *d,
-   struct rdtgroup *rdtgrp, int evtid, int first);
+void mon_event_read(struct rmid_read *rr, struct rdt_resource *r,
+   struct rdt_domain *d, struct rdtgroup *rdtgrp,
+   int evtid, int first);
 void mbm_setup_overflow_handler(struct rdt_domain *dom,
unsigned long delay_ms);
 void mbm_handle_overflow(struct work_struct *work);
diff --git a/arch/x86/kernel/cpu/resctrl/monitor.c 
b/arch/x86/kernel/cpu/resctrl/monitor.c
index 773124b0e18a..df964c03f6c6 100644
--- a/arch/x86/kernel/cpu/resctrl/monitor.c
+++ b/arch/x86/kernel/cpu/resctrl/monitor.c
@@ -214,9 +214,9 @@ void free_rmid(u32 rmid)
list_add_tail(>list, _free_lru);
 }
 
-static u64 mbm_overflow_count(u64 prev_msr, u64 cur_msr)
+static u64 mbm_overflow_count(u64 prev_msr, u64 cur_msr, unsigned int width)
 {
-   u64 shift = 64 - MBM_CNTR_WIDTH, chunks;
+   u64 shift = 64 - width, chunks;
 
chunks = (cur_msr << shift) - (prev_msr << shift);
return chunks >>= shift;
@@ -256,7 +256,7 @@ static int __mon_event_count(u32 rmid, struct rmid_read *rr)
return 0;
}
 
-   chunks = mbm_overflow_count(m->prev_msr, tval);
+   chunks = mbm_overflow_count(m->prev_msr, tval, rr->r->mbm_width);
m->chunks += chunks;
m->prev_msr = tval;
 
@@ -278,7 +278,7 @@ static