Re: [PATCH] drivers/virt: vmgenid: add vm generation id driver

[Jann Horn]

On Sat, Oct 17, 2020 at 8:44 AM Willy Tarreau  wrote:
> On Sat, Oct 17, 2020 at 07:52:48AM +0200, Jann Horn wrote:
> > On Sat, Oct 17, 2020 at 7:37 AM Willy Tarreau  wrote:
> > > On Sat, Oct 17, 2020 at 07:01:31AM +0200, Jann Horn wrote:
> > > > Microsoft's documentation
> > > > (http://go.microsoft.com/fwlink/?LinkId=260709) says that the VM
> > > > Generation ID that we get after a fork "is a 128-bit,
> > > > cryptographically random integer value". If multiple people use the
> > > > same image, it guarantees that each use of the image gets its own,
> > > > fresh ID:
> > >
> > > No. It cannot be more unique than the source that feeds that cryptographic
> > > transformation. All it guarantees is that the entropy source is protected
> > > from being guessed based on the output. Applying cryptography on a simple
> > > counter provides apparently random numbers that will be unique for a long
> > > period for the same source, but as soon as you duplicate that code between
> > > users and they start from the same counter they'll get the same IDs.
> > >
> > > This is why I think that using a counter is better if you really need 
> > > something
> > > unique. Randoms only reduce predictability which helps avoiding 
> > > collisions.
> >
> > Microsoft's spec tells us that they're giving us cryptographically
> > random numbers. Where they're getting those from is not our problem.
> > (And if even the hypervisor is not able to collect enough entropy to
> > securely generate random numbers, worrying about RNG reseeding in the
> > guest would be kinda pointless, we'd be fairly screwed anyway.)
>
> Sorry if I sound annoying, but it's a matter of terminology and needs.
>
> Cryptograhically random means safe for use with cryptography in that it
> is unguessable enough so that you can use it for encryption keys that
> nobody will be able to guess. It in no ways guarantees uniqueness, just
> like you don't really care if the symmetric crypto key of you VPN has
> already been used once somewhere else as long as there's no way to know.
> However with the good enough distribution that a CSPRNG provides,
> collisions within a *same* generator are bound to a very low, predictable
> rate which is by generally considered as acceptable for all use cases.

Yes.

> Something random (cryptographically or not) *cannot* be unique by
> definition, otherwise it's not random anymore, since each draw has an
> influence on the remaining list of possible draws, which is contrary to
> randomness. And conversely something unique cannot be completely random
> because if you know it's unique, you can already rule out all other known
> values from the candidates, thus it's more predictable than random.

Yes.

> With this in mind, picking randoms from a same RNG is often highly
> sufficient to consider they're highly likely unique within a long
> period. But it's not a guarantee. And it's even less one between two
> RNGs (e.g. if uniqueness is required between multiple hypervisors in
> case VMs are migrated or centrally managed, which I don't know).
>
> If what is sought here is a strong guarantee of uniqueness, using a
> counter as you first suggested is better.

My suggestion is to use a counter *in the UAPI*, not in the hypervisor
protocol. (And as long as that counter can only miss increments in a
cryptographically negligible fraction of cases, everything's fine.)

> If what is sought is pure
> randomness (in the sense that it's unpredictable, which I don't think
> is needed here), then randoms are better.

And this is what *the hypervisor protocol* gives us (which could be
very useful for reseeding the kernel RNG).

> If both are required, just
> concatenate a counter and a random. And if you need them to be spatially
> unique, just include a node identifier.
>
> Now the initial needs in the forwarded message are not entirely clear
> to me but I wanted to rule out the apparent mismatch between the expressed
> needs for uniqueness and the proposed solutions solely based on randomness.

Sure, from a theoretical standpoint, it would be a little bit nicer if
the hypervisor protocol included a generation number along with the
128-bit random value. But AFAIU it doesn't, so if we want this to just
work under Microsoft's existing hypervisor, we'll have to make do with
checking whether the random value changed. :P

Re: [PATCH] drivers/virt: vmgenid: add vm generation id driver

[Willy Tarreau]

On Sat, Oct 17, 2020 at 07:52:48AM +0200, Jann Horn wrote:
> On Sat, Oct 17, 2020 at 7:37 AM Willy Tarreau  wrote:
> > On Sat, Oct 17, 2020 at 07:01:31AM +0200, Jann Horn wrote:
> > > Microsoft's documentation
> > > (http://go.microsoft.com/fwlink/?LinkId=260709) says that the VM
> > > Generation ID that we get after a fork "is a 128-bit,
> > > cryptographically random integer value". If multiple people use the
> > > same image, it guarantees that each use of the image gets its own,
> > > fresh ID:
> >
> > No. It cannot be more unique than the source that feeds that cryptographic
> > transformation. All it guarantees is that the entropy source is protected
> > from being guessed based on the output. Applying cryptography on a simple
> > counter provides apparently random numbers that will be unique for a long
> > period for the same source, but as soon as you duplicate that code between
> > users and they start from the same counter they'll get the same IDs.
> >
> > This is why I think that using a counter is better if you really need 
> > something
> > unique. Randoms only reduce predictability which helps avoiding collisions.
> 
> Microsoft's spec tells us that they're giving us cryptographically
> random numbers. Where they're getting those from is not our problem.
> (And if even the hypervisor is not able to collect enough entropy to
> securely generate random numbers, worrying about RNG reseeding in the
> guest would be kinda pointless, we'd be fairly screwed anyway.)

Sorry if I sound annoying, but it's a matter of terminology and needs.

Cryptograhically random means safe for use with cryptography in that it
is unguessable enough so that you can use it for encryption keys that
nobody will be able to guess. It in no ways guarantees uniqueness, just
like you don't really care if the symmetric crypto key of you VPN has
already been used once somewhere else as long as there's no way to know.
However with the good enough distribution that a CSPRNG provides,
collisions within a *same* generator are bound to a very low, predictable
rate which is by generally considered as acceptable for all use cases.

Something random (cryptographically or not) *cannot* be unique by
definition, otherwise it's not random anymore, since each draw has an
influence on the remaining list of possible draws, which is contrary to
randomness. And conversely something unique cannot be completely random
because if you know it's unique, you can already rule out all other known
values from the candidates, thus it's more predictable than random.

With this in mind, picking randoms from a same RNG is often highly
sufficient to consider they're highly likely unique within a long
period. But it's not a guarantee. And it's even less one between two
RNGs (e.g. if uniqueness is required between multiple hypervisors in
case VMs are migrated or centrally managed, which I don't know).

If what is sought here is a strong guarantee of uniqueness, using a
counter as you first suggested is better. If what is sought is pure
randomness (in the sense that it's unpredictable, which I don't think
is needed here), then randoms are better. If both are required, just
concatenate a counter and a random. And if you need them to be spatially
unique, just include a node identifier.

Now the initial needs in the forwarded message are not entirely clear
to me but I wanted to rule out the apparent mismatch between the expressed
needs for uniqueness and the proposed solutions solely based on randomness.

Cheers,
Willy

Re: [RFC PATCH] topology: Represent clusters of CPUs within a die.

[Greg Kroah-Hartman]

On Fri, Oct 16, 2020 at 11:27:02PM +0800, Jonathan Cameron wrote:
> Both ACPI and DT provide the ability to describe additional layers of
> topology between that of individual cores and higher level constructs
> such as the level at which the last level cache is shared.
> In ACPI this can be represented in PPTT as a Processor Hierarchy
> Node Structure [1] that is the parent of the CPU cores and in turn
> has a parent Processor Hierarchy Nodes Structure representing
> a higher level of topology.
> 
> For example Kunpeng 920 has clusters of 4 CPUs.  These do not share
> any cache resources, but the interconnect topology is such that
> the cost to transfer ownership of a cacheline between CPUs within
> a cluster is lower than between CPUs in different clusters on the same
> die.   Hence, it can make sense to deliberately schedule threads
> sharing data to a single cluster.
> 
> This patch simply exposes this information to userspace libraries
> like hwloc by providing cluster_cpus and related sysfs attributes.
> PoC of HWLOC support at [2].
> 
> Note this patch only handle the ACPI case.
> 
> Special consideration is needed for SMT processors, where it is
> necessary to move 2 levels up the hierarchy from the leaf nodes
> (thus skipping the processor core level).
> 
> Currently the ID provided is the offset of the Processor
> Hierarchy Nodes Structure within PPTT.  Whilst this is unique
> it is not terribly elegant so alternative suggestions welcome.
> 
> Note that arm64 / ACPI does not provide any means of identifying
> a die level in the topology but that may be unrelate to the cluster
> level.
> 
> RFC questions:
> 1) Naming
> 2) Related to naming, do we want to represent all potential levels,
>or this enough?  On Kunpeng920, the next level up from cluster happens
>to be covered by llc cache sharing, but in theory more than one
>level of cluster description might be needed by some future system.
> 3) Do we need DT code in place? I'm not sure any DT based ARM64
>systems would have enough complexity for this to be useful.
> 4) Other architectures?  Is this useful on x86 for example?
> 
> [1] ACPI Specification 6.3 - section 5.2.29.1 processor hierarchy node
> structure (Type 0)
> [2] https://github.com/hisilicon/hwloc/tree/linux-cluster
> 
> Signed-off-by: Jonathan Cameron 
> ---
> 
>  Documentation/admin-guide/cputopology.rst | 26 --

You are adding new sysfs files here, but not adding Documentation/ABI/
entries as well?  This cputopology document is nice, but no one knows to
look there for sysfs stuff :)

thanks,

greg k-h

[PATCH] fat: Add KUnit tests for checksums and timestamps

[David Gow]

Add some basic sanity-check tests for the fat_checksum() function and
the fat_time_unix2fat() and fat_time_fat2unix() functions. These unit
tests verify these functions return correct output for a number of test
inputs.

These tests were inspored by -- and serve a similar purpose to -- the
timestamp parsing KUnit tests in ext4[1].

[1]:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/ext4/inode-test.c

Signed-off-by: David Gow 
---
 fs/fat/Kconfig|  13 +++
 fs/fat/Makefile   |   2 +
 fs/fat/fat_test.c | 197 ++
 3 files changed, 212 insertions(+)
 create mode 100644 fs/fat/fat_test.c

diff --git a/fs/fat/Kconfig b/fs/fat/Kconfig
index 66532a71e8fd..fdef03b79c69 100644
--- a/fs/fat/Kconfig
+++ b/fs/fat/Kconfig
@@ -115,3 +115,16 @@ config FAT_DEFAULT_UTF8
  Say Y if you use UTF-8 encoding for file names, N otherwise.
 
  See  for more information.
+
+config FAT_KUNIT_TEST
+   tristate "Unit Tests for FAT filesystems" if !KUNIT_ALL_TESTS
+   select FAT_FS
+   depends on KUNIT
+   default KUNIT_ALL_TESTS
+   help
+ This builds the FAT KUnit tests
+
+ For more information on KUnit and unit tests in general, please refer
+ to the KUnit documentation in Documentation/dev-tools/kunit
+
+ If unsure, say N
diff --git a/fs/fat/Makefile b/fs/fat/Makefile
index 70645ce2f7fc..2b034112690d 100644
--- a/fs/fat/Makefile
+++ b/fs/fat/Makefile
@@ -10,3 +10,5 @@ obj-$(CONFIG_MSDOS_FS) += msdos.o
 fat-y := cache.o dir.o fatent.o file.o inode.o misc.o nfs.o
 vfat-y := namei_vfat.o
 msdos-y := namei_msdos.o
+
+obj-$(CONFIG_FAT_KUNIT_TEST) += fat_test.o
diff --git a/fs/fat/fat_test.c b/fs/fat/fat_test.c
new file mode 100644
index ..c1b4348b9b3b
--- /dev/null
+++ b/fs/fat/fat_test.c
@@ -0,0 +1,197 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * KUnit tests for FAT filesystems.
+ *
+ * Copyright (C) 2020 Google LLC.
+ * Author: David Gow 
+ */
+
+#include 
+
+#include "fat.h"
+
+static void fat_checksum_test(struct kunit *test)
+{
+   /* With no extension. */
+   KUNIT_EXPECT_EQ(test, fat_checksum("VMLINUX"), 44);
+   /* With 3-letter extension. */
+   KUNIT_EXPECT_EQ(test, fat_checksum("README  TXT"), 115);
+   /* With short (1-letter) extension. */
+   KUNIT_EXPECT_EQ(test, fat_checksum("ABCDEFGHA  "), 98);
+}
+
+
+struct fat_timestamp_testcase {
+   const char *name;
+   struct timespec64 ts;
+   __le16 time;
+   __le16 date;
+   u8 cs;
+   int time_offset;
+};
+
+const static struct fat_timestamp_testcase time_test_cases[] = {
+   {
+   .name = "Earliest possible UTC (1980-01-01 00:00:00)",
+   .ts = {.tv_sec = 315532800LL, .tv_nsec = 0L},
+   .time = 0,
+   .date = 33,
+   .cs = 0,
+   .time_offset = 0,
+   },
+   {
+   .name = "Latest possible UTC (2107-12-31 23:59:58)",
+   .ts = {.tv_sec = 4354819198LL, .tv_nsec = 0L},
+   .time = 49021,
+   .date = 65439,
+   .cs = 0,
+   .time_offset = 0,
+   },
+   {
+   .name = "Earliest possible (UTC-11) (== 1979-12-31 13:00:00 
UTC)",
+   .ts = {.tv_sec = 315493200LL, .tv_nsec = 0L},
+   .time = 0,
+   .date = 33,
+   .cs = 0,
+   .time_offset = 11 * 60,
+   },
+   {
+   .name = "Latest possible (UTC+11) (== 2108-01-01 10:59:58 UTC)",
+   .ts = {.tv_sec = 4354858798LL, .tv_nsec = 0L},
+   .time = 49021,
+   .date = 65439,
+   .cs = 0,
+   .time_offset = -11 * 60,
+   },
+   {
+   .name = "Leap Day / Year (1996-02-29 00:00:00)",
+   .ts = {.tv_sec = 825552000LL, .tv_nsec = 0L},
+   .time = 0,
+   .date = 8285,
+   .cs = 0,
+   .time_offset = 0,
+   },
+   {
+   .name = "Year 2000 is leap year (2000-02-29 00:00:00)",
+   .ts = {.tv_sec = 951782400LL, .tv_nsec = 0L},
+   .time = 0,
+   .date = 10333,
+   .cs = 0,
+   .time_offset = 0,
+   },
+   {
+   .name = "Year 2100 not leap year (2100-03-01 00:00:00)",
+   .ts = {.tv_sec = 4107542400LL, .tv_nsec = 0L},
+   .time = 0,
+   .date = 61537,
+   .cs = 0,
+   .time_offset = 0,
+   },
+   {
+   .name = "Leap year + timezone UTC+1 (== 2004-02-29 00:30:00 
UTC)",
+   .ts = {.tv_sec = 1078014600LL, .tv_nsec = 0L},
+   .time = 48064,
+   .date = 12380,
+   .cs = 0,
+   .time_offset = -60,
+   },
+   {
+   .name = "Leap year + timezone UTC-1 (== 2004-02-29 23:30:00 
UTC)",
+   .ts = {.tv_

Re: [PATCH v2] checkpatch: add new exception to repeated word check

[Joe Perches]

On Wed, 2020-10-14 at 11:35 -0700, Joe Perches wrote:
> On Wed, 2020-10-14 at 23:42 +0530, Dwaipayan Ray wrote:
> > On Wed, Oct 14, 2020 at 11:33 PM Joe Perches  wrote:
> > > On Wed, 2020-10-14 at 22:07 +0530, Dwaipayan Ray wrote:
> > > > Recently, commit 4f6ad8aa1eac ("checkpatch: move repeated word test")
> > > > moved the repeated word test to check for more file types. But after
> > > > this, if checkpatch.pl is run on MAINTAINERS, it generates several
> > > > new warnings of the type:
> > > 
> > > Perhaps instead of adding more content checks so that
> > > word boundaries are not something like \S but also
> > > not punctuation so that content like
> > > 
> > > git git://
> > > @size size
> > > 
> > > does not match?
> > > 
> > > 
> > Hi,
> > So currently the words are trimmed of non alphabets before the check:
> > 
> > while ($rawline =~ /\b($word_pattern) (?=($word_pattern))/g) {
> > my $first = $1;
> > my $second = $2;
> > 
> > where, the word_pattern is:
> > my $word_pattern = '\b[A-Z]?[a-z]{2,}\b';
> 
> I'm familiar.
> 
> > So do you perhaps recommend modifying this word pattern to
> > include the punctuation as well rather than trimming them off?
> 
> Not really, perhaps use the capture group position
> markers @- @+ or $-[1] $+[1] and $-[2] $+[2] with the
> substr could be used to see what characters are
> before and after the word matches.

Perhaps something like:
---
 scripts/checkpatch.pl | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index fab38b493cef..a65eb40a5539 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -3054,15 +3054,25 @@ sub process {
 
my $first = $1;
my $second = $2;
+   my $start_pos = $-[1];
+   my $end_pos = $+[2];
 
if ($first =~ /(?:struct|union|enum)/) {
pos($rawline) += length($first) + 
length($second) + 1;
next;
}
 
-   next if ($first ne $second);
+   next if (lc($first) ne lc($second));
next if ($first eq 'long');
 
+   my $start_char = "";
+   my $end_char = "";
+   $start_char = substr($rawline, $start_pos - 1, 
1) if ($start_pos > 0);
+   $end_char = substr($rawline, $end_pos, 1) if 
(length($rawline) > $end_pos);
+
+   next if ($start_char =~ /^\S$/);
+   next if ($end_char !~ /^[\.\,\s]?$/);
+
if (WARN("REPEATED_WORD",
 "Possible repeated word: '$first'\n" . 
$herecurr) &&
$fix) {

Dearest beloved in the Lord,

[Mrs. Barbara Roth.]

Dearest beloved in the Lord,

Mine names are Mrs. Barbara Roth, I am a 66 years old woman. My beloved late 
husband is from United Kingdom England, while I am of a Dutch nationality by 
birth .I was born an orphan and GOD blessed me and mine late beloved husband 
with abundantly with riches but no children. I am not a happy woman because i 
have no husband or children, my husband died 21 years ago. Right now I am 
affected with cancer of the lung and breast i also have partial stroke which 
has affected my speeches. I can no longer talk well and half of my body is 
paralyzed, i send this email to you with the help of my private female nurse 
who is typing my request at China cancer research facility.

My condition is really deteriorating and is quite obvious that i may not live 
more than 3 weeks, because the cancer stage has gotten to its 3rd stage. After 
my Doctor Notice, i have decided to divide part of my fortune by contributing 
to the Charities & Motherless. I don't know you but i am contacting you with 
the hope that, you will be able to carry out my wish for the sake of humanity.

I am willing to donate the sum of ￡10,500,000.00, Ten Million Five Hundred 
Thousand, Great Britain Pound to the poor through you. I have also made some 
cash donations to orphanage children in Somalia, Syria, Ethiopian, Cambodia, 
Philippines, South Sudan and some in South Africa and Europe.

If you are willing and able to do this task for the sake of humanity then send 
me below information for more details to receive the funds.
1. Name...
2. Phone number...
3. Address.
May GOD guide you.

Mrs. Barbara Roth.

Re: [PATCH] video: fbdev: fsl-diu-fb: remove unneeded variable 'res'

[Sam Ravnborg]

On Thu, Sep 10, 2020 at 10:05:58PM +0800, Jason Yan wrote:
> Eliminate the following coccicheck warning:
> 
> drivers/video/fbdev/fsl-diu-fb.c:1428:5-8: Unneeded variable: "res".
> Return "0" on line 1450
> 
> Reported-by: Hulk Robot 
> Signed-off-by: Jason Yan 

Hi Jason,

applied to drm-misc-next too.

Sam

> ---
>  drivers/video/fbdev/fsl-diu-fb.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/video/fbdev/fsl-diu-fb.c 
> b/drivers/video/fbdev/fsl-diu-fb.c
> index a547c21c7e92..e332017c6af6 100644
> --- a/drivers/video/fbdev/fsl-diu-fb.c
> +++ b/drivers/video/fbdev/fsl-diu-fb.c
> @@ -1425,7 +1425,6 @@ static int fsl_diu_open(struct fb_info *info, int user)
>  static int fsl_diu_release(struct fb_info *info, int user)
>  {
>   struct mfb_info *mfbi = info->par;
> - int res = 0;
>  
>   spin_lock(&diu_lock);
>   mfbi->count--;
> @@ -1447,7 +1446,7 @@ static int fsl_diu_release(struct fb_info *info, int 
> user)
>   }
>  
>   spin_unlock(&diu_lock);
> - return res;
> + return 0;
>  }
>  
>  static const struct fb_ops fsl_diu_ops = {
> -- 
> 2.25.4
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] video: fbdev: sis: remove unneeded semicolon

[Sam Ravnborg]

On Thu, Sep 10, 2020 at 10:05:36PM +0800, Jason Yan wrote:
> Eliminate the following coccicheck warning:
> 
> drivers/video/fbdev/sis/sis_accel.h:143:72-73: Unneeded semicolon
> drivers/video/fbdev/sis/sis_accel.h:144:72-73: Unneeded semicolon
> drivers/video/fbdev/sis/sis_accel.h:145:72-73: Unneeded semicolon
> drivers/video/fbdev/sis/sis_accel.h:273:75-76: Unneeded semicolon
> drivers/video/fbdev/sis/sis_accel.h:274:75-76: Unneeded semicolon
> drivers/video/fbdev/sis/sis_accel.h:275:73-74: Unneeded semicolon
> drivers/video/fbdev/sis/sis_accel.h:276:75-76: Unneeded semicolon
> 
> Reported-by: Hulk Robot 
> Signed-off-by: Jason Yan 

Applied to drm-misc-next.
checkpatch was not happy with the patch - but I ignored these warnings
as this is an old code base.

Sam

Re: [PATCH] drm/mediatek: Optimize functions which do not need to return

[Chun-Kuang Hu]

Bernard Zhao  於 2020年10月13日 週二 下午4:55寫道：
>
> Function mtk_hdmi_aud_set_input always return 0, no need to
> keep the return value. Functions mtk_hdmi_aud_enable_packet &
> mtk_hdmi_aud_on_off_hw_ncts are the same, these two functions
> just call next functions. Maybe it`s a bit better to just call
> the inner function.

Reviewed-by: Chun-Kuang Hu 

>
> Signed-off-by: Bernard Zhao 
> ---
>  drivers/gpu/drm/mediatek/mtk_hdmi.c | 27 +++
>  1 file changed, 7 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c 
> b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> index a97725680d4e..f1d987df0550 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> @@ -870,19 +870,8 @@ static void mtk_hdmi_video_set_display_mode(struct 
> mtk_hdmi *hdmi,
> mtk_hdmi_hw_msic_setting(hdmi, mode);
>  }
>
> -static int mtk_hdmi_aud_enable_packet(struct mtk_hdmi *hdmi, bool enable)
> -{
> -   mtk_hdmi_hw_send_aud_packet(hdmi, enable);
> -   return 0;
> -}
>
> -static int mtk_hdmi_aud_on_off_hw_ncts(struct mtk_hdmi *hdmi, bool on)
> -{
> -   mtk_hdmi_hw_ncts_enable(hdmi, on);
> -   return 0;
> -}
> -
> -static int mtk_hdmi_aud_set_input(struct mtk_hdmi *hdmi)
> +static void mtk_hdmi_aud_set_input(struct mtk_hdmi *hdmi)
>  {
> enum hdmi_aud_channel_type chan_type;
> u8 chan_count;
> @@ -912,8 +901,6 @@ static int mtk_hdmi_aud_set_input(struct mtk_hdmi *hdmi)
> chan_count = mtk_hdmi_aud_get_chnl_count(chan_type);
> mtk_hdmi_hw_aud_set_i2s_chan_num(hdmi, chan_type, chan_count);
> mtk_hdmi_hw_aud_set_input_type(hdmi, hdmi->aud_param.aud_input_type);
> -
> -   return 0;
>  }
>
>  static int mtk_hdmi_aud_set_src(struct mtk_hdmi *hdmi,
> @@ -921,7 +908,7 @@ static int mtk_hdmi_aud_set_src(struct mtk_hdmi *hdmi,
>  {
> unsigned int sample_rate = hdmi->aud_param.codec_params.sample_rate;
>
> -   mtk_hdmi_aud_on_off_hw_ncts(hdmi, false);
> +   mtk_hdmi_hw_ncts_enable(hdmi, false);
> mtk_hdmi_hw_aud_src_disable(hdmi);
> mtk_hdmi_clear_bits(hdmi, GRL_CFG2, CFG2_ACLK_INV);
>
> @@ -959,7 +946,7 @@ static int mtk_hdmi_aud_output_config(struct mtk_hdmi 
> *hdmi,
>   struct drm_display_mode *display_mode)
>  {
> mtk_hdmi_hw_aud_mute(hdmi);
> -   mtk_hdmi_aud_enable_packet(hdmi, false);
> +   mtk_hdmi_hw_send_aud_packet(hdmi, false);
>
> mtk_hdmi_aud_set_input(hdmi);
> mtk_hdmi_aud_set_src(hdmi, display_mode);
> @@ -968,8 +955,8 @@ static int mtk_hdmi_aud_output_config(struct mtk_hdmi 
> *hdmi,
>
> usleep_range(50, 100);
>
> -   mtk_hdmi_aud_on_off_hw_ncts(hdmi, true);
> -   mtk_hdmi_aud_enable_packet(hdmi, true);
> +   mtk_hdmi_hw_ncts_enable(hdmi, true);
> +   mtk_hdmi_hw_send_aud_packet(hdmi, true);
> mtk_hdmi_hw_aud_unmute(hdmi);
> return 0;
>  }
> @@ -1097,13 +1084,13 @@ static int mtk_hdmi_output_init(struct mtk_hdmi *hdmi)
>
>  static void mtk_hdmi_audio_enable(struct mtk_hdmi *hdmi)
>  {
> -   mtk_hdmi_aud_enable_packet(hdmi, true);
> +   mtk_hdmi_hw_send_aud_packet(hdmi, true);
> hdmi->audio_enable = true;
>  }
>
>  static void mtk_hdmi_audio_disable(struct mtk_hdmi *hdmi)
>  {
> -   mtk_hdmi_aud_enable_packet(hdmi, false);
> +   mtk_hdmi_hw_send_aud_packet(hdmi, false);
> hdmi->audio_enable = false;
>  }
>
> --
> 2.28.0
>

[PATCH] drivers/thermal: remove unnecessary structure members allocated_tzp

[Bernard Zhao]

Struct power_allocator_params element allocated_tzp is only used
in unbind to kfree the kzalloc space.
Maybe we don’t have to need this member to mark, also, kfree will
handle NULL point, there is no risk.
This change is to make the code run a bit fast.

Signed-off-by: Bernard Zhao 
---
 drivers/thermal/gov_power_allocator.c | 11 ++-
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/drivers/thermal/gov_power_allocator.c 
b/drivers/thermal/gov_power_allocator.c
index 5cb518d8f156..e4672a94e6b1 100644
--- a/drivers/thermal/gov_power_allocator.c
+++ b/drivers/thermal/gov_power_allocator.c
@@ -51,8 +51,6 @@ static inline s64 div_frac(s64 x, s64 y)
 
 /**
  * struct power_allocator_params - parameters for the power allocator governor
- * @allocated_tzp: whether we have allocated tzp for this thermal zone and
- * it needs to be freed on unbind
  * @err_integral:  accumulated error in the PID controller.
  * @prev_err:  error in the previous iteration of the PID controller.
  * Used to calculate the derivative term.
@@ -65,7 +63,6 @@ static inline s64 div_frac(s64 x, s64 y)
  * controlling for.
  */
 struct power_allocator_params {
-   bool allocated_tzp;
s64 err_integral;
s32 prev_err;
int trip_switch_on;
@@ -556,8 +553,6 @@ static int power_allocator_bind(struct thermal_zone_device 
*tz)
ret = -ENOMEM;
goto free_params;
}
-
-   params->allocated_tzp = true;
}
 
if (!tz->tzp->sustainable_power)
@@ -593,10 +588,8 @@ static void power_allocator_unbind(struct 
thermal_zone_device *tz)
 
dev_dbg(&tz->device, "Unbinding from thermal zone %d\n", tz->id);
 
-   if (params->allocated_tzp) {
-   kfree(tz->tzp);
-   tz->tzp = NULL;
-   }
+   kfree(tz->tzp);
+   tz->tzp = NULL;
 
kfree(tz->governor_data);
tz->governor_data = NULL;
-- 
2.28.0

Re: [PATCH -next] omapfb: connector-dvi: simplify the return expression of dvic_connect()

[Sam Ravnborg]

Hi Liu.

On Tue, Sep 15, 2020 at 11:26:27AM +0800, Liu Shixin wrote:
> Simplify the return expression.
> 
> Signed-off-by: Liu Shixin 

Thanks, also applied.
If you have other drm/fbdev patches pending then I have missed them.
So please resend if this is the case.

Sam

> ---
>  drivers/video/fbdev/omap2/omapfb/displays/connector-dvi.c | 7 +--
>  1 file changed, 1 insertion(+), 6 deletions(-)
> 
> diff --git a/drivers/video/fbdev/omap2/omapfb/displays/connector-dvi.c 
> b/drivers/video/fbdev/omap2/omapfb/displays/connector-dvi.c
> index b4a1aefff766..2fa436475b40 100644
> --- a/drivers/video/fbdev/omap2/omapfb/displays/connector-dvi.c
> +++ b/drivers/video/fbdev/omap2/omapfb/displays/connector-dvi.c
> @@ -51,16 +51,11 @@ static int dvic_connect(struct omap_dss_device *dssdev)
>  {
>   struct panel_drv_data *ddata = to_panel_data(dssdev);
>   struct omap_dss_device *in = ddata->in;
> - int r;
>  
>   if (omapdss_device_is_connected(dssdev))
>   return 0;
>  
> - r = in->ops.dvi->connect(in, dssdev);
> - if (r)
> - return r;
> -
> - return 0;
> + return in->ops.dvi->connect(in, dssdev);
>  }
>  
>  static void dvic_disconnect(struct omap_dss_device *dssdev)
> -- 
> 2.25.1
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: UBSAN: array-index-out-of-bounds in alg_bind

[Jann Horn]

+linux-api because this is about fixing UAPI without breaking userspace

On Sat, Oct 17, 2020 at 8:02 AM Kees Cook  wrote:
> On Fri, Oct 16, 2020 at 01:12:24AM -0700, syzbot wrote:
> > dashboard link: https://syzkaller.appspot.com/bug?extid=92ead4eb8e26a26d465e
> > [...]
> > Reported-by: syzbot+92ead4eb8e26a26d4...@syzkaller.appspotmail.com
> > [...]
> > UBSAN: array-index-out-of-bounds in crypto/af_alg.c:166:2
> > index 91 is out of range for type '__u8 [64]'
>
> This seems to be an "as intended", if very odd. false positive (the actual
> memory area is backed by the on-stack _K_SS_MAXSIZE-sized sockaddr_storage
> "address" variable in __sys_bind. But yes, af_alg's salg_name member
> size here doesn't make sense. The origin appears to be that 3f69cc60768b
> ("crypto: af_alg - Allow arbitrarily long algorithm names") intentionally
> didn't extend the kernel structure (which is actually just using the UAPI
> structure). I don't see a reason the UAPI couldn't have been extended:
> it's a sockaddr implementation, so the size is always passed in as part
> of the existing API.

If you e.g. recompiled the wrong parts of the "btcheck" project with
such changed UAPI headers, I think you'd get OOB writes, because they
have this in a header
(https://sources.debian.org/src/btcheck/2.1-4/src/kernelcryptoapi.h/?hl=29#L29):

typedef struct {
  struct sockaddr_alg sa;
  int safd;
  int fd;
} lkca_hash_ctx;

so if you rebuilt e.g. kernelcryptoapi.o (which uses the struct)
without also rebuilding hash.o (which allocates the struct), code in
kernelcryptoapi.o would write beyond the end of lkca_hash_ctx, I
think.

Sure, there aren't many places that do this kind of thing for this
struct. But at least in theory, you can't change the size of UAPI
structs because someone might be passing instances of that struct
around between object files.

> At the very least the kernel needs to switch to using a correctly-sized
> structure: I expected UBSAN_BOUNDS to be enabled globally by default at
> some point in the future (with the minimal runtime -- the
> instrumentation is tiny and catches real issues).

Yeah, the kernel should probably use a struct that looks different
from the userspace one. :/ I guess we'll probably end up with some
ugly hack with "#ifdef __KERNEL__", where the same struct has
different sizes between kernel and userspace? Or am I being too
puritan about UAPI consistency?

> Reproduction:
>
> struct sockaddr_alg sa = {
> .salg_family = AF_ALG,
> .salg_type = "skcipher",
> .salg_name = "cbc(aes)"
> };
> fd = socket(AF_ALG, SOCK_SEQPACKET, 0);
> bind(fd, (void *)&sa, sizeof(sa));
>
> Replace "sizeof(sa)" with x where 64

Re: [PATCH -next] drm/panel: simplify the return expression of rb070d30_panel_enable()

[Sam Ravnborg]

Hi Liu

On Tue, Sep 15, 2020 at 11:26:23AM +0800, Liu Shixin wrote:
> Simplify the return expression.
> 
> Signed-off-by: Liu Shixin 

Thanks, applied to drm-misc-next.
The patch will appear in drm-misc-next in a few weeks.

Sam

> ---
>  drivers/gpu/drm/panel/panel-ronbo-rb070d30.c | 7 +--
>  1 file changed, 1 insertion(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/panel/panel-ronbo-rb070d30.c 
> b/drivers/gpu/drm/panel/panel-ronbo-rb070d30.c
> index 535c8d1cca21..a3782830ae3c 100644
> --- a/drivers/gpu/drm/panel/panel-ronbo-rb070d30.c
> +++ b/drivers/gpu/drm/panel/panel-ronbo-rb070d30.c
> @@ -75,13 +75,8 @@ static int rb070d30_panel_unprepare(struct drm_panel 
> *panel)
>  static int rb070d30_panel_enable(struct drm_panel *panel)
>  {
>   struct rb070d30_panel *ctx = panel_to_rb070d30_panel(panel);
> - int ret;
>  
> - ret = mipi_dsi_dcs_exit_sleep_mode(ctx->dsi);
> - if (ret)
> - return ret;
> -
> - return 0;
> + return mipi_dsi_dcs_exit_sleep_mode(ctx->dsi);
>  }
>  
>  static int rb070d30_panel_disable(struct drm_panel *panel)
> -- 
> 2.25.1
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] staging: wfx: make a const array static, makes object smaller

[Joe Perches]

On Fri, 2020-10-16 at 23:33 +0100, Colin King wrote:
> From: Colin Ian King 
> 
> Don't populate const array filter_ies on the stack but instead
> make it static. Makes the object code smaller by 261 bytes.
> 
> Before:
>text  data bss dec hex filename
>   21674  3166 448   2528862c8 drivers/staging/wfx/sta.o
> 
> After:
>text  data bss dec hex filename
>   21349  3230 448   2502761c3 drivers/staging/wfx/sta.o

Thanks.

It's odd to me it's so large a change as it's only
24 bytes of initialization. (3 entries, each 8 bytes)

This line in the same function:

hif_set_beacon_filter_table(wvif, 3, filter_ies);

might as well use ARRAY_SIZE(filter_ies) instead of 3

Re: [PATCH v4 0/4] drm: panel: add support for TDO tl070wsh30 panel

[Sam Ravnborg]

Hi Neil.

On Tue, Sep 29, 2020 at 11:25:17AM +0200, Neil Armstrong wrote:
> Hi Sam,
> 
> Is there anything more to change ?
Sorry for taking so long to get back to you on this.

All patches looks good and are:
Reviewed-by: Sam Ravnborg 

I assume you will apply the patches.

Sam

Re: For review: seccomp_user_notif(2) manual page

[Jann Horn]

On Fri, Oct 16, 2020 at 8:29 PM Michael Kerrisk (man-pages)
 wrote:
> On 10/15/20 10:32 PM, Jann Horn wrote:
> > On Thu, Oct 15, 2020 at 1:24 PM Michael Kerrisk (man-pages)
> >  wrote:
> >> On 9/30/20 5:53 PM, Jann Horn wrote:
> >>> On Wed, Sep 30, 2020 at 1:07 PM Michael Kerrisk (man-pages)
> >>>  wrote:
>  I knew it would be a big ask, but below is kind of the manual page
>  I was hoping you might write [1] for the seccomp user-space notification
>  mechanism. Since you didn't (and because 5.9 adds various new pieces
>  such as SECCOMP_ADDFD_FLAG_SETFD and SECCOMP_IOCTL_NOTIF_ADDFD
>  that also will need documenting [2]), I did :-). But of course I may
>  have made mistakes...
> > [...]
> 3. The supervisor process will receive notification events on the
>    listening  file  descriptor.   These  events  are  returned as
>    structures of type seccomp_notif.  Because this structure  and
>    its  size may evolve over kernel versions, the supervisor must
>    first determine the size of  this  structure  using  the  sec‐
>    comp(2)  SECCOMP_GET_NOTIF_SIZES  operation,  which  returns a
>    structure of type seccomp_notif_sizes.  The  supervisor  allo‐
>    cates a buffer of size seccomp_notif_sizes.seccomp_notif bytes
>    to receive notification events.   In  addition,the  supervisor
>    allocates  another  buffer  of  size  seccomp_notif_sizes.sec‐
>    comp_notif_resp  bytes  for  the  response  (a   struct   sec‐
>    comp_notif_resp  structure) that it will provide to the kernel
>    (and thus the target process).
> 
> 4. The target process then performs its workload, which  includes
>    system  calls  that  will be controlled by the seccomp filter.
>    Whenever one of these system calls causes the filter to return
>    the  SECCOMP_RET_USER_NOTIF  action value, the kernel does not
>    execute the system call;  instead,  execution  of  the  target
>    process is temporarily blocked inside the kernel and a notifi‐
> >>>
> >>> where "blocked" refers to the interruptible, restartable kind - if the
> >>> child receives a signal with an SA_RESTART signal handler in the
> >>> meantime, it'll leave the syscall, go through the signal handler, then
> >>> restart the syscall again and send the same request to the supervisor
> >>> again. so the supervisor may see duplicate syscalls.
> >>
> >> So, I partially demonstrated what you describe here, for two example
> >> system calls (epoll_wait() and pause()). But I could not exactly
> >> demonstrate things as I understand you to be describing them. (So,
> >> I'm not sure whether I have not understood you correctly, or
> >> if things are not exactly as you describe them.)
> >>
> >> Here's a scenario (A) that I tested:
> >>
> >> 1. Target installs seccomp filters for a blocking syscall
> >>(epoll_wait() or pause(), both of which should never restart,
> >>regardless of SA_RESTART)
> >> 2. Target installs SIGINT handler with SA_RESTART
> >> 3. Supervisor is sleeping (i.e., is not blocked in
> >>SECCOMP_IOCTL_NOTIF_RECV operation).
> >> 4. Target makes a blocking system call (epoll_wait() or pause()).
> >> 5. SIGINT gets delivered to target; handler gets called;
> >>***and syscall gets restarted by the kernel***
> >>
> >> That last should never happen, of course, and is a result of the
> >> combination of both the user-notify filter and the SA_RESTART flag.
> >> If one or other is not present, then the system call is not
> >> restarted.
> >>
> >> So, as you note below, the UAPI gets broken a little.
> >>
> >> However, from your description above I had understood that
> >> something like the following scenario (B) could occur:
> >>
> >> 1. Target installs seccomp filters for a blocking syscall
> >>(epoll_wait() or pause(), both of which should never restart,
> >>regardless of SA_RESTART)
> >> 2. Target installs SIGINT handler with SA_RESTART
> >> 3. Supervisor performs SECCOMP_IOCTL_NOTIF_RECV operation (which
> >>blocks).
> >> 4. Target makes a blocking system call (epoll_wait() or pause()).
> >> 5. Supervisor gets seccomp user-space notification (i.e.,
> >>SECCOMP_IOCTL_NOTIF_RECV ioctl() returns
> >> 6. SIGINT gets delivered to target; handler gets called;
> >>and syscall gets restarted by the kernel
> >> 7. Supervisor performs another SECCOMP_IOCTL_NOTIF_RECV operation
> >>which gets another notification for the restarted system call.
> >>
> >> However, I don't observe such behavior. In step 6, the syscall
> >> does not get restarted by the kernel, but instead returns -1/EINTR.
> >> Perhaps I have misconstructed my experiment in the second case, or
> >> perhaps I've misunderstood what you meant, or is it possibly the
> >> case that things are not quite as you said?
>
>

Re: [PATCH v3] checkpatch: add new exception to repeated word check

[Dwaipayan Ray]

> Why include a + character here?
>
Hi,
I tried it without + first, but then lines like
"The the repeated word."
didn't register a warning.

I think checkpatch adds a + to the line when used on
files. Am not sure but my $rawline was:
+The the repeated word.

> Please use "next if (test);" to be similar to the other uses above.
>
> And this doesn't work on end of phrase or sentence.
>
> ie: "my sentence is is, a duplicate word word."
>
> so $end_char could be a comma or a period.
>
> so likely the $end_char test should be !~
>

I tried on "my sentence is is, a duplicate word word.",
and got the following:

WARNING: Possible repeated word: 'is'
#8: FILE: MAINTAINERS:8:
+my sentence is is, a duplicate word word.

WARNING: Possible repeated word: 'word'
#8: FILE: MAINTAINERS:8:
+my sentence is is, a duplicate word word.

Am I doing something wrong?

> What is the reason to add and use $exclude_chars?
>
I am comparing both start_char and end_char to find
whether they have the characters which will exclude them
from repeated word check. So i am keeping the common
variable to match from. I thought I would do that so that
more exceptions could be added later on easily.

I might be wrong in doing that. What do you think?

Thanks,
Dwaipayan.

Re: [PATCH v7 2/6] rcu/segcblist: Add counters to segcblist datastructure

[joel]

On Thu, Oct 15, 2020 at 02:21:58PM +0200, Frederic Weisbecker wrote:
> On Wed, Oct 14, 2020 at 08:22:57PM -0400, Joel Fernandes (Google) wrote:
> > Add counting of segment lengths of segmented callback list.
> > 
> > This will be useful for a number of things such as knowing how big the
> > ready-to-execute segment have gotten. The immediate benefit is ability
> > to trace how the callbacks in the segmented callback list change.
> > 
> > Also this patch remove hacks related to using donecbs's ->len field as a
> > temporary variable to save the segmented callback list's length. This 
> > cannot be
> > done anymore and is not needed.
> > 
> > Signed-off-by: Joel Fernandes (Google) 
> > ---
> >  include/linux/rcu_segcblist.h |   2 +
> >  kernel/rcu/rcu_segcblist.c| 133 +++---
> >  kernel/rcu/rcu_segcblist.h|   2 -
> >  3 files changed, 92 insertions(+), 45 deletions(-)
> > 
> > diff --git a/include/linux/rcu_segcblist.h b/include/linux/rcu_segcblist.h
> > index b36afe7b22c9..d462ae5e340a 100644
> > --- a/include/linux/rcu_segcblist.h
> > +++ b/include/linux/rcu_segcblist.h
> > @@ -69,8 +69,10 @@ struct rcu_segcblist {
> > unsigned long gp_seq[RCU_CBLIST_NSEGS];
> >  #ifdef CONFIG_RCU_NOCB_CPU
> > atomic_long_t len;
> > +   atomic_long_t seglen[RCU_CBLIST_NSEGS];
> 
> Also does it really need to be atomic?

Yeah I think not. In fact, I am not even sure if ->len in the existing code
needs to be atomic. I am considering vetting all code paths. Paul told me it
used to be the case that ->len could be lockless written (possibly without
IRQs disabled) I think but that maybe nowadays it is not the case. Let us
double check to be sure.

> > @@ -245,7 +280,7 @@ void rcu_segcblist_enqueue(struct rcu_segcblist *rsclp,
> >struct rcu_head *rhp)
> >  {
> > rcu_segcblist_inc_len(rsclp);
> > -   smp_mb(); /* Ensure counts are updated before callback is enqueued. */
> 
> That's a significant change that shouldn't be hidden and unexplained in an 
> unrelated
> patch or it may be easily missed. I'd suggest to move this line together in
> "rcu/tree: Remove redundant smp_mb() in rcu_do_batch" (with the title updated 
> perhaps)
> and maybe put it in the beginning of the series?

Ok I can do that.

> > +   rcu_segcblist_inc_seglen(rsclp, RCU_NEXT_TAIL);
> > rhp->next = NULL;
> > WRITE_ONCE(*rsclp->tails[RCU_NEXT_TAIL], rhp);
> > WRITE_ONCE(rsclp->tails[RCU_NEXT_TAIL], &rhp->next);
> [...]
> > @@ -330,11 +353,16 @@ void rcu_segcblist_extract_pend_cbs(struct 
> > rcu_segcblist *rsclp,
> >  
> > if (!rcu_segcblist_pend_cbs(rsclp))
> > return; /* Nothing to do. */
> > +   rclp->len = rcu_segcblist_get_seglen(rsclp, RCU_WAIT_TAIL) +
> > +   rcu_segcblist_get_seglen(rsclp, RCU_NEXT_READY_TAIL) +
> > +   rcu_segcblist_get_seglen(rsclp, RCU_NEXT_TAIL);
> > *rclp->tail = *rsclp->tails[RCU_DONE_TAIL];
> > rclp->tail = rsclp->tails[RCU_NEXT_TAIL];
> > WRITE_ONCE(*rsclp->tails[RCU_DONE_TAIL], NULL);
> > -   for (i = RCU_DONE_TAIL + 1; i < RCU_CBLIST_NSEGS; i++)
> > +   for (i = RCU_DONE_TAIL + 1; i < RCU_CBLIST_NSEGS; i++) {
> > WRITE_ONCE(rsclp->tails[i], rsclp->tails[RCU_DONE_TAIL]);
> > +   rcu_segcblist_set_seglen(rsclp, i, 0);
> > +   }
> 
> So, that's probably just a matter of personal preference, so feel free to
> ignore but I'd rather do:
> 
> rclp->len += rcu_segcblist_get_seglen(rsclp, i);
> rcu_segcblist_set_seglen(rsclp, i, 0);
> 
> instead of the big addition above. That way, if a new index ever gets 
> added/renamed
> to the segcblist, we'll take it into account. Also that spares a few lines.

Yeah your way is better, I will do it this way.

thanks,

 - Joel

[PATCH v4 5/7] dma-buf: system_heap: Allocate higher order pages if available

[John Stultz]

While the system heap can return non-contiguous pages,
try to allocate larger order pages if possible.

This will allow slight performance gains and make implementing
page pooling easier.

Cc: Sumit Semwal 
Cc: Liam Mark 
Cc: Laura Abbott 
Cc: Brian Starkey 
Cc: Hridya Valsaraju 
Cc: Suren Baghdasaryan 
Cc: Sandeep Patil 
Cc: Daniel Mentz 
Cc: Chris Goldsworthy 
Cc: Ørjan Eide 
Cc: Robin Murphy 
Cc: Ezequiel Garcia 
Cc: Simon Ser 
Cc: James Jones 
Cc: linux-me...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Reviewed-by: Brian Starkey 
Signed-off-by: John Stultz 
---
v3:
* Use page_size() rather then opencoding it
---
 drivers/dma-buf/heaps/system_heap.c | 83 ++---
 1 file changed, 65 insertions(+), 18 deletions(-)

diff --git a/drivers/dma-buf/heaps/system_heap.c 
b/drivers/dma-buf/heaps/system_heap.c
index 15b36bc862b1..ef4b2c1032df 100644
--- a/drivers/dma-buf/heaps/system_heap.c
+++ b/drivers/dma-buf/heaps/system_heap.c
@@ -40,6 +40,14 @@ struct dma_heap_attachment {
bool mapped;
 };
 
+#define HIGH_ORDER_GFP  (((GFP_HIGHUSER | __GFP_ZERO | __GFP_NOWARN \
+   | __GFP_NORETRY) & ~__GFP_RECLAIM) \
+   | __GFP_COMP)
+#define LOW_ORDER_GFP (GFP_HIGHUSER | __GFP_ZERO | __GFP_COMP)
+static gfp_t order_flags[] = {HIGH_ORDER_GFP, LOW_ORDER_GFP, LOW_ORDER_GFP};
+static const unsigned int orders[] = {8, 4, 0};
+#define NUM_ORDERS ARRAY_SIZE(orders)
+
 static struct sg_table *dup_sg_table(struct sg_table *table)
 {
struct sg_table *new_table;
@@ -270,8 +278,11 @@ static void system_heap_dma_buf_release(struct dma_buf 
*dmabuf)
int i;
 
table = &buffer->sg_table;
-   for_each_sgtable_sg(table, sg, i)
-   __free_page(sg_page(sg));
+   for_each_sg(table->sgl, sg, table->nents, i) {
+   struct page *page = sg_page(sg);
+
+   __free_pages(page, compound_order(page));
+   }
sg_free_table(table);
kfree(buffer);
 }
@@ -289,6 +300,26 @@ static const struct dma_buf_ops system_heap_buf_ops = {
.release = system_heap_dma_buf_release,
 };
 
+static struct page *alloc_largest_available(unsigned long size,
+   unsigned int max_order)
+{
+   struct page *page;
+   int i;
+
+   for (i = 0; i < NUM_ORDERS; i++) {
+   if (size <  (PAGE_SIZE << orders[i]))
+   continue;
+   if (max_order < orders[i])
+   continue;
+
+   page = alloc_pages(order_flags[i], orders[i]);
+   if (!page)
+   continue;
+   return page;
+   }
+   return NULL;
+}
+
 static int system_heap_allocate(struct dma_heap *heap,
unsigned long len,
unsigned long fd_flags,
@@ -296,11 +327,13 @@ static int system_heap_allocate(struct dma_heap *heap,
 {
struct system_heap_buffer *buffer;
DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
+   unsigned long size_remaining = len;
+   unsigned int max_order = orders[0];
struct dma_buf *dmabuf;
struct sg_table *table;
struct scatterlist *sg;
-   pgoff_t pagecount;
-   pgoff_t pg;
+   struct list_head pages;
+   struct page *page, *tmp_page;
int i, ret = -ENOMEM;
 
buffer = kzalloc(sizeof(*buffer), GFP_KERNEL);
@@ -312,25 +345,35 @@ static int system_heap_allocate(struct dma_heap *heap,
buffer->heap = heap;
buffer->len = len;
 
-   table = &buffer->sg_table;
-   pagecount = len / PAGE_SIZE;
-   if (sg_alloc_table(table, pagecount, GFP_KERNEL))
-   goto free_buffer;
-
-   sg = table->sgl;
-   for (pg = 0; pg < pagecount; pg++) {
-   struct page *page;
+   INIT_LIST_HEAD(&pages);
+   i = 0;
+   while (size_remaining > 0) {
/*
 * Avoid trying to allocate memory if the process
 * has been killed by SIGKILL
 */
if (fatal_signal_pending(current))
-   goto free_pages;
-   page = alloc_page(GFP_KERNEL | __GFP_ZERO);
+   goto free_buffer;
+
+   page = alloc_largest_available(size_remaining, max_order);
if (!page)
-   goto free_pages;
+   goto free_buffer;
+
+   list_add_tail(&page->lru, &pages);
+   size_remaining -= page_size(page);
+   max_order = compound_order(page);
+   i++;
+   }
+
+   table = &buffer->sg_table;
+   if (sg_alloc_table(table, i, GFP_KERNEL))
+   goto free_buffer;
+
+   sg = table->sgl;
+   list_for_each_entry_safe(page, tmp_page, &pages, lru) {
sg_set_page(sg, page, page_size(page), 0);
sg = sg_next(sg);
+   list_del(&page->lru);
 

Re: [PATCH 2/2] ASoC: fsl_spdif: Add support for i.MX8QM platform

[Nicolin Chen]

On Thu, Oct 15, 2020 at 01:28:48PM +0800, Shengjiu Wang wrote:
> On i.MX8QM, there are separate interrupts for TX and RX.
> 
> As the EDMA can't be configured to swing back to first FIFO
> after writing the second FIFO, so we need to force the burst
> size to be 2 on i.MX8QM. And EDMA don't support to shift
> the data from S24_LE to S16_LE, so the supported TX format
> is also different on i.MX8QM.
> 
> Signed-off-by: Shengjiu Wang 

One small nit, yet I am okay if you don't resend. So:

Acked-by: Nicolin Chen 

>  /* Check if clk is a root clock that does not share clock source with others 
> */
> @@ -1283,6 +1313,8 @@ static int fsl_spdif_probe(struct platform_device *pdev)
>   /* Initialize this copy of the CPU DAI driver structure */
>   memcpy(&spdif_priv->cpu_dai_drv, &fsl_spdif_dai, sizeof(fsl_spdif_dai));
>   spdif_priv->cpu_dai_drv.name = dev_name(&pdev->dev);
> + spdif_priv->cpu_dai_drv.playback.formats =
> + spdif_priv->soc->tx_formats;

Kernel no longer has strict 80-character limit now, and it seems
to fits 80 characters?

Re: [PATCH v7 6/6] rcu/segcblist: Add additional comments to explain smp_mb()

[joel]

Adding Alan as well as its memory barrier discussion ;-)

On Thu, Oct 15, 2020 at 03:35:11PM +0200, Frederic Weisbecker wrote:
> On Wed, Oct 14, 2020 at 08:23:01PM -0400, Joel Fernandes (Google) wrote:
> > Memory barriers are needed when updating the full length of the
> > segcblist, however it is not fully clearly why one is needed before and
> > after. This patch therefore adds additional comments to the function
> > header to explain it.
> > 
> > Signed-off-by: Joel Fernandes (Google) 
> > ---
> >  kernel/rcu/rcu_segcblist.c | 38 ++
> >  1 file changed, 34 insertions(+), 4 deletions(-)
> > 
> > diff --git a/kernel/rcu/rcu_segcblist.c b/kernel/rcu/rcu_segcblist.c
> > index 271d5d9d7f60..25ffd07f9951 100644
> > --- a/kernel/rcu/rcu_segcblist.c
> > +++ b/kernel/rcu/rcu_segcblist.c
> > @@ -147,17 +147,47 @@ static void rcu_segcblist_inc_seglen(struct 
> > rcu_segcblist *rsclp, int seg)
> >   * field to disagree with the actual number of callbacks on the structure.
> >   * This increase is fully ordered with respect to the callers accesses
> >   * both before and after.
> > + *
> > + * About memory barriers:
> > + * There is a situation where rcu_barrier() locklessly samples the full
> > + * length of the segmented cblist before deciding what to do. That can
> > + * race with another path that calls this function. rcu_barrier() should
> > + * not wrongly assume there are no callbacks, so any transitions from 1->0
> > + * and 0->1 have to be carefully ordered with respect to list 
> > modifications.
> > + *
> > + * Memory barrier is needed before adding to length, for the case where
> > + * v is negative which does not happen in current code, but used
> > + * to happen. Keep the memory barrier for robustness reasons.
> 
> Heh, I seem to recongnize someone's decision's style ;-)

Actually, the last paragraph I added is bogus. Indeed this memory barrier is
not just for robustness reasons. It is needed because rcu_do_batch() adjusts
the length of the list (possibly to 0) _after_ executing the callbacks, so
that's a negative number:
rcu_segcblist_add_len(&rdp->cblist, -count);

> > When/If the
> > + * length transitions from 1 -> 0, the write to 0 has to be ordered *after*
> > + * the memory accesses of the CBs that were dequeued and the segcblist
> > + * modifications:
> > + * P0 (what P1 sees)   P1
> > + * set len = 0
> > + *  rcu_barrier sees len as 0
> > + * dequeue from list
> > + *  rcu_barrier does nothing.
> 
> It's a bit difficult to read that way. So that would be:
> 
> 
>   rcu_do_batch()rcu_barrier()
>   ----
>   dequeue   l = READ(len)
>   smp_mb()  if (!l)
>   WRITE(len, 0) check next CPU...
> 
> But I'm a bit confused against what it pairs in rcu_barrier().

I believe it pairs with an implied memory barrier via control dependency.

The following litmus test would confirm it:

C rcubarrier+ctrldep

(*
 * Result: Never
 *
 * This litmus test shows that rcu_barrier (P1) prematurely
 * returning by reading len 0 can cause issues if P0 does
 * NOT have a smb_mb() before WRITE_ONCE().
 *
 * mod_data == 2 means garbage which the callback should never see.
 *)

{ int len = 1; }

P0(int *len, int *mod_data)
{
int r0;

// accessed by say RCU callback in rcu_do_batch();
r0 = READ_ONCE(*mod_data);
smp_mb(); // Remove this and the "exists" will become true.
WRITE_ONCE(*len, 0);
}

P1(int *len, int *mod_data)
{
int r0;

r0 = READ_ONCE(*len);

// rcu_barrier will return early if len is 0
if (r0 == 0)
WRITE_ONCE(*mod_data, 2);
}

// Is it possible?
exists (0:r0=2 /\ 1:r0=0)

> > + *
> > + * Memory barrier is needed after adding to length for the case
> > + * where length transitions from 0 -> 1. This is because rcu_barrier()
> > + * should never miss an update to the length. So the update to length
> > + * has to be seen *before* any modifications to the segmented list. 
> > Otherwise a
> > + * race can happen.
> > + * P0 (what P1 sees)   P1
> > + * queue to list
> > + *  rcu_barrier sees len as 0
> > + * set len = 1.
> > + *  rcu_barrier does nothing.
> 
> So that would be:
> 
>   call_rcu()rcu_barrier()
>   ----
>   WRITE(len, len + 1)   l = READ(len)
>   smp_mb()  if (!l)
>   queuecheck next CPU...
> 
> 
> But I still don't see against what it pairs in rcu_barrier.

Actually, for the second case maybe a similar reasoning can be applied
(control dependency) but I'm unable to come up with a litmus test.
In fact, now I'm wondering how is it possible that call_rcu() races with
rcu_barrier(). The module should ensure that no more call_rcu() should happe

Re: [PATCH v4 1/2] ASoC: fsl_xcvr: Add XCVR ASoC CPU DAI driver

[Nicolin Chen]

On Tue, Oct 13, 2020 at 03:17:32PM +0300, Viorel Suman (OSS) wrote:
> From: Viorel Suman 
> 
> XCVR (Audio Transceiver) is a on-chip functional module found
> on i.MX8MP. It support HDMI2.1 eARC, HDMI1.4 ARC and SPDIF.
> 
> Signed-off-by: Viorel Suman 

Acked-by: Nicolin Chen 

[PATCH v4 4/7] dma-buf: heaps: Skip sync if not mapped

[John Stultz]

This patch is basically a port of Ørjan Eide's similar patch for ION
 https://lore.kernel.org/lkml/20200414134629.54567-1-orjan.e...@arm.com/

Only sync the sg-list of dma-buf heap attachment when the attachment
is actually mapped on the device.

dma-bufs may be synced at any time. It can be reached from user space
via DMA_BUF_IOCTL_SYNC, so there are no guarantees from callers on when
syncs may be attempted, and dma_buf_end_cpu_access() and
dma_buf_begin_cpu_access() may not be paired.

Since the sg_list's dma_address isn't set up until the buffer is used
on the device, and dma_map_sg() is called on it, the dma_address will be
NULL if sync is attempted on the dma-buf before it's mapped on a device.

Before v5.0 (commit 55897af63091 ("dma-direct: merge swiotlb_dma_ops
into the dma_direct code")) this was a problem as the dma-api (at least
the swiotlb_dma_ops on arm64) would use the potentially invalid
dma_address. How that failed depended on how the device handled physical
address 0. If 0 was a valid address to physical ram, that page would get
flushed a lot, while the actual pages in the buffer would not get synced
correctly. While if 0 is an invalid physical address it may cause a
fault and trigger a crash.

In v5.0 this was incidentally fixed by commit 55897af63091 ("dma-direct:
merge swiotlb_dma_ops into the dma_direct code"), as this moved the
dma-api to use the page pointer in the sg_list, and (for Ion buffers at
least) this will always be valid if the sg_list exists at all.

But, this issue is re-introduced in v5.3 with
commit 449fa54d6815 ("dma-direct: correct the physical addr in
dma_direct_sync_sg_for_cpu/device") moves the dma-api back to the old
behaviour and picks the dma_address that may be invalid.

dma-buf core doesn't ensure that the buffer is mapped on the device, and
thus have a valid sg_list, before calling the exporter's
begin_cpu_access.

Logic and commit message originally by: Ørjan Eide 

Cc: Sumit Semwal 
Cc: Liam Mark 
Cc: Laura Abbott 
Cc: Brian Starkey 
Cc: Hridya Valsaraju 
Cc: Suren Baghdasaryan 
Cc: Sandeep Patil 
Cc: Daniel Mentz 
Cc: Chris Goldsworthy 
Cc: Ørjan Eide 
Cc: Robin Murphy 
Cc: Ezequiel Garcia 
Cc: Simon Ser 
Cc: James Jones 
Cc: linux-me...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Reviewed-by: Brian Starkey 
Signed-off-by: John Stultz 
---
 drivers/dma-buf/heaps/cma_heap.c| 10 ++
 drivers/dma-buf/heaps/system_heap.c | 10 ++
 2 files changed, 20 insertions(+)

diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c
index d6fab7cdeaf9..d7f5d3d7a0c0 100644
--- a/drivers/dma-buf/heaps/cma_heap.c
+++ b/drivers/dma-buf/heaps/cma_heap.c
@@ -44,6 +44,7 @@ struct dma_heap_attachment {
struct device *dev;
struct sg_table table;
struct list_head list;
+   bool mapped;
 };
 
 static int cma_heap_attach(struct dma_buf *dmabuf,
@@ -68,6 +69,7 @@ static int cma_heap_attach(struct dma_buf *dmabuf,
 
a->dev = attachment->dev;
INIT_LIST_HEAD(&a->list);
+   a->mapped = false;
 
attachment->priv = a;
 
@@ -102,6 +104,7 @@ static struct sg_table *cma_heap_map_dma_buf(struct 
dma_buf_attachment *attachme
ret = dma_map_sgtable(attachment->dev, table, direction, 0);
if (ret)
return ERR_PTR(-ENOMEM);
+   a->mapped = true;
return table;
 }
 
@@ -109,6 +112,9 @@ static void cma_heap_unmap_dma_buf(struct 
dma_buf_attachment *attachment,
   struct sg_table *table,
   enum dma_data_direction direction)
 {
+   struct dma_heap_attachment *a = attachment->priv;
+
+   a->mapped = false;
dma_unmap_sgtable(attachment->dev, table, direction, 0);
 }
 
@@ -123,6 +129,8 @@ static int cma_heap_dma_buf_begin_cpu_access(struct dma_buf 
*dmabuf,
 
mutex_lock(&buffer->lock);
list_for_each_entry(a, &buffer->attachments, list) {
+   if (!a->mapped)
+   continue;
dma_sync_sgtable_for_cpu(a->dev, &a->table, direction);
}
mutex_unlock(&buffer->lock);
@@ -141,6 +149,8 @@ static int cma_heap_dma_buf_end_cpu_access(struct dma_buf 
*dmabuf,
 
mutex_lock(&buffer->lock);
list_for_each_entry(a, &buffer->attachments, list) {
+   if (!a->mapped)
+   continue;
dma_sync_sgtable_for_device(a->dev, &a->table, direction);
}
mutex_unlock(&buffer->lock);
diff --git a/drivers/dma-buf/heaps/system_heap.c 
b/drivers/dma-buf/heaps/system_heap.c
index 5c44f9c06807..15b36bc862b1 100644
--- a/drivers/dma-buf/heaps/system_heap.c
+++ b/drivers/dma-buf/heaps/system_heap.c
@@ -37,6 +37,7 @@ struct dma_heap_attachment {
struct device *dev;
struct sg_table *table;
struct list_head list;
+   bool mapped;
 };
 
 static struct sg_table *dup_sg_table(struct sg_table *table)
@@ -84,6 +85,7 @@ static int system_heap_attach(struc

Re: [PATCH 0/3] net: dsa: move skb reallocation to dsa_slave_xmit

[Florian Fainelli]

On 10/16/2020 1:02 PM, Christian Eggers wrote:

[snip]


On Friday, 16 October 2020, 20:03:11 CEST, Jakub Kicinski wrote:

FWIW if you want to avoid the reallocs you may want to set
needed_tailroom on the netdev.

I haven't looked for this yet. If this can really solve the tagging AND
padding problem, I would like to do this in a follow up patch.


The comment in netdevice.h says:

   *  @needed_headroom: Extra headroom the hardware may need, but 
not in all

   *cases can this be guaranteed
   *  @needed_tailroom: Extra tailroom the hardware may need, but 
not in all
   *cases can this be guaranteed. Some cases 
also use

   *LL_MAX_HEADER instead to allocate the skb

and while I have never seen a reallocation occur while pushing a 
descriptor status block in front of a frame on transmit after setting 
the correct needed_headroom, it was not exercised in a very complicated 
way either, just TCP or UDP over IPv4 or IPv6. This makes me think that 
the comment is cautionary about more complicated transmit scenarios with 
stacked devices, tunneling etc.




Wishing a nice weekend for netdev.


Likewise!
--
Florian

[PATCH v4 1/7] dma-buf: system_heap: Rework system heap to use sgtables instead of pagelists

[John Stultz]

In preparation for some patches to optmize the system
heap code, rework the dmabuf exporter to utilize sgtables rather
then pageslists for tracking the associated pages.

This will allow for large order page allocations, as well as
more efficient page pooling.

In doing so, the system heap stops using the heap-helpers logic
which sadly is not quite as generic as I was hoping it to be, so
this patch adds heap specific implementations of the dma_buf_ops
function handlers.

Cc: Sumit Semwal 
Cc: Liam Mark 
Cc: Laura Abbott 
Cc: Brian Starkey 
Cc: Hridya Valsaraju 
Cc: Suren Baghdasaryan 
Cc: Sandeep Patil 
Cc: Daniel Mentz 
Cc: Chris Goldsworthy 
Cc: Ørjan Eide 
Cc: Robin Murphy 
Cc: Ezequiel Garcia 
Cc: Simon Ser 
Cc: James Jones 
Cc: linux-me...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Reviewed-by: Brian Starkey 
Signed-off-by: John Stultz 
---
v2:
* Fix locking issue and an unused return value Reported-by:
 kernel test robot 
 Julia Lawall 
* Make system_heap_buf_ops static Reported-by:
 kernel test robot 
v3:
* Use the new sgtable mapping functions, as Suggested-by:
 Daniel Mentz 
v4:
* Make sys_heap static (indirectly) Reported-by:
 kernel test robot 
* Spelling fix suggested by BrianS
---
 drivers/dma-buf/heaps/system_heap.c | 344 
 1 file changed, 298 insertions(+), 46 deletions(-)

diff --git a/drivers/dma-buf/heaps/system_heap.c 
b/drivers/dma-buf/heaps/system_heap.c
index 0bf688e3c023..5c44f9c06807 100644
--- a/drivers/dma-buf/heaps/system_heap.c
+++ b/drivers/dma-buf/heaps/system_heap.c
@@ -3,7 +3,11 @@
  * DMABUF System heap exporter
  *
  * Copyright (C) 2011 Google, Inc.
- * Copyright (C) 2019 Linaro Ltd.
+ * Copyright (C) 2019, 2020 Linaro Ltd.
+ *
+ * Portions based off of Andrew Davis' SRAM heap:
+ * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/
+ * Andrew F. Davis 
  */
 
 #include 
@@ -15,72 +19,321 @@
 #include 
 #include 
 #include 
-#include 
-#include 
+#include 
+
+static struct dma_heap *sys_heap;
 
-#include "heap-helpers.h"
+struct system_heap_buffer {
+   struct dma_heap *heap;
+   struct list_head attachments;
+   struct mutex lock;
+   unsigned long len;
+   struct sg_table sg_table;
+   int vmap_cnt;
+   void *vaddr;
+};
 
-struct dma_heap *sys_heap;
+struct dma_heap_attachment {
+   struct device *dev;
+   struct sg_table *table;
+   struct list_head list;
+};
 
-static void system_heap_free(struct heap_helper_buffer *buffer)
+static struct sg_table *dup_sg_table(struct sg_table *table)
 {
-   pgoff_t pg;
+   struct sg_table *new_table;
+   int ret, i;
+   struct scatterlist *sg, *new_sg;
+
+   new_table = kzalloc(sizeof(*new_table), GFP_KERNEL);
+   if (!new_table)
+   return ERR_PTR(-ENOMEM);
+
+   ret = sg_alloc_table(new_table, table->orig_nents, GFP_KERNEL);
+   if (ret) {
+   kfree(new_table);
+   return ERR_PTR(-ENOMEM);
+   }
+
+   new_sg = new_table->sgl;
+   for_each_sgtable_sg(table, sg, i) {
+   sg_set_page(new_sg, sg_page(sg), sg->length, sg->offset);
+   new_sg = sg_next(new_sg);
+   }
+
+   return new_table;
+}
+
+static int system_heap_attach(struct dma_buf *dmabuf,
+ struct dma_buf_attachment *attachment)
+{
+   struct system_heap_buffer *buffer = dmabuf->priv;
+   struct dma_heap_attachment *a;
+   struct sg_table *table;
+
+   a = kzalloc(sizeof(*a), GFP_KERNEL);
+   if (!a)
+   return -ENOMEM;
+
+   table = dup_sg_table(&buffer->sg_table);
+   if (IS_ERR(table)) {
+   kfree(a);
+   return -ENOMEM;
+   }
+
+   a->table = table;
+   a->dev = attachment->dev;
+   INIT_LIST_HEAD(&a->list);
+
+   attachment->priv = a;
+
+   mutex_lock(&buffer->lock);
+   list_add(&a->list, &buffer->attachments);
+   mutex_unlock(&buffer->lock);
+
+   return 0;
+}
+
+static void system_heap_detach(struct dma_buf *dmabuf,
+  struct dma_buf_attachment *attachment)
+{
+   struct system_heap_buffer *buffer = dmabuf->priv;
+   struct dma_heap_attachment *a = attachment->priv;
+
+   mutex_lock(&buffer->lock);
+   list_del(&a->list);
+   mutex_unlock(&buffer->lock);
+
+   sg_free_table(a->table);
+   kfree(a->table);
+   kfree(a);
+}
 
-   for (pg = 0; pg < buffer->pagecount; pg++)
-   __free_page(buffer->pages[pg]);
-   kfree(buffer->pages);
+static struct sg_table *system_heap_map_dma_buf(struct dma_buf_attachment 
*attachment,
+   enum dma_data_direction 
direction)
+{
+   struct dma_heap_attachment *a = attachment->priv;
+   struct sg_table *table = a->table;
+   int ret;
+
+   ret = dma_map_sgtable(attachment->dev, table, direction, 0);
+   if (ret)
+   return ERR_PTR(

[PATCH v4 2/7] dma-buf: heaps: Move heap-helper logic into the cma_heap implementation

[John Stultz]

Since the heap-helpers logic ended up not being as generic as
hoped, move the heap-helpers dma_buf_ops implementations into
the cma_heap directly.

This will allow us to remove the heap_helpers code in a following
patch.

Cc: Sumit Semwal 
Cc: Liam Mark 
Cc: Laura Abbott 
Cc: Brian Starkey 
Cc: Hridya Valsaraju 
Cc: Suren Baghdasaryan 
Cc: Sandeep Patil 
Cc: Daniel Mentz 
Cc: Chris Goldsworthy 
Cc: Ørjan Eide 
Cc: Robin Murphy 
Cc: Ezequiel Garcia 
Cc: Simon Ser 
Cc: James Jones 
Cc: linux-me...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Reviewed-by: Brian Starkey 
Signed-off-by: John Stultz 
---
v2:
* Fix unused return value and locking issue Reported-by:
kernel test robot 
Julia Lawall 
* Make cma_heap_buf_ops static suggested by
kernel test robot 
* Fix uninitialized return in cma Reported-by:
kernel test robot 
* Minor cleanups
v3:
* Use the new sgtable mapping functions, as Suggested-by:
 Daniel Mentz 
v4:
* Spelling fix suggested by BrianS
---
 drivers/dma-buf/heaps/cma_heap.c | 317 ++-
 1 file changed, 267 insertions(+), 50 deletions(-)

diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c
index 626cf7fd033a..d6fab7cdeaf9 100644
--- a/drivers/dma-buf/heaps/cma_heap.c
+++ b/drivers/dma-buf/heaps/cma_heap.c
@@ -2,76 +2,291 @@
 /*
  * DMABUF CMA heap exporter
  *
- * Copyright (C) 2012, 2019 Linaro Ltd.
+ * Copyright (C) 2012, 2019, 2020 Linaro Ltd.
  * Author:  for ST-Ericsson.
+ *
+ * Also utilizing parts of Andrew Davis' SRAM heap:
+ * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/
+ * Andrew F. Davis 
  */
-
 #include 
-#include 
 #include 
-#include 
 #include 
+#include 
+#include 
 #include 
-#include 
 #include 
+#include 
+#include 
 #include 
-#include 
 #include 
-#include 
+#include 
 
-#include "heap-helpers.h"
 
 struct cma_heap {
struct dma_heap *heap;
struct cma *cma;
 };
 
-static void cma_heap_free(struct heap_helper_buffer *buffer)
+struct cma_heap_buffer {
+   struct cma_heap *heap;
+   struct list_head attachments;
+   struct mutex lock;
+   unsigned long len;
+   struct page *cma_pages;
+   struct page **pages;
+   pgoff_t pagecount;
+   int vmap_cnt;
+   void *vaddr;
+};
+
+struct dma_heap_attachment {
+   struct device *dev;
+   struct sg_table table;
+   struct list_head list;
+};
+
+static int cma_heap_attach(struct dma_buf *dmabuf,
+  struct dma_buf_attachment *attachment)
 {
-   struct cma_heap *cma_heap = dma_heap_get_drvdata(buffer->heap);
-   unsigned long nr_pages = buffer->pagecount;
-   struct page *cma_pages = buffer->priv_virt;
+   struct cma_heap_buffer *buffer = dmabuf->priv;
+   struct dma_heap_attachment *a;
+   int ret;
 
-   /* free page list */
-   kfree(buffer->pages);
-   /* release memory */
-   cma_release(cma_heap->cma, cma_pages, nr_pages);
+   a = kzalloc(sizeof(*a), GFP_KERNEL);
+   if (!a)
+   return -ENOMEM;
+
+   ret = sg_alloc_table_from_pages(&a->table, buffer->pages,
+   buffer->pagecount, 0,
+   buffer->pagecount << PAGE_SHIFT,
+   GFP_KERNEL);
+   if (ret) {
+   kfree(a);
+   return ret;
+   }
+
+   a->dev = attachment->dev;
+   INIT_LIST_HEAD(&a->list);
+
+   attachment->priv = a;
+
+   mutex_lock(&buffer->lock);
+   list_add(&a->list, &buffer->attachments);
+   mutex_unlock(&buffer->lock);
+
+   return 0;
+}
+
+static void cma_heap_detach(struct dma_buf *dmabuf,
+   struct dma_buf_attachment *attachment)
+{
+   struct cma_heap_buffer *buffer = dmabuf->priv;
+   struct dma_heap_attachment *a = attachment->priv;
+
+   mutex_lock(&buffer->lock);
+   list_del(&a->list);
+   mutex_unlock(&buffer->lock);
+
+   sg_free_table(&a->table);
+   kfree(a);
+}
+
+static struct sg_table *cma_heap_map_dma_buf(struct dma_buf_attachment 
*attachment,
+enum dma_data_direction direction)
+{
+   struct dma_heap_attachment *a = attachment->priv;
+   struct sg_table *table = &a->table;
+   int ret;
+
+   ret = dma_map_sgtable(attachment->dev, table, direction, 0);
+   if (ret)
+   return ERR_PTR(-ENOMEM);
+   return table;
+}
+
+static void cma_heap_unmap_dma_buf(struct dma_buf_attachment *attachment,
+  struct sg_table *table,
+  enum dma_data_direction direction)
+{
+   dma_unmap_sgtable(attachment->dev, table, direction, 0);
+}
+
+static int cma_heap_dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
+enum dma_data_direction direction)
+{
+   struct cma_heap_buffer *buffer = dmabuf->priv;
+  

Re: [PATCH 5.8 00/14] 5.8.16-rc1 review

[Jeffrin Jose T]

On Fri, 2020-10-16 at 17:00 +0200, Greg Kroah-Hartman wrote:
> On Fri, Oct 16, 2020 at 07:41:05PM +0530, Jeffrin Jose T wrote:
> > On Fri, 2020-10-16 at 11:07 +0200, Greg Kroah-Hartman wrote:
> > > This is the start of the stable review cycle for the 5.8.16
> > > release.
> > > There are 14 patches in this series, all will be posted as a
> > > response
> > > to this one.  If anyone has any issues with these being applied,
> > > please
> > > let me know.
> > > 
> > > Responses should be made by Sun, 18 Oct 2020 09:04:25 +.
> > > Anything received after that time might be too late.
> > > 
> > > The whole patch series can be found in one patch at:
> > >   
> > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.8.16-rc1.gz
> > > or in the git tree and branch at:
> > >   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-
> > > stable-rc.git linux-5.8.y
> > > and the diffstat can be found below.
> > > 
> > > thanks,
> 
> > [   10.718252] i8042: PNP: PS/2 appears to have AUX port disabled,
> > if
> > this is incorrect please boot with i8042.nopnp
> 
> Is this incorrect?
it seems to be incorrect for me, because the warning
disappeared when i passed i8042.nopnp to kernel.
-- 
software engineer
rajagiri school of engineering and technology

[PATCH v4 6/7] dma-buf: dma-heap: Keep track of the heap device struct

[John Stultz]

Keep track of the heap device struct.

This will be useful for special DMA allocations
and actions.

Cc: Sumit Semwal 
Cc: Liam Mark 
Cc: Laura Abbott 
Cc: Brian Starkey 
Cc: Hridya Valsaraju 
Cc: Suren Baghdasaryan 
Cc: Sandeep Patil 
Cc: Daniel Mentz 
Cc: Chris Goldsworthy 
Cc: Ørjan Eide 
Cc: Robin Murphy 
Cc: Ezequiel Garcia 
Cc: Simon Ser 
Cc: James Jones 
Cc: linux-me...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: John Stultz 
---
 drivers/dma-buf/dma-heap.c | 33 +
 include/linux/dma-heap.h   |  9 +
 2 files changed, 34 insertions(+), 8 deletions(-)

diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
index afd22c9dbdcf..72c746755d89 100644
--- a/drivers/dma-buf/dma-heap.c
+++ b/drivers/dma-buf/dma-heap.c
@@ -30,6 +30,7 @@
  * @heap_devt  heap device node
  * @list   list head connecting to list of heaps
  * @heap_cdev  heap char device
+ * @heap_dev   heap device struct
  *
  * Represents a heap of memory from which buffers can be made.
  */
@@ -40,6 +41,7 @@ struct dma_heap {
dev_t heap_devt;
struct list_head list;
struct cdev heap_cdev;
+   struct device *heap_dev;
 };
 
 static LIST_HEAD(heap_list);
@@ -190,10 +192,21 @@ void *dma_heap_get_drvdata(struct dma_heap *heap)
return heap->priv;
 }
 
+/**
+ * dma_heap_get_dev() - get device struct for the heap
+ * @heap: DMA-Heap to retrieve device struct from
+ *
+ * Returns:
+ * The device struct for the heap.
+ */
+struct device *dma_heap_get_dev(struct dma_heap *heap)
+{
+   return heap->heap_dev;
+}
+
 struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info)
 {
struct dma_heap *heap, *h, *err_ret;
-   struct device *dev_ret;
unsigned int minor;
int ret;
 
@@ -247,16 +260,20 @@ struct dma_heap *dma_heap_add(const struct 
dma_heap_export_info *exp_info)
goto err1;
}
 
-   dev_ret = device_create(dma_heap_class,
-   NULL,
-   heap->heap_devt,
-   NULL,
-   heap->name);
-   if (IS_ERR(dev_ret)) {
+   heap->heap_dev = device_create(dma_heap_class,
+  NULL,
+  heap->heap_devt,
+  NULL,
+  heap->name);
+   if (IS_ERR(heap->heap_dev)) {
pr_err("dma_heap: Unable to create device\n");
-   err_ret = ERR_CAST(dev_ret);
+   err_ret = ERR_CAST(heap->heap_dev);
goto err2;
}
+
+   /* Make sure it doesn't disappear on us */
+   heap->heap_dev = get_device(heap->heap_dev);
+
/* Add heap to the list */
mutex_lock(&heap_list_lock);
list_add(&heap->list, &heap_list);
diff --git a/include/linux/dma-heap.h b/include/linux/dma-heap.h
index 454e354d1ffb..82857e096910 100644
--- a/include/linux/dma-heap.h
+++ b/include/linux/dma-heap.h
@@ -50,6 +50,15 @@ struct dma_heap_export_info {
  */
 void *dma_heap_get_drvdata(struct dma_heap *heap);
 
+/**
+ * dma_heap_get_dev() - get device struct for the heap
+ * @heap: DMA-Heap to retrieve device struct from
+ *
+ * Returns:
+ * The device struct for the heap.
+ */
+struct device *dma_heap_get_dev(struct dma_heap *heap);
+
 /**
  * dma_heap_add - adds a heap to dmabuf heaps
  * @exp_info:  information needed to register this heap
-- 
2.17.1

Re: [PATCH] drivers/virt: vmgenid: add vm generation id driver

[Jann Horn]

On Sat, Oct 17, 2020 at 5:36 AM Willy Tarreau  wrote:
> On Sat, Oct 17, 2020 at 03:40:08AM +0200, Jann Horn wrote:
> > [adding some more people who are interested in RNG stuff: Andy, Jason,
> > Theodore, Willy Tarreau, Eric Biggers. also linux-api@, because this
> > concerns some pretty fundamental API stuff related to RNG usage]
> >
> > On Fri, Oct 16, 2020 at 4:33 PM Catangiu, Adrian Costin
> >  wrote:
> > > This patch is a driver which exposes the Virtual Machine Generation ID
> > > via a char-dev FS interface that provides ID update sync and async
> > > notification, retrieval and confirmation mechanisms:
> > >
> > > When the device is 'open()'ed a copy of the current vm UUID is
> > > associated with the file handle. 'read()' operations block until the
> > > associated UUID is no longer up to date - until HW vm gen id changes -
> > > at which point the new UUID is provided/returned. Nonblocking 'read()'
> > > uses EWOULDBLOCK to signal that there is no _new_ UUID available.
> > >
> > > 'poll()' is implemented to allow polling for UUID updates. Such
> > > updates result in 'EPOLLIN' events.
> > >
> > > Subsequent read()s following a UUID update no longer block, but return
> > > the updated UUID. The application needs to acknowledge the UUID update
> > > by confirming it through a 'write()'.
> > > Only on writing back to the driver the right/latest UUID, will the
> > > driver mark this "watcher" as up to date and remove EPOLLIN status.
> > >
> > > 'mmap()' support allows mapping a single read-only shared page which
> > > will always contain the latest UUID value at offset 0.
> >
> > It would be nicer if that page just contained an incrementing counter,
> > instead of a UUID. It's not like the application cares *what* the UUID
> > changed to, just that it *did* change and all RNGs state now needs to
> > be reseeded from the kernel, right? And an application can't reliably
> > read the entire UUID from the memory mapping anyway, because the VM
> > might be forked in the middle.
> >
> > So I think your kernel driver should detect UUID changes and then turn
> > those into a monotonically incrementing counter. (Probably 64 bits
> > wide?) (That's probably also a little bit faster than comparing an
> > entire UUID.)
>
> I agree with this. Further, I'm observing there is a very common
> confusion between "universally unique" and "random". Randoms are
> needed when seeking unpredictability. A random number generator
> *must* be able to return the same value multiple times in a row
> (though this is rare), otherwise it's not random.
[...]
> If the UUIDs used there are real UUIDs, it could be as simple as
> updating them according to their format, i.e. updating the timestamp,
> and if the timestamp is already the same, just increase the seq counter.
> Doing this doesn't require entropy, doesn't need to block and doesn't
> needlessly leak randoms that sometimes make people feel nervous.

Those UUIDs are supplied by existing hypervisor code; in that regard,
this is almost like a driver for a hardware device. It is written
against a fixed API provided by the underlying machine. Making sure
that the sequence of UUIDs, as seen from inside the machine, never
changes back to a previous one is the responsibility of the hypervisor
and out of scope for this driver.

Microsoft's spec document (which is a .docx file for reasons I don't
understand) actually promises us that it is a cryptographically random
128-bit integer value, which means that if you fork a VM 2^64 times,
the probability that any two of those VMs have the same counter is
2^-64. That should be good enough.

But in userspace, we just need a simple counter. There's no need for
us to worry about anything else, like timestamps or whatever. If we
repeatedly fork a paused VM, the forked VMs will see the same counter
value, but that's totally fine, because the only thing that matters to
userspace is that the counter changes when the VM is forked.

And actually, since the value is a cryptographically random 128-bit
value, I think that we should definitely use it to help reseed the
kernel's RNG, and keep it secret from userspace. That way, even if the
VM image is public, we can ensure that going forward, the kernel RNG
will return securely random data.

Re: UBSAN: array-index-out-of-bounds in alg_bind

[Kees Cook]

On Fri, Oct 16, 2020 at 01:12:24AM -0700, syzbot wrote:
> dashboard link: https://syzkaller.appspot.com/bug?extid=92ead4eb8e26a26d465e
> [...]
> Reported-by: syzbot+92ead4eb8e26a26d4...@syzkaller.appspotmail.com
> [...]
> UBSAN: array-index-out-of-bounds in crypto/af_alg.c:166:2
> index 91 is out of range for type '__u8 [64]'

This seems to be an "as intended", if very odd. false positive (the actual
memory area is backed by the on-stack _K_SS_MAXSIZE-sized sockaddr_storage
"address" variable in __sys_bind. But yes, af_alg's salg_name member
size here doesn't make sense. The origin appears to be that 3f69cc60768b
("crypto: af_alg - Allow arbitrarily long algorithm names") intentionally
didn't extend the kernel structure (which is actually just using the UAPI
structure). I don't see a reason the UAPI couldn't have been extended:
it's a sockaddr implementation, so the size is always passed in as part
of the existing API.

At the very least the kernel needs to switch to using a correctly-sized
structure: I expected UBSAN_BOUNDS to be enabled globally by default at
some point in the future (with the minimal runtime -- the
instrumentation is tiny and catches real issues).

Reproduction:

struct sockaddr_alg sa = {
.salg_family = AF_ALG,
.salg_type = "skcipher",
.salg_name = "cbc(aes)"
};
fd = socket(AF_ALG, SOCK_SEQPACKET, 0);
bind(fd, (void *)&sa, sizeof(sa));

Replace "sizeof(sa)" with x where 64

Re: [PATCH v39 21/24] x86/vdso: Implement a vDSO for Intel SGX enclave call

[Andy Lutomirski]

On Fri, Oct 2, 2020 at 9:51 PM Jarkko Sakkinen
 wrote:
>
> From: Sean Christopherson 
>
> An SGX runtime must be aware of the exceptions, which happen inside an
> enclave. Introduce a vDSO call that wraps EENTER/ERESUME cycle and returns
> the CPU exception back to the caller exactly when it happens.
>
> Kernel fixups the exception information to RDI, RSI and RDX. The SGX call
> vDSO handler fills this information to the user provided buffer or
> alternatively trigger user provided callback at the time of the exception.
>
> The calling convention supports providing the parameters in standard RDI
> RSI, RDX, RCX, R8 and R9 registers, i.e. it is possible to declare the vDSO
> as a C prototype, but other than that there is no specific support for
> SystemV ABI. Storing XSAVE etc. is all responsibility of the enclave and
> the associated run-time.
>
> Suggested-by: Andy Lutomirski 
> Acked-by: Jethro Beekman 
> Tested-by: Jethro Beekman 
> Signed-off-by: Sean Christopherson 
> Co-developed-by: Cedric Xing 
> Signed-off-by: Cedric Xing 
> Co-developed-by: Jarkko Sakkinen 
> Signed-off-by: Jarkko Sakkinen 

> +SYM_FUNC_START(__vdso_sgx_enter_enclave)
> +   /* Prolog */
> +   .cfi_startproc
> +   push%rbp
> +   .cfi_adjust_cfa_offset  8
> +   .cfi_rel_offset %rbp, 0
> +   mov %rsp, %rbp
> +   .cfi_def_cfa_register   %rbp
> +   push%rbx
> +   .cfi_rel_offset %rbx, -8

This *looks* right, but I'm not really an expert.

> +
> +   mov %ecx, %eax
> +.Lenter_enclave:
> +   /* EENTER <= leaf <= ERESUME */
> +   cmp $EENTER, %eax
> +   jb  .Linvalid_input
> +   cmp $ERESUME, %eax
> +   ja  .Linvalid_input
> +
> +   mov SGX_ENCLAVE_OFFSET_OF_RUN(%rbp), %rcx
> +
> +   /* Validate that the reserved area contains only zeros. */
> +   push%rax
> +   push%rbx

This could use a .cfi_register_something_or_other for rbx

> +   mov $SGX_ENCLAVE_RUN_RESERVED_START, %rbx
> +1:
> +   mov (%rcx, %rbx), %rax
> +   cmpq$0, %rax
> +   jne .Linvalid_input
> +
> +   add $8, %rbx
> +   cmpq$SGX_ENCLAVE_RUN_RESERVED_END, %rbx
> +   jne 1b
> +   pop %rbx

This should undo it.

> +   pop %rax
> +
> +   /* Load TCS and AEP */
> +   mov SGX_ENCLAVE_RUN_TCS(%rcx), %rbx
> +   lea .Lasync_exit_pointer(%rip), %rcx
> +
> +   /* Single ENCLU serving as both EENTER and AEP (ERESUME) */
> +.Lasync_exit_pointer:
> +.Lenclu_eenter_eresume:
> +   enclu
> +
> +   /* EEXIT jumps here unless the enclave is doing something fancy. */
> +   mov SGX_ENCLAVE_OFFSET_OF_RUN(%rbp), %rbx
> +
> +   /* Set exit_reason. */
> +   movl$EEXIT, SGX_ENCLAVE_RUN_LEAF(%rbx)
> +
> +   /* Invoke userspace's exit handler if one was provided. */
> +.Lhandle_exit:
> +   cmpq$0, SGX_ENCLAVE_RUN_USER_HANDLER(%rbx)
> +   jne .Linvoke_userspace_handler
> +
> +   /* Success, in the sense that ENCLU was attempted. */
> +   xor %eax, %eax
> +
> +.Lout:
> +   pop %rbx

and this should undo the .cfi_register.

> +   leave
> +   .cfi_def_cfa%rsp, 8
> +   ret
> +
> +   /* The out-of-line code runs with the pre-leave stack frame. */
> +   .cfi_def_cfa%rbp, 16
> +
> +.Linvalid_input:

Here rbx and rax are pushed, and I guess pop rbx and leave fixes that
up, so okay.

> +   mov $(-EINVAL), %eax
> +   jmp .Lout
> +
> +.Lhandle_exception:
> +   mov SGX_ENCLAVE_OFFSET_OF_RUN(%rbp), %rbx
> +
> +   /* Set the exception info. */
> +   mov %eax, (SGX_ENCLAVE_RUN_LEAF)(%rbx)
> +   mov %di,  (SGX_ENCLAVE_RUN_EXCEPTION_VECTOR)(%rbx)
> +   mov %si,  (SGX_ENCLAVE_RUN_EXCEPTION_ERROR_CODE)(%rbx)
> +   mov %rdx, (SGX_ENCLAVE_RUN_EXCEPTION_ADDR)(%rbx)
> +   jmp .Lhandle_exit
> +
> +.Linvoke_userspace_handler:
> +   /* Pass the untrusted RSP (at exit) to the callback via %rcx. */
> +   mov %rsp, %rcx
> +
> +   /* Save struct sgx_enclave_exception %rbx is about to be clobbered. */
> +   mov %rbx, %rax
> +
> +   /* Save the untrusted RSP offset in %rbx (non-volatile register). */
> +   mov %rsp, %rbx
> +   and $0xf, %rbx
> +
> +   /*
> +* Align stack per x86_64 ABI. Note, %rsp needs to be 16-byte aligned
> +* _after_ pushing the parameters on the stack, hence the bonus push.
> +*/
> +   and $-0x10, %rsp
> +   push%rax
> +
> +   /* Push struct sgx_enclave_exception as a param to the callback. */
> +   push%rax
> +
> +   /* Clear RFLAGS.DF per x86_64 ABI */
> +   cld
> +
> +   /*
> +* Load the callback pointer to %rax and lfence for LVI (load value
> +* injection) protection before making the call.
> +*/
> +   mov SGX_ENCLAVE_RUN_USER_HANDLER(%rax), %rax
> +   lfence

Re: [PATCH] drivers/virt: vmgenid: add vm generation id driver

[Jann Horn]

[adding some more people who are interested in RNG stuff: Andy, Jason,
Theodore, Willy Tarreau, Eric Biggers. also linux-api@, because this
concerns some pretty fundamental API stuff related to RNG usage]

On Fri, Oct 16, 2020 at 4:33 PM Catangiu, Adrian Costin
 wrote:
> - Background
>
> The VM Generation ID is a feature defined by Microsoft (paper:
> http://go.microsoft.com/fwlink/?LinkId=260709) and supported by
> multiple hypervisor vendors.
>
> The feature is required in virtualized environments by apps that work
> with local copies/caches of world-unique data such as random values,
> uuids, monotonically increasing counters, etc.
> Such apps can be negatively affected by VM snapshotting when the VM
> is either cloned or returned to an earlier point in time.
>
> The VM Generation ID is a simple concept meant to alleviate the issue
> by providing a unique ID that changes each time the VM is restored
> from a snapshot. The hw provided UUID value can be used to
> differentiate between VMs or different generations of the same VM.
>
> - Problem
>
> The VM Generation ID is exposed through an ACPI device by multiple
> hypervisor vendors but neither the vendors or upstream Linux have no
> default driver for it leaving users to fend for themselves.
>
> Furthermore, simply finding out about a VM generation change is only
> the starting point of a process to renew internal states of possibly
> multiple applications across the system. This process could benefit
> from a driver that provides an interface through which orchestration
> can be easily done.
>
> - Solution
>
> This patch is a driver which exposes the Virtual Machine Generation ID
> via a char-dev FS interface that provides ID update sync and async
> notification, retrieval and confirmation mechanisms:
>
> When the device is 'open()'ed a copy of the current vm UUID is
> associated with the file handle. 'read()' operations block until the
> associated UUID is no longer up to date - until HW vm gen id changes -
> at which point the new UUID is provided/returned. Nonblocking 'read()'
> uses EWOULDBLOCK to signal that there is no _new_ UUID available.
>
> 'poll()' is implemented to allow polling for UUID updates. Such
> updates result in 'EPOLLIN' events.
>
> Subsequent read()s following a UUID update no longer block, but return
> the updated UUID. The application needs to acknowledge the UUID update
> by confirming it through a 'write()'.
> Only on writing back to the driver the right/latest UUID, will the
> driver mark this "watcher" as up to date and remove EPOLLIN status.
>
> 'mmap()' support allows mapping a single read-only shared page which
> will always contain the latest UUID value at offset 0.

It would be nicer if that page just contained an incrementing counter,
instead of a UUID. It's not like the application cares *what* the UUID
changed to, just that it *did* change and all RNGs state now needs to
be reseeded from the kernel, right? And an application can't reliably
read the entire UUID from the memory mapping anyway, because the VM
might be forked in the middle.

So I think your kernel driver should detect UUID changes and then turn
those into a monotonically incrementing counter. (Probably 64 bits
wide?) (That's probably also a little bit faster than comparing an
entire UUID.)

An option might be to put that counter into the vDSO, instead of a
separate VMA; but I don't know how the other folks feel about that.
Andy, do you have opinions on this? That way, normal userspace code
that uses this infrastructure wouldn't have to mess around with a
special device at all. And it'd be usable in seccomp sandboxes and so
on without needing special plumbing. And libraries wouldn't have to
call open() and mess with file descriptor numbers.

> The driver also adds support for tracking count of open file handles
> that haven't acknowledged an UUID update. This is exposed through
> two IOCTLs:
>  * VMGENID_GET_OUTDATED_WATCHERS: immediately returns the number of
>_outdated_ watchers - number of file handles that were open during
>a VM generation change, and which have not yet confirmed the new
>Vm-Gen-Id.
>  * VMGENID_WAIT_WATCHERS: blocks until there are no more _outdated_
>watchers, or if a 'timeout' argument is provided, until the timeout
>expires.

Does this mean that code that uses the memory mapping to detect
changes is still supposed to confirm generation IDs? What about
multithreaded processes, especially ones that use libraries - if a
library opens a single file descriptor that is used from multiple
threads, is the library required to synchronize all its threads before
confirming the change? That seems like it could get messy. And it
again means that this interface can't easily be used from inside
seccomp sandboxes.

[...]
> diff --git a/Documentation/virt/vmgenid.rst b/Documentation/virt/vmgenid.rst
[...]
> +``close()``:
> +  Removes the file handle as a Vm-Gen-Id watcher.

(Linux doesn't have "file handles". Technically close(

[PATCH v4 7/7] dma-buf: system_heap: Add a system-uncached heap re-using the system heap

[John Stultz]

This adds a heap that allocates non-contiguous buffers that are
marked as writecombined, so they are not cached by the CPU.

This is useful, as most graphics buffers are usually not touched
by the CPU or only written into once by the CPU. So when mapping
the buffer over and over between devices, we can skip the CPU
syncing, which saves a lot of cache management overhead, greatly
improving performance.

For folk using ION, there was a ION_FLAG_CACHED flag, which
signaled if the returned buffer should be CPU cacheable or not.
With DMA-BUF heaps, we do not yet have such a flag, and by default
the current heaps (system and cma) produce CPU cachable buffers.
So for folks transitioning from ION to DMA-BUF Heaps, this fills
in some of that missing functionality.

There has been a suggestion to make this functionality a flag
(DMAHEAP_FLAG_UNCACHED?) on the system heap, similar to how
ION used the ION_FLAG_CACHED. But I want to make sure an
_UNCACHED flag would truely be a generic attribute across all
heaps. So far that has been unclear, so having it as a separate
heap seemes better for now. (But I'm open to discussion on this
point!)

This is a rework of earlier efforts to add a uncached system heap,
done utilizing the exisitng system heap, adding just a bit of
logic to handle the uncached case.

Feedback would be very welcome!

Many thanks to Liam Mark for his help to get this working.

Pending opensource users of this code include:
* AOSP HiKey960 gralloc:
  - https://android-review.googlesource.com/c/device/linaro/hikey/+/1399519
  - Visibly improves performance over the system heap
* AOSP Codec2 (possibly, needs more review):
  - 
https://android-review.googlesource.com/c/platform/frameworks/av/+/1360640/17/media/codec2/vndk/C2DmaBufAllocator.cpp#325

Cc: Sumit Semwal 
Cc: Liam Mark 
Cc: Laura Abbott 
Cc: Brian Starkey 
Cc: Hridya Valsaraju 
Cc: Suren Baghdasaryan 
Cc: Sandeep Patil 
Cc: Daniel Mentz 
Cc: Chris Goldsworthy 
Cc: Ørjan Eide 
Cc: Robin Murphy 
Cc: Ezequiel Garcia 
Cc: Simon Ser 
Cc: James Jones 
Cc: linux-me...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: John Stultz 
---
v4:
* Make sys_uncached_heap static, as
Reported-by: kernel test robot 
* Fix wrong return value, caught by smatch
Reported-by: kernel test robot 
Reported-by: Dan Carpenter 
* Ensure we call flush/invalidate_kernel_vmap_range() in the
  uncached cases to try to address feedback about VIVT caches
  from Christoph
* Reorder a few lines as suggested by BrianS
* Avoid holding the initial mapping for the lifetime of the buffer
  as suggested by BrianS
* Fix a unlikely race between allocate and updating the dma_mask
  that BrianS noticed.
---
 drivers/dma-buf/heaps/system_heap.c | 111 
 1 file changed, 95 insertions(+), 16 deletions(-)

diff --git a/drivers/dma-buf/heaps/system_heap.c 
b/drivers/dma-buf/heaps/system_heap.c
index ef4b2c1032df..a328c76249d2 100644
--- a/drivers/dma-buf/heaps/system_heap.c
+++ b/drivers/dma-buf/heaps/system_heap.c
@@ -22,6 +22,7 @@
 #include 
 
 static struct dma_heap *sys_heap;
+static struct dma_heap *sys_uncached_heap;
 
 struct system_heap_buffer {
struct dma_heap *heap;
@@ -31,6 +32,8 @@ struct system_heap_buffer {
struct sg_table sg_table;
int vmap_cnt;
void *vaddr;
+
+   bool uncached;
 };
 
 struct dma_heap_attachment {
@@ -38,6 +41,8 @@ struct dma_heap_attachment {
struct sg_table *table;
struct list_head list;
bool mapped;
+
+   bool uncached;
 };
 
 #define HIGH_ORDER_GFP  (((GFP_HIGHUSER | __GFP_ZERO | __GFP_NOWARN \
@@ -94,7 +99,7 @@ static int system_heap_attach(struct dma_buf *dmabuf,
a->dev = attachment->dev;
INIT_LIST_HEAD(&a->list);
a->mapped = false;
-
+   a->uncached = buffer->uncached;
attachment->priv = a;
 
mutex_lock(&buffer->lock);
@@ -124,9 +129,13 @@ static struct sg_table *system_heap_map_dma_buf(struct 
dma_buf_attachment *attac
 {
struct dma_heap_attachment *a = attachment->priv;
struct sg_table *table = a->table;
+   int attr = 0;
int ret;
 
-   ret = dma_map_sgtable(attachment->dev, table, direction, 0);
+   if (a->uncached)
+   attr = DMA_ATTR_SKIP_CPU_SYNC;
+
+   ret = dma_map_sgtable(attachment->dev, table, direction, attr);
if (ret)
return ERR_PTR(ret);
 
@@ -139,9 +148,12 @@ static void system_heap_unmap_dma_buf(struct 
dma_buf_attachment *attachment,
  enum dma_data_direction direction)
 {
struct dma_heap_attachment *a = attachment->priv;
+   int attr = 0;
 
+   if (a->uncached)
+   attr = DMA_ATTR_SKIP_CPU_SYNC;
a->mapped = false;
-   dma_unmap_sgtable(attachment->dev, table, direction, 0);
+   dma_unmap_sgtable(attachment->dev, table, direction, attr);
 }
 
 static int system_heap_dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
@@ -155,10 +167

Re: [PATCH net-next 1/3] net: dsa: don't pass cloned skb's to drivers xmit function

[Florian Fainelli]

On 10/16/2020 1:02 PM, Christian Eggers wrote:

Ensure that the skb is not cloned and has enough tail room for the tail
tag. This code will be removed from the drivers in the next commits.

Signed-off-by: Christian Eggers 
---


[snip]


+   /* We have to pad he packet to the minimum Ethernet frame size,
+* if necessary, before adding the trailer (tail tagging only).
+*/
+   padlen = (skb->len >= ETH_ZLEN) ? 0 : ETH_ZLEN - skb->len;
+
+   /* To keep the slave's xmit() methods simple, don't pass cloned skbs to
+* them. Additionally ensure, that suitable room for tail tagging is
+* available.
+*/
+   if (skb_cloned(skb) ||
+   (p->tail_tag && skb_tailroom(skb) < (padlen + p->overhead))) {
+   struct sk_buff *nskb;
+
+   nskb = alloc_skb(NET_IP_ALIGN + skb->len +
+padlen + p->overhead, GFP_ATOMIC);
+   if (!nskb) {
+   kfree_skb(skb);
+   return NETDEV_TX_OK;
+   }
+   skb_reserve(nskb, NET_IP_ALIGN);
+
+   skb_reset_mac_header(nskb);
+   skb_set_network_header(nskb,
+  skb_network_header(skb) - skb->head);
+   skb_set_transport_header(nskb,
+skb_transport_header(skb) - skb->head);
+   skb_copy_and_csum_dev(skb, skb_put(nskb, skb->len));
+   consume_skb(skb);
+
+   if (padlen)
+   skb_put_zero(nskb, padlen);
+
+   skb = nskb;
+   }


Given the low number of tail taggers, maybe this should be a helper 
function that is used by them where applicable? If nothing else you may 
want to sprinkle unlikely() conditions to sort of hing the processor 
that these are unlikely conditions.

--
Florian

[PATCH v4 0/7] dma-buf: Performance improvements for system heap & a system-uncached implementation

[John Stultz]

Hey All,
  So this is another revision of my patch series to performance
optimizations to the dma-buf system heap.

This series reworks the system heap to use sgtables, and then
consolidates the pagelist method from the heap-helpers into the
CMA heap. After which the heap-helpers logic is removed (as it
is unused). I'd still like to find a better way to avoid some of
the logic duplication in implementing the entire dma_buf_ops
handlers per heap. But unfortunately that code is tied somewhat
to how the buffer's memory is tracked.

After this, the series introduces an optimization that
Ørjan Eide implemented for ION that avoids calling sync on
attachments that don't have a mapping.

Next, an optimization to use larger order pages for the system
heap. This change brings us closer to the current performance
of the ION allocation code (though there still is a gap due
to ION using a mix of deferred-freeing and page pools, I'll be
looking at integrating those eventually).

Finally, a reworked version of my uncached system heap
implementation I was submitting a few weeks back. Since it
duplicated a lot of the now reworked system heap code, I
realized it would be much simpler to add the functionality to
the system_heap implementaiton itself.

While not improving the core allocation performance, the
uncached heap allocations do result in *much* improved
performance on HiKey960 as it avoids a lot of flushing and
invalidating buffers that the cpu doesn't touch often.

Feedback on these would be great!

thanks
-john

New in v4:
* Make sys_heap static (indirectly) Reported-by:
 kernel test robot 
* Spelling fixes suggested by BrianS
* Make sys_uncached_heap static, as
Reported-by: kernel test robot 
* Fix wrong return value, caught by smatch
Reported-by: kernel test robot 
Reported-by: Dan Carpenter 
* Ensure we call flush/invalidate_kernel_vmap_range() in the
  uncached cases to try to address feedback about VIVT caches
  from Christoph
* Reorder a few lines as suggested by BrianS
* Avoid holding the initial mapping for the lifetime of the buffer
  as suggested by BrianS
* Fix a unlikely race between allocate and updating the dma_mask
  that BrianS noticed.


Cc: Sumit Semwal 
Cc: Liam Mark 
Cc: Laura Abbott 
Cc: Brian Starkey 
Cc: Hridya Valsaraju 
Cc: Suren Baghdasaryan 
Cc: Sandeep Patil 
Cc: Daniel Mentz 
Cc: Chris Goldsworthy 
Cc: Ørjan Eide 
Cc: Robin Murphy 
Cc: Ezequiel Garcia 
Cc: Simon Ser 
Cc: James Jones 
Cc: linux-me...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org

John Stultz (7):
  dma-buf: system_heap: Rework system heap to use sgtables instead of
pagelists
  dma-buf: heaps: Move heap-helper logic into the cma_heap
implementation
  dma-buf: heaps: Remove heap-helpers code
  dma-buf: heaps: Skip sync if not mapped
  dma-buf: system_heap: Allocate higher order pages if available
  dma-buf: dma-heap: Keep track of the heap device struct
  dma-buf: system_heap: Add a system-uncached heap re-using the system
heap

 drivers/dma-buf/dma-heap.c   |  33 +-
 drivers/dma-buf/heaps/Makefile   |   1 -
 drivers/dma-buf/heaps/cma_heap.c | 327 +++---
 drivers/dma-buf/heaps/heap-helpers.c | 270 ---
 drivers/dma-buf/heaps/heap-helpers.h |  53 ---
 drivers/dma-buf/heaps/system_heap.c  | 488 ---
 include/linux/dma-heap.h |   9 +
 7 files changed, 749 insertions(+), 432 deletions(-)
 delete mode 100644 drivers/dma-buf/heaps/heap-helpers.c
 delete mode 100644 drivers/dma-buf/heaps/heap-helpers.h

-- 
2.17.1

[PATCH v4 3/7] dma-buf: heaps: Remove heap-helpers code

[John Stultz]

The heap-helpers code was not as generic as initially hoped
and it is now not being used, so remove it from the tree.

Cc: Sumit Semwal 
Cc: Liam Mark 
Cc: Laura Abbott 
Cc: Brian Starkey 
Cc: Hridya Valsaraju 
Cc: Suren Baghdasaryan 
Cc: Sandeep Patil 
Cc: Daniel Mentz 
Cc: Chris Goldsworthy 
Cc: Ørjan Eide 
Cc: Robin Murphy 
Cc: Ezequiel Garcia 
Cc: Simon Ser 
Cc: James Jones 
Cc: linux-me...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Reviewed-by: Brian Starkey 
Signed-off-by: John Stultz 
---
 drivers/dma-buf/heaps/Makefile   |   1 -
 drivers/dma-buf/heaps/heap-helpers.c | 270 ---
 drivers/dma-buf/heaps/heap-helpers.h |  53 --
 3 files changed, 324 deletions(-)
 delete mode 100644 drivers/dma-buf/heaps/heap-helpers.c
 delete mode 100644 drivers/dma-buf/heaps/heap-helpers.h

diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile
index 6e54cdec3da0..974467791032 100644
--- a/drivers/dma-buf/heaps/Makefile
+++ b/drivers/dma-buf/heaps/Makefile
@@ -1,4 +1,3 @@
 # SPDX-License-Identifier: GPL-2.0
-obj-y  += heap-helpers.o
 obj-$(CONFIG_DMABUF_HEAPS_SYSTEM)  += system_heap.o
 obj-$(CONFIG_DMABUF_HEAPS_CMA) += cma_heap.o
diff --git a/drivers/dma-buf/heaps/heap-helpers.c 
b/drivers/dma-buf/heaps/heap-helpers.c
deleted file mode 100644
index d0696cf937af..
--- a/drivers/dma-buf/heaps/heap-helpers.c
+++ /dev/null
@@ -1,270 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include "heap-helpers.h"
-
-void init_heap_helper_buffer(struct heap_helper_buffer *buffer,
-void (*free)(struct heap_helper_buffer *))
-{
-   buffer->priv_virt = NULL;
-   mutex_init(&buffer->lock);
-   buffer->vmap_cnt = 0;
-   buffer->vaddr = NULL;
-   buffer->pagecount = 0;
-   buffer->pages = NULL;
-   INIT_LIST_HEAD(&buffer->attachments);
-   buffer->free = free;
-}
-
-struct dma_buf *heap_helper_export_dmabuf(struct heap_helper_buffer *buffer,
- int fd_flags)
-{
-   DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
-
-   exp_info.ops = &heap_helper_ops;
-   exp_info.size = buffer->size;
-   exp_info.flags = fd_flags;
-   exp_info.priv = buffer;
-
-   return dma_buf_export(&exp_info);
-}
-
-static void *dma_heap_map_kernel(struct heap_helper_buffer *buffer)
-{
-   void *vaddr;
-
-   vaddr = vmap(buffer->pages, buffer->pagecount, VM_MAP, PAGE_KERNEL);
-   if (!vaddr)
-   return ERR_PTR(-ENOMEM);
-
-   return vaddr;
-}
-
-static void dma_heap_buffer_destroy(struct heap_helper_buffer *buffer)
-{
-   if (buffer->vmap_cnt > 0) {
-   WARN(1, "%s: buffer still mapped in the kernel\n", __func__);
-   vunmap(buffer->vaddr);
-   }
-
-   buffer->free(buffer);
-}
-
-static void *dma_heap_buffer_vmap_get(struct heap_helper_buffer *buffer)
-{
-   void *vaddr;
-
-   if (buffer->vmap_cnt) {
-   buffer->vmap_cnt++;
-   return buffer->vaddr;
-   }
-   vaddr = dma_heap_map_kernel(buffer);
-   if (IS_ERR(vaddr))
-   return vaddr;
-   buffer->vaddr = vaddr;
-   buffer->vmap_cnt++;
-   return vaddr;
-}
-
-static void dma_heap_buffer_vmap_put(struct heap_helper_buffer *buffer)
-{
-   if (!--buffer->vmap_cnt) {
-   vunmap(buffer->vaddr);
-   buffer->vaddr = NULL;
-   }
-}
-
-struct dma_heaps_attachment {
-   struct device *dev;
-   struct sg_table table;
-   struct list_head list;
-};
-
-static int dma_heap_attach(struct dma_buf *dmabuf,
-  struct dma_buf_attachment *attachment)
-{
-   struct dma_heaps_attachment *a;
-   struct heap_helper_buffer *buffer = dmabuf->priv;
-   int ret;
-
-   a = kzalloc(sizeof(*a), GFP_KERNEL);
-   if (!a)
-   return -ENOMEM;
-
-   ret = sg_alloc_table_from_pages(&a->table, buffer->pages,
-   buffer->pagecount, 0,
-   buffer->pagecount << PAGE_SHIFT,
-   GFP_KERNEL);
-   if (ret) {
-   kfree(a);
-   return ret;
-   }
-
-   a->dev = attachment->dev;
-   INIT_LIST_HEAD(&a->list);
-
-   attachment->priv = a;
-
-   mutex_lock(&buffer->lock);
-   list_add(&a->list, &buffer->attachments);
-   mutex_unlock(&buffer->lock);
-
-   return 0;
-}
-
-static void dma_heap_detach(struct dma_buf *dmabuf,
-   struct dma_buf_attachment *attachment)
-{
-   struct dma_heaps_attachment *a = attachment->priv;
-   struct heap_helper_buffer *buffer = dmabuf->priv;
-
-   mutex_lock(&buffer->lock);
-   list_del(&a->list);
-   mutex_unlock(&buffer->lock);
-
-   sg_free_table(&a->table

Re: [RFC PATCH resend 3/6] mm: Add refcount for preserving mm_struct without pgd

[Jann Horn]

On Sat, Oct 17, 2020 at 1:21 AM Jason Gunthorpe  wrote:
> On Sat, Oct 17, 2020 at 01:09:12AM +0200, Jann Horn wrote:
> > Currently, mm_struct has two refcounts:
> >
> >  - mm_users: preserves everything - the mm_struct, the page tables, the
> >memory mappings, and so on
> >  - mm_count: preserves the mm_struct and pgd
> >
> > However, there are three types of users of mm_struct:
> >
> > 1. users that want page tables, memory mappings and so on
> > 2. users that want to preserve the pgd (for lazy TLB)
> > 3. users that just want to keep the mm_struct itself around (e.g. for
> >mmget_not_zero() or __ptrace_may_access())
> >
> > Dropping mm_count references can be messy because dropping mm_count to
> > zero deletes the pgd, which takes the pgd_lock on x86, meaning it doesn't
> > work from RCU callbacks (which run in IRQ context). In those cases,
> > mmdrop_async() must be used to punt the invocation of __mmdrop() to
> > workqueue context.
> >
> > That's fine when mmdrop_async() is a rare case, but the preceding patch
> > "ptrace: Keep mm around after exit_mm() for __ptrace_may_access()" makes it
> > the common case; we should probably avoid punting freeing to workqueue
> > context all the time if we can avoid it?
> >
> > To resolve this, add a third refcount that just protects the mm_struct and
> > the user_ns it points to, and which can be dropped with synchronous freeing
> > from (almost) any context.
> >
> > Signed-off-by: Jann Horn 
> > ---
> >  arch/x86/kernel/tboot.c|  2 ++
> >  drivers/firmware/efi/efi.c |  2 ++
> >  include/linux/mm_types.h   | 13 +++--
> >  include/linux/sched/mm.h   | 13 +
> >  kernel/fork.c  | 14 ++
> >  mm/init-mm.c   |  2 ++
> >  6 files changed, 40 insertions(+), 6 deletions(-)
>
> I think mmu notifiers and the stuff in drivers/infiniband/core/ can be
> converted to this as well..
>
> Actually I kind of wonder if you should go the reverse and find the
> few callers that care about the pgd and give them a new api with a
> better name (mmget_pgd?).

Yeah, that might make more sense... as long as I'm really sure about
all the places I haven't changed. ^^

I'll try to change it as you suggested for v2.

[PATCH v7 4/4] bus: mhi: Add userspace client interface driver

[Hemant Kumar]

This MHI client driver allows userspace clients to transfer
raw data between MHI device and host using standard file operations.
Driver instantiates uci device object which is associated to device
file node. uci device object instantiates uci channel object when device
file node is opened. uci channel object is used to manage MHI channels
by calling MHI core APIs for read and write operations. MHI channels
are started as part of device open(). MHI channels remain in start
state until last release() is called on uci device file node. Device
file node is created with format

/dev/mhi__

Currently it supports LOOPBACK channel.

Signed-off-by: Hemant Kumar 
---
 drivers/bus/mhi/Kconfig  |  13 +
 drivers/bus/mhi/Makefile |   4 +
 drivers/bus/mhi/uci.c| 656 +++
 3 files changed, 673 insertions(+)
 create mode 100644 drivers/bus/mhi/uci.c

diff --git a/drivers/bus/mhi/Kconfig b/drivers/bus/mhi/Kconfig
index e841c10..3891b31 100644
--- a/drivers/bus/mhi/Kconfig
+++ b/drivers/bus/mhi/Kconfig
@@ -20,3 +20,16 @@ config MHI_BUS_DEBUG
  Enable debugfs support for use with the MHI transport. Allows
  reading and/or modifying some values within the MHI controller
  for debug and test purposes.
+
+config MHI_UCI
+   tristate "MHI UCI"
+   depends on MHI_BUS
+   help
+ MHI based userspace client interface driver is used for transferring
+ raw data between host and device using standard file operations from
+ userspace. Open, read, write, and close operations are supported
+ by this driver. Please check mhi_uci_match_table for all supported
+ channels that are exposed to userspace.
+
+ To compile this driver as a module, choose M here: the module will be
+ called mhi_uci.
diff --git a/drivers/bus/mhi/Makefile b/drivers/bus/mhi/Makefile
index 19e6443..80feefb 100644
--- a/drivers/bus/mhi/Makefile
+++ b/drivers/bus/mhi/Makefile
@@ -1,2 +1,6 @@
 # core layer
 obj-y += core/
+
+# MHI client
+mhi_uci-y := uci.o
+obj-$(CONFIG_MHI_UCI) += mhi_uci.o
diff --git a/drivers/bus/mhi/uci.c b/drivers/bus/mhi/uci.c
new file mode 100644
index 000..8334836
--- /dev/null
+++ b/drivers/bus/mhi/uci.c
@@ -0,0 +1,656 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/* Copyright (c) 2018-2020, The Linux Foundation. All rights reserved.*/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DEVICE_NAME "mhi"
+#define MHI_UCI_DRIVER_NAME "mhi_uci"
+#define MAX_UCI_MINORS (128)
+
+static DEFINE_IDR(uci_idr);
+static DEFINE_MUTEX(uci_drv_mutex);
+static struct class *uci_dev_class;
+static int uci_dev_major;
+
+/**
+ * struct uci_chan - MHI channel for a uci device
+ * @udev: associated uci device object
+ * @ul_wq: wait queue for writer
+ * @write_lock: mutex write lock for ul channel
+ * @dl_wq: wait queue for reader
+ * @read_lock: mutex read lock for dl channel
+ * @dl_lock: spin lock
+ * @pending: list of dl buffers userspace is waiting to read
+ * @cur_buf: current buffer userspace is reading
+ * @dl_size: size of the current dl buffer userspace is reading
+ * @ref_count: uci_chan reference count
+ */
+struct uci_chan {
+   struct uci_dev *udev;
+   wait_queue_head_t ul_wq;
+
+   /* ul channel lock to synchronize multiple writes */
+   struct mutex write_lock;
+
+   wait_queue_head_t dl_wq;
+
+   /* dl channel lock to synchronize multiple reads */
+   struct mutex read_lock;
+
+   /*
+* protects pending and cur_buf members in bh context, channel release,
+* read and poll
+*/
+   spinlock_t dl_lock;
+
+   struct list_head pending;
+   struct uci_buf *cur_buf;
+   size_t dl_size;
+   struct kref ref_count;
+};
+
+/**
+ * struct uci_buf - uci buffer
+ * @data: data buffer
+ * @len: length of data buffer
+ * @node: list node of the uci buffer
+ */
+struct uci_buf {
+   void *data;
+   size_t len;
+   struct list_head node;
+};
+
+/**
+ * struct uci_dev - MHI uci device
+ * @minor: uci device node minor number
+ * @mhi_dev: associated mhi device object
+ * @uchan: uci uplink and downlink channel object
+ * @mtu: max TRE buffer length
+ * @enabled: uci device probed
+ * @lock: mutex lock to manage uchan object
+ * @ref_count: uci_dev reference count
+ */
+struct uci_dev {
+   unsigned int minor;
+   struct mhi_device *mhi_dev;
+   struct uci_chan *uchan;
+   size_t mtu;
+   bool enabled;
+
+   /* synchronize open, release and driver remove */
+   struct mutex lock;
+   struct kref ref_count;
+};
+
+static void mhi_uci_dev_chan_release(struct kref *ref)
+{
+   struct uci_buf *buf_itr, *tmp;
+   struct uci_chan *uchan =
+   container_of(ref, struct uci_chan, ref_count);
+
+   if (uchan->udev->enabled)
+   mhi_unprepare_from_transfer(uchan->udev->mhi_dev);
+
+   spin_lock_bh(&uchan->dl_lock);
+   list_for_each_entry_safe(buf_itr, tmp, &ucha

Re: [PATCH v2] checkpatch: add new exception to repeated word check

[Joe Perches]

On Sat, 2020-10-17 at 10:02 +0530, Dwaipayan Ray wrote:
> On Sat, Oct 17, 2020 at 8:26 AM Joe Perches  wrote:
> > On Wed, 2020-10-14 at 11:35 -0700, Joe Perches wrote:
> > > On Wed, 2020-10-14 at 23:42 +0530, Dwaipayan Ray wrote:
> > > > On Wed, Oct 14, 2020 at 11:33 PM Joe Perches  wrote:
> > > > > On Wed, 2020-10-14 at 22:07 +0530, Dwaipayan Ray wrote:
> > > > > > Recently, commit 4f6ad8aa1eac ("checkpatch: move repeated word 
> > > > > > test")
> > > > > > moved the repeated word test to check for more file types. But after
> > > > > > this, if checkpatch.pl is run on MAINTAINERS, it generates several
> > > > > > new warnings of the type:
> > > > > 
> > > > > Perhaps instead of adding more content checks so that
> > > > > word boundaries are not something like \S but also
> > > > > not punctuation so that content like
> > > > > 
> > > > > git git://
> > > > > @size size
> > > > > 
> > > > > does not match?
> > > > > 
> > > > > 
> > > > Hi,
> > > > So currently the words are trimmed of non alphabets before the check:
> > > > 
> > > > while ($rawline =~ /\b($word_pattern) (?=($word_pattern))/g) {
> > > > my $first = $1;
> > > > my $second = $2;
> > > > 
> > > > where, the word_pattern is:
> > > > my $word_pattern = '\b[A-Z]?[a-z]{2,}\b';
> > > 
> > > I'm familiar.
> > > 
> > > > So do you perhaps recommend modifying this word pattern to
> > > > include the punctuation as well rather than trimming them off?
> > > 
> > > Not really, perhaps use the capture group position
> > > markers @- @+ or $-[1] $+[1] and $-[2] $+[2] with the
> > > substr could be used to see what characters are
> > > before and after the word matches.
> > 
> > Perhaps something like:
> > ---
> >  scripts/checkpatch.pl | 12 +++-
> >  1 file changed, 11 insertions(+), 1 deletion(-)
> > 
> > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> > index fab38b493cef..a65eb40a5539 100755
> > --- a/scripts/checkpatch.pl
> > +++ b/scripts/checkpatch.pl
> > @@ -3054,15 +3054,25 @@ sub process {
> > 
> > my $first = $1;
> > my $second = $2;
> > +   my $start_pos = $-[1];
> > +   my $end_pos = $+[2];
> > 
> > if ($first =~ /(?:struct|union|enum)/) {
> > pos($rawline) += length($first) + 
> > length($second) + 1;
> > next;
> > }
> > 
> > -   next if ($first ne $second);
> > +   next if (lc($first) ne lc($second));
> > next if ($first eq 'long');
> > 
> > +   my $start_char = "";
> > +   my $end_char = "";
> > +   $start_char = substr($rawline, $start_pos - 
> > 1, 1) if ($start_pos > 0);
> > +   $end_char = substr($rawline, $end_pos, 1) 
> > if (length($rawline) > $end_pos);
> > +
> > +   next if ($start_char =~ /^\S$/);
> > +   next if ($end_char !~ /^[\.\,\s]?$/);
> > +
> > if (WARN("REPEATED_WORD",
> >  "Possible repeated word: 
> > '$first'\n" . $herecurr) &&
> > $fix) {
> > 
> > 
> 
> Hi Joe,
> Thank you for the insight. I was also doing something similar:
> 
> ---
>  scripts/checkpatch.pl | 16 
>  1 file changed, 16 insertions(+)
> 
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index f1a4e61917eb..82497a71ac96 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -595,6 +595,7 @@ our @mode_permission_funcs = (
>  );
> 
>  my $word_pattern = '\b[A-Z]?[a-z]{2,}\b';
> +my $punctuation_chars = '[,:;@\.\-]';
> 
>  #Create a search pattern for all these functions to speed up a loop below
>  our $mode_perms_search = "";
> @@ -3065,6 +3066,21 @@ sub process {
>   next if ($first ne $second);
>   next if ($first eq 'long');
> 
> + # check for character before and after the word matches
> + my $ca_first = substr($rawline, $-[1]-1, 1);
> + my $cb_first = substr($rawline, $+[1], 1);
> + my $ca_second = substr($rawline, $-[2]-1, 1);
> + my $cb_second = substr($rawline, $+[2], 1);
> +
> + if ($ca_first ne $ca_second || $cb_first ne $cb_second) {
> + if ($ca_first =~ /$punctuation_chars/ ||
> + $ca_second =~ /$punctuation_chars/ ||
> + $cb_first =~ /$punctuation_chars/ ||
> + $cb_second =~ /$punctuation_chars/) {
> + next;
> + }
> + }
> +
>   if (WARN("REPEATED_WORD",
>   "Possible repeated word: '$first'\n" . $herecurr) &&
>   $fix) {
> 
> Does it look okay to you??

Not really, as ca_second and cb_first are both known
to be the same position and known to be a single space.

[PATCH v7 0/4] userspace MHI client interface driver

[Hemant Kumar]

This patch series adds support for UCI driver. UCI driver enables userspace
clients to communicate to external MHI devices like modem and WLAN. UCI driver
probe creates standard character device file nodes for userspace clients to
perform open, read, write, poll and release file operations. These file
operations call MHI core layer APIs to perform data transfer using MHI bus
to communicate with MHI device. Patch is tested using arm64 based platform.

V7:
- Decoupled uci device and uci channel objects. uci device is
  associated with device file node. uci channel is associated
  with MHI channels. uci device refers to uci channel to perform
  MHI channel operations for device file operations like read()
  and write(). uci device increments its reference count for
  every open(). uci device calls mhi_uci_dev_start_chan() to start
  the MHI channel. uci channel object is tracking number of times
  MHI channel is referred. This allows to keep the MHI channel in
  start state until last release() is called. After that uci channel
  reference count goes to 0 and uci channel clean up is performed
  which stops the MHI channel. After the last call to release() if
  driver is removed uci reference count becomes 0 and uci object is
  cleaned up.
- Use separate uci channel read and write lock to fine grain locking
  between reader and writer.
- Use uci device lock to synchronize open, release and driver remove.
- Optimize for downlink only or uplink only UCI device.

V6:
- Moved uci.c to mhi directory.
- Updated Kconfig to add module information.
- Updated Makefile to rename uci object file name as mhi_uci
- Removed kref for open count

V5:
- Removed mhi_uci_drv structure.
- Used idr instead of creating global list of uci devices.
- Used kref instead of local ref counting for uci device and
  open count.
- Removed unlikely macro.

V4:
- Fix locking to protect proper struct members.
- Updated documentation describing uci client driver use cases.
- Fixed uci ref counting in mhi_uci_open for error case.
- Addressed style related review comments.

V3: Added documentation for MHI UCI driver.

V2: Added mutex lock to prevent multiple readers to access same
mhi buffer which can result into use after free.

Hemant Kumar (4):
  bus: mhi: core: Add helper API to return number of free TREs
  bus: mhi: core: Move MHI_MAX_MTU to external header file
  docs: Add documentation for userspace client interface
  bus: mhi: Add userspace client interface driver

 Documentation/mhi/index.rst |   1 +
 Documentation/mhi/uci.rst   |  39 +++
 drivers/bus/mhi/Kconfig |  13 +
 drivers/bus/mhi/Makefile|   4 +
 drivers/bus/mhi/core/internal.h |   1 -
 drivers/bus/mhi/core/main.c |  12 +
 drivers/bus/mhi/uci.c   | 661 
 include/linux/mhi.h |  12 +
 8 files changed, 742 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/mhi/uci.rst
 create mode 100644 drivers/bus/mhi/uci.c

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

Re: [patch 4/4] media: cx231xx: Consolidate dmesg output

[kernel test robot]

Hi Thomas,

I love your patch! Perhaps something to improve:

[auto build test WARNING on linuxtv-media/master]
[also build test WARNING on linus/master linux/master v5.9 next-20201016]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Thomas-Gleixner/media-Cleanup-in_interrupt-usage/20201013-224011
base:   git://linuxtv.org/media_tree.git master
config: x86_64-randconfig-a016-20201017 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 
efd02c1548ee458d59063f6393e94e972b5c3d50)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
# 
https://github.com/0day-ci/linux/commit/703daca167ddea5ab71b9547b549c1c1499f2bf4
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Thomas-Gleixner/media-Cleanup-in_interrupt-usage/20201013-224011
git checkout 703daca167ddea5ab71b9547b549c1c1499f2bf4
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 

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

All warnings (new ones prefixed by >>):

>> drivers/media/usb/cx231xx/cx231xx-vbi.c:411:57: warning: more '%' 
>> conversions than data arguments [-Wformat-insufficient-args]
   "unable to allocate %i bytes for transfer 
buffer %i%s\n",

  ~^
   include/linux/dev_printk.h:104:24: note: expanded from macro 'dev_err'
   _dev_err(dev, dev_fmt(fmt), ##__VA_ARGS__)
 ^~~
   include/linux/dev_printk.h:19:22: note: expanded from macro 'dev_fmt'
   #define dev_fmt(fmt) fmt
^~~
   1 warning generated.

vim +411 drivers/media/usb/cx231xx/cx231xx-vbi.c

e0d3bafd02586c drivers/media/video/cx231xx/cx231xx-vbi.c Sri Deevi 
2009-03-03  336  
e0d3bafd02586c drivers/media/video/cx231xx/cx231xx-vbi.c Sri Deevi 
2009-03-03  337  /*
e0d3bafd02586c drivers/media/video/cx231xx/cx231xx-vbi.c Sri Deevi 
2009-03-03  338   * Allocate URBs and start IRQ
e0d3bafd02586c drivers/media/video/cx231xx/cx231xx-vbi.c Sri Deevi 
2009-03-03  339   */
e0d3bafd02586c drivers/media/video/cx231xx/cx231xx-vbi.c Sri Deevi 
2009-03-03  340  int cx231xx_init_vbi_isoc(struct cx231xx *dev, int max_packets,
e0d3bafd02586c drivers/media/video/cx231xx/cx231xx-vbi.c Sri Deevi 
2009-03-03  341int num_bufs, int max_pkt_size,
64fbf444552606 drivers/media/video/cx231xx/cx231xx-vbi.c Palash Bandyopadhyay  
2010-07-06  342int (*bulk_copy) (struct cx231xx 
*dev,
84b5dbf39ed2f5 drivers/media/video/cx231xx/cx231xx-vbi.c Mauro Carvalho Chehab 
2009-03-03  343  struct urb *urb))
e0d3bafd02586c drivers/media/video/cx231xx/cx231xx-vbi.c Sri Deevi 
2009-03-03  344  {
e0d3bafd02586c drivers/media/video/cx231xx/cx231xx-vbi.c Sri Deevi 
2009-03-03  345  struct cx231xx_dmaqueue *dma_q = &dev->vbi_mode.vidq;
e0d3bafd02586c drivers/media/video/cx231xx/cx231xx-vbi.c Sri Deevi 
2009-03-03  346  int i;
e0d3bafd02586c drivers/media/video/cx231xx/cx231xx-vbi.c Sri Deevi 
2009-03-03  347  int sb_size, pipe;
e0d3bafd02586c drivers/media/video/cx231xx/cx231xx-vbi.c Sri Deevi 
2009-03-03  348  struct urb *urb;
e0d3bafd02586c drivers/media/video/cx231xx/cx231xx-vbi.c Sri Deevi 
2009-03-03  349  int rc;
e0d3bafd02586c drivers/media/video/cx231xx/cx231xx-vbi.c Sri Deevi 
2009-03-03  350  
336fea922936c1 drivers/media/usb/cx231xx/cx231xx-vbi.c   Mauro Carvalho Chehab 
2014-11-03  351  dev_dbg(dev->dev, "called cx231xx_vbi_isoc\n");
e0d3bafd02586c drivers/media/video/cx231xx/cx231xx-vbi.c Sri Deevi 
2009-03-03  352  
e0d3bafd02586c drivers/media/video/cx231xx/cx231xx-vbi.c Sri Deevi 
2009-03-03  353  /* De-allocates all pending stuff */
e0d3bafd02586c drivers/media/video/cx231xx/cx231xx-vbi.c Sri Deevi 
2009-03-03  354  cx231xx_uninit_vbi_isoc(dev);
e0d3bafd02586c drivers/media/video/cx231xx/cx231xx-vbi.c Sri Deevi 
2009-03-03  355  
e0d3bafd02586c drivers/media/video/cx231xx/cx231xx-vbi.c Sri Deevi 
2009-03-03  356

[PATCH v7 3/4] docs: Add documentation for userspace client interface

[Hemant Kumar]

MHI userspace client driver is creating device file node
for user application to perform file operations. File
operations are handled by MHI core driver. Currently
Loopback MHI channel is supported by this driver.

Signed-off-by: Hemant Kumar 
---
 Documentation/mhi/index.rst |  1 +
 Documentation/mhi/uci.rst   | 83 +
 2 files changed, 84 insertions(+)
 create mode 100644 Documentation/mhi/uci.rst

diff --git a/Documentation/mhi/index.rst b/Documentation/mhi/index.rst
index 1d8dec3..c75a371 100644
--- a/Documentation/mhi/index.rst
+++ b/Documentation/mhi/index.rst
@@ -9,6 +9,7 @@ MHI
 
mhi
topology
+   uci
 
 .. only::  subproject and html
 
diff --git a/Documentation/mhi/uci.rst b/Documentation/mhi/uci.rst
new file mode 100644
index 000..fe901c4
--- /dev/null
+++ b/Documentation/mhi/uci.rst
@@ -0,0 +1,83 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=
+Userspace Client Interface (UCI)
+=
+
+UCI driver enables userspace clients to communicate to external MHI devices
+like modem and WLAN. UCI driver probe creates standard character device file
+nodes for userspace clients to perform open, read, write, poll and release file
+operations.
+
+Operations
+==
+
+open
+
+
+Instantiates UCI channel object and starts MHI channels to move it to running
+state. Inbound buffers are queued to downlink channel transfer ring. Every
+subsequent open() increments UCI device reference count as well as UCI channel
+reference count.
+
+read
+
+
+When data transfer is completed on downlink channel, TRE buffer is copied to
+pending list. Reader is unblocked and data is copied to userspace buffer. TRE
+buffer is queued back to downlink channel transfer ring.
+
+write
+-
+
+Write buffer is queued to uplink channel transfer ring if ring is not full. 
Upon
+uplink transfer completion buffer is freed.
+
+poll
+
+
+Returns EPOLLIN | EPOLLRDNORM mask if pending list has buffers to be read by
+userspace. Returns EPOLLOUT | EPOLLWRNORM mask if MHI uplink channel transfer
+ring is not empty. Returns EPOLLERR when UCI driver is removed. MHI channels
+move to disabled state upon driver remove.
+
+release
+---
+
+Decrements UCI device reference count and UCI channel reference count upon last
+release(). UCI channel clean up is performed. MHI channel moves to disabled
+state and inbound buffers are freed.
+
+Usage
+=
+
+Device file node is created with format:-
+
+/dev/mhi__
+
+controller_name is the name of underlying bus used to transfer data. mhi_device
+name is the name of the MHI channel being used by MHI client in userspace to
+send or receive data using MHI protocol.
+
+There is a separate character device file node created for each channel
+specified in mhi device id table. MHI channels are statically defined by MHI
+specification. The list of supported channels is in the channel list variable
+of mhi_device_id table in UCI driver.
+
+LOOPBACK Channel
+
+
+Userspace MHI client using LOOPBACK channel opens device file node. As part of
+open operation TREs to transfer ring of LOOPBACK channel 1 gets queued and 
channel
+doorbell is rung. When userspace MHI client performs write operation on device 
node,
+data buffer gets queued as a TRE to transfer ring of LOOPBACK channel 0. MHI 
Core
+driver rings the channel doorbell for MHI device to move data over underlying 
bus.
+When userspace MHI client driver performs read operation, same data gets 
looped back
+to MHI host using LOOPBACK channel 1. LOOPBACK channel is used to verify data 
path
+and data integrity between MHI Host and MHI device.
+
+Other Use Cases
+---
+
+Getting MHI device specific diagnostics information to userspace MHI diag 
client
+using DIAG channel 4 (Host to device) and 5 (Device to Host).
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v7 1/4] bus: mhi: core: Add helper API to return number of free TREs

[Hemant Kumar]

Introduce mhi_get_free_desc_count() API to return number
of TREs available to queue buffer. MHI clients can use this
API to know before hand if ring is full without calling queue
API.

Signed-off-by: Hemant Kumar 
Reviewed-by: Jeffrey Hugo 
---
 drivers/bus/mhi/core/main.c | 12 
 include/linux/mhi.h |  9 +
 2 files changed, 21 insertions(+)

diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c
index 2cff5dd..3950792 100644
--- a/drivers/bus/mhi/core/main.c
+++ b/drivers/bus/mhi/core/main.c
@@ -258,6 +258,18 @@ int mhi_destroy_device(struct device *dev, void *data)
return 0;
 }
 
+int mhi_get_free_desc_count(struct mhi_device *mhi_dev,
+   enum dma_data_direction dir)
+{
+   struct mhi_controller *mhi_cntrl = mhi_dev->mhi_cntrl;
+   struct mhi_chan *mhi_chan = (dir == DMA_TO_DEVICE) ?
+   mhi_dev->ul_chan : mhi_dev->dl_chan;
+   struct mhi_ring *tre_ring = &mhi_chan->tre_ring;
+
+   return get_nr_avail_ring_elements(mhi_cntrl, tre_ring);
+}
+EXPORT_SYMBOL_GPL(mhi_get_free_desc_count);
+
 void mhi_notify(struct mhi_device *mhi_dev, enum mhi_callback cb_reason)
 {
struct mhi_driver *mhi_drv;
diff --git a/include/linux/mhi.h b/include/linux/mhi.h
index d4841e5..7829b1d 100644
--- a/include/linux/mhi.h
+++ b/include/linux/mhi.h
@@ -597,6 +597,15 @@ void mhi_set_mhi_state(struct mhi_controller *mhi_cntrl,
 void mhi_notify(struct mhi_device *mhi_dev, enum mhi_callback cb_reason);
 
 /**
+ * mhi_get_free_desc_count - Get transfer ring length
+ * Get # of TD available to queue buffers
+ * @mhi_dev: Device associated with the channels
+ * @dir: Direction of the channel
+ */
+int mhi_get_free_desc_count(struct mhi_device *mhi_dev,
+   enum dma_data_direction dir);
+
+/**
  * mhi_prepare_for_power_up - Do pre-initialization before power up.
  *This is optional, call this before power up if
  *the controller does not want bus framework to
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v7 2/4] bus: mhi: core: Move MHI_MAX_MTU to external header file

[Hemant Kumar]

Currently this macro is defined in internal MHI header as
a TRE length mask. Moving it to external header allows MHI
client drivers to set this upper bound for the transmit
buffer size.

Signed-off-by: Hemant Kumar 
Reviewed-by: Jeffrey Hugo 
---
 drivers/bus/mhi/core/internal.h | 1 -
 include/linux/mhi.h | 3 +++
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/bus/mhi/core/internal.h b/drivers/bus/mhi/core/internal.h
index 7989269..4abf0cf 100644
--- a/drivers/bus/mhi/core/internal.h
+++ b/drivers/bus/mhi/core/internal.h
@@ -453,7 +453,6 @@ enum mhi_pm_state {
 #define CMD_EL_PER_RING128
 #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 {
diff --git a/include/linux/mhi.h b/include/linux/mhi.h
index 7829b1d..6e1122c 100644
--- a/include/linux/mhi.h
+++ b/include/linux/mhi.h
@@ -15,6 +15,9 @@
 #include 
 #include 
 
+/* MHI client drivers to set this upper bound for tx buffer */
+#define MHI_MAX_MTU 0x
+
 #define MHI_MAX_OEM_PK_HASH_SEGMENTS 16
 
 struct mhi_chan;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH V2] mm: fix potential pte_unmap_unlock pte error

[Shijie Luo]

When flags don't have MPOL_MF_MOVE or MPOL_MF_MOVE_ALL bits, code breaks
 and passing origin pte - 1 to pte_unmap_unlock seems like not a good idea.

Signed-off-by: Shijie Luo 
Signed-off-by: Michal Hocko 
Signed-off-by: Miaohe Lin 
---
 mm/mempolicy.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index 3fde772ef5ef..3ca4898f3f24 100644
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -525,7 +525,7 @@ static int queue_pages_pte_range(pmd_t *pmd, unsigned long 
addr,
unsigned long flags = qp->flags;
int ret;
bool has_unmovable = false;
-   pte_t *pte;
+   pte_t *pte, *mapped_pte;
spinlock_t *ptl;
 
ptl = pmd_trans_huge_lock(pmd, vma);
@@ -539,7 +539,7 @@ static int queue_pages_pte_range(pmd_t *pmd, unsigned long 
addr,
if (pmd_trans_unstable(pmd))
return 0;
 
-   pte = pte_offset_map_lock(walk->mm, pmd, addr, &ptl);
+   mapped_pte = pte = pte_offset_map_lock(walk->mm, pmd, addr, &ptl);
for (; addr != end; pte++, addr += PAGE_SIZE) {
if (!pte_present(*pte))
continue;
@@ -571,7 +571,7 @@ static int queue_pages_pte_range(pmd_t *pmd, unsigned long 
addr,
} else
break;
}
-   pte_unmap_unlock(pte - 1, ptl);
+   pte_unmap_unlock(mapped_pte, ptl);
cond_resched();
 
if (has_unmovable)
-- 
2.19.1

[PATCH 2/2] arm64: allow hotpluggable sections to be offlined

[Sudarshan Rajagopalan]

On receiving the MEM_GOING_OFFLINE notification, we disallow offlining of
any boot memory by checking if section_early or not. With the introduction
of SECTION_MARK_HOTPLUGGABLE, allow boot mem sections that are marked as
hotpluggable with this bit set to be offlined and removed. This now allows
certain boot mem sections to be offlined.

Signed-off-by: Sudarshan Rajagopalan 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Anshuman Khandual 
Cc: Mark Rutland 
Cc: Gavin Shan 
Cc: Logan Gunthorpe 
Cc: David Hildenbrand 
Cc: Andrew Morton 
Cc: Steven Price 
Cc: Suren Baghdasaryan 
---
 arch/arm64/mm/mmu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 75df62fea1b6..fb8878698672 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -1487,7 +1487,7 @@ static int prevent_bootmem_remove_notifier(struct 
notifier_block *nb,
 
for (; pfn < end_pfn; pfn += PAGES_PER_SECTION) {
ms = __pfn_to_section(pfn);
-   if (early_section(ms))
+   if (early_section(ms) && !removable_section(ms))
return NOTIFY_BAD;
}
return NOTIFY_OK;
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH 1/2] mm/memory_hotplug: allow marking of memory sections as hotpluggable

[Sudarshan Rajagopalan]

Certain architectures such as arm64 doesn't allow boot memory to be
offlined and removed. Distinguish certain memory sections as
"hotpluggable" which can be marked by module drivers stating to memory
hotplug layer that these sections can be offlined and then removed.
This is done by using a separate section memory mab bit and setting it,
rather than clearing the existing SECTION_IS_EARLY bit.
This patch introduces SECTION_MARK_HOTPLUGGABLE bit into section mem map.
Only the allowed sections which are in movable zone and have unmovable
pages are allowed to be set with this new bit.

Signed-off-by: Sudarshan Rajagopalan 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Mike Rapoport 
Cc: Anshuman Khandual 
Cc: David Hildenbrand 
Cc: Mark Rutland 
Cc: Steven Price 
Cc: Logan Gunthorpe 
Cc: Suren Baghdasaryan 
---
 include/linux/memory_hotplug.h |  1 +
 include/linux/mmzone.h |  9 -
 mm/memory_hotplug.c| 20 
 mm/sparse.c| 31 +++
 4 files changed, 60 insertions(+), 1 deletion(-)

diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
index 375515803cd8..81df45b582c8 100644
--- a/include/linux/memory_hotplug.h
+++ b/include/linux/memory_hotplug.h
@@ -319,6 +319,7 @@ extern int offline_pages(unsigned long start_pfn, unsigned 
long nr_pages);
 extern int remove_memory(int nid, u64 start, u64 size);
 extern void __remove_memory(int nid, u64 start, u64 size);
 extern int offline_and_remove_memory(int nid, u64 start, u64 size);
+extern int mark_memory_hotpluggable(unsigned long start, unsigned long end);
 
 #else
 static inline void try_offline_node(int nid) {}
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 8379432f4f2f..3df3a4975236 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -1247,7 +1247,8 @@ extern size_t mem_section_usage_size(void);
 #define SECTION_HAS_MEM_MAP(1UL<<1)
 #define SECTION_IS_ONLINE  (1UL<<2)
 #define SECTION_IS_EARLY   (1UL<<3)
-#define SECTION_MAP_LAST_BIT   (1UL<<4)
+#define SECTION_MARK_HOTPLUGGABLE  (1UL<<4)
+#define SECTION_MAP_LAST_BIT   (1UL<<5)
 #define SECTION_MAP_MASK   (~(SECTION_MAP_LAST_BIT-1))
 #define SECTION_NID_SHIFT  3
 
@@ -1278,6 +1279,11 @@ static inline int early_section(struct mem_section 
*section)
return (section && (section->section_mem_map & SECTION_IS_EARLY));
 }
 
+static inline int removable_section(struct mem_section *section)
+{
+   return (section && (section->section_mem_map & 
SECTION_MARK_HOTPLUGGABLE));
+}
+
 static inline int valid_section_nr(unsigned long nr)
 {
return valid_section(__nr_to_section(nr));
@@ -1297,6 +1303,7 @@ static inline int online_section_nr(unsigned long nr)
 void online_mem_sections(unsigned long start_pfn, unsigned long end_pfn);
 #ifdef CONFIG_MEMORY_HOTREMOVE
 void offline_mem_sections(unsigned long start_pfn, unsigned long end_pfn);
+int section_mark_hotpluggable(struct mem_section *ms);
 #endif
 #endif
 
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index e9d5ab5d3ca0..503b0de489a0 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -1860,4 +1860,24 @@ int offline_and_remove_memory(int nid, u64 start, u64 
size)
return rc;
 }
 EXPORT_SYMBOL_GPL(offline_and_remove_memory);
+
+int mark_memory_hotpluggable(unsigned long start_pfn, unsigned long end_pfn)
+{
+   struct mem_section *ms;
+   unsigned long nr;
+   int rc = -EINVAL;
+
+   if (end_pfn < start_pfn)
+   return rc;
+
+   for (nr = start_pfn; nr <= end_pfn; nr++) {
+   ms = __pfn_to_section(nr);
+   rc = section_mark_hotpluggable(ms);
+   if (!rc)
+   break;
+   }
+
+   return rc;
+}
+EXPORT_SYMBOL_GPL(mark_memory_hotpluggable);
 #endif /* CONFIG_MEMORY_HOTREMOVE */
diff --git a/mm/sparse.c b/mm/sparse.c
index fcc3d176f1ea..cc21c23e2f1d 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "internal.h"
 #include 
@@ -644,6 +645,36 @@ void offline_mem_sections(unsigned long start_pfn, 
unsigned long end_pfn)
ms->section_mem_map &= ~SECTION_IS_ONLINE;
}
 }
+
+int section_mark_hotpluggable(struct mem_section *ms)
+{
+   unsigned long section_nr, pfn;
+   bool unmovable;
+   struct page *page;
+
+   /* section needs to be both valid and present to be marked */
+   if (WARN_ON(!valid_section(ms)) || !present_section(ms))
+   return -EINVAL;
+
+   /*
+* now check if this section is removable. This can be done by checking
+* if section has unmovable pages or not.
+*/
+   section_nr = __section_nr(ms);
+   pfn = section_nr_to_pfn(section_nr);
+   page = pfn_to_page(pfn);
+   unmovable = has_unmovable_pages(page_zone(page), page,
+   MIGRATE_MOVABLE, MEMORY_OFFLINE | 
REPORT_FA

[PATCH 0/2] mm/memory_hotplug, arm64: allow certain bootmem sections to be offlinable

[Sudarshan Rajagopalan]

In the patch that enables memory hot-remove (commit bbd6ec605c0f ("arm64/mm: 
Enable memory hot remove")) for arm64, there’s a notifier put in place that 
prevents boot memory from being offlined and removed. The commit text mentions 
that boot memory on arm64 cannot be removed. But x86 and other archs doesn’t 
seem to do this prevention.

The current logic is that only “new” memory blocks which are hot-added can 
later be offlined and removed. The memory that system booted up with cannot be 
offlined and removed. But there could be many usercases such as inter-VM memory 
sharing where a primary VM could offline and hot-remove a block/section of 
memory and lend it to secondary VM where it could hot-add it. And after usecase 
is done, the reverse happens where secondary VM hot-removes and gives it back 
to primary which can hot-add it back. In such cases, the present logic for 
arm64 doesn’t allow this hot-remove in primary to happen.

Also, on systems with movable zone that sort of guarantees pages to be migrated 
and isolated so that blocks can be offlined, this logic also defeats the 
purpose of having a movable zone which system can rely on memory hot-plugging, 
which say virt-io mem also relies on for fully plugged memory blocks.

This patch tries to solve by introducing a new section mem map sit 
'SECTION_MARK_HOTPLUGGABLE' which allows the concerned module drivers be able
to mark requried sections as "hotpluggable" by setting this bit. Also this 
marking is only allowed for sections which are in movable zone and have 
unmovable pages. The arm64 mmu code on receiving the MEM_GOING_OFFLINE 
notification, we disallow offlining of any boot memory by checking if 
section_early or not. With the introduction of SECTION_MARK_HOTPLUGGABLE, we 
allow boot mem sections that are marked as hotpluggable with this bit set to be 
offlined and removed. Thereby allowing required bootmem sections to be 
offlinable.

Sudarshan Rajagopalan (2):
  mm/memory_hotplug: allow marking of memory sections as hotpluggable
  arm64: allow hotpluggable sections to be offlined

 arch/arm64/mm/mmu.c|  2 +-
 include/linux/memory_hotplug.h |  1 +
 include/linux/mmzone.h |  9 -
 mm/memory_hotplug.c| 20 
 mm/sparse.c| 31 +++
 5 files changed, 61 insertions(+), 2 deletions(-)

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

[PATCH v4 0/3] iommu/arm-smmu-qcom: Support maintaining bootloader mappings

[Bjorn Andersson]

This is the fourth attempt of inheriting the stream mapping for the framebuffer
on many Qualcomm platforms, in order to not hit catastrophic faults during
arm-smmu initialization.

The new approach does, based on Robin's suggestion, take a much more direct
approach with the allocation of a context bank for bypass emulation and use of
this context bank pretty much isolated to the Qualcomm specific implementation.

As before the patchset has been tested to boot DB845c (with splash screen) and
Lenovo Yoga C630 (with EFI framebuffer).

Bjorn Andersson (3):
  iommu/arm-smmu: Allow implementation specific write_s2cr
  iommu/arm-smmu-qcom: Read back stream mappings
  iommu/arm-smmu-qcom: Implement S2CR quirk

 drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 92 ++
 drivers/iommu/arm/arm-smmu/arm-smmu.c  | 22 --
 drivers/iommu/arm/arm-smmu/arm-smmu.h  |  1 +
 3 files changed, 107 insertions(+), 8 deletions(-)

-- 
2.28.0

[PATCH v4 2/3] iommu/arm-smmu-qcom: Read back stream mappings

[Bjorn Andersson]

The Qualcomm boot loader configures stream mapping for the peripherals
that it accesses and in particular it sets up the stream mapping for the
display controller to be allowed to scan out a splash screen or EFI
framebuffer.

Read back the stream mappings during initialization and make the
arm-smmu driver maintain the streams in bypass mode.

Signed-off-by: Bjorn Andersson 
---

Changes since v3:
- Extracted from different patch in v3.
- Now configures the stream as BYPASS, rather than translate, which should work
  for platforms with working S2CR handling as well.

 drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 24 ++
 1 file changed, 24 insertions(+)

diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c 
b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
index be4318044f96..0089048342dd 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
@@ -23,6 +23,29 @@ static const struct of_device_id qcom_smmu_client_of_match[] 
__maybe_unused = {
{ }
 };
 
+static int qcom_smmu_cfg_probe(struct arm_smmu_device *smmu)
+{
+   u32 smr;
+   int i;
+
+   for (i = 0; i < smmu->num_mapping_groups; i++) {
+   smr = arm_smmu_gr0_read(smmu, ARM_SMMU_GR0_SMR(i));
+
+   if (FIELD_GET(ARM_SMMU_SMR_VALID, smr)) {
+   smmu->smrs[i].id = FIELD_GET(ARM_SMMU_SMR_ID, smr);
+   smmu->smrs[i].mask = FIELD_GET(ARM_SMMU_SMR_MASK, smr);
+   smmu->smrs[i].valid = true;
+
+   smmu->s2crs[i].type = S2CR_TYPE_BYPASS;
+   smmu->s2crs[i].privcfg = S2CR_PRIVCFG_DEFAULT;
+   smmu->s2crs[i].cbndx = 0xff;
+   smmu->s2crs[i].count++;
+   }
+   }
+
+   return 0;
+}
+
 static int qcom_smmu_def_domain_type(struct device *dev)
 {
const struct of_device_id *match =
@@ -61,6 +84,7 @@ static int qcom_smmu500_reset(struct arm_smmu_device *smmu)
 }
 
 static const struct arm_smmu_impl qcom_smmu_impl = {
+   .cfg_probe = qcom_smmu_cfg_probe,
.def_domain_type = qcom_smmu_def_domain_type,
.reset = qcom_smmu500_reset,
 };
-- 
2.28.0

[PATCH v4 3/3] iommu/arm-smmu-qcom: Implement S2CR quirk

[Bjorn Andersson]

The firmware found in some Qualcomm platforms intercepts writes to S2CR
in order to replace bypass type streams with fault; and ignore S2CR
updates of type fault.

Detect this behavior and implement a custom write_s2cr function in order
to trick the firmware into supporting bypass streams by the means of
configuring the stream for translation using a reserved and disabled
context bank.

Also circumvent the problem of configuring faulting streams by
configuring the stream as bypass.

Signed-off-by: Bjorn Andersson 
---

Changes since v3:
- Move the reservation of the "identity context bank" to the Qualcomm specific
  implementation.
- Implement the S2CR quirk with the newly introduced write_s2cr callback.

 drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 68 ++
 1 file changed, 68 insertions(+)

diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c 
b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
index 0089048342dd..c0f42d6a6e01 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
@@ -10,8 +10,14 @@
 
 struct qcom_smmu {
struct arm_smmu_device smmu;
+   bool bypass_cbndx;
 };
 
+static struct qcom_smmu *to_qcom_smmu(struct arm_smmu_device *smmu)
+{
+   return container_of(smmu, struct qcom_smmu, smmu);
+}
+
 static const struct of_device_id qcom_smmu_client_of_match[] __maybe_unused = {
{ .compatible = "qcom,adreno" },
{ .compatible = "qcom,mdp4" },
@@ -25,9 +31,32 @@ static const struct of_device_id qcom_smmu_client_of_match[] 
__maybe_unused = {
 
 static int qcom_smmu_cfg_probe(struct arm_smmu_device *smmu)
 {
+   unsigned int last_s2cr = ARM_SMMU_GR0_S2CR(smmu->num_mapping_groups - 
1);
+   struct qcom_smmu *qsmmu = to_qcom_smmu(smmu);
+   u32 reg;
u32 smr;
int i;
 
+   /*
+* With some firmware versions writes to S2CR of type FAULT are
+* ignored, and writing BYPASS will end up written as FAULT in the
+* register. Perform a write to S2CR to detect if this is the case and
+* if so reserve a context bank to emulate bypass streams.
+*/
+   reg = FIELD_PREP(ARM_SMMU_S2CR_TYPE, S2CR_TYPE_BYPASS) |
+ FIELD_PREP(ARM_SMMU_S2CR_CBNDX, 0xff) |
+ FIELD_PREP(ARM_SMMU_S2CR_PRIVCFG, S2CR_PRIVCFG_DEFAULT);
+   arm_smmu_gr0_write(smmu, last_s2cr, reg);
+   reg = arm_smmu_gr0_read(smmu, last_s2cr);
+   if (FIELD_GET(ARM_SMMU_S2CR_TYPE, reg) != S2CR_TYPE_BYPASS) {
+   qsmmu->bypass_cbndx = smmu->num_context_banks - 1;
+
+   set_bit(qsmmu->bypass_cbndx, smmu->context_map);
+
+   reg = FIELD_PREP(ARM_SMMU_CBAR_TYPE, 
CBAR_TYPE_S1_TRANS_S2_BYPASS);
+   arm_smmu_gr1_write(smmu, 
ARM_SMMU_GR1_CBAR(qsmmu->bypass_cbndx), reg);
+   }
+
for (i = 0; i < smmu->num_mapping_groups; i++) {
smr = arm_smmu_gr0_read(smmu, ARM_SMMU_GR0_SMR(i));
 
@@ -46,6 +75,44 @@ static int qcom_smmu_cfg_probe(struct arm_smmu_device *smmu)
return 0;
 }
 
+static void qcom_smmu_write_s2cr(struct arm_smmu_device *smmu, int idx)
+{
+   struct arm_smmu_s2cr *s2cr = smmu->s2crs + idx;
+   struct qcom_smmu *qsmmu = to_qcom_smmu(smmu);
+   u32 cbndx = s2cr->cbndx;
+   u32 type = s2cr->type;
+   u32 reg;
+
+   if (qsmmu->bypass_cbndx) {
+   if (type == S2CR_TYPE_BYPASS) {
+   /*
+* Firmware with quirky S2CR handling will substitute
+* BYPASS writes with FAULT, so point the stream to the
+* reserved context bank and ask for translation on the
+* stream
+*/
+   type = S2CR_TYPE_TRANS;
+   cbndx = qsmmu->bypass_cbndx;
+   } else if (type == S2CR_TYPE_FAULT) {
+   /*
+* Firmware with quirky S2CR handling will ignore FAULT
+* writes, so trick it to write FAULT by asking for a
+* BYPASS.
+*/
+   type = S2CR_TYPE_BYPASS;
+   cbndx = 0xff;
+   }
+   }
+
+   reg = FIELD_PREP(ARM_SMMU_S2CR_TYPE, type) |
+ FIELD_PREP(ARM_SMMU_S2CR_CBNDX, cbndx) |
+ FIELD_PREP(ARM_SMMU_S2CR_PRIVCFG, s2cr->privcfg);
+
+   if (smmu->features & ARM_SMMU_FEAT_EXIDS && smmu->smrs && 
smmu->smrs[idx].valid)
+   reg |= ARM_SMMU_S2CR_EXIDVALID;
+   arm_smmu_gr0_write(smmu, ARM_SMMU_GR0_S2CR(idx), reg);
+}
+
 static int qcom_smmu_def_domain_type(struct device *dev)
 {
const struct of_device_id *match =
@@ -87,6 +154,7 @@ static const struct arm_smmu_impl qcom_smmu_impl = {
.cfg_probe = qcom_smmu_cfg_probe,
.def_domain_type = qcom_smmu_def_domain_type,
.reset = qcom_smmu500_reset,
+   .write_s2cr = qcom_smmu_write_s2cr,
 };
 
 struct a

[PATCH v4 1/3] iommu/arm-smmu: Allow implementation specific write_s2cr

[Bjorn Andersson]

The firmware found in some Qualcomm platforms intercepts writes to the
S2CR register in order to replace the BYPASS type with FAULT. Further
more it treats faults at this level as catastrophic and restarts the
device.

Add support for providing implementation specific versions of the S2CR
write function, to allow the Qualcomm driver to work around this
behavior.

Signed-off-by: Bjorn Andersson 
---

Changes since v3:
- New patch

 drivers/iommu/arm/arm-smmu/arm-smmu.c | 22 ++
 drivers/iommu/arm/arm-smmu/arm-smmu.h |  1 +
 2 files changed, 15 insertions(+), 8 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c 
b/drivers/iommu/arm/arm-smmu/arm-smmu.c
index dad7fa86fbd4..ed3f0428c110 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
@@ -929,14 +929,20 @@ static void arm_smmu_write_smr(struct arm_smmu_device 
*smmu, int idx)
 static void arm_smmu_write_s2cr(struct arm_smmu_device *smmu, int idx)
 {
struct arm_smmu_s2cr *s2cr = smmu->s2crs + idx;
-   u32 reg = FIELD_PREP(ARM_SMMU_S2CR_TYPE, s2cr->type) |
- FIELD_PREP(ARM_SMMU_S2CR_CBNDX, s2cr->cbndx) |
- FIELD_PREP(ARM_SMMU_S2CR_PRIVCFG, s2cr->privcfg);
-
-   if (smmu->features & ARM_SMMU_FEAT_EXIDS && smmu->smrs &&
-   smmu->smrs[idx].valid)
-   reg |= ARM_SMMU_S2CR_EXIDVALID;
-   arm_smmu_gr0_write(smmu, ARM_SMMU_GR0_S2CR(idx), reg);
+   u32 reg;
+
+   if (smmu->impl && smmu->impl->write_s2cr) {
+   smmu->impl->write_s2cr(smmu, idx);
+   } else {
+   reg = FIELD_PREP(ARM_SMMU_S2CR_TYPE, s2cr->type) |
+ FIELD_PREP(ARM_SMMU_S2CR_CBNDX, s2cr->cbndx) |
+ FIELD_PREP(ARM_SMMU_S2CR_PRIVCFG, s2cr->privcfg);
+
+   if (smmu->features & ARM_SMMU_FEAT_EXIDS && smmu->smrs &&
+   smmu->smrs[idx].valid)
+   reg |= ARM_SMMU_S2CR_EXIDVALID;
+   arm_smmu_gr0_write(smmu, ARM_SMMU_GR0_S2CR(idx), reg);
+   }
 }
 
 static void arm_smmu_write_sme(struct arm_smmu_device *smmu, int idx)
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.h 
b/drivers/iommu/arm/arm-smmu/arm-smmu.h
index 1a746476927c..b71647eaa319 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.h
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.h
@@ -436,6 +436,7 @@ struct arm_smmu_impl {
int (*alloc_context_bank)(struct arm_smmu_domain *smmu_domain,
  struct arm_smmu_device *smmu,
  struct device *dev, int start);
+   void (*write_s2cr)(struct arm_smmu_device *smmu, int idx);
 };
 
 #define INVALID_SMENDX -1
-- 
2.28.0

Re: [PATCH] drivers/virt: vmgenid: add vm generation id driver

[Jann Horn]

On Sat, Oct 17, 2020 at 7:37 AM Willy Tarreau  wrote:
> On Sat, Oct 17, 2020 at 07:01:31AM +0200, Jann Horn wrote:
> > Microsoft's documentation
> > (http://go.microsoft.com/fwlink/?LinkId=260709) says that the VM
> > Generation ID that we get after a fork "is a 128-bit,
> > cryptographically random integer value". If multiple people use the
> > same image, it guarantees that each use of the image gets its own,
> > fresh ID:
>
> No. It cannot be more unique than the source that feeds that cryptographic
> transformation. All it guarantees is that the entropy source is protected
> from being guessed based on the output. Applying cryptography on a simple
> counter provides apparently random numbers that will be unique for a long
> period for the same source, but as soon as you duplicate that code between
> users and they start from the same counter they'll get the same IDs.
>
> This is why I think that using a counter is better if you really need 
> something
> unique. Randoms only reduce predictability which helps avoiding collisions.

Microsoft's spec tells us that they're giving us cryptographically
random numbers. Where they're getting those from is not our problem.
(And if even the hypervisor is not able to collect enough entropy to
securely generate random numbers, worrying about RNG reseeding in the
guest would be kinda pointless, we'd be fairly screwed anyway.)

Also note that we don't actually need to *always* reinitialize RNG
state on forks for functional correctness; it is fine if that fails
with a probability of 2^-128, because functionally everything will be
fine, and an attacker who is that lucky could also just guess an AES
key (which has the same probability of being successful). (And also
2^-128 is such a tiny number that it doesn't matter anyway.)

> And I'm saying this as someone who had on his external gateway the same SSH
> host key as 89 other hosts on the net, each of them using randoms to provide
> a universally unique one...

If your SSH host key was shared with 89 other hosts, it evidently
wasn't generated from cryptographically random numbers. :P Either
because the key generator was not properly hooked up to the system's
entropy pool (if you're talking about the Debian fiasco), or because
the system simply did not have enough entropy available. (Or because
the key generator is broken, but I don't think that ever happened with
OpenSSH?)

drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c:932:2: warning: 'strncpy' specified bound 128 equals destination size

[kernel test robot]

Hi Jacopo,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   8119c4332d253660e0a6b8748fe0749961cfbc97
commit: b18ee53ad297264a79cf4ea53f20786b6455 staging: bcm2835: Break MMAL 
support out from camera
date:   4 months ago
config: nds32-randconfig-r026-20201017 (attached as .config)
compiler: nds32le-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b18ee53ad297264a79cf4ea53f20786b6455
git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout b18ee53ad297264a79cf4ea53f20786b6455
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=nds32 

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

All warnings (new ones prefixed by >>):

   In file included from include/linux/kernel.h:11,
from 
drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c:19:
   include/linux/dma-mapping.h: In function 'dma_map_resource':
   arch/nds32/include/asm/memory.h:82:32: warning: comparison of unsigned 
expression >= 0 is always true [-Wtype-limits]
  82 | #define pfn_valid(pfn)  ((pfn) >= PHYS_PFN_OFFSET && (pfn) < 
(PHYS_PFN_OFFSET + max_mapnr))
 |^~
   include/linux/compiler.h:58:52: note: in definition of macro '__trace_if_var'
  58 | #define __trace_if_var(cond) (__builtin_constant_p(cond) ? (cond) : 
__trace_if_value(cond))
 |^~~~
   include/linux/dma-mapping.h:352:2: note: in expansion of macro 'if'
 352 |  if (WARN_ON_ONCE(pfn_valid(PHYS_PFN(phys_addr
 |  ^~
   include/linux/dma-mapping.h:352:6: note: in expansion of macro 'WARN_ON_ONCE'
 352 |  if (WARN_ON_ONCE(pfn_valid(PHYS_PFN(phys_addr
 |  ^~~~
   include/linux/dma-mapping.h:352:19: note: in expansion of macro 'pfn_valid'
 352 |  if (WARN_ON_ONCE(pfn_valid(PHYS_PFN(phys_addr
 |   ^
   arch/nds32/include/asm/memory.h:82:32: warning: comparison of unsigned 
expression >= 0 is always true [-Wtype-limits]
  82 | #define pfn_valid(pfn)  ((pfn) >= PHYS_PFN_OFFSET && (pfn) < 
(PHYS_PFN_OFFSET + max_mapnr))
 |^~
   include/linux/compiler.h:58:61: note: in definition of macro '__trace_if_var'
  58 | #define __trace_if_var(cond) (__builtin_constant_p(cond) ? (cond) : 
__trace_if_value(cond))
 | ^~~~
   include/linux/dma-mapping.h:352:2: note: in expansion of macro 'if'
 352 |  if (WARN_ON_ONCE(pfn_valid(PHYS_PFN(phys_addr
 |  ^~
   include/linux/dma-mapping.h:352:6: note: in expansion of macro 'WARN_ON_ONCE'
 352 |  if (WARN_ON_ONCE(pfn_valid(PHYS_PFN(phys_addr
 |  ^~~~
   include/linux/dma-mapping.h:352:19: note: in expansion of macro 'pfn_valid'
 352 |  if (WARN_ON_ONCE(pfn_valid(PHYS_PFN(phys_addr
 |   ^
   arch/nds32/include/asm/memory.h:82:32: warning: comparison of unsigned 
expression >= 0 is always true [-Wtype-limits]
  82 | #define pfn_valid(pfn)  ((pfn) >= PHYS_PFN_OFFSET && (pfn) < 
(PHYS_PFN_OFFSET + max_mapnr))
 |^~
   include/linux/compiler.h:69:3: note: in definition of macro 
'__trace_if_value'
  69 |  (cond) ? \
 |   ^~~~
   include/linux/compiler.h:56:28: note: in expansion of macro '__trace_if_var'
  56 | #define if(cond, ...) if ( __trace_if_var( !!(cond , ## __VA_ARGS__) 
) )
 |^~
   include/linux/dma-mapping.h:352:2: note: in expansion of macro 'if'
 352 |  if (WARN_ON_ONCE(pfn_valid(PHYS_PFN(phys_addr
 |  ^~
   include/linux/dma-mapping.h:352:6: note: in expansion of macro 'WARN_ON_ONCE'
 352 |  if (WARN_ON_ONCE(pfn_valid(PHYS_PFN(phys_addr
 |  ^~~~
   include/linux/dma-mapping.h:352:19: note: in expansion of macro 'pfn_valid'
 352 |  if (WARN_ON_ONCE(pfn_valid(PHYS_PFN(phys_addr
 |   ^
   drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c: In function 
'create_component':
>> drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c:932:2: warning: 
>> 'strncpy' specified bound 128 equals destination size [-Wstringop-truncation]
 932 |  strncpy(m.u.component_create.name, name,
 |  ^~~~
 933 |   sizeof(m.u.component_create.name));
 |   ~~~

Re: [PATCH v7 6/6] rcu/segcblist: Add additional comments to explain smp_mb()

[joel]

On Fri, Oct 16, 2020 at 09:27:53PM -0400, j...@joelfernandes.org wrote:
[..]
> > > + *
> > > + * Memory barrier is needed after adding to length for the case
> > > + * where length transitions from 0 -> 1. This is because rcu_barrier()
> > > + * should never miss an update to the length. So the update to length
> > > + * has to be seen *before* any modifications to the segmented list. 
> > > Otherwise a
> > > + * race can happen.
> > > + * P0 (what P1 sees) P1
> > > + * queue to list
> > > + *  rcu_barrier sees len as 0
> > > + * set len = 1.
> > > + *  rcu_barrier does nothing.
> > 
> > So that would be:
> > 
> >   call_rcu()rcu_barrier()
> >   ----
> >   WRITE(len, len + 1)   l = READ(len)
> >   smp_mb()  if (!l)
> >   queuecheck next CPU...
> > 
> > 
> > But I still don't see against what it pairs in rcu_barrier.
> 
> Actually, for the second case maybe a similar reasoning can be applied
> (control dependency) but I'm unable to come up with a litmus test.
> In fact, now I'm wondering how is it possible that call_rcu() races with
> rcu_barrier(). The module should ensure that no more call_rcu() should happen
> before rcu_barrier() is called.
> 
> confused

So I made a litmus test to show that smp_mb() is needed also after the update
to length. Basically, otherwise it is possible the callback will see garbage
that the module cleanup/unload did.

C rcubarrier+ctrldep

(*
 * Result: Never
 *
 * This litmus test shows that rcu_barrier (P1) prematurely
 * returning by reading len 0 can cause issues if P0 does
 * NOT have a smb_mb() after WRITE_ONCE(len, 1).
 * mod_data == 2 means module was unloaded (so data is garbage).
 *)

{ int len = 0; int enq = 0; }

P0(int *len, int *mod_data, int *enq)
{
int r0;

WRITE_ONCE(*len, 1);
smp_mb();   /* Needed! */
WRITE_ONCE(*enq, 1);

r0 = READ_ONCE(*mod_data);
}

P1(int *len, int *mod_data, int *enq)
{
int r0;
int r1;

r1 = READ_ONCE(*enq);

// barrier Just for test purpose ("exists" clause) to force the..
// ..rcu_barrier() to see enq before len
smp_mb();   
r0 = READ_ONCE(*len);

// implicit memory barrier due to conditional */
if (r0 == 0)
WRITE_ONCE(*mod_data, 2);
}

// Did P0 read garbage?
exists (0:r0=2 /\ 1:r0=0 /\ 1:r1=1)

Re: [PATCH v9 12/15] PCI/RCEC: Add RCiEP's linked RCEC to AER/ERR

[Kuppuswamy, Sathyanarayanan]

On 10/16/20 3:29 PM, Bjorn Helgaas wrote:

[+cc Christoph, Ethan, Sinan, Keith; sorry should have cc'd you to
begin with since you're looking at this code too.  Particularly
interested in your thoughts about whether we should be touching
PCI_ERR_ROOT_COMMAND and PCI_ERR_ROOT_STATUS when we don't own AER.]

This part is not very clear in ACPI spec or PCI firmware spec.

IMO, since AEPI notifies the OS about the error, then I guess
we are allowed to clear the PCI_ERR_ROOT_STATUS register
after handling the error (similar to EDR case).


On Fri, Oct 16, 2020 at 03:30:37PM -0500, Bjorn Helgaas wrote:

[+to Jonathan]

On Thu, Oct 15, 2020 at 05:11:10PM -0700, Sean V Kelley wrote:

From: Qiuxu Zhuo 

When attempting error recovery for an RCiEP associated with an RCEC device,
there needs to be a way to update the Root Error Status, the Uncorrectable
Error Status and the Uncorrectable Error Severity of the parent RCEC.  In
some non-native cases in which there is no OS-visible device associated
with the RCiEP, there is nothing to act upon as the firmware is acting
before the OS.

Add handling for the linked RCEC in AER/ERR while taking into account
non-native cases.

Co-developed-by: Sean V Kelley 
Link: 
https://lore.kernel.org/r/20201002184735.1229220-12-seanvk@oregontracks.org
Signed-off-by: Sean V Kelley 
Signed-off-by: Qiuxu Zhuo 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Jonathan Cameron 
---
  drivers/pci/pcie/aer.c | 53 ++
  drivers/pci/pcie/err.c | 20 
  2 files changed, 48 insertions(+), 25 deletions(-)

diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
index 65dff5f3457a..083f69b67bfd 100644
--- a/drivers/pci/pcie/aer.c
+++ b/drivers/pci/pcie/aer.c
@@ -1357,27 +1357,50 @@ static int aer_probe(struct pcie_device *dev)
   */
  static pci_ers_result_t aer_root_reset(struct pci_dev *dev)
  {
-   int aer = dev->aer_cap;
+   int type = pci_pcie_type(dev);
+   struct pci_dev *root;
+   int aer = 0;
+   int rc = 0;
u32 reg32;
-   int rc;
  
+	if (pci_pcie_type(dev) == PCI_EXP_TYPE_RC_END)

"type == PCI_EXP_TYPE_RC_END"


+   /*
+* The reset should only clear the Root Error Status
+* of the RCEC. Only perform this for the
+* native case, i.e., an RCEC is present.
+*/
+   root = dev->rcec;
+   else
+   root = dev;
  
-	/* Disable Root's interrupt in response to error messages */

-   pci_read_config_dword(dev, aer + PCI_ERR_ROOT_COMMAND, ®32);
-   reg32 &= ~ROOT_PORT_INTR_ON_MESG_MASK;
-   pci_write_config_dword(dev, aer + PCI_ERR_ROOT_COMMAND, reg32);
+   if (root)
+   aer = dev->aer_cap;
  
-	rc = pci_bus_error_reset(dev);

-   pci_info(dev, "Root Port link has been reset\n");
+   if (aer) {
+   /* Disable Root's interrupt in response to error messages */
+   pci_read_config_dword(root, aer + PCI_ERR_ROOT_COMMAND, ®32);
+   reg32 &= ~ROOT_PORT_INTR_ON_MESG_MASK;
+   pci_write_config_dword(root, aer + PCI_ERR_ROOT_COMMAND, reg32);

Not directly related to *this* patch, but my assumption was that in
the APEI case, the firmware should retain ownership of the AER
Capability, so the OS should not touch PCI_ERR_ROOT_COMMAND and
PCI_ERR_ROOT_STATUS.

But this code appears to ignore that ownership.  Jonathan, you must
have looked at this recently for 068c29a248b6 ("PCI/ERR: Clear PCIe
Device Status errors only if OS owns AER").  Do you have any insight
about this?


-   /* Clear Root Error Status */
-   pci_read_config_dword(dev, aer + PCI_ERR_ROOT_STATUS, ®32);
-   pci_write_config_dword(dev, aer + PCI_ERR_ROOT_STATUS, reg32);
+   /* Clear Root Error Status */
+   pci_read_config_dword(root, aer + PCI_ERR_ROOT_STATUS, ®32);
+   pci_write_config_dword(root, aer + PCI_ERR_ROOT_STATUS, reg32);
  
-	/* Enable Root Port's interrupt in response to error messages */

-   pci_read_config_dword(dev, aer + PCI_ERR_ROOT_COMMAND, ®32);
-   reg32 |= ROOT_PORT_INTR_ON_MESG_MASK;
-   pci_write_config_dword(dev, aer + PCI_ERR_ROOT_COMMAND, reg32);
+   /* Enable Root Port's interrupt in response to error messages */
+   pci_read_config_dword(root, aer + PCI_ERR_ROOT_COMMAND, ®32);
+   reg32 |= ROOT_PORT_INTR_ON_MESG_MASK;
+   pci_write_config_dword(root, aer + PCI_ERR_ROOT_COMMAND, reg32);
+   }
+
+   if ((type == PCI_EXP_TYPE_RC_EC) || (type == PCI_EXP_TYPE_RC_END)) {
+   if (pcie_has_flr(root)) {
+   rc = pcie_flr(root);
+   pci_info(dev, "has been reset (%d)\n", rc);
+   }
+   } else {
+   rc = pci_bus_error_reset(root);

Don't we want "dev" for both the FLR and pci_bus_error_reset()?  I
think "root == dev" except when dev is an RCiEP.  When dev is an

Re: [PATCH v2] checkpatch: add new exception to repeated word check

[Dwaipayan Ray]

On Sat, Oct 17, 2020 at 8:26 AM Joe Perches  wrote:
>
> On Wed, 2020-10-14 at 11:35 -0700, Joe Perches wrote:
> > On Wed, 2020-10-14 at 23:42 +0530, Dwaipayan Ray wrote:
> > > On Wed, Oct 14, 2020 at 11:33 PM Joe Perches  wrote:
> > > > On Wed, 2020-10-14 at 22:07 +0530, Dwaipayan Ray wrote:
> > > > > Recently, commit 4f6ad8aa1eac ("checkpatch: move repeated word test")
> > > > > moved the repeated word test to check for more file types. But after
> > > > > this, if checkpatch.pl is run on MAINTAINERS, it generates several
> > > > > new warnings of the type:
> > > >
> > > > Perhaps instead of adding more content checks so that
> > > > word boundaries are not something like \S but also
> > > > not punctuation so that content like
> > > >
> > > > git git://
> > > > @size size
> > > >
> > > > does not match?
> > > >
> > > >
> > > Hi,
> > > So currently the words are trimmed of non alphabets before the check:
> > >
> > > while ($rawline =~ /\b($word_pattern) (?=($word_pattern))/g) {
> > > my $first = $1;
> > > my $second = $2;
> > >
> > > where, the word_pattern is:
> > > my $word_pattern = '\b[A-Z]?[a-z]{2,}\b';
> >
> > I'm familiar.
> >
> > > So do you perhaps recommend modifying this word pattern to
> > > include the punctuation as well rather than trimming them off?
> >
> > Not really, perhaps use the capture group position
> > markers @- @+ or $-[1] $+[1] and $-[2] $+[2] with the
> > substr could be used to see what characters are
> > before and after the word matches.
>
> Perhaps something like:
> ---
>  scripts/checkpatch.pl | 12 +++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index fab38b493cef..a65eb40a5539 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -3054,15 +3054,25 @@ sub process {
>
> my $first = $1;
> my $second = $2;
> +   my $start_pos = $-[1];
> +   my $end_pos = $+[2];
>
> if ($first =~ /(?:struct|union|enum)/) {
> pos($rawline) += length($first) + 
> length($second) + 1;
> next;
> }
>
> -   next if ($first ne $second);
> +   next if (lc($first) ne lc($second));
> next if ($first eq 'long');
>
> +   my $start_char = "";
> +   my $end_char = "";
> +   $start_char = substr($rawline, $start_pos - 
> 1, 1) if ($start_pos > 0);
> +   $end_char = substr($rawline, $end_pos, 1) if 
> (length($rawline) > $end_pos);
> +
> +   next if ($start_char =~ /^\S$/);
> +   next if ($end_char !~ /^[\.\,\s]?$/);
> +
> if (WARN("REPEATED_WORD",
>  "Possible repeated word: '$first'\n" 
> . $herecurr) &&
> $fix) {
>
>

Hi Joe,
Thank you for the insight. I was also doing something similar:

---
 scripts/checkpatch.pl | 16 
 1 file changed, 16 insertions(+)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index f1a4e61917eb..82497a71ac96 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -595,6 +595,7 @@ our @mode_permission_funcs = (
 );

 my $word_pattern = '\b[A-Z]?[a-z]{2,}\b';
+my $punctuation_chars = '[,:;@\.\-]';

 #Create a search pattern for all these functions to speed up a loop below
 our $mode_perms_search = "";
@@ -3065,6 +3066,21 @@ sub process {
  next if ($first ne $second);
  next if ($first eq 'long');

+ # check for character before and after the word matches
+ my $ca_first = substr($rawline, $-[1]-1, 1);
+ my $cb_first = substr($rawline, $+[1], 1);
+ my $ca_second = substr($rawline, $-[2]-1, 1);
+ my $cb_second = substr($rawline, $+[2], 1);
+
+ if ($ca_first ne $ca_second || $cb_first ne $cb_second) {
+ if ($ca_first =~ /$punctuation_chars/ ||
+ $ca_second =~ /$punctuation_chars/ ||
+ $cb_first =~ /$punctuation_chars/ ||
+ $cb_second =~ /$punctuation_chars/) {
+ next;
+ }
+ }
+
  if (WARN("REPEATED_WORD",
  "Possible repeated word: '$first'\n" . $herecurr) &&
  $fix) {

Does it look okay to you??

Thanks,
Dwaipayan.

drivers/media/i2c/mt9t112.c:670:12: warning: stack frame size of 8344 bytes in function 'mt9t112_init_camera'

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   071a0578b0ce0b0e543d1e38ee6926b9cc21c198
commit: f0fe00d4972a8cd4b98cc2c29758615e4d51cdfe security: allow using Clang's 
zero initialization for stack variables
date:   4 months ago
config: x86_64-randconfig-a012-20201017 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 
efd02c1548ee458d59063f6393e94e972b5c3d50)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
# 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f0fe00d4972a8cd4b98cc2c29758615e4d51cdfe
git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout f0fe00d4972a8cd4b98cc2c29758615e4d51cdfe
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 

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

All warnings (new ones prefixed by >>):

>> drivers/media/i2c/mt9t112.c:670:12: warning: stack frame size of 8344 bytes 
>> in function 'mt9t112_init_camera' [-Wframe-larger-than=]
   static int mt9t112_init_camera(const struct i2c_client *client)
  ^
   1 warning generated.

vim +/mt9t112_init_camera +670 drivers/media/i2c/mt9t112.c

7641b04421954ea Jacopo Mondi 2018-03-12  669  
7641b04421954ea Jacopo Mondi 2018-03-12 @670  static int 
mt9t112_init_camera(const struct i2c_client *client)
7641b04421954ea Jacopo Mondi 2018-03-12  671  {
7641b04421954ea Jacopo Mondi 2018-03-12  672int ret;
7641b04421954ea Jacopo Mondi 2018-03-12  673  
7641b04421954ea Jacopo Mondi 2018-03-12  674ECHECKER(ret, 
mt9t112_reset(client));
7641b04421954ea Jacopo Mondi 2018-03-12  675ECHECKER(ret, 
mt9t112_init_pll(client));
7641b04421954ea Jacopo Mondi 2018-03-12  676ECHECKER(ret, 
mt9t112_init_setting(client));
7641b04421954ea Jacopo Mondi 2018-03-12  677ECHECKER(ret, 
mt9t112_auto_focus_setting(client));
7641b04421954ea Jacopo Mondi 2018-03-12  678  
7641b04421954ea Jacopo Mondi 2018-03-12  679mt9t112_reg_mask_set(ret, 
client, 0x0018, 0x0004, 0);
7641b04421954ea Jacopo Mondi 2018-03-12  680  
6a26f141bf6200a Jacopo Mondi 2018-03-12  681/* Analog setting B.*/
7641b04421954ea Jacopo Mondi 2018-03-12  682mt9t112_reg_write(ret, client, 
0x3084, 0x2409);
7641b04421954ea Jacopo Mondi 2018-03-12  683mt9t112_reg_write(ret, client, 
0x3092, 0x0A49);
7641b04421954ea Jacopo Mondi 2018-03-12  684mt9t112_reg_write(ret, client, 
0x3094, 0x4949);
7641b04421954ea Jacopo Mondi 2018-03-12  685mt9t112_reg_write(ret, client, 
0x3096, 0x4950);
7641b04421954ea Jacopo Mondi 2018-03-12  686  
7641b04421954ea Jacopo Mondi 2018-03-12  687/*
6a26f141bf6200a Jacopo Mondi 2018-03-12  688 * Disable adaptive clock.
7641b04421954ea Jacopo Mondi 2018-03-12  689 * 
PRI_A_CONFIG_JPEG_OB_TX_CONTROL_VAR
7641b04421954ea Jacopo Mondi 2018-03-12  690 * 
PRI_B_CONFIG_JPEG_OB_TX_CONTROL_VAR
7641b04421954ea Jacopo Mondi 2018-03-12  691 */
7641b04421954ea Jacopo Mondi 2018-03-12  692mt9t112_mcu_write(ret, client, 
VAR(26, 160), 0x0A2E);
7641b04421954ea Jacopo Mondi 2018-03-12  693mt9t112_mcu_write(ret, client, 
VAR(27, 160), 0x0A2E);
7641b04421954ea Jacopo Mondi 2018-03-12  694  
6a26f141bf6200a Jacopo Mondi 2018-03-12  695/*
6a26f141bf6200a Jacopo Mondi 2018-03-12  696 * Configure Status in 
Status_before_length Format and enable header.
6a26f141bf6200a Jacopo Mondi 2018-03-12  697 * 
PRI_B_CONFIG_JPEG_OB_TX_CONTROL_VAR
6a26f141bf6200a Jacopo Mondi 2018-03-12  698 */
7641b04421954ea Jacopo Mondi 2018-03-12  699mt9t112_mcu_write(ret, client, 
VAR(27, 144), 0x0CB4);
7641b04421954ea Jacopo Mondi 2018-03-12  700  
6a26f141bf6200a Jacopo Mondi 2018-03-12  701/*
6a26f141bf6200a Jacopo Mondi 2018-03-12  702 * Enable JPEG in context B.
6a26f141bf6200a Jacopo Mondi 2018-03-12  703 * 
PRI_B_CONFIG_JPEG_OB_TX_CONTROL_VAR
6a26f141bf6200a Jacopo Mondi 2018-03-12  704 */
7641b04421954ea Jacopo Mondi 2018-03-12  705mt9t112_mcu_write(ret, client, 
VAR8(27, 142), 0x01);
7641b04421954ea Jacopo Mondi 2018-03-12  706  
6a26f141bf6200a Jacopo Mondi 2018-03-12  707/* Disable Dac_TXLO. */
7641b04421954ea Jacopo Mondi 2018-03-12  708mt9t112_reg_write(ret, client, 
0x316C, 0x350F);
7641b04421954ea Jacopo Mondi 2018-03-12  709  
6a26f141bf6200a Jacopo Mondi 2018-03-12  710/* Set max slew rates. */
7641b04421954ea Jacopo Mondi 2018-03-12  711mt9t112_reg_write(ret, client, 
0x1E, 0x777);
7641b04421954ea Jacopo Mondi 2018-03-12  712  
7641b04421954ea Jacopo Mondi 2018-03-12  713retur

Re: [EXT] Re: [PATCH v4 03/13] task_isolation: userspace hard isolation from kernel

[Alex Belits]

On Mon, 2020-10-05 at 14:52 -0400, Nitesh Narayan Lal wrote:
> On 10/4/20 7:14 PM, Frederic Weisbecker wrote:
> > On Sun, Oct 04, 2020 at 02:44:39PM +, Alex Belits wrote:
> > > On Thu, 2020-10-01 at 15:56 +0200, Frederic Weisbecker wrote:
> > > > External Email
> > > > 
> > > > -
> > > > --
> > > > ---
> > > > On Wed, Jul 22, 2020 at 02:49:49PM +, Alex Belits wrote:
> > > > > +/*
> > > > > + * Description of the last two tasks that ran isolated on a
> > > > > given
> > > > > CPU.
> > > > > + * This is intended only for messages about isolation
> > > > > breaking. We
> > > > > + * don't want any references to actual task while accessing
> > > > > this
> > > > > from
> > > > > + * CPU that caused isolation breaking -- we know nothing
> > > > > about
> > > > > timing
> > > > > + * and don't want to use locking or RCU.
> > > > > + */
> > > > > +struct isol_task_desc {
> > > > > + atomic_t curr_index;
> > > > > + atomic_t curr_index_wr;
> > > > > + boolwarned[2];
> > > > > + pid_t   pid[2];
> > > > > + pid_t   tgid[2];
> > > > > + charcomm[2][TASK_COMM_LEN];
> > > > > +};
> > > > > +static DEFINE_PER_CPU(struct isol_task_desc,
> > > > > isol_task_descs);
> > > > So that's quite a huge patch that would have needed to be split
> > > > up.
> > > > Especially this tracing engine.
> > > > 
> > > > Speaking of which, I agree with Thomas that it's unnecessary.
> > > > It's
> > > > too much
> > > > code and complexity. We can use the existing trace events and
> > > > perform
> > > > the
> > > > analysis from userspace to find the source of the disturbance.
> > > The idea behind this is that isolation breaking events are
> > > supposed to
> > > be known to the applications while applications run normally, and
> > > they
> > > should not require any analysis or human intervention to be
> > > handled.
> > Sure but you can use trace events for that. Just trace interrupts,
> > workqueues,
> > timers, syscalls, exceptions and scheduler events and you get all
> > the local
> > disturbance. You might want to tune a few filters but that's pretty
> > much it.
> > 
> > As for the source of the disturbances, if you really need that
> > information,
> > you can trace the workqueue and timer queue events and just filter
> > those that
> > target your isolated CPUs.
> > 
> 
> I agree that we can do all those things with tracing.
> However, IMHO having a simplified logging mechanism to gather the
> source of
> violation may help in reducing the manual effort.
> 
> Although, I am not sure how easy will it be to maintain such an
> interface
> over time.

I think that the goal of "finding source of disturbance" interface is
different from what can be accomplished by tracing in two ways:

1. "Source of disturbance" should provide some useful information about
category of event and it cause as opposed to determining all precise
details about things being called that resulted or could result in
disturbance. It should not depend on the user's knowledge about details
of implementations, it should provide some definite answer of what
happened (with whatever amount of details can be given in a generic
mechanism) even if the user has no idea how those things happen and
what part of kernel is responsible for either causing or processing
them. Then if the user needs further details, they can be obtained with
tracing.

2. It should be usable as a runtime error handling mechanism, so the
information it provides should be suitable for application use and
logging. It should be usable when applications are running on a system
in production, and no specific tracing or monitoring mechanism can be
in use. If, say, thousands of devices are controlling neutrino
detectors on an ocean floor, and in a month of work one of them got one
isolation breaking event, it should be able to report that isolation
was broken by an interrupt from a network interface, so the users will
be able to track it down to some userspace application reconfiguring
those interrupts.

It will be a good idea to make such mechanism optional and suitable for
tracking things on conditions other than "always enabled" and "enabled
with task isolation". However in my opinion, there should be something
in kernel entry procedure that, if enabled, prepared something to be
filled by the cause data, and we know at least one such situation when
this kernel entry procedure should be triggered -- when task isolation
is on.

-- 
Alex

Re: [PATCH v4 3/3] clk: qcom: lpasscc-sc7180: Re-configure the PLL in case lost

[Doug Anderson]

Hi,

On Fri, Oct 16, 2020 at 7:01 PM Stephen Boyd  wrote:
>
> Quoting Stephen Boyd (2020-10-15 20:16:27)
> > Quoting Douglas Anderson (2020-10-14 17:13:29)
> > > From: Taniya Das 
> > >
> > > In the case where the PLL configuration is lost, then the pm runtime
> > > resume will reconfigure before usage.
> >
> > Taniya, this commit needs a lot more describing than one sentence. I see
> > that the PLL's L value is reset at boot, but only once. That seems to be
> > because the bootloader I have doesn't set bit 11 for the RETAIN_FF bit
> > on the lpass_core_hm_gdsc. Once the gdsc is turned off the first time,
> > the PLL settings are lost and the L val is reset to 0. That makes sense
> > because RETAIN_FF isn't set. This also means the other register writes
> > during probe are lost during the first suspend of the lpass core clk
> > controller. Then when the GDSC is turned on the next time for this clk
> > controller  being runtime resumed we will set the retain bit and then
> > configure the PLL again. BTW, I see that runtime PM is called for this
> > clk controller for all the clk operations. Maybe there should be some
> > auto suspend timeout so that we're not toggling the gdsc constantly?
> >
> > I hacked up the GDSC code to set the bit at gdsc registration time and
> > it seems to fix the problem I'm seeing (i.e. that the PLL is stuck,
> > which should also be in the commit text here). When I try to set the bit
> > in the bootloader though my kernel won't boot. I guess something is
> > hanging the system if I enable the retain bit in the GDSC?
> >
>
> After hacking on this for some time it looks like we can apply this
> patch instead and things are good. The first two patches in this series
> look mostly good to me minus some nitpicks so please resend.

By this you mean the two newlines you mentioned on
, right?  I think all the rest of your
comments were on patch #3 (this patch) which I think we're dropping.

I'm happy to repost a v5 of just patches #1 and #2 with the newlines
fixed next week, or I'm happy if you want to fix them when applying as
you alluded to on the Chrome OS gerrit.  Just let me know.  I just
want to make sure I'm not missing some other nits before I post the
v5.  ;-)

-Doug

Re: [PATCH 1/1] net: ftgmac100: add handling of mdio/phy nodes for ast2400/2500

[Andrew Lunn]

> + if (priv->is_aspeed &&
> + phy_intf != PHY_INTERFACE_MODE_RMII &&
> + phy_intf != PHY_INTERFACE_MODE_RGMII &&
> + phy_intf != PHY_INTERFACE_MODE_RGMII_ID &&
> + phy_intf != PHY_INTERFACE_MODE_RGMII_RXID &&
> + phy_intf != PHY_INTERFACE_MODE_RGMII_TXID) {


phy_interface_mode_is_rgmii()

Andrew

Re: [EXT] Re: [PATCH v4 03/13] task_isolation: userspace hard isolation from kernel

[Alex Belits]

On Tue, 2020-10-06 at 12:35 +0200, Frederic Weisbecker wrote:
> On Mon, Oct 05, 2020 at 02:52:49PM -0400, Nitesh Narayan Lal wrote:
> > On 10/4/20 7:14 PM, Frederic Weisbecker wrote:
> > > On Sun, Oct 04, 2020 at 02:44:39PM +, Alex Belits wrote:
> > > 
> > > > The idea behind this is that isolation breaking events are
> > > > supposed to
> > > > be known to the applications while applications run normally,
> > > > and they
> > > > should not require any analysis or human intervention to be
> > > > handled.
> > > Sure but you can use trace events for that. Just trace
> > > interrupts, workqueues,
> > > timers, syscalls, exceptions and scheduler events and you get all
> > > the local
> > > disturbance. You might want to tune a few filters but that's
> > > pretty much it.
> 
> formation,
> > > you can trace the workqueue and timer queue events and just
> > > filter those that
> > > target your isolated CPUs.
> > > 
> > 
> > I agree that we can do all those things with tracing.
> > However, IMHO having a simplified logging mechanism to gather the
> > source of
> > violation may help in reducing the manual effort.
> > 
> > Although, I am not sure how easy will it be to maintain such an
> > interface
> > over time.
> 
> The thing is: tracing is your simplified logging mechanism here. You
> can achieve
> the same in userspace with _way_ less code, no race, and you can do
> it in
> bash.

The idea is that this mechanism should be usable when no one is there
to run things in bash, or no information about what might happen. It
should be able to report rare events in production when users may not
be able to reproduce them.

-- 
Alex

Re: [PATCH RFC V3 5/9] x86/pks: Add PKS kernel API

[Ira Weiny]

On Fri, Oct 16, 2020 at 01:07:47PM +0200, Peter Zijlstra wrote:
> On Fri, Oct 09, 2020 at 12:42:54PM -0700, ira.we...@intel.com wrote:
> > +static inline void pks_update_protection(int pkey, unsigned long 
> > protection)
> > +{
> > +   current->thread.saved_pkrs = update_pkey_val(current->thread.saved_pkrs,
> > +pkey, protection);
> > +   preempt_disable();
> > +   write_pkrs(current->thread.saved_pkrs);
> > +   preempt_enable();
> > +}
> 
> write_pkrs() already disables preemption itself. Wrapping it in yet
> another layer is useless.

I was thinking the update to saved_pkrs needed this protection as well and that
was to be included in the preemption disable.  But that too is incorrect.

I've removed this preemption disable.

Thanks,
Ira

Re: [PATCH] mm: fix potential pte_unmap_unlock pte error

[Shijie Luo]

On 2020/10/16 22:05, osalva...@suse.de wrote:

On 2020-10-16 15:42, Michal Hocko wrote:

OK, I finally managed to convince my friday brain to think and grasped
what the code is intended to do. The loop is hairy and we want to
prevent from spurious EIO when all the pages are on a proper node. So
the check has to be done inside the loop. Anyway I would find the
following fix less error prone and easier to follow
diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index eddbe4e56c73..8cc1fc9c4d13 100644
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -525,7 +525,7 @@ static int queue_pages_pte_range(pmd_t *pmd,
unsigned long addr,
 unsigned long flags = qp->flags;
 int ret;
 bool has_unmovable = false;
-    pte_t *pte;
+    pte_t *pte, *mapped_pte;
 spinlock_t *ptl;

 ptl = pmd_trans_huge_lock(pmd, vma);
@@ -539,7 +539,7 @@ static int queue_pages_pte_range(pmd_t *pmd,
unsigned long addr,
 if (pmd_trans_unstable(pmd))
 return 0;

-    pte = pte_offset_map_lock(walk->mm, pmd, addr, &ptl);
+    mapped_pte = pte = pte_offset_map_lock(walk->mm, pmd, addr, &ptl);
 for (; addr != end; pte++, addr += PAGE_SIZE) {
 if (!pte_present(*pte))
 continue;
@@ -571,7 +571,7 @@ static int queue_pages_pte_range(pmd_t *pmd,
unsigned long addr,
 } else
 break;
 }
-    pte_unmap_unlock(pte - 1, ptl);
+    pte_unmap_unlock(mapped_pte, ptl);
 cond_resched();

 if (has_unmovable)


It is more clear to grasp, definitely.

Yeah, this one is more comprehensible, I 'll send a v2 patch, thank you.

Re: [PATCH v3] checkpatch: add new exception to repeated word check

[Joe Perches]

On Sat, 2020-10-17 at 10:52 +0530, Dwaipayan Ray wrote:
> Recently, commit 4f6ad8aa1eac ("checkpatch: move repeated word test")
> moved the repeated word test to check for more file types. But after
> this, if checkpatch.pl is run on MAINTAINERS, it generates several
> new warnings of the type:
> 
> WARNING: Possible repeated word: 'git'
> 
> For example:
> WARNING: Possible repeated word: 'git'
> +T:   git git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml.git
> 
> So, the pattern "git git://..." is a false positive in this case.
> 
> There are several other combinations which may produce a wrong
> warning message, such as "@size size", ":Begin begin", etc.
> 
> Extend repeated word check to compare the characters before and
> after the word matches. If the preceding or succeeding character
> belongs to the exception list, the warning is avoided.
> 
> Link: 
> https://lore.kernel.org/linux-kernel-mentees/81b6a0bb2c7b9256361573f7a13201ebcd4876f1.ca...@perches.com/
> Suggested-by: Joe Perches 
> Suggested-by: Lukas Bulwahn 
> Signed-off-by: Dwaipayan Ray 
> ---
>  scripts/checkpatch.pl | 17 +++--
>  1 file changed, 15 insertions(+), 2 deletions(-)
> 
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index f1a4e61917eb..89430dfd6652 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -595,6 +595,7 @@ our @mode_permission_funcs = (
>  );
>  
>  my $word_pattern = '\b[A-Z]?[a-z]{2,}\b';
> +my $exclude_chars = '[^\.\,\+\s]';

Why include a + character here?

>  #Create a search pattern for all these functions to speed up a loop below
>  our $mode_perms_search = "";
> @@ -3056,15 +3057,27 @@ sub process {
>  
>   my $first = $1;
>   my $second = $2;
> -
> + my $start_pos = $-[1];
> + my $end_pos = $+[2];
>   if ($first =~ /(?:struct|union|enum)/) {
>   pos($rawline) += length($first) + 
> length($second) + 1;
>   next;
>   }
>  
> - next if ($first ne $second);
> + next if (lc($first) ne lc($second));
>   next if ($first eq 'long');
>  
> + # check for character before and after the word 
> matches
> + my $start_char = '';
> + my $end_char = '';
> + $start_char = substr($rawline, $start_pos - 1, 
> 1) if ($start_pos > 0);
> + $end_char = substr($rawline, $end_pos, 1) if 
> ($end_pos <= length($rawline));


substr uses index 0, so I believe the if should be < 

> +
> + if ($start_char =~ /^$exclude_chars$/ ||
> + $end_char =~ /^$exclude_chars$/) {
> + next;
> + }
 
Please use "next if (test);" to be similar to the other uses above.

And this doesn't work on end of phrase or sentence.

ie: "my sentence is is, a duplicate word word."

so $end_char could be a comma or a period.

so likely the $end_char test should be !~

What is the reason to add and use $exclude_chars?

Re: 5.9.0-next-20201015: autofs oops in update-binfmts

[Ian Kent]

On Fri, 2020-10-16 at 14:35 +0200, Pavel Machek wrote:
> Hi!
> 
> I'm getting this during boot: 32-bit thinkpad x60.

This is very odd.

The change in next is essentially a revert of a change, maybe I'm
missing something and the revert isn't quite a revert. Although
there was one difference.

I'll check for other revert differences too.

Are you in a position to check a kernel without the 5.9 change
if I send you a patch?

And we should check if that difference to what was originally
there is the source of the problem, so probably two things to
follow up on, reverting that small difference first would be
the way to go.

Are you able to reliably reproduce it?

> 
> [   10.718377] BUG: kernel NULL pointer dereference, address:
> 
> [   10.721848] #PF: supervisor read access in kernel mode
> [   10.722763] #PF: error_code(0x) - not-present page
> [   10.726759] *pdpt = 0339e001 *pde =  
> [   10.730793] Oops:  [#1] PREEMPT SMP PTI
> [   10.736201] CPU: 1 PID: 2762 Comm: update-binfmts Not tainted
> 5.9.0-next-20201015+ #152
> [   10.738769] Hardware name: LENOVO 17097HU/17097HU, BIOS 7BETD8WW
> (2.19 ) 03/31/2011
> [   10.742769] EIP: __kernel_write+0xd4/0x230
> [   10.746769] Code: 89 d6 64 8b 15 b4 77 4c c5 8b 8a 38 0b 00 00 31
> d2 85 c9 74 04 0f b7 51 30 66 89 75 e8 8b 75 ac 8d 4d b0 89 45 e4 66
> 89 55 ea <8b> 06 8b 56 04 57 6a 01 89 45 d4 8d 45 b8 89 55 d8 ba 01
> 00 00 00
> [   10.758762] EAX: 0002 EBX: c1922a40 ECX: c33cdad0 EDX:
> 
> [   10.762791] ESI:  EDI: 012c EBP: c33cdb20 ESP:
> c33cdacc
> [   10.766766] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS:
> 00010286
> [   10.770762] CR0: 80050033 CR2:  CR3: 033d CR4:
> 06b0
> [   10.770762] Call Trace:
> [   10.770762]  ? __mutex_unlock_slowpath+0x2b/0x2c0
> [   10.770762]  ? dma_direct_map_sg+0x13a/0x320
> [   10.770762]  autofs_notify_daemon+0x14d/0x2b0
> [   10.770762]  autofs_wait+0x4cd/0x770
> [   10.793051]  ? autofs_d_automount+0xd6/0x1e0
> [   10.793051]  autofs_mount_wait+0x43/0xe0
> [   10.797808]  autofs_d_automount+0xdf/0x1e0
> [   10.797808]  __traverse_mounts+0x85/0x200
> [   10.797808]  step_into+0x368/0x620
> [   10.797808]  ? proc_setup_thread_self+0x110/0x110
> [   10.797808]  walk_component+0x58/0x190
> [   10.811838]  link_path_walk.part.0+0x245/0x360
> [   10.811838]  path_lookupat.isra.0+0x31/0x130
> [   10.811838]  filename_lookup+0x8d/0x130
> [   10.818749]  ? cache_alloc_debugcheck_after+0x151/0x180
> [   10.818749]  ? getname_flags+0x1f/0x160
> [   10.818749]  ? kmem_cache_alloc+0x75/0x100
> [   10.818749]  user_path_at_empty+0x25/0x30
> [   10.818749]  vfs_statx+0x63/0x100
> [   10.831022]  ? _raw_spin_unlock+0x18/0x30
> [   10.831022]  ? replace_page_cache_page+0x160/0x160
> [   10.831022]  __do_sys_stat64+0x36/0x60
> [   10.831022]  ? exit_to_user_mode_prepare+0x35/0xe0
> [   10.831022]  ? irqentry_exit_to_user_mode+0x8/0x20
> [   10.838773]  ? irqentry_exit+0x55/0x70
> [   10.838773]  ? exc_page_fault+0x228/0x3c0
> [   10.838773]  __ia32_sys_stat64+0xd/0x10
> [   10.838773]  do_int80_syscall_32+0x2c/0x40
> [   10.848561]  entry_INT80_32+0x111/0x111
> [   10.848561] EIP: 0xb7ee2092
> [   10.848561] Code: 00 00 00 e9 90 ff ff ff ff a3 24 00 00 00 68 30
> 00 00 00 e9 80 ff ff ff ff a3 e8 ff ff ff 66 90 00 00 00 00 00 00 00
> 00 cd 80  8d b4 26 00 00 00 00 8d b6 00 00 00 00 8b 1c 24 c3 8d
> b4 26 00
> [   10.848561] EAX: ffda EBX: 00468490 ECX: bfbce6ec EDX:
> 00467348
> [   10.848561] ESI:  EDI: 00468490 EBP: bfbce6ec ESP:
> bfbce6c4
> [   10.848561] DS: 007b ES: 007b FS:  GS: 0033 SS: 007b EFLAGS:
> 0292
> [   10.848561] Modules linked in:
> [   10.848561] CR2: 
> [   10.851552] ---[ end trace d01bd7323c2317a5 ]---
> [   10.851558] EIP: __kernel_write+0xd4/0x230
> [   10.851561] Code: 89 d6 64 8b 15 b4 77 4c c5 8b 8a 38 0b 00 00 31
> d2 85 c9 74 04 0f b7 51 30 66 89 75 e8 8b 75 ac 8d 4d b0 89 45 e4 66
> 89 55 ea <8b> 06 8b 56 04 57 6a 01 89 45 d4 8d 45 b8 89 55 d8 ba 01
> 00 00 00
> [   10.851563] EAX: 0002 EBX: c1922a40 ECX: c33cdad0 EDX:
> 
> [   10.851565] ESI:  EDI: 012c EBP: c33cdb20 ESP:
> c33cdacc
> [   10.851568] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS:
> 00010286
> [   10.851570] CR0: 80050033 CR2: 004a700e CR3: 033d CR4:
> 06b0
> [   11.803128] systemd-journald[2514]: Received request to flush
> runtime journal from PID 1
> [   26.113941] iwl3945 :03:00.0: loaded firmware version
> 15.32.2.9
> [   59.809322] traps: clock-applet[3636] trap int3 ip:b724ffc0
> sp:bf879b90 error:0 in libglib-2.0.so.0.5000.3[b7203000+12a000]
> [   59.812036] traps: mateweather-app[3638] trap int3 ip:b7283fc0
> sp:bfb65760 error:0 in libglib-2.0.so.0.5000.3[b7237000+12a000]
> [   64.628401] wlan0: authenticate with 5c:f4:ab:10:d2:bb
> 
-- 
Ian Kent 

drivers/dma/ppc4xx/adma.c:1188:34: sparse: sparse: incorrect type in argument 1 (different address spaces)

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   071a0578b0ce0b0e543d1e38ee6926b9cc21c198
commit: 8f28ca6bd8211214faf717677bbffe375c2a6072 iomap: constify ioreadX() 
iomem argument (as in generic implementation)
date:   9 weeks ago
config: powerpc-randconfig-s032-20201017 (attached as .config)
compiler: powerpc-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
# apt-get install sparse
# sparse version: v0.6.3-rc1-2-g368fd9ce-dirty
# 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8f28ca6bd8211214faf717677bbffe375c2a6072
git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 8f28ca6bd8211214faf717677bbffe375c2a6072
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=powerpc 

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


"sparse warnings: (new ones prefixed by >>)"
   drivers/dma/ppc4xx/adma.c:73:1: sparse: sparse: symbol 
'ppc440spe_adma_chan_list' was not declared. Should it be static?
   drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32
   drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32
   drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32
   drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32
   drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32
   drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32
   drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32
   drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32
   drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32
   drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32
   drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32
   drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32
   drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32
   drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32
   drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32
   drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32
   drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32
   drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32
   drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32
   drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32
   drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32
   drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32
   drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32
   drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32
   drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32
   drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32
   drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32
   drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32
   drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32
   drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32
   drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32
   drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32
   drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32
   drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32
   drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32
   drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32
   drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32
   drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32
   drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32
   drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32
   drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32
   drivers/dma/ppc4xx/adma.c:140:17: sparse: sparse: cast to restricted __le32
   drivers/dma/ppc4xx/adma.c:543:35: sparse: sparse: incorrect type in 
assignment (different base types) @@ expected unsigned int [usertype] sg1l 
@@ got restricted __le32 [usertype] @@
   drivers/dma/ppc4xx/adma.c:543:35: sparse: expected unsigned int 
[usertype

Re: [PATCH v7 3/3] iommu/tegra-smmu: Add PCI support

[Nicolin Chen]

On Fri, Oct 16, 2020 at 03:10:26PM +0100, Robin Murphy wrote:
> On 2020-10-16 04:53, Nicolin Chen wrote:
> > On Thu, Oct 15, 2020 at 10:55:52AM +0100, Robin Murphy wrote:
> > > On 2020-10-15 05:13, Nicolin Chen wrote:
> > > > On Wed, Oct 14, 2020 at 06:42:36PM +0100, Robin Murphy wrote:
> > > > > On 2020-10-09 17:19, Nicolin Chen wrote:
> > > > > > This patch simply adds support for PCI devices.
> > > > > > 
> > > > > > Reviewed-by: Dmitry Osipenko 
> > > > > > Tested-by: Dmitry Osipenko 
> > > > > > Signed-off-by: Nicolin Chen 
> > > > > > ---
> > > > > > 
> > > > > > Changelog
> > > > > > v6->v7
> > > > > > * Renamed goto labels, suggested by Thierry.
> > > > > > v5->v6
> > > > > > * Added Dmitry's Reviewed-by and Tested-by.
> > > > > > v4->v5
> > > > > > * Added Dmitry's Reviewed-by
> > > > > > v3->v4
> > > > > > * Dropped !iommu_present() check
> > > > > > * Added CONFIG_PCI check in the exit path
> > > > > > v2->v3
> > > > > > * Replaced ternary conditional operator with if-else in 
> > > > > > .device_group()
> > > > > > * Dropped change in tegra_smmu_remove()
> > > > > > v1->v2
> > > > > > * Added error-out labels in tegra_smmu_probe()
> > > > > > * Dropped pci_request_acs() since IOMMU core would call it.
> > > > > > 
> > > > > > drivers/iommu/tegra-smmu.c | 35 
> > > > > > +--
> > > > > > 1 file changed, 25 insertions(+), 10 deletions(-)
> > > > > > 
> > > > > > diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
> > > > > > index be29f5977145..2941d6459076 100644
> > > > > > --- a/drivers/iommu/tegra-smmu.c
> > > > > > +++ b/drivers/iommu/tegra-smmu.c
> > > > > > @@ -10,6 +10,7 @@
> > > > > > #include 
> > > > > > #include 
> > > > > > #include 
> > > > > > +#include 
> > > > > > #include 
> > > > > > #include 
> > > > > > #include 
> > > > > > @@ -865,7 +866,11 @@ static struct iommu_group 
> > > > > > *tegra_smmu_device_group(struct device *dev)
> > > > > > group->smmu = smmu;
> > > > > > group->soc = soc;
> > > > > > -   group->group = iommu_group_alloc();
> > > > > > +   if (dev_is_pci(dev))
> > > > > > +   group->group = pci_device_group(dev);
> > > > > 
> > > > > Just to check, is it OK to have two or more swgroups "owning" the same
> > > > > iommu_group if an existing one gets returned here? It looks like that 
> > > > > might
> > > > > not play nice with the use of iommu_group_set_iommudata().
> > > > 
> > > > Do you mean by "gets returned here" the "IS_ERR" check below?
> > > 
> > > I mean that unlike iommu_group_alloc()/generic_device_group(),
> > > pci_device_group() may give you back a group that already contains another
> > > device and has already been set up from that device's perspective. This 
> > > can
> > > happen for topological reasons like requester ID aliasing through a 
> > > PCI-PCIe
> > > bridge or lack of isolation between functions.
> > 
> > Okay..but we don't really have two swgroups owning the same groups
> > in case of PCI devices. For Tegra210, all PCI devices inherit the
> > same swgroup from the PCI controller. And I'd think previous chips
> > do the same. The only use case currently of 2+ swgroups owning the
> > same iommu_group is for display controller.
> > 
> > Or do you suggest we need an additional check for pci_device_group?
> 
> Ah, OK - I still don't have the best comprehension of what exactly swgroups

The "swgroup" stands for "software group", which associates with
an ASID (Address Space Identifier) for SMMU to determine whether
this client is going through SMMU translation or not.

> are, and the path through .of_xlate looked like you might be using the PCI
> requester ID as the swgroup identifier, but I guess that ultimately depends
> on what your "iommu-map" is supposed to look like. If pci_device_group()

This is copied from pcie node in our downstream dtsi file:

iommus = <&mc TEGRA_SWGROUP_AFI>;
iommu-map = <0x0 &mc TEGRA_SWGROUP_AFI 0x1000>;
iommu-map-mask = <0x0>;

> will effectively only ever get called once regardless of how many endpoints
> exist, then indeed this won't be a concern (although if that's *guaranteed*
> to be the case then you may as well just stick with calling
> iommu_group_alloc() directly). Thanks for clarifying.

All PCI devices are supposed to get this swgroup of the pcie node
above. So the function will return the existing group of the pcie
controller, before giving a chance to call iommu_group_alloc().

Thanks for the review and input.

[PATCH] skd_main: remove unused including

[Tian Tao]

Remove including  that don't need it.

Signed-off-by: Tian Tao 
---
 drivers/block/skd_main.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/block/skd_main.c b/drivers/block/skd_main.c
index ae6454c..a962b45 100644
--- a/drivers/block/skd_main.c
+++ b/drivers/block/skd_main.c
@@ -25,7 +25,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
-- 
2.7.4

Re: [PATCH] drivers/virt: vmgenid: add vm generation id driver

[Jann Horn]

On Sat, Oct 17, 2020 at 6:34 AM Colm MacCarthaigh  wrote:
> On 16 Oct 2020, at 21:02, Jann Horn wrote:
> > On Sat, Oct 17, 2020 at 5:36 AM Willy Tarreau  wrote:
> > But in userspace, we just need a simple counter. There's no need for
> > us to worry about anything else, like timestamps or whatever. If we
> > repeatedly fork a paused VM, the forked VMs will see the same counter
> > value, but that's totally fine, because the only thing that matters to
> > userspace is that the counter changes when the VM is forked.
>
> For user-space, even a single bit would do. We added MADVISE_WIPEONFORK
> so that userspace libraries can detect fork()/clone() robustly, for the
> same reasons. It just wipes a page as the indicator, which is
> effectively a single-bit signal, and it works well. On the user-space
> side of this, I’m keen to find a solution like that that we can use
> fairly easily inside of portable libraries and applications. The “have
> I forked” checks do end up in hot paths, so it’s nice if they can be
> CPU cache friendly. Comparing a whole 128-bit value wouldn’t be my
> favorite.

I'm pretty sure a single bit is not enough if you want to have a
single page, shared across the entire system, that stores the VM
forking state; you need a counter for that.

> > And actually, since the value is a cryptographically random 128-bit
> > value, I think that we should definitely use it to help reseed the
> > kernel's RNG, and keep it secret from userspace. That way, even if the
> > VM image is public, we can ensure that going forward, the kernel RNG
> > will return securely random data.
>
> If the image is public, you need some extra new raw entropy from
> somewhere. The gen-id could be mixed in, that can’t do any harm as
> long as rigorous cryptographic mixing with the prior state is used, but
> if that’s all you do then the final state is still deterministic and
> non-secret.

Microsoft's documentation
(http://go.microsoft.com/fwlink/?LinkId=260709) says that the VM
Generation ID that we get after a fork "is a 128-bit,
cryptographically random integer value". If multiple people use the
same image, it guarantees that each use of the image gets its own,
fresh ID: The table in section "How to implement virtual machine
generation ID support in a virtualization platform" says that (among
other things) "Virtual machine is imported, copied, or cloned"
generates a new generation ID.

So the RNG state after mixing in the new VM Generation ID would
contain 128 bits of secret entropy not known to anyone else, including
people with access to the VM image.

Now, 128 bits of cryptographically random data aren't _optimal_; I
think something on the order of 256 bits would be nicer from a
theoretical standpoint. But in practice I think we'll be good with the
128 bits we're getting (since the number of users who fork a VM image
is probably not going to be so large that worst-case collision
probabilities matter).

> The kernel would need to use the change as a trigger to
> measure some entropy (e.g. interrupts and RDRAND, or whatever). Our just
> define the machine contract as “this has to be unique random data and
> if it’s not unique, or if it’s pubic, you’re toast”.

As far as I can tell from Microsoft's spec, that is a guarantee we're
already getting.

Re: [PATCH 1/2] tools/include: Update if_link.h and netlink.h

[Jesse Brandeburg]

Jakub Kicinski wrote:

> On Fri, 16 Oct 2020 14:23:48 -0700 Jesse Brandeburg wrote:
> > > These are tested to be the latest as part of the tools/lib/bpf build.  
> > 
> > But you didn't mention why you're making these changes, and you're
> > removing a lot of comments without explaining why/where there might be
> > a replacement or why the comments are useless. I now see that you're
> > adding actual kdoc which is good, except for the part where
> > you don't put kdoc on all the structures.
> 
> Note that he's just syncing the uAPI headers to tools/
> 
> The source of the change is here:
> 
> 78a3ea555713 ("net: remove comments on struct rtnl_link_stats")
> 0db0c34cfbc9 ("net: tighten the definition of interface statistics")


Thanks Kuba, I'm not trying to be a hard ass, but the commit message
didn't say why he's making the change, and if I bisect back to this
and see "sync" as the commit message, I think I'd be stuck chasing
"sync to what?"

I guess that his changelog could just say what you said?

Proposed:
Sync the uAPI headers so that userspace and the kernel match. These
changes match the updates to the files in the tools directory that were
already updated by commits:
78a3ea555713 ("net: remove comments on struct rtnl_link_stats")
0db0c34cfbc9 ("net: tighten the definition of interface statistics")

Re: [PATCH RFC V3 4/9] x86/pks: Preserve the PKRS MSR on context switch

[Ira Weiny]

On Fri, Oct 16, 2020 at 01:06:36PM +0200, Peter Zijlstra wrote:
> On Fri, Oct 09, 2020 at 12:42:53PM -0700, ira.we...@intel.com wrote:
> 
> > @@ -644,6 +663,8 @@ void __switch_to_xtra(struct task_struct *prev_p, 
> > struct task_struct *next_p)
> >  
> > if ((tifp ^ tifn) & _TIF_SLD)
> > switch_to_sld(tifn);
> > +
> > +   pks_sched_in();
> >  }
> >  
> 
> You seem to have lost the comment proposed here:
> 
>   
> https://lkml.kernel.org/r/20200717083140.gw10...@hirez.programming.kicks-ass.net
> 
> It is useful and important information that the wrmsr normally doesn't
> happen.

Added back in here.

> 
> > diff --git a/arch/x86/mm/pkeys.c b/arch/x86/mm/pkeys.c
> > index 3cf8f775f36d..30f65dd3d0c5 100644
> > --- a/arch/x86/mm/pkeys.c
> > +++ b/arch/x86/mm/pkeys.c
> > @@ -229,3 +229,31 @@ u32 update_pkey_val(u32 pk_reg, int pkey, unsigned int 
> > flags)
> >  
> > return pk_reg;
> >  }
> > +
> > +DEFINE_PER_CPU(u32, pkrs_cache);
> > +
> > +/**
> > + * It should also be noted that the underlying WRMSR(MSR_IA32_PKRS) is not
> > + * serializing but still maintains ordering properties similar to WRPKRU.
> > + * The current SDM section on PKRS needs updating but should be the same as
> > + * that of WRPKRU.  So to quote from the WRPKRU text:
> > + *
> > + * WRPKRU will never execute transiently. Memory accesses
> > + * affected by PKRU register will not execute (even transiently)
> > + * until all prior executions of WRPKRU have completed execution
> > + * and updated the PKRU register.
> 
> (whitespace damage; space followed by tabstop)

Fixed thanks.

> 
> > + */
> > +void write_pkrs(u32 new_pkrs)
> > +{
> > +   u32 *pkrs;
> > +
> > +   if (!static_cpu_has(X86_FEATURE_PKS))
> > +   return;
> > +
> > +   pkrs = get_cpu_ptr(&pkrs_cache);
> > +   if (*pkrs != new_pkrs) {
> > +   *pkrs = new_pkrs;
> > +   wrmsrl(MSR_IA32_PKRS, new_pkrs);
> > +   }
> > +   put_cpu_ptr(pkrs);
> > +}
> 
> looks familiar that... :-)

Added you as a co-developer if that is ok?

Ira

Re: [PATCH v4 3/3] clk: qcom: lpasscc-sc7180: Re-configure the PLL in case lost

[Stephen Boyd]

Quoting Stephen Boyd (2020-10-15 20:16:27)
> Quoting Douglas Anderson (2020-10-14 17:13:29)
> > From: Taniya Das 
> > 
> > In the case where the PLL configuration is lost, then the pm runtime
> > resume will reconfigure before usage.
> 
> Taniya, this commit needs a lot more describing than one sentence. I see
> that the PLL's L value is reset at boot, but only once. That seems to be
> because the bootloader I have doesn't set bit 11 for the RETAIN_FF bit
> on the lpass_core_hm_gdsc. Once the gdsc is turned off the first time,
> the PLL settings are lost and the L val is reset to 0. That makes sense
> because RETAIN_FF isn't set. This also means the other register writes
> during probe are lost during the first suspend of the lpass core clk
> controller. Then when the GDSC is turned on the next time for this clk
> controller  being runtime resumed we will set the retain bit and then
> configure the PLL again. BTW, I see that runtime PM is called for this
> clk controller for all the clk operations. Maybe there should be some
> auto suspend timeout so that we're not toggling the gdsc constantly?
> 
> I hacked up the GDSC code to set the bit at gdsc registration time and
> it seems to fix the problem I'm seeing (i.e. that the PLL is stuck,
> which should also be in the commit text here). When I try to set the bit
> in the bootloader though my kernel won't boot. I guess something is
> hanging the system if I enable the retain bit in the GDSC?
> 

After hacking on this for some time it looks like we can apply this
patch instead and things are good. The first two patches in this series
look mostly good to me minus some nitpicks so please resend.

---8<---
diff --git a/drivers/clk/qcom/gdsc.c b/drivers/clk/qcom/gdsc.c
index 99834564bcc2..508c2901abfa 100644
--- a/drivers/clk/qcom/gdsc.c
+++ b/drivers/clk/qcom/gdsc.c
@@ -343,6 +343,14 @@ static int gdsc_init(struct gdsc *sc)
if ((sc->flags & VOTABLE) && on)
gdsc_enable(&sc->pd);
 
+   /*
+* Make sure the retain bit is set if the GDSC is already on, otherwise
+* we end up turning off the GDSC and destroying all the register
+* contents that we thought we were saving.
+*/
+   if ((sc->flags & RETAIN_FF_ENABLE) && on)
+   gdsc_retain_ff_on(sc);
+
/* If ALWAYS_ON GDSCs are not ON, turn them ON */
if (sc->flags & ALWAYS_ON) {
if (!on)

Re: [PATCH] drivers/virt: vmgenid: add vm generation id driver

[Willy Tarreau]

On Sat, Oct 17, 2020 at 07:01:31AM +0200, Jann Horn wrote:
> Microsoft's documentation
> (http://go.microsoft.com/fwlink/?LinkId=260709) says that the VM
> Generation ID that we get after a fork "is a 128-bit,
> cryptographically random integer value". If multiple people use the
> same image, it guarantees that each use of the image gets its own,
> fresh ID:

No. It cannot be more unique than the source that feeds that cryptographic
transformation. All it guarantees is that the entropy source is protected
from being guessed based on the output. Applying cryptography on a simple
counter provides apparently random numbers that will be unique for a long
period for the same source, but as soon as you duplicate that code between
users and they start from the same counter they'll get the same IDs.

This is why I think that using a counter is better if you really need something
unique. Randoms only reduce predictability which helps avoiding collisions.
And I'm saying this as someone who had on his external gateway the same SSH
host key as 89 other hosts on the net, each of them using randoms to provide
a universally unique one...

Willy

[PATCH] clk: qcom: gdsc: Keep RETAIN_FF bit set if gdsc is already on

[Stephen Boyd]

If the GDSC is enabled out of boot but doesn't have the retain ff bit
set we will get confusing results where the registers that are powered
by the GDSC lose their contents on the first power off of the GDSC but
thereafter they retain their contents. This is because gdsc_init() fails
to make sure the RETAIN_FF bit is set when it probes the GDSC the first
time and thus powering off the GDSC causes the register contents to be
reset. We do set the RETAIN_FF bit the next time we power on the GDSC,
see gdsc_enable(), so that subsequent GDSC power off's don't lose
register contents state.

Forcibly set the bit at device probe time so that the kernel's assumed
view of the GDSC is consistent with the state of the hardware. This
fixes a problem where the audio PLL doesn't work on sc7180 when the
bootloader leaves the lpass_core_hm GDSC enabled at boot (e.g. to make a
noise) but critically doesn't set the RETAIN_FF bit.

Cc: Douglas Anderson 
Cc: Taniya Das 
Cc: Rajendra Nayak 
Fixes: 173722995cdb ("clk: qcom: gdsc: Add support to enable retention of 
GSDCR")
Signed-off-by: Stephen Boyd 
---
 drivers/clk/qcom/gdsc.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/clk/qcom/gdsc.c b/drivers/clk/qcom/gdsc.c
index bfc4ac02f9ea..af26e0695b86 100644
--- a/drivers/clk/qcom/gdsc.c
+++ b/drivers/clk/qcom/gdsc.c
@@ -358,6 +358,14 @@ static int gdsc_init(struct gdsc *sc)
if ((sc->flags & VOTABLE) && on)
gdsc_enable(&sc->pd);
 
+   /*
+* Make sure the retain bit is set if the GDSC is already on, otherwise
+* we end up turning off the GDSC and destroying all the register
+* contents that we thought we were saving.
+*/
+   if ((sc->flags & RETAIN_FF_ENABLE) && on)
+   gdsc_retain_ff_on(sc);
+
/* If ALWAYS_ON GDSCs are not ON, turn them ON */
if (sc->flags & ALWAYS_ON) {
if (!on)

base-commit: 9ff9b0d392ea08090cd1780fb196f36dbb586529
-- 
https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git/

Re: [PATCH RFC V3 4/9] x86/pks: Preserve the PKRS MSR on context switch

[Ira Weiny]

On Fri, Oct 16, 2020 at 01:12:26PM +0200, Peter Zijlstra wrote:
> On Tue, Oct 13, 2020 at 11:31:45AM -0700, Dave Hansen wrote:
> > > +/**
> > > + * It should also be noted that the underlying WRMSR(MSR_IA32_PKRS) is 
> > > not
> > > + * serializing but still maintains ordering properties similar to WRPKRU.
> > > + * The current SDM section on PKRS needs updating but should be the same 
> > > as
> > > + * that of WRPKRU.  So to quote from the WRPKRU text:
> > > + *
> > > + *   WRPKRU will never execute transiently. Memory accesses
> > > + *   affected by PKRU register will not execute (even transiently)
> > > + *   until all prior executions of WRPKRU have completed execution
> > > + *   and updated the PKRU register.
> > > + */
> > > +void write_pkrs(u32 new_pkrs)
> > > +{
> > > + u32 *pkrs;
> > > +
> > > + if (!static_cpu_has(X86_FEATURE_PKS))
> > > + return;
> > > +
> > > + pkrs = get_cpu_ptr(&pkrs_cache);
> > > + if (*pkrs != new_pkrs) {
> > > + *pkrs = new_pkrs;
> > > + wrmsrl(MSR_IA32_PKRS, new_pkrs);
> > > + }
> > > + put_cpu_ptr(pkrs);
> > > +}
> > > 
> > 
> > It bugs me a *bit* that this is being called in a preempt-disabled
> > region, but we still bother with the get/put_cpu jazz.  Are there other
> > future call-sites for this that aren't in preempt-disabled regions?
> 
> So the previous version had a useful comment that got lost.

Ok Looking back I see what happened...  This comment...

 /*
  * PKRS is only temporarily changed during specific code paths.
  * Only a preemption during these windows away from the default
  * value would require updating the MSR.
  */

... was added to pks_sched_in() but that got simplified down because cleaning
up write_pkrs() made the code there obsolete.

> This stuff
> needs to fundamentally be preempt disabled,

I agree, the update to the percpu cache value and MSR can not be torn.

> so it either needs to
> explicitly do so, or have an assertion that preemption is indeed
> disabled.

However, I don't think I understand clearly.  Doesn't [get|put]_cpu_ptr()
handle the preempt_disable() for us?  Is it not sufficient to rely on that?

Dave's comment seems to be the opposite where we need to eliminate preempt
disable before calling write_pkrs().

FWIW I think I'm mistaken in my response to Dave regarding the
preempt_disable() in pks_update_protection().

Ira

[PATCH] nds32: Fix a broken copyright header in gen_vdso_offsets.sh

[Palmer Dabbelt]

From: Palmer Dabbelt 

I was going to copy this but I didn't want to chase around the build
system stuff so I did it a different way.

Signed-off-by: Palmer Dabbelt 
---
 arch/nds32/kernel/vdso/gen_vdso_offsets.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/nds32/kernel/vdso/gen_vdso_offsets.sh 
b/arch/nds32/kernel/vdso/gen_vdso_offsets.sh
index 01924ff071ad..5b329aed3501 100755
--- a/arch/nds32/kernel/vdso/gen_vdso_offsets.sh
+++ b/arch/nds32/kernel/vdso/gen_vdso_offsets.sh
@@ -7,7 +7,7 @@
 # Doing this inside the Makefile will break the $(filter-out) function,
 # causing Kbuild to rebuild the vdso-offsets header file every time.
 #
-# Author: Will Deacon 
 #
 
 LC_ALL=C
-- 
2.29.0.rc1.297.gfa9743e501-goog

Re: [PATCH RFC V3 2/9] x86/fpu: Refactor arch_set_user_pkey_access() for PKS support

[Ira Weiny]

On Fri, Oct 16, 2020 at 12:57:43PM +0200, Peter Zijlstra wrote:
> On Fri, Oct 09, 2020 at 12:42:51PM -0700, ira.we...@intel.com wrote:
> > From: Fenghua Yu 
> > 
> > Define a helper, update_pkey_val(), which will be used to support both
> > Protection Key User (PKU) and the new Protection Key for Supervisor
> > (PKS) in subsequent patches.
> > 
> > Co-developed-by: Ira Weiny 
> > Signed-off-by: Ira Weiny 
> > Signed-off-by: Fenghua Yu 
> > ---
> >  arch/x86/include/asm/pkeys.h |  2 ++
> >  arch/x86/kernel/fpu/xstate.c | 22 --
> >  arch/x86/mm/pkeys.c  | 21 +
> >  3 files changed, 27 insertions(+), 18 deletions(-)
> 
> This is not from Fenghua.
> 
>   
> https://lkml.kernel.org/r/20200717085442.gx10...@hirez.programming.kicks-ass.net
> 
> This is your patch based on the code I wrote.

Ok, I apologize.  Yes the code below was all yours.

Is it ok to add?

Co-developed-by: Peter Zijlstra 
Signed-off-by: Peter Zijlstra 

?

Thanks,
Ira

> 
> > diff --git a/arch/x86/mm/pkeys.c b/arch/x86/mm/pkeys.c
> > index f5efb4007e74..3cf8f775f36d 100644
> > --- a/arch/x86/mm/pkeys.c
> > +++ b/arch/x86/mm/pkeys.c
> > @@ -208,3 +208,24 @@ static __init int setup_init_pkru(char *opt)
> > return 1;
> >  }
> >  __setup("init_pkru=", setup_init_pkru);
> > +
> > +/*
> > + * Update the pk_reg value and return it.
> > + *
> > + * Kernel users use the same flags as user space:
> > + * PKEY_DISABLE_ACCESS
> > + * PKEY_DISABLE_WRITE
> > + */
> > +u32 update_pkey_val(u32 pk_reg, int pkey, unsigned int flags)
> > +{
> > +   int pkey_shift = pkey * PKR_BITS_PER_PKEY;
> > +
> > +   pk_reg &= ~(((1 << PKR_BITS_PER_PKEY) - 1) << pkey_shift);
> > +
> > +   if (flags & PKEY_DISABLE_ACCESS)
> > +   pk_reg |= PKR_AD_BIT << pkey_shift;
> > +   if (flags & PKEY_DISABLE_WRITE)
> > +   pk_reg |= PKR_WD_BIT << pkey_shift;
> > +
> > +   return pk_reg;
> > +}
> > -- 
> > 2.28.0.rc0.12.gb6a658bd00c9
> > 

Re: [PATCH net-next 1/3] net: dsa: don't pass cloned skb's to drivers xmit function

[Vladimir Oltean]

On Fri, Oct 16, 2020 at 10:02:24PM +0200, Christian Eggers wrote:
> Ensure that the skb is not cloned and has enough tail room for the tail
> tag. This code will be removed from the drivers in the next commits.
> 
> Signed-off-by: Christian Eggers 
> ---

Does 1588 work for you using this change, or you haven't finished
implementing it yet? If you haven't, I would suggest finishing that
part first.

The post-reallocation skb looks nothing like the one before.

Before:
skb len=68 headroom=2 headlen=68 tailroom=186
mac=(2,14) net=(16,-1) trans=-1
shinfo(txflags=1 nr_frags=0 gso(size=0 type=0 segs=0))
csum(0x0 ip_summed=0 complete_sw=0 valid=0 level=0)
hash(0x9d6927ec sw=1 l4=0) proto=0x88f7 pkttype=0 iif=0
dev name=swp2 feat=0x0x00025020
sk family=17 type=3 proto=0

After:
skb len=68 headroom=2 headlen=68 tailroom=186
mac=(2,16) net=(18,-17) trans=1
shinfo(txflags=0 nr_frags=0 gso(size=0 type=0 segs=0))
csum(0x0 ip_summed=0 complete_sw=0 valid=0 level=0)
hash(0x0 sw=0 l4=0) proto=0x pkttype=0 iif=0

Notice how you've changed shinfo(txflags), among other things.

Which proves that you can't just copy&paste whatever you found in
tag_trailer.c.

I am not yet sure whether there is any helper that can be used instead
of this crazy open-coding. Right now, not having tested anything yet, my
candidates of choice would be pskb_expand_head or __pskb_pull_tail. You
should probably also try to cater here for the potential reallocation
done in the skb_cow_head() of non-tail taggers. Which would lean the
balance towards pskb_expand_head(), I believe.

Also, if the result is going to be longer than ~20 lines of code, I
strongly suggest moving the reallocation to a separate function so you
don't clutter dsa_slave_xmit.

Also, please don't redeclare struct sk_buff *nskb, you don't need to.

Re: [PATCH 3/5] gpio: msc313: MStar MSC313 GPIO driver

[Daniel Palmer]

Hi Linus

On Sat, 17 Oct 2020 at 01:56, Linus Walleij  wrote:
> (...)
>
> > +config GPIO_MSC313
> > +   bool "MStar MSC313 GPIO support"
> > +   default y if ARCH_MSTARV7
> > +   depends on ARCH_MSTARV7
> > +   select GPIO_GENERIC
>
> Selecting GPIO_GENERIC, that is good.
> But you're not using it, because you can't.
> This chip does not have the bits lined up nicely
> in one register, instead there seems to be something
> like one register per line, right?
> So skip GPIO_GENERIC.

Well spotted. Copy/paste fail on my side :).

> > +#define MSC313_GPIO_IN  BIT(0)
> > +#define MSC313_GPIO_OUT BIT(4)
> > +#define MSC313_GPIO_OEN BIT(5)
> > +
> > +#define MSC313_GPIO_BITSTOSAVE (MSC313_GPIO_OUT | MSC313_GPIO_OEN)
>
> Some comment here telling us why these need saving and
> not others.

There is a comment near to the save function that explains it I think.
When the hardware goes into low power mode with the CPU turned off
the register contents are lost and those two bits are the only ones that are
writable from what I can tell. I'll add an extra comment above that line.

> > +#define FUART_NAMES\
> > +   MSC313_PINNAME_FUART_RX,\
> > +   MSC313_PINNAME_FUART_TX,\
> > +   MSC313_PINNAME_FUART_CTS,   \
> > +   MSC313_PINNAME_FUART_RTS
> > +
> > +#define OFF_FUART_RX   0x50
> > +#define OFF_FUART_TX   0x54
> > +#define OFF_FUART_CTS  0x58
> > +#define OFF_FUART_RTS  0x5c
> > +
> > +#define FUART_OFFSETS  \
> > +   OFF_FUART_RX,   \
> > +   OFF_FUART_TX,   \
> > +   OFF_FUART_CTS,  \
> > +   OFF_FUART_RTS
>
> This looks a bit strange. The GPIO driver should not really
> have to know about any other use cases for pins than
> GPIO. But I guess it is intuitive for the driver.
>

>
> Same with all these. I suppose it is the offsets of stuff
> that would be there unless we were using it for GPIO.

The pad FUART_RX can't move but the function FUART_RX can.
If the function FUART_RX (or another function) isn't on the pad/pin
FUART_RX it's connected to the GPIO block.
Even more confusingly some of the other chips (SSD201/SSD202)
have pads called GPIO1, GPIO2 etc that only have GPIO functionality
but the offsets of the registers to control the GPIO on those pads might
not have a relation to the name.
GPIO1 isn't gpio_base + (1 * 4) and instead some random address.

Basically using the pad name as the name of the GPIO made sense
because it's fixed and the pad name and offset are the same with all
of the chips I've seen so far.

> > +static int msc313_gpio_to_irq(struct gpio_chip *chip, unsigned int offset)
> > +{
> > +   struct msc313_gpio *gpio = gpiochip_get_data(chip);
> > +> +
>
> > +   return gpio->irqs[offset];
> > +}
>
> Please do not use custom IRQ handling like this.
> As there seems to be one IRQ per line, look into using
>
> select GPIOLIB_IRQCHIP
> select IRQ_DOMAIN_HIERARCHY
>
> See for example in gpio-ixp4xx.c how we deal with
> hiearchical GPIO IRQs.



> Use hierarchical generic GPIO IRQs for these.
>
> Assign ->fwnode, ->parent_domain, ->child_to_parent_hwirq,
> and probably also ->handler on the struct gpio_irq_chip *.
>
> Skip assigning gpiochip->to_irq, the generic code will
> handle that.
>
> Again see gpio-ixp4xx.c for an example.

I'll look into this.
I don't have datasheets so I'm working from some crusty header
files from the vendor kernel but there isn't one irq per line from
what I can tell.
There seems to have been 4 spare lines on an interrupt controller
so they wired GPIOs to them.

Thank you for the comments. I'll send a v2 in a few days.

Thanks,

Daniel

[PATCH] arm64: Fix a broken copyright header in gen_vdso_offsets.sh

[Palmer Dabbelt]

From: Palmer Dabbelt 

I was going to copy this but I didn't want to chase around the build
system stuff so I did it a different way.

Signed-off-by: Palmer Dabbelt 
---
 arch/arm64/kernel/vdso/gen_vdso_offsets.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/vdso/gen_vdso_offsets.sh 
b/arch/arm64/kernel/vdso/gen_vdso_offsets.sh
index 0664acaf61ff..8b806eacd0a6 100755
--- a/arch/arm64/kernel/vdso/gen_vdso_offsets.sh
+++ b/arch/arm64/kernel/vdso/gen_vdso_offsets.sh
@@ -8,7 +8,7 @@
 # Doing this inside the Makefile will break the $(filter-out) function,
 # causing Kbuild to rebuild the vdso-offsets header file every time.
 #
-# Author: Will Deacon 
 #
 
 LC_ALL=C
-- 
2.29.0.rc1.297.gfa9743e501-goog

Re: [PATCH v2] HID: i2c-hid: add polling mode based on connected GPIO chip's pin status

[Coiby Xu]

Hi,

Thank you for examine this patch in such a careful way!

On Fri, Oct 16, 2020 at 03:00:49PM +, Barnabás Pőcze wrote:

Hi,

I still think that `i2c_hid_resume()` and `i2c_hid_suspend()` are asymmetric and
that might lead to issues.



Do you think this commit message is relevant to your concern?

$ git show d1c48038b849e9df0475621a52193a62424a4e87
commit d1c48038b849e9df0475621a52193a62424a4e87
HID: i2c-hid: Only disable irq wake if it was successfully enabled during 
suspend

Enabling irq wake could potentially fail and calling disable_irq_wake
after a failed call to enable_irq_wake could result in an unbalanced irq
warning. This patch warns if enable_irq_wake fails and avoids other
potential issues caused by calling disable_irq_wake on resume after
enable_irq_wake failed during suspend.

So I think all cases about irq have been handled. But for the regulator
part, you are right. I made a mistake.



[...]
When polling mode is enabled, an I2C device can't wake up the suspended
system since enable/disable_irq_wake is invalid for polling mode.



Excuse my ignorance, but could you elaborate this because I am not sure I 
understand.
Aren't the two things orthogonal (polling and waking up the system)?


Waking up the system depends on irq. Since we use polling, we don't set
up irq.



[...]
 #define I2C_HID_PWR_ON 0x00
 #define I2C_HID_PWR_SLEEP  0x01

+/* polling mode */
+#define I2C_POLLING_DISABLED 0
+#define I2C_POLLING_GPIO_PIN 1


This is a very small detail, but I personally think that these defines should be
called I2C_HID_ since they are only used here.


Thank you! This is absolutely a good suggestion.



+#define POLLING_INTERVAL 10
+
+static u8 polling_mode;
+module_param(polling_mode, byte, 0444);
+MODULE_PARM_DESC(polling_mode, "How to poll - 0 disabled; 1 based on GPIO pin's 
status");
+
+static unsigned int polling_interval_active_us = 4000;
+module_param(polling_interval_active_us, uint, 0644);
+MODULE_PARM_DESC(polling_interval_active_us,
+"Poll every {polling_interval_active_us} us when the touchpad is 
active. Default to 4000 us");
+
+static unsigned int polling_interval_idle_ms = 10;


There is a define for this value, I don't really see why you don't use it here.
And if there is a define for one value, I don't really see why there isn't one
for the other. (As far as I see `POLLING_INTERVAL` is not even used anywhere.)


Thank you for spotting this leftover issue after introducing two
parameters to control the polling interval.

Another issue is "MODULE_PARM_DESC(polling_interval_ms" should be
"MODULE_PARM_DESC(polling_interval_idle_ms" although this won't cause
real problem.



+module_param(polling_interval_idle_ms, uint, 0644);
+MODULE_PARM_DESC(polling_interval_ms,
+"Poll every {polling_interval_idle_ms} ms when the touchpad is 
idle. Default to 10 ms");
 /* debug option */
 static bool debug;
 module_param(debug, bool, 0444);
@@ -158,6 +178,8 @@ struct i2c_hid {

struct i2c_hid_platform_data pdata;

+   struct task_struct *polling_thread;
+
boolirq_wake_enabled;
struct mutexreset_lock;
 };
@@ -772,7 +794,9 @@ static int i2c_hid_start(struct hid_device *hid)
i2c_hid_free_buffers(ihid);

ret = i2c_hid_alloc_buffers(ihid, bufsize);
-   enable_irq(client->irq);
+
+   if (polling_mode == I2C_POLLING_DISABLED)
+   enable_irq(client->irq);

if (ret)
return ret;
@@ -814,6 +838,86 @@ struct hid_ll_driver i2c_hid_ll_driver = {
 };
 EXPORT_SYMBOL_GPL(i2c_hid_ll_driver);

+static int get_gpio_pin_state(struct irq_desc *irq_desc)
+{
+   struct gpio_chip *gc = irq_data_get_irq_chip_data(&irq_desc->irq_data);
+
+   return gc->get(gc, irq_desc->irq_data.hwirq);
+}
+
+static bool interrupt_line_active(struct i2c_client *client)
+{
+   unsigned long trigger_type = irq_get_trigger_type(client->irq);
+   struct irq_desc *irq_desc = irq_to_desc(client->irq);
+
+   /*
+* According to Windows Precsiontion Touchpad's specs
+* 
https://docs.microsoft.com/en-us/windows-hardware/design/component-guidelines/windows-precision-touchpad-device-bus-connectivity,
+* GPIO Interrupt Assertion Leve could be either ActiveLow or
+* ActiveHigh.
+*/
+   if (trigger_type & IRQF_TRIGGER_LOW)
+   return !get_gpio_pin_state(irq_desc);
+
+   return get_gpio_pin_state(irq_desc);
+}


Excuse my ignorance, but I think some kind of error handling regarding the 
return
value of `get_gpio_pin_state()` should be present here.


What kind of errors would you expect? It seems (struct gpio_chip *)->get
only return 0 or 1.



+
+static int i2c_hid_polling_thread(void *i2c_hid)
+{
+   struct i2c_hid *ihid = i2c_hid;
+   struct i2c_client *client = ihid->client;
+   unsigned int polling_interval_id

Re: fw_devlink on will break all snps,dw-apb-gpio users

[Saravana Kannan]

On Thu, Oct 15, 2020 at 8:39 PM Jisheng Zhang
 wrote:
>
> On Thu, 15 Oct 2020 15:08:33 +0100
> Robin Murphy  wrote:
>
> >
> >
> > On 2020-10-15 10:52, Jisheng Zhang wrote:
> > > On Thu, 15 Oct 2020 01:48:13 -0700
> > > Saravana Kannan  wrote:
> > >
> > >> On Thu, Oct 15, 2020 at 1:15 AM Jisheng Zhang
> > >>  wrote:
> > >>>
> > >>> On Wed, 14 Oct 2020 22:04:24 -0700 Saravana Kannan wrote:
> > >>>
> > 
> > 
> >  On Wed, Oct 14, 2020 at 9:02 PM Jisheng Zhang
> >   wrote:
> > >
> > > On Wed, 14 Oct 2020 10:29:36 -0700
> > > Saravana Kannan  wrote:
> > >
> > >>
> > >>
> > >> On Wed, Oct 14, 2020 at 4:12 AM Jisheng Zhang
> > >>  wrote:
> > >>>
> > >>> Hi,
> > >>>
> > >>> If set fw_devlink as on, any consumers of dw apb gpio won't probe.
> > >>>
> > >>> The related dts looks like:
> > >>>
> > >>> gpio0: gpio@2400 {
> > >>> compatible = "snps,dw-apb-gpio";
> > >>> #address-cells = <1>;
> > >>> #size-cells = <0>;
> > >>>
> > >>> porta: gpio-port@0 {
> > >>>compatible = "snps,dw-apb-gpio-port";
> > >>>gpio-controller;
> > >>>#gpio-cells = <2>;
> > >>>ngpios = <32>;
> > >>>reg = <0>;
> > >>> };
> > >>> };
> > >>>
> > >>> device_foo {
> > >>>  status = "okay"
> > >>>  ...;
> > >>>  reset-gpio = <&porta, 0, GPIO_ACTIVE_HIGH>;
> > >>> };
> > >>>
> > >>> If I change the reset-gpio property to use another kind of gpio 
> > >>> phandle,
> > >>> e.g gpio expander, then device_foo can be probed successfully.
> > >>>
> > >>> The gpio expander dt node looks like:
> > >>>
> > >>>  expander3: gpio@44 {
> > >>>  compatible = "fcs,fxl6408";
> > >>>  pinctrl-names = "default";
> > >>>  pinctrl-0 = <&expander3_pmux>;
> > >>>  reg = <0x44>;
> > >>>  gpio-controller;
> > >>>  #gpio-cells = <2>;
> > >>>  interrupt-parent = <&portb>;
> > >>>  interrupts = <23 IRQ_TYPE_NONE>;
> > >>>  interrupt-controller;
> > >>>  #interrupt-cells = <2>;
> > >>>  };
> > >>>
> > >>> The common pattern looks like the devlink can't cope with suppliers 
> > >>> from
> > >>> child dt node.
> > >>
> > >> fw_devlink doesn't have any problem dealing with child devices being
> > >> suppliers. The problem with your case is that the
> > >> drivers/gpio/gpio-dwapb.c driver directly parses the child nodes and
> > >> never creates struct devices for them. If you have a node with
> > >> compatible string, fw_devlink expects you to create and probe a 
> > >> struct
> > >> device for it. So change your driver to add the child devices as
> > >> devices instead of just parsing the node directly and doing stuff 
> > >> with
> > >> it.
> > >>
> > >> Either that, or stop putting "compatible" string in a node if you
> > >> don't plan to actually treat it as a device -- but that's too late 
> > >> for
> > >> this driver (it needs to be backward compatible). So change the 
> > >> driver
> > >> to add of_platform_populate() and write a driver that probes
> > >> "snps,dw-apb-gpio-port".
> > >>
> > >
> > > Thanks for the information. The "snps,dw-apb-gpio-port" is never used,
> > > so I just sent out a series to remove it.
> > 
> >  I'd actually prefer that you fix the kernel code to actually use it.
> >  So that fw_devlink can be backward compatible (Older DT + new kernel).
> >  The change is pretty trivial (I just have time to do it for you).
> > 
> > >>>
> > >>> I agree the change is trivial, but it will add some useless LoCs like 
> > >>> below.
> > >>
> > >> It's not useless if it preserves backward compatibility with DT.
> > >>
> > >>> I'm not sure whether this is acceptable.So add GPIO and DT maintainers 
> > >>> to comment.
> > >>>
> > >>> Hi Linus, Rob,
> > >>>
> > >>> Could you please comment? A simple introduction of the problem:
> > >>>
> > >>> As pointed out by Saravana, "gpio-dwapb.c driver directly parses the 
> > >>> child
> > >>> nodes and never creates struct devices for them. If you have a node with
> > >>> compatible string, fw_devlink expects you to create and probe a struct
> > >>> device for it", so once we set fw_devlink=on, then any users of 
> > >>> gpio-dwapb
> > >>> as below won't be probed.
> > >>>
> > >>> device_foo {
> > >>>   status = "okay"
> > >>>   ...;
> > >>>   reset-gpio = <&porta, 0, GPIO_ACTIVE_HIGH>;
> > >>> };
> > >>>
> > >>> The compatible string "snps,dw-apb-gpio-port" is never used, but it's in
> > >>> the dt-binding since the dw gpio mainlined. I be

Re: [EXT] Re: [PATCH v4 10/13] task_isolation: don't interrupt CPUs with tick_nohz_full_kick_cpu()

[Alex Belits]

On Tue, 2020-10-06 at 23:41 +0200, Frederic Weisbecker wrote:
> On Sun, Oct 04, 2020 at 03:22:09PM +, Alex Belits wrote:
> > On Thu, 2020-10-01 at 16:44 +0200, Frederic Weisbecker wrote:
> > > > @@ -268,7 +269,8 @@ static void tick_nohz_full_kick(void)
> > > >   */
> > > >  void tick_nohz_full_kick_cpu(int cpu)
> > > >  {
> > > > -   if (!tick_nohz_full_cpu(cpu))
> > > > +   smp_rmb();
> > > 
> > > What is it ordering?
> > 
> > ll_isol_flags will be read in task_isolation_on_cpu(), that accrss
> > should be ordered against writing in
> > task_isolation_kernel_enter(), fast_task_isolation_cpu_cleanup()
> > and task_isolation_start().
> > 
> > Since task_isolation_on_cpu() is often called for multiple CPUs in
> > a
> > sequence, it would be wasteful to include a barrier inside it.
> 
> Then I think you meant a full barrier: smp_mb()

For read-only operation? task_isolation_on_cpu() is the only place
where per-cpu ll_isol_flags is accessed, read-only, from multiple CPUs.
All other access to ll_isol_flags is done from the local CPU, and
writes are followed by smp_mb(). There are no other dependencies here,
except operations that depend on the value returned from
task_isolation_on_cpu().

If/when more flags will be added, those rules will be still followed,
because the intention is to store the state of isolation and phases of
entering/breaking/reporting it that can only be updated from the local
CPUs.

> 
> > > > +   if (!tick_nohz_full_cpu(cpu) ||
> > > > task_isolation_on_cpu(cpu))
> > > > return;
> > > 
> > > You can't simply ignore an IPI. There is always a reason for a
> > > nohz_full CPU
> > > to be kicked. Something triggered a tick dependency. It can be
> > > posix
> > > cpu timers
> > > for example, or anything.

This was added some time ago, when timers appeared and CPUs were kicked
seemingly out of nowhere. At that point breaking posix timers when
running tasks that are not supposed to rely on posix timers, was the
least problematic solution. From user's point of view in this case
entering isolation had an effect on timer similar to task exiting while
the timer is running.

Right now, there are still sources of superfluous calls to this, when
tick_nohz_full_kick_all() is used. If I will be able to confirm that
this is the only problematic place, I would rather fix calls to it, and
make this condition produce a warning.

This gives me an idea that if there will be a mechanism specifically
for reporting kernel entry and isolation breaking, maybe it should be
possible to add a distinction between:

1. isolation breaking that already happened upon kernel entry;
2. performing operation that will immediately and synchronously cause
isolation breaking;
3. operations or conditions that will eventually or asynchronously
cause isolation breaking (having timers running, possibly sending
signals should be in the same category).

This will be (2).

I assume that when reporting of isolation breaking will be separated
from the isolation implementation, it will be implemented as a runtime
error condition reporting mechanism. Then it can be focused on
providing information about category of events and their sources, and
have internal logic designed for that purpose, as opposed to designed
entirely for debugging, providing flexibility and obtaining maximum
details about internals involved.

> > 
> > I realize that this is unusual, however the idea is that while the
> > task
> > is running in isolated mode in userspace, we assume that from this
> > CPUs
> > point of view whatever is happening in kernel, can wait until CPU
> > is
> > back in kernel and when it first enters kernel from this mode, it
> > should "catch up" with everything that happened in its absence.
> > task_isolation_kernel_enter() is supposed to do that, so by the
> > time
> > anything should be done involving the rest of the kernel, CPU is
> > back
> > to normal.
> 
> You can't assume that. If something needs the tick, this can't wait.
> If the user did something wrong, such as setting a posix cpu timer
> to an isolated task, that's his fault and the kernel has to stick
> with
> correctness and kick that task out of isolation mode.

That would be true if not multiple "let's just tell all other CPUs that
they should check if they have to update something" situations like the
above.

In case of timers it's possible that I will be able to eliminate all
specific instances when this is done, however I think that as a general
approach we have to establish some distinction between things that must
cause IPI (and break isolation) and things that may be delayed until
the isolated userspace task will allow that or some other unavoidable
isolation-breaking event will happen.

> 
> > It is application's responsibility to avoid triggering things that
> > break its isolation
> 
> Precisely.

Right. However there are tings like tick_nohz_full_kick_all() and
similar procedures that result in mass-sending of IPIs without
determining i

[rcu:master] BUILD SUCCESS 78b9b11ec17709681e5fc7b50287354f9b0f7728

[kernel test robot]

nfig
sparcallyesconfig
sparc   defconfig
i386defconfig
mips allyesconfig
mips allmodconfig
powerpc  allyesconfig
powerpc  allmodconfig
powerpc   allnoconfig
i386 randconfig-a005-20201016
i386 randconfig-a006-20201016
i386 randconfig-a001-20201016
i386 randconfig-a003-20201016
i386 randconfig-a004-20201016
i386 randconfig-a002-20201016
x86_64   randconfig-a016-20201016
x86_64   randconfig-a012-20201016
x86_64   randconfig-a015-20201016
x86_64   randconfig-a013-20201016
x86_64   randconfig-a014-20201016
x86_64   randconfig-a011-20201016
i386 randconfig-a016-20201016
i386 randconfig-a013-20201016
i386 randconfig-a015-20201016
i386 randconfig-a011-20201016
i386 randconfig-a012-20201016
i386 randconfig-a014-20201016
riscvnommu_k210_defconfig
riscvallyesconfig
riscv allnoconfig
riscv   defconfig
riscv  rv32_defconfig
riscvallmodconfig
x86_64   rhel
x86_64   allyesconfig
x86_64rhel-7.6-kselftests
x86_64  defconfig
x86_64   rhel-8.3
x86_64  kexec

clang tested configs:
x86_64   randconfig-a004-20201016
x86_64   randconfig-a002-20201016
x86_64   randconfig-a006-20201016
x86_64   randconfig-a001-20201016
x86_64   randconfig-a005-20201016
x86_64   randconfig-a003-20201016
x86_64   randconfig-a016-20201017
x86_64   randconfig-a012-20201017
x86_64   randconfig-a015-20201017
x86_64   randconfig-a013-20201017
x86_64   randconfig-a014-20201017
x86_64   randconfig-a011-20201017

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

Re: [PATCH v9 12/15] PCI/RCEC: Add RCiEP's linked RCEC to AER/ERR

[Kuppuswamy, Sathyanarayanan]

On 10/16/20 3:29 PM, Bjorn Helgaas wrote:

[+cc Christoph, Ethan, Sinan, Keith; sorry should have cc'd you to
begin with since you're looking at this code too.  Particularly
interested in your thoughts about whether we should be touching
PCI_ERR_ROOT_COMMAND and PCI_ERR_ROOT_STATUS when we don't own AER.]

This part is not very clear in ACPI spec or PCI firmware spec.

IMO, since AEPI notifies the OS about the error, then I guess
we are allowed to clear the PCI_ERR_ROOT_STATUS register
after handling the error.



On Fri, Oct 16, 2020 at 03:30:37PM -0500, Bjorn Helgaas wrote:

[+to Jonathan]

On Thu, Oct 15, 2020 at 05:11:10PM -0700, Sean V Kelley wrote:

From: Qiuxu Zhuo 

When attempting error recovery for an RCiEP associated with an RCEC device,
there needs to be a way to update the Root Error Status, the Uncorrectable
Error Status and the Uncorrectable Error Severity of the parent RCEC.  In
some non-native cases in which there is no OS-visible device associated
with the RCiEP, there is nothing to act upon as the firmware is acting
before the OS.

Add handling for the linked RCEC in AER/ERR while taking into account
non-native cases.

Co-developed-by: Sean V Kelley 
Link: 
https://lore.kernel.org/r/20201002184735.1229220-12-seanvk@oregontracks.org
Signed-off-by: Sean V Kelley 
Signed-off-by: Qiuxu Zhuo 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Jonathan Cameron 
---
  drivers/pci/pcie/aer.c | 53 ++
  drivers/pci/pcie/err.c | 20 
  2 files changed, 48 insertions(+), 25 deletions(-)

diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
index 65dff5f3457a..083f69b67bfd 100644
--- a/drivers/pci/pcie/aer.c
+++ b/drivers/pci/pcie/aer.c
@@ -1357,27 +1357,50 @@ static int aer_probe(struct pcie_device *dev)
   */
  static pci_ers_result_t aer_root_reset(struct pci_dev *dev)
  {
-   int aer = dev->aer_cap;
+   int type = pci_pcie_type(dev);
+   struct pci_dev *root;
+   int aer = 0;
+   int rc = 0;
u32 reg32;
-   int rc;
  
+	if (pci_pcie_type(dev) == PCI_EXP_TYPE_RC_END)

"type == PCI_EXP_TYPE_RC_END"


+   /*
+* The reset should only clear the Root Error Status
+* of the RCEC. Only perform this for the
+* native case, i.e., an RCEC is present.
+*/
+   root = dev->rcec;
+   else
+   root = dev;
  
-	/* Disable Root's interrupt in response to error messages */

-   pci_read_config_dword(dev, aer + PCI_ERR_ROOT_COMMAND, ®32);
-   reg32 &= ~ROOT_PORT_INTR_ON_MESG_MASK;
-   pci_write_config_dword(dev, aer + PCI_ERR_ROOT_COMMAND, reg32);
+   if (root)
+   aer = dev->aer_cap;
  
-	rc = pci_bus_error_reset(dev);

-   pci_info(dev, "Root Port link has been reset\n");
+   if (aer) {
+   /* Disable Root's interrupt in response to error messages */
+   pci_read_config_dword(root, aer + PCI_ERR_ROOT_COMMAND, ®32);
+   reg32 &= ~ROOT_PORT_INTR_ON_MESG_MASK;
+   pci_write_config_dword(root, aer + PCI_ERR_ROOT_COMMAND, reg32);

Not directly related to *this* patch, but my assumption was that in
the APEI case, the firmware should retain ownership of the AER
Capability, so the OS should not touch PCI_ERR_ROOT_COMMAND and
PCI_ERR_ROOT_STATUS.

But this code appears to ignore that ownership.  Jonathan, you must
have looked at this recently for 068c29a248b6 ("PCI/ERR: Clear PCIe
Device Status errors only if OS owns AER").  Do you have any insight
about this?


-   /* Clear Root Error Status */
-   pci_read_config_dword(dev, aer + PCI_ERR_ROOT_STATUS, ®32);
-   pci_write_config_dword(dev, aer + PCI_ERR_ROOT_STATUS, reg32);
+   /* Clear Root Error Status */
+   pci_read_config_dword(root, aer + PCI_ERR_ROOT_STATUS, ®32);
+   pci_write_config_dword(root, aer + PCI_ERR_ROOT_STATUS, reg32);
  
-	/* Enable Root Port's interrupt in response to error messages */

-   pci_read_config_dword(dev, aer + PCI_ERR_ROOT_COMMAND, ®32);
-   reg32 |= ROOT_PORT_INTR_ON_MESG_MASK;
-   pci_write_config_dword(dev, aer + PCI_ERR_ROOT_COMMAND, reg32);
+   /* Enable Root Port's interrupt in response to error messages */
+   pci_read_config_dword(root, aer + PCI_ERR_ROOT_COMMAND, ®32);
+   reg32 |= ROOT_PORT_INTR_ON_MESG_MASK;
+   pci_write_config_dword(root, aer + PCI_ERR_ROOT_COMMAND, reg32);
+   }
+
+   if ((type == PCI_EXP_TYPE_RC_EC) || (type == PCI_EXP_TYPE_RC_END)) {
+   if (pcie_has_flr(root)) {
+   rc = pcie_flr(root);
+   pci_info(dev, "has been reset (%d)\n", rc);
+   }
+   } else {
+   rc = pci_bus_error_reset(root);

Don't we want "dev" for both the FLR and pci_bus_error_reset()?  I
think "root == dev" except when dev is an RCiEP.  When dev is an
RCiEP, "root" is the

[PATCH v3] checkpatch: add new exception to repeated word check

[Dwaipayan Ray]

Recently, commit 4f6ad8aa1eac ("checkpatch: move repeated word test")
moved the repeated word test to check for more file types. But after
this, if checkpatch.pl is run on MAINTAINERS, it generates several
new warnings of the type:

WARNING: Possible repeated word: 'git'

For example:
WARNING: Possible repeated word: 'git'
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml.git

So, the pattern "git git://..." is a false positive in this case.

There are several other combinations which may produce a wrong
warning message, such as "@size size", ":Begin begin", etc.

Extend repeated word check to compare the characters before and
after the word matches. If the preceding or succeeding character
belongs to the exception list, the warning is avoided.

Link: 
https://lore.kernel.org/linux-kernel-mentees/81b6a0bb2c7b9256361573f7a13201ebcd4876f1.ca...@perches.com/
Suggested-by: Joe Perches 
Suggested-by: Lukas Bulwahn 
Signed-off-by: Dwaipayan Ray 
---
 scripts/checkpatch.pl | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index f1a4e61917eb..89430dfd6652 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -595,6 +595,7 @@ our @mode_permission_funcs = (
 );
 
 my $word_pattern = '\b[A-Z]?[a-z]{2,}\b';
+my $exclude_chars = '[^\.\,\+\s]';
 
 #Create a search pattern for all these functions to speed up a loop below
 our $mode_perms_search = "";
@@ -3056,15 +3057,27 @@ sub process {
 
my $first = $1;
my $second = $2;
-
+   my $start_pos = $-[1];
+   my $end_pos = $+[2];
if ($first =~ /(?:struct|union|enum)/) {
pos($rawline) += length($first) + 
length($second) + 1;
next;
}
 
-   next if ($first ne $second);
+   next if (lc($first) ne lc($second));
next if ($first eq 'long');
 
+   # check for character before and after the word 
matches
+   my $start_char = '';
+   my $end_char = '';
+   $start_char = substr($rawline, $start_pos - 1, 
1) if ($start_pos > 0);
+   $end_char = substr($rawline, $end_pos, 1) if 
($end_pos <= length($rawline));
+
+   if ($start_char =~ /^$exclude_chars$/ ||
+   $end_char =~ /^$exclude_chars$/) {
+   next;
+   }
+
if (WARN("REPEATED_WORD",
 "Possible repeated word: '$first'\n" . 
$herecurr) &&
$fix) {
-- 
2.27.0

[PATCH v5 0/4] Qualcomm Light Pulse Generator

[Bjorn Andersson]

This series introduces a generic pattern interface in the LED class and
a driver for the Qualcomm Light Pulse Generator.

It seems like it's been almost 3 years since I posted v3, which was hung
up on the lack of conclusion on the hw_pattern and multicolor support.
Now that those are concluded I hope we can make some progress on the LPG
support again.

The dts patches are included in the series as "examples", ultimately my
expectation is that the dt binding and driver patches are picked up
through the leds tree, while Andy or myself take the dts patches.

Bjorn Andersson (4):
  dt-bindings: leds: Add Qualcomm Light Pulse Generator binding
  leds: Add driver for Qualcomm LPG
  arm64: dts: qcom: pm(i)8994: Add mpp and lpg blocks
  arm64: dts: qcom: Add user LEDs on db820c

 .../bindings/leds/leds-qcom-lpg.yaml  |  170 +++
 arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi  |   49 +
 arch/arm64/boot/dts/qcom/pm8994.dtsi  |9 +
 arch/arm64/boot/dts/qcom/pmi8994.dtsi |   20 +
 drivers/leds/Kconfig  |9 +
 drivers/leds/Makefile |1 +
 drivers/leds/leds-qcom-lpg.c  | 1206 +
 7 files changed, 1464 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/leds/leds-qcom-lpg.yaml
 create mode 100644 drivers/leds/leds-qcom-lpg.c

-- 
2.28.0

[PATCH net-next] drivers/net/wan/hdlc_fr: Improve fr_rx and add support for any Ethertype

[Xie He]

1. Change the fr_rx function to make this driver support any Ethertype
when receiving. (This driver is already able to handle any Ethertype
when sending.)

Originally in the fr_rx function, the code that parses the long (10-byte)
header only recognizes a few Ethertype values and drops frames with other
Ethertype values. This patch replaces this code to make fr_rx support
any Ethertype. This patch also creates a new function fr_snap_parse as
part of the new code.

2. Change the use of the "dev" variable in fr_rx. Originally we do
"dev = something", and then at the end do "if (dev) skb->dev = dev".
Now we do "if (something) skb->dev = something", then at the end do
"dev = skb->dev".

This is to make the logic of our code consistent with eth_type_trans
(which we call). The eth_type_trans function expects a non-NULL pointer
as a parameter and assigns it directly to skb->dev.

3. Change the initial skb->len check in fr_fx from "<= 4" to "< 4".
At first we only need to ensure a 4-byte header is present. We indeed
normally need the 5th byte, too, but it'd be more logical to check its
existence when we actually need it.

Also add an fh->ea2 check to the initial checks in fr_fx. fh->ea2 == 1
means the second address byte is the final address byte. We only support
the case where the address length is 2 bytes.

4. Use "goto rx_drop" whenever we need to drop a valid frame.

Cc: Krzysztof Halasa 
Signed-off-by: Xie He 
---
 drivers/net/wan/hdlc_fr.c | 119 +++---
 1 file changed, 73 insertions(+), 46 deletions(-)

diff --git a/drivers/net/wan/hdlc_fr.c b/drivers/net/wan/hdlc_fr.c
index 409e5a7ad8e2..e95efc14bc97 100644
--- a/drivers/net/wan/hdlc_fr.c
+++ b/drivers/net/wan/hdlc_fr.c
@@ -871,6 +871,45 @@ static int fr_lmi_recv(struct net_device *dev, struct 
sk_buff *skb)
return 0;
 }
 
+static int fr_snap_parse(struct sk_buff *skb, struct pvc_device *pvc)
+{
+   /* OUI 00-00-00 indicates an Ethertype follows */
+   if (skb->data[0] == 0x00 &&
+   skb->data[1] == 0x00 &&
+   skb->data[2] == 0x00) {
+   if (!pvc->main)
+   return -1;
+   skb->dev = pvc->main;
+   skb->protocol = *(__be16 *)(skb->data + 3); /* Ethertype */
+   skb_pull(skb, 5);
+   skb_reset_mac_header(skb);
+   return 0;
+
+   /* OUI 00-80-C2 stands for the 802.1 organization */
+   } else if (skb->data[0] == 0x00 &&
+  skb->data[1] == 0x80 &&
+  skb->data[2] == 0xC2) {
+   /* PID 00-07 stands for Ethernet frames without FCS */
+   if (skb->data[3] == 0x00 &&
+   skb->data[4] == 0x07) {
+   if (!pvc->ether)
+   return -1;
+   skb_pull(skb, 5);
+   if (skb->len < ETH_HLEN)
+   return -1;
+   skb->protocol = eth_type_trans(skb, pvc->ether);
+   return 0;
+
+   /* PID unsupported */
+   } else {
+   return -1;
+   }
+
+   /* OUI unsupported */
+   } else {
+   return -1;
+   }
+}
 
 static int fr_rx(struct sk_buff *skb)
 {
@@ -880,9 +919,9 @@ static int fr_rx(struct sk_buff *skb)
u8 *data = skb->data;
u16 dlci;
struct pvc_device *pvc;
-   struct net_device *dev = NULL;
+   struct net_device *dev;
 
-   if (skb->len <= 4 || fh->ea1 || data[2] != FR_UI)
+   if (skb->len < 4 || fh->ea1 || !fh->ea2 || data[2] != FR_UI)
goto rx_error;
 
dlci = q922_to_dlci(skb->data);
@@ -904,8 +943,7 @@ static int fr_rx(struct sk_buff *skb)
netdev_info(frad, "No PVC for received frame's DLCI %d\n",
dlci);
 #endif
-   dev_kfree_skb_any(skb);
-   return NET_RX_DROP;
+   goto rx_drop;
}
 
if (pvc->state.fecn != fh->fecn) {
@@ -931,63 +969,52 @@ static int fr_rx(struct sk_buff *skb)
}
 
if (data[3] == NLPID_IP) {
+   if (!pvc->main)
+   goto rx_drop;
skb_pull(skb, 4); /* Remove 4-byte header (hdr, UI, NLPID) */
-   dev = pvc->main;
+   skb->dev = pvc->main;
skb->protocol = htons(ETH_P_IP);
+   skb_reset_mac_header(skb);
 
} else if (data[3] == NLPID_IPV6) {
+   if (!pvc->main)
+   goto rx_drop;
skb_pull(skb, 4); /* Remove 4-byte header (hdr, UI, NLPID) */
-   dev = pvc->main;
+   skb->dev = pvc->main;
skb->protocol = htons(ETH_P_IPV6);
+   skb_reset_mac_header(skb);
 
-   } else if (skb->len > 10 && data[3] == FR_PAD &&
-  data[4] == NLPID_SNAP && data[5] == FR_PAD) {
-   u16 oui = ntohs(*(__be16*)(data + 6));
- 

[PATCH v5 3/4] arm64: dts: qcom: pm(i)8994: Add mpp and lpg blocks

[Bjorn Andersson]

The pm8994 contains a 6 LPG channels and the pmi8994 contains 4 MPP
channels and a 4 channel LPG, with TRILED and LUT blocks.

Add nodes for these blocks.

Signed-off-by: Bjorn Andersson 
---

Changes since v4:
- Replaced msm8996 with pm(i)8994 in subject

 arch/arm64/boot/dts/qcom/pm8994.dtsi  |  9 +
 arch/arm64/boot/dts/qcom/pmi8994.dtsi | 20 
 2 files changed, 29 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/pm8994.dtsi 
b/arch/arm64/boot/dts/qcom/pm8994.dtsi
index 7e4f46cb..b5bef687aa3c 100644
--- a/arch/arm64/boot/dts/qcom/pm8994.dtsi
+++ b/arch/arm64/boot/dts/qcom/pm8994.dtsi
@@ -86,6 +86,15 @@ pmic@1 {
#address-cells = <1>;
#size-cells = <0>;
 
+   pm8994_lpg: lpg {
+   compatible = "qcom,pm8994-lpg";
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   status = "disabled";
+   };
+
pm8994_spmi_regulators: regulators {
compatible = "qcom,pm8994-regulators";
};
diff --git a/arch/arm64/boot/dts/qcom/pmi8994.dtsi 
b/arch/arm64/boot/dts/qcom/pmi8994.dtsi
index e5ed28ab9b2d..23f41328d191 100644
--- a/arch/arm64/boot/dts/qcom/pmi8994.dtsi
+++ b/arch/arm64/boot/dts/qcom/pmi8994.dtsi
@@ -19,6 +19,17 @@ pmi8994_gpios: gpios@c000 {
interrupt-controller;
#interrupt-cells = <2>;
};
+
+   pmi8994_mpps: mpps@a000 {
+   compatible = "qcom,pm8994-mpp";
+   reg = <0xa000>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   interrupts = <0 0xa0 0 IRQ_TYPE_NONE>,
+<0 0xa1 0 IRQ_TYPE_NONE>,
+<0 0xa2 0 IRQ_TYPE_NONE>,
+<0 0xa3 0 IRQ_TYPE_NONE>;
+   };
};
 
pmic@3 {
@@ -27,6 +38,15 @@ pmic@3 {
#address-cells = <1>;
#size-cells = <0>;
 
+   pmi8994_lpg: lpg@b100 {
+   compatible = "qcom,pmi8994-lpg";
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   status = "disabled";
+   };
+
pmi8994_spmi_regulators: regulators {
compatible = "qcom,pmi8994-regulators";
#address-cells = <1>;
-- 
2.28.0

[PATCH v5 4/4] arm64: dts: qcom: Add user LEDs on db820c

[Bjorn Andersson]

The db820c has 4 "user LEDs", all connected to the PMI8994. The first
three are connected to the three current sinks provided by the TRILED
and the fourth is connected to MPP2.

By utilizing the DTEST bus the MPP is fed the control signal from the
fourth LPG block, providing a consistent interface to the user.

Signed-off-by: Bjorn Andersson 
---

Changes since v4:
- None

 arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi | 49 
 1 file changed, 49 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi 
b/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
index defcbd15edf9..7e51677d256e 100644
--- a/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
+++ b/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
@@ -8,6 +8,7 @@
 #include "pmi8994.dtsi"
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -682,6 +683,54 @@ pinconf {
};
 };
 
+&pmi8994_mpps {
+   pmi8994_mpp2_userled4: mpp2-userled4 {
+   pins = "mpp2";
+   function = "sink";
+
+   output-low;
+   qcom,dtest = <4>;
+   };
+};
+
+&pmi8994_lpg {
+   qcom,power-source = <1>;
+
+   pinctrl-names = "default";
+   pinctrl-0 = <&pmi8994_mpp2_userled4>;
+
+   status = "okay";
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   led@1 {
+   reg = <1>;
+   label = "green:user1";
+
+   linux,default-trigger = "heartbeat";
+   default-state = "on";
+   };
+
+   led@2 {
+   reg = <2>;
+   label = "green:user0";
+   default-state = "on";
+   };
+
+   led@3 {
+   reg = <3>;
+   label = "green:user2";
+   };
+
+   led@4 {
+   reg = <4>;
+   label = "green:user3";
+
+   qcom,dtest = <4 1>;
+   };
+};
+
 &pmi8994_spmi_regulators {
vdd_gfx: s2@1700 {
reg = <0x1700 0x100>;
-- 
2.28.0

Re: [PATCH v2] checkpatch: add new exception to repeated word check

[Dwaipayan Ray]

On Sat, Oct 17, 2020 at 10:12 AM Joe Perches  wrote:
>
> On Sat, 2020-10-17 at 10:02 +0530, Dwaipayan Ray wrote:
> > On Sat, Oct 17, 2020 at 8:26 AM Joe Perches  wrote:
> > > On Wed, 2020-10-14 at 11:35 -0700, Joe Perches wrote:
> > > > On Wed, 2020-10-14 at 23:42 +0530, Dwaipayan Ray wrote:
> > > > > On Wed, Oct 14, 2020 at 11:33 PM Joe Perches  wrote:
> > > > > > On Wed, 2020-10-14 at 22:07 +0530, Dwaipayan Ray wrote:
> > > > > > > Recently, commit 4f6ad8aa1eac ("checkpatch: move repeated word 
> > > > > > > test")
> > > > > > > moved the repeated word test to check for more file types. But 
> > > > > > > after
> > > > > > > this, if checkpatch.pl is run on MAINTAINERS, it generates several
> > > > > > > new warnings of the type:
> > > > > >
> > > > > > Perhaps instead of adding more content checks so that
> > > > > > word boundaries are not something like \S but also
> > > > > > not punctuation so that content like
> > > > > >
> > > > > > git git://
> > > > > > @size size
> > > > > >
> > > > > > does not match?
> > > > > >
> > > > > >
> > > > > Hi,
> > > > > So currently the words are trimmed of non alphabets before the check:
> > > > >
> > > > > while ($rawline =~ /\b($word_pattern) (?=($word_pattern))/g) {
> > > > > my $first = $1;
> > > > > my $second = $2;
> > > > >
> > > > > where, the word_pattern is:
> > > > > my $word_pattern = '\b[A-Z]?[a-z]{2,}\b';
> > > >
> > > > I'm familiar.
> > > >
> > > > > So do you perhaps recommend modifying this word pattern to
> > > > > include the punctuation as well rather than trimming them off?
> > > >
> > > > Not really, perhaps use the capture group position
> > > > markers @- @+ or $-[1] $+[1] and $-[2] $+[2] with the
> > > > substr could be used to see what characters are
> > > > before and after the word matches.
> > >
> > > Perhaps something like:
> > > ---
> > >  scripts/checkpatch.pl | 12 +++-
> > >  1 file changed, 11 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> > > index fab38b493cef..a65eb40a5539 100755
> > > --- a/scripts/checkpatch.pl
> > > +++ b/scripts/checkpatch.pl
> > > @@ -3054,15 +3054,25 @@ sub process {
> > >
> > > my $first = $1;
> > > my $second = $2;
> > > +   my $start_pos = $-[1];
> > > +   my $end_pos = $+[2];
> > >
> > > if ($first =~ /(?:struct|union|enum)/) {
> > > pos($rawline) += length($first) + 
> > > length($second) + 1;
> > > next;
> > > }
> > >
> > > -   next if ($first ne $second);
> > > +   next if (lc($first) ne lc($second));
> > > next if ($first eq 'long');
> > >
> > > +   my $start_char = "";
> > > +   my $end_char = "";
> > > +   $start_char = substr($rawline, $start_pos 
> > > - 1, 1) if ($start_pos > 0);
> > > +   $end_char = substr($rawline, $end_pos, 1) 
> > > if (length($rawline) > $end_pos);
> > > +
> > > +   next if ($start_char =~ /^\S$/);
> > > +   next if ($end_char !~ /^[\.\,\s]?$/);
> > > +
> > > if (WARN("REPEATED_WORD",
> > >  "Possible repeated word: 
> > > '$first'\n" . $herecurr) &&
> > > $fix) {
> > >
> > >
> >
> > Hi Joe,
> > Thank you for the insight. I was also doing something similar:
> >
> > ---
> >  scripts/checkpatch.pl | 16 
> >  1 file changed, 16 insertions(+)
> >
> > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> > index f1a4e61917eb..82497a71ac96 100755
> > --- a/scripts/checkpatch.pl
> > +++ b/scripts/checkpatch.pl
> > @@ -595,6 +595,7 @@ our @mode_permission_funcs = (
> >  );
> >
> >  my $word_pattern = '\b[A-Z]?[a-z]{2,}\b';
> > +my $punctuation_chars = '[,:;@\.\-]';
> >
> >  #Create a search pattern for all these functions to speed up a loop below
> >  our $mode_perms_search = "";
> > @@ -3065,6 +3066,21 @@ sub process {
> >   next if ($first ne $second);
> >   next if ($first eq 'long');
> >
> > + # check for character before and after the word matches
> > + my $ca_first = substr($rawline, $-[1]-1, 1);
> > + my $cb_first = substr($rawline, $+[1], 1);
> > + my $ca_second = substr($rawline, $-[2]-1, 1);
> > + my $cb_second = substr($rawline, $+[2], 1);
> > +
> > + if ($ca_first ne $ca_second || $cb_first ne $cb_second) {
> > + if ($ca_first =~ /$punctuation_chars/ ||
> > + $ca_second =~ /$punctuation_chars/ ||
> > + $cb_first =~ /$punctuation_chars/ ||
> > + $cb_second =~ /$punctuation_chars/) {
> > + next;
> > + }
> > + }
> > +
> >   if (WARN("REPEAT

[PATCH v5 1/4] dt-bindings: leds: Add Qualcomm Light Pulse Generator binding

[Bjorn Andersson]

This adds the binding document describing the three hardware blocks
related to the Light Pulse Generator found in a wide range of Qualcomm
PMICs.

Signed-off-by: Bjorn Andersson 
---

Changes since v4:
- Dropped quotes around power-source
- Moved "multi-led" to properties
- Corrected tab-indented line in example

 .../bindings/leds/leds-qcom-lpg.yaml  | 170 ++
 1 file changed, 170 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/leds/leds-qcom-lpg.yaml

diff --git a/Documentation/devicetree/bindings/leds/leds-qcom-lpg.yaml 
b/Documentation/devicetree/bindings/leds/leds-qcom-lpg.yaml
new file mode 100644
index ..5ccf0f3d8f1b
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-qcom-lpg.yaml
@@ -0,0 +1,170 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/leds-qcom-lpg.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Light Pulse Generator
+
+maintainers:
+  - Bjorn Andersson 
+
+description: >
+  The Qualcomm Light Pulse Generator consists of three different hardware 
blocks;
+  a ramp generator with lookup table, the light pulse generator and a three
+  channel current sink. These blocks are found in a wide range of Qualcomm 
PMICs.
+
+properties:
+  compatible:
+enum:
+  - qcom,pm8916-pwm
+  - qcom,pm8941-lpg
+  - qcom,pm8994-lpg
+  - qcom,pmi8994-lpg
+  - qcom,pmi8998-lpg
+
+  "#pwm-cells":
+const: 2
+
+  "#address-cells":
+const: 1
+
+  "#size-cells":
+const: 0
+
+  qcom,power-source:
+$ref: /schemas/types.yaml#definitions/uint32
+description: >
+  power-source used to drive the output, as defined in the datasheet.
+  Should be specified if the TRILED block is present
+enum:
+  - 0
+  - 1
+  - 3
+
+  multi-led:
+type: object
+$ref: leds-class-multicolor.yaml#
+properties:
+  "#address-cells":
+const: 1
+
+  "#size-cells":
+const: 0
+
+  "^led@[0-9a-f]$":
+type: object
+$ref: common.yaml#
+
+properties:
+  "qcom,dtest":
+$ref: /schemas/types.yaml#definitions/uint32-array
+description: >
+  configures the output into an internal test line of the pmic. 
Specified
+  by a list of u32 pairs, one pair per channel, where each pair 
denotes the
+  test line to drive and the second configures how the value 
should be
+  outputed, as defined in the datasheet
+minItems: 2
+maxItems: 2
+
+required:
+  - reg
+
+patternProperties:
+  "^led@[0-9a-f]$":
+type: object
+$ref: common.yaml#
+properties:
+  "qcom,dtest":
+$ref: /schemas/types.yaml#definitions/uint32-array
+description: >
+  configures the output into an internal test line of the pmic. 
Specified
+  by a list of u32 pairs, one pair per channel, where each pair 
denotes the
+  test line to drive and the second configures how the value should be
+  outputed, as defined in the datasheet
+minItems: 2
+maxItems: 2
+
+required:
+  - reg
+
+required:
+  - compatible
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+
+lpg {
+  compatible = "qcom,pmi8994-lpg";
+
+  #address-cells = <1>;
+  #size-cells = <0>;
+
+  qcom,power-source = <1>;
+
+  led@1 {
+reg = <1>;
+label = "green:user1";
+  };
+
+  led@2 {
+reg = <2>;
+label = "green:user0";
+default-state = "on";
+  };
+
+  led@3 {
+reg = <3>;
+label = "green:user2";
+  };
+
+  led@4 {
+reg = <4>;
+label = "green:user3";
+
+qcom,dtest = <4 1>;
+  };
+};
+  - |
+#include 
+
+lpg {
+  compatible = "qcom,pmi8994-lpg";
+
+  #address-cells = <1>;
+  #size-cells = <0>;
+
+  qcom,power-source = <1>;
+
+  multi-led {
+color = ;
+label = "rgb:notification";
+
+#address-cells = <1>;
+#size-cells = <0>;
+
+led@1 {
+  reg = <1>;
+  color = ;
+};
+
+led@2 {
+  reg = <2>;
+  color = ;
+};
+
+led@3 {
+  reg = <3>;
+  color = ;
+};
+  };
+};
+  - |
+lpg {
+  compatible = "qcom,pm8916-pwm";
+  #pwm-cells = <2>;
+};
+...
-- 
2.28.0

[PATCH v5 2/4] leds: Add driver for Qualcomm LPG

[Bjorn Andersson]

The Light Pulse Generator (LPG) is a PWM-block found in a wide range of
PMICs from Qualcomm. It can operate on fixed parameters or based on a
lookup-table, altering the duty cycle over time - which provides the
means for e.g. hardware assisted transitions of LED brightness.

Signed-off-by: Bjorn Andersson 
---

Changes since v4:
- Introduced div_u64() to avoid compilation errors on 32 bit machines
- Fixed SPDX license header and a couple of spacing issues pointed out by 
checkpatch

 drivers/leds/Kconfig |9 +
 drivers/leds/Makefile|1 +
 drivers/leds/leds-qcom-lpg.c | 1206 ++
 3 files changed, 1216 insertions(+)
 create mode 100644 drivers/leds/leds-qcom-lpg.c

diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 849d3c5f908e..d500648c586f 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -803,6 +803,15 @@ config LEDS_POWERNV
  To compile this driver as a module, choose 'm' here: the module
  will be called leds-powernv.
 
+config LEDS_QCOM_LPG
+   tristate "LED support for Qualcomm LPG"
+   depends on LEDS_CLASS_MULTICOLOR
+   depends on OF
+   depends on SPMI
+   help
+ This option enables support for the Light Pulse Generator found in a
+ wide variety of Qualcomm PMICs.
+
 config LEDS_SYSCON
bool "LED support for LEDs on system controllers"
depends on LEDS_CLASS=y
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 73e603e1727e..52d0ea26fc35 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -79,6 +79,7 @@ obj-$(CONFIG_LEDS_PCA963X)+= leds-pca963x.o
 obj-$(CONFIG_LEDS_PM8058)  += leds-pm8058.o
 obj-$(CONFIG_LEDS_POWERNV) += leds-powernv.o
 obj-$(CONFIG_LEDS_PWM) += leds-pwm.o
+obj-$(CONFIG_LEDS_QCOM_LPG)+= leds-qcom-lpg.o
 obj-$(CONFIG_LEDS_REGULATOR)   += leds-regulator.o
 obj-$(CONFIG_LEDS_S3C24XX) += leds-s3c24xx.o
 obj-$(CONFIG_LEDS_SC27XX_BLTC) += leds-sc27xx-bltc.o
diff --git a/drivers/leds/leds-qcom-lpg.c b/drivers/leds/leds-qcom-lpg.c
new file mode 100644
index ..49282cedeb6e
--- /dev/null
+++ b/drivers/leds/leds-qcom-lpg.c
@@ -0,0 +1,1206 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2017-2020 Linaro Ltd
+ * Copyright (c) 2010-2012, The Linux Foundation. All rights reserved.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define LPG_PATTERN_CONFIG_REG 0x40
+#define LPG_SIZE_CLK_REG   0x41
+#define LPG_PREDIV_CLK_REG 0x42
+#define PWM_TYPE_CONFIG_REG0x43
+#define PWM_VALUE_REG  0x44
+#define PWM_ENABLE_CONTROL_REG 0x46
+#define PWM_SYNC_REG   0x47
+#define LPG_RAMP_DURATION_REG  0x50
+#define LPG_HI_PAUSE_REG   0x52
+#define LPG_LO_PAUSE_REG   0x54
+#define LPG_HI_IDX_REG 0x56
+#define LPG_LO_IDX_REG 0x57
+#define PWM_SEC_ACCESS_REG 0xd0
+#define PWM_DTEST_REG(x)   (0xe2 + (x) - 1)
+
+#define TRI_LED_SRC_SEL0x45
+#define TRI_LED_EN_CTL 0x46
+#define TRI_LED_ATC_CTL0x47
+
+#define LPG_LUT_REG(x) (0x40 + (x) * 2)
+#define RAMP_CONTROL_REG   0xc8
+
+struct lpg_channel;
+struct lpg_data;
+
+/**
+ * struct lpg - LPG device context
+ * @dev:   struct device for LPG device
+ * @map:   regmap for register access
+ * @pwm:   PWM-chip object, if operating in PWM mode
+ * @lut_base:  base address of the LUT block (optional)
+ * @lut_size:  number of entries in the LUT block
+ * @lut_bitmap:allocation bitmap for LUT entries
+ * @triled_base: base address of the TRILED block (optional)
+ * @triled_src:power-source for the TRILED
+ * @channels:  list of PWM channels
+ * @num_channels: number of @channels
+ */
+struct lpg {
+   struct device *dev;
+   struct regmap *map;
+
+   struct pwm_chip pwm;
+
+   const struct lpg_data *data;
+
+   u32 lut_base;
+   u32 lut_size;
+   unsigned long *lut_bitmap;
+
+   u32 triled_base;
+   u32 triled_src;
+
+   struct lpg_channel *channels;
+   unsigned int num_channels;
+};
+
+/**
+ * struct lpg_channel - per channel data
+ * @lpg:   reference to parent lpg
+ * @base:  base address of the PWM channel
+ * @triled_mask: mask in TRILED to enable this channel
+ * @lut_mask:  mask in LUT to start pattern generator for this channel
+ * @in_use:channel is exposed to LED framework
+ * @color: color of the LED attached to this channel
+ * @dtest_line:DTEST line for output, or 0 if disabled
+ * @dtest_value: DTEST line configuration
+ * @pwm_value: duty (in microseconds) of the generated pulses, overridden by 
LUT
+ * @enabled:   output enabled?
+ * @period_us: period (in microseconds) of the generated pulses
+ * @pwm_size:  resolution of the @pwm_value, 6 or 9 bits
+ * @clk:   base frequency of the clock generator
+ * @pre_div:   d

Re: [PATCH] drivers/virt: vmgenid: add vm generation id driver

[Colm MacCarthaigh]

On 16 Oct 2020, at 22:01, Jann Horn wrote:


On Sat, Oct 17, 2020 at 6:34 AM Colm MacCarthaigh 
 wrote:
For user-space, even a single bit would do. We added 
MADVISE_WIPEONFORK
so that userspace libraries can detect fork()/clone() robustly, for 
the

same reasons. It just wipes a page as the indicator, which is
effectively a single-bit signal, and it works well. On the user-space
side of this, I’m keen to find a solution like that that we can use
fairly easily inside of portable libraries and applications. The 
“have
I forked” checks do end up in hot paths, so it’s nice if they can 
be

CPU cache friendly. Comparing a whole 128-bit value wouldn’t be my
favorite.


I'm pretty sure a single bit is not enough if you want to have a
single page, shared across the entire system, that stores the VM
forking state; you need a counter for that.


You’re right. WIPEONFORK is more like a single-bit per use. If it’s 
something system wide then a counter is better.



So the RNG state after mixing in the new VM Generation ID would
contain 128 bits of secret entropy not known to anyone else, including
people with access to the VM image.

Now, 128 bits of cryptographically random data aren't _optimal_; I
think something on the order of 256 bits would be nicer from a
theoretical standpoint. But in practice I think we'll be good with the
128 bits we're getting (since the number of users who fork a VM image
is probably not going to be so large that worst-case collision
probabilities matter).


This reminds me on key/IV usage limits for AES encryption, where the 
same birthday bounds apply, and even though 256-bits would be better, we 
routinely make 128-bit birthday bounds work for massively scalable 
systems.



The kernel would need to use the change as a trigger to
measure some entropy (e.g. interrupts and RDRAND, or whatever). Our 
just
define the machine contract as “this has to be unique random data 
and

if it’s not unique, or if it’s pubic, you’re toast”.


As far as I can tell from Microsoft's spec, that is a guarantee we're
already getting.


Neat.

-
Colm

[PATCH] ipmi_si: replace spin_lock_irqsave by spin_lock in hard IRQ

[Tian Tao]

It is redundant to do irqsave and irqrestore in hardIRQ context.

Signed-off-by: Tian Tao 
---
 drivers/char/ipmi/ipmi_si_intf.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/char/ipmi/ipmi_si_intf.c b/drivers/char/ipmi/ipmi_si_intf.c
index 45546ac..97452a8 100644
--- a/drivers/char/ipmi/ipmi_si_intf.c
+++ b/drivers/char/ipmi/ipmi_si_intf.c
@@ -1116,7 +1116,6 @@ static void smi_timeout(struct timer_list *t)
 irqreturn_t ipmi_si_irq_handler(int irq, void *data)
 {
struct smi_info *smi_info = data;
-   unsigned long   flags;
 
if (smi_info->io.si_type == SI_BT)
/* We need to clear the IRQ flag for the BT interface. */
@@ -1124,14 +1123,14 @@ irqreturn_t ipmi_si_irq_handler(int irq, void *data)
 IPMI_BT_INTMASK_CLEAR_IRQ_BIT
 | IPMI_BT_INTMASK_ENABLE_IRQ_BIT);
 
-   spin_lock_irqsave(&(smi_info->si_lock), flags);
+   spin_lock(&(smi_info->si_lock));
 
smi_inc_stat(smi_info, interrupts);
 
debug_timestamp("Interrupt");
 
smi_event_handler(smi_info, 0);
-   spin_unlock_irqrestore(&(smi_info->si_lock), flags);
+   spin_unlock(&(smi_info->si_lock));
return IRQ_HANDLED;
 }
 
-- 
2.7.4

Re: [PATCH v6 07/25] treewide: remove DISABLE_LTO

[Masahiro Yamada]

On Thu, Oct 15, 2020 at 7:43 AM Kees Cook  wrote:
>
> On Mon, Oct 12, 2020 at 05:31:45PM -0700, Sami Tolvanen wrote:
> > This change removes all instances of DISABLE_LTO from
> > Makefiles, as they are currently unused, and the preferred
> > method of disabling LTO is to filter out the flags instead.
> >
> > Suggested-by: Kees Cook 
> > Signed-off-by: Sami Tolvanen 
> > Reviewed-by: Kees Cook 
>
> Hi Masahiro,
>
> Since this is independent of anything else and could be seen as a
> general cleanup, can this patch be taken into your tree, just to
> separate it from the list of dependencies for this series?
>
> -Kees
>
> --
> Kees Cook



Yes, this is stale code because GCC LTO was not pulled.

Applied to linux-kbuild.

I added the following historical background.



Note added by Masahiro Yamada:
DISABLE_LTO was added as preparation for GCC LTO, but GCC LTO was
not pulled into the mainline. (https://lkml.org/lkml/2014/4/8/272)




-- 
Best Regards
Masahiro Yamada

Re: [PATCH 3/3] MIPS: Loongson64: Add /proc/boardinfo

[Tiezhu Yang]

On 10/16/2020 09:11 PM, Pavel Machek wrote:

Hi!


Add /proc/boardinfo to get mainboard and BIOS info easily on the Loongson
platform, this is useful to point out the current used mainboard type and
BIOS version when there exists problems related with hardware or firmware.

E.g. with this patch:

[loongson@linux ~]$ cat /proc/boardinfo
Board Info
Manufacturer: LEMOTE
Board Name  : LEMOTE-LS3A4000-7A1000-1w-V01-pc
Family  : LOONGSON3

BIOS Info
Vendor  : Kunlun
Version : Kunlun-A1901-V4.1.3-20200414093938
ROM Size: 4 KB
Release Date: 2020-04-14

Please put this into /sys somewhere, with usual rules. This is hard to
extend/parse.


Hi Pavel,

Thanks for your suggestion. I submitted a new version some days ago.

[1/2] MIPS: Loongson64: Add /sys/firmware/lefi/boardinfo
https://lore.kernel.org/patchwork/patch/1320574/

[2/2] Documentation: ABI: Add /sys/firmware/lefi/boardinfo description 
for Loongson64

https://lore.kernel.org/patchwork/patch/1320573/

Thanks,
Tiezhu



Pavel

Re: [PATCH v9 09/10] fs/ntfs3: Add NTFS3 in fs/Kconfig and fs/Makefile

[kernel test robot]

Hi Konstantin,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[also build test WARNING on v5.9 next-20201016]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Konstantin-Komarov/NTFS-read-write-driver-GPL-implementation-by-Paragon-Software/20201016-233309
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
9ff9b0d392ea08090cd1780fb196f36dbb586529
config: x86_64-randconfig-a011-20201017 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 
efd02c1548ee458d59063f6393e94e972b5c3d50)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
# 
https://github.com/0day-ci/linux/commit/3339f0d0890cfe6ed760dc24916de15e74c4f67d
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Konstantin-Komarov/NTFS-read-write-driver-GPL-implementation-by-Paragon-Software/20201016-233309
git checkout 3339f0d0890cfe6ed760dc24916de15e74c4f67d
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 

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

All warnings (new ones prefixed by >>):

>> fs/ntfs3/attrib.c:1256:7: warning: variable 'hint' is used uninitialized 
>> whenever '&&' condition is false [-Wsometimes-uninitialized]
   if (vcn + clst_data &&
   ^~~
   fs/ntfs3/attrib.c:1263:11: note: uninitialized use occurs here
hint + 1, len - clst_data, 
NULL, 0,
^~~~
   fs/ntfs3/attrib.c:1256:7: note: remove the '&&' if its condition is always 
true
   if (vcn + clst_data &&
   ^~
   fs/ntfs3/attrib.c:1254:18: note: initialize the variable 'hint' to silence 
this warning
   CLST alen, hint;
  ^
   = 0
   fs/ntfs3/attrib.c:72:20: warning: unused function 'attr_must_be_resident' 
[-Wunused-function]
   static inline bool attr_must_be_resident(struct ntfs_sb_info *sbi,
  ^
   2 warnings generated.

vim +1256 fs/ntfs3/attrib.c

dc58d89d2835db2 Konstantin Komarov 2020-10-16  1171  
dc58d89d2835db2 Konstantin Komarov 2020-10-16  1172  /*
dc58d89d2835db2 Konstantin Komarov 2020-10-16  1173   * attr_allocate_frame
dc58d89d2835db2 Konstantin Komarov 2020-10-16  1174   *
dc58d89d2835db2 Konstantin Komarov 2020-10-16  1175   * allocate/free clusters 
for 'frame'
dc58d89d2835db2 Konstantin Komarov 2020-10-16  1176   */
dc58d89d2835db2 Konstantin Komarov 2020-10-16  1177  int 
attr_allocate_frame(struct ntfs_inode *ni, CLST frame, size_t compr_size,
dc58d89d2835db2 Konstantin Komarov 2020-10-16  1178 u64 
new_valid)
dc58d89d2835db2 Konstantin Komarov 2020-10-16  1179  {
dc58d89d2835db2 Konstantin Komarov 2020-10-16  1180 int err = 0;
dc58d89d2835db2 Konstantin Komarov 2020-10-16  1181 struct runs_tree *run = 
&ni->file.run;
dc58d89d2835db2 Konstantin Komarov 2020-10-16  1182 struct ntfs_sb_info 
*sbi = ni->mi.sbi;
dc58d89d2835db2 Konstantin Komarov 2020-10-16  1183 struct ATTRIB *attr, 
*attr_b;
dc58d89d2835db2 Konstantin Komarov 2020-10-16  1184 struct ATTR_LIST_ENTRY 
*le, *le_b;
dc58d89d2835db2 Konstantin Komarov 2020-10-16  1185 struct mft_inode *mi, 
*mi_b;
dc58d89d2835db2 Konstantin Komarov 2020-10-16  1186 CLST svcn, evcn1, 
next_evcn1, next_svcn, lcn, len;
dc58d89d2835db2 Konstantin Komarov 2020-10-16  1187 CLST vcn, end, 
clst_data;
dc58d89d2835db2 Konstantin Komarov 2020-10-16  1188 u64 total_size, 
valid_size, data_size;
dc58d89d2835db2 Konstantin Komarov 2020-10-16  1189 bool is_compr;
dc58d89d2835db2 Konstantin Komarov 2020-10-16  1190  
dc58d89d2835db2 Konstantin Komarov 2020-10-16  1191 le_b = NULL;
dc58d89d2835db2 Konstantin Komarov 2020-10-16  1192 attr_b = 
ni_find_attr(ni, NULL, &le_b, ATTR_DATA, NULL, 0, NULL, &mi_b);
dc58d89d2835db2 Konstantin Komarov 2020-10-16  1193 if (!attr_b)
dc58d89d2835db2 Konstantin Komarov 2020-10-16  1194 return -ENOENT;
dc58d89d2835db2 Konstantin Komarov 2020-10-16  1195  
dc58d89d2835db2 Konstantin Komarov 2020-10-16  1196 if 
(!is_attr_ext(attr_b))
dc58d89d283

Re: [PATCH] drivers/virt: vmgenid: add vm generation id driver

[Willy Tarreau]

On Sat, Oct 17, 2020 at 03:40:08AM +0200, Jann Horn wrote:
> [adding some more people who are interested in RNG stuff: Andy, Jason,
> Theodore, Willy Tarreau, Eric Biggers. also linux-api@, because this
> concerns some pretty fundamental API stuff related to RNG usage]
> 
> On Fri, Oct 16, 2020 at 4:33 PM Catangiu, Adrian Costin
>  wrote:
> > This patch is a driver which exposes the Virtual Machine Generation ID
> > via a char-dev FS interface that provides ID update sync and async
> > notification, retrieval and confirmation mechanisms:
> >
> > When the device is 'open()'ed a copy of the current vm UUID is
> > associated with the file handle. 'read()' operations block until the
> > associated UUID is no longer up to date - until HW vm gen id changes -
> > at which point the new UUID is provided/returned. Nonblocking 'read()'
> > uses EWOULDBLOCK to signal that there is no _new_ UUID available.
> >
> > 'poll()' is implemented to allow polling for UUID updates. Such
> > updates result in 'EPOLLIN' events.
> >
> > Subsequent read()s following a UUID update no longer block, but return
> > the updated UUID. The application needs to acknowledge the UUID update
> > by confirming it through a 'write()'.
> > Only on writing back to the driver the right/latest UUID, will the
> > driver mark this "watcher" as up to date and remove EPOLLIN status.
> >
> > 'mmap()' support allows mapping a single read-only shared page which
> > will always contain the latest UUID value at offset 0.
> 
> It would be nicer if that page just contained an incrementing counter,
> instead of a UUID. It's not like the application cares *what* the UUID
> changed to, just that it *did* change and all RNGs state now needs to
> be reseeded from the kernel, right? And an application can't reliably
> read the entire UUID from the memory mapping anyway, because the VM
> might be forked in the middle.
> 
> So I think your kernel driver should detect UUID changes and then turn
> those into a monotonically incrementing counter. (Probably 64 bits
> wide?) (That's probably also a little bit faster than comparing an
> entire UUID.)

I agree with this. Further, I'm observing there is a very common
confusion between "universally unique" and "random". Randoms are
needed when seeking unpredictability. A random number generator
*must* be able to return the same value multiple times in a row
(though this is rare), otherwise it's not random.

To illustrate this, a die has less than 3 bits of randomness and
is sufficient to play games with friends where a counter would allow
everyone to cheat. Conversely if you want to assign IDs to members
of your family you'd rather use a counter than a die for this or
you risk collisions and/or long series of retries to pick unique
IDs.

RFC4122 explains in great length how to produce guaranteed unique
IDs, and this only involves space, time and counters. There's
indeed a lazy variant that probably everyone uses nowadays,
consisting in picking random numbers, but this is not guaranteed
unique anymore.

If the UUIDs used there are real UUIDs, it could be as simple as
updating them according to their format, i.e. updating the timestamp,
and if the timestamp is already the same, just increase the seq counter.
Doing this doesn't require entropy, doesn't need to block and doesn't
needlessly leak randoms that sometimes make people feel nervous.

Just my two cents,
Willy