date:20210326

From: Gao Xiang 

Add a bitmap for available compression algorithms and a variable-sized
on-disk table for compression options in preparation for upcoming big
pcluster and LZMA algorithm, which follows the end of super block.

To parse the compression options, the bitmap is scanned one by one.
For each available algorithm, there is data followed by 2-byte `length'
correspondingly (it's enough for most cases, or entire fs blocks should
be used.)

With such available algorithm bitmap, kernel itself can also refuse to
mount such filesystem if any unsupported compression algorithm exists.

Signed-off-by: Gao Xiang 
---
 fs/erofs/decompressor.c |   2 +-
 fs/erofs/erofs_fs.h |  16 +++--
 fs/erofs/internal.h |   5 +-
 fs/erofs/super.c| 145 +++-
 4 files changed, 161 insertions(+), 7 deletions(-)

diff --git a/fs/erofs/decompressor.c b/fs/erofs/decompressor.c
index 97538ff24a19..27aa6a99b371 100644
--- a/fs/erofs/decompressor.c
+++ b/fs/erofs/decompressor.c
@@ -41,7 +41,7 @@ int z_erofs_load_lz4_config(struct super_block *sb,
}
distance = le16_to_cpu(lz4->max_distance);
} else {
-   distance = le16_to_cpu(dsb->lz4_max_distance);
+   distance = le16_to_cpu(dsb->u1.lz4_max_distance);
}
 
EROFS_SB(sb)->lz4.max_distance_pages = distance ?
diff --git a/fs/erofs/erofs_fs.h b/fs/erofs/erofs_fs.h
index 1322ae63944b..ef3f8a99aa5f 100644
--- a/fs/erofs/erofs_fs.h
+++ b/fs/erofs/erofs_fs.h
@@ -18,15 +18,18 @@
  * be incompatible with this kernel version.
  */
 #define EROFS_FEATURE_INCOMPAT_LZ4_0PADDING0x0001
-#define EROFS_ALL_FEATURE_INCOMPAT 
EROFS_FEATURE_INCOMPAT_LZ4_0PADDING
+#define EROFS_FEATURE_INCOMPAT_COMPR_CFGS  0x0002
+#define EROFS_ALL_FEATURE_INCOMPAT \
+   (EROFS_FEATURE_INCOMPAT_LZ4_0PADDING | \
+EROFS_FEATURE_INCOMPAT_COMPR_CFGS)
 
-/* 128-byte erofs on-disk super block */
+/* erofs on-disk super block (currently 128 bytes) */
 struct erofs_super_block {
__le32 magic;   /* file system magic number */
__le32 checksum;/* crc32c(super_block) */
__le32 feature_compat;
__u8 blkszbits; /* support block_size == PAGE_SIZE only */
-   __u8 reserved;
+   __u8 sb_extslots;   /* superblock size = 128 + sb_extslots * 16 */
 
__le16 root_nid;/* nid of root directory */
__le64 inos;/* total valid ino # (== f_files - f_favail) */
@@ -39,7 +42,11 @@ struct erofs_super_block {
__u8 uuid[16];  /* 128-bit uuid for volume */
__u8 volume_name[16];   /* volume name */
__le32 feature_incompat;
-   __le16 lz4_max_distance;
+   union {
+   /* bitmap for available compression algorithms */
+   __le16 available_compr_algs;
+   __le16 lz4_max_distance;
+   } __packed u1;
__u8 reserved2[42];
 };
 
@@ -195,6 +202,7 @@ enum {
Z_EROFS_COMPRESSION_LZ4 = 0,
Z_EROFS_COMPRESSION_MAX
 };
+#define Z_EROFS_ALL_COMPR_ALGS (1 << (Z_EROFS_COMPRESSION_MAX - 1))
 
 /* 14 bytes (+ length field = 16 bytes) */
 struct z_erofs_lz4_cfgs {
diff --git a/fs/erofs/internal.h b/fs/erofs/internal.h
index 46b977f348eb..f3fa895d809f 100644
--- a/fs/erofs/internal.h
+++ b/fs/erofs/internal.h
@@ -75,6 +75,7 @@ struct erofs_sb_info {
struct xarray managed_pslots;
 
unsigned int shrinker_run_no;
+   u16 available_compr_algs;
 
/* pseudo inode to manage cached pages */
struct inode *managed_cache;
@@ -90,6 +91,7 @@ struct erofs_sb_info {
/* inode slot unit size in bit shift */
unsigned char islotbits;
 
+   u32 sb_size;/* total superblock size */
u32 build_time_nsec;
u64 build_time;
 
@@ -233,6 +235,7 @@ static inline bool erofs_sb_has_##name(struct erofs_sb_info 
*sbi) \
 }
 
 EROFS_FEATURE_FUNCS(lz4_0padding, incompat, INCOMPAT_LZ4_0PADDING)
+EROFS_FEATURE_FUNCS(compr_cfgs, incompat, INCOMPAT_COMPR_CFGS)
 EROFS_FEATURE_FUNCS(sb_chksum, compat, COMPAT_SB_CHKSUM)
 
 /* atomic flag definitions */
@@ -454,7 +457,7 @@ static inline int z_erofs_load_lz4_config(struct 
super_block *sb,
  struct erofs_super_block *dsb,
  struct z_erofs_lz4_cfgs *lz4, int len)
 {
-   if (lz4 || dsb->lz4_max_distance) {
+   if (lz4 || dsb->u1.lz4_max_distance) {
erofs_err(sb, "lz4 algorithm isn't enabled");
return -EINVAL;
}
diff --git a/fs/erofs/super.c b/fs/erofs/super.c
index 1ca8da3f2125..c5e3039f51bf 100644
--- a/fs/erofs/super.c
+++ b/fs/erofs/super.c
@@ -122,6 +122,138 @@ static bool check_layout_compatibility(struct super_block 
*sb,
return true;
 }
 
+#ifdef CONFIG_EROFS_FS_ZIP
+/* read variable-sized metadata, offset will be aligned by 4-byte */
+static void

[PATCH 3/4] erofs: introduce on-disk lz4 fs configurations

From: Gao Xiang 

Introduce z_erofs_lz4_cfgs to store all lz4 configurations.
Currently it's only max_distance, but will be used for new
features later.

Signed-off-by: Gao Xiang 
---
 fs/erofs/decompressor.c | 15 +--
 fs/erofs/erofs_fs.h |  6 ++
 fs/erofs/internal.h |  8 +---
 fs/erofs/super.c|  2 +-
 4 files changed, 25 insertions(+), 6 deletions(-)

diff --git a/fs/erofs/decompressor.c b/fs/erofs/decompressor.c
index 93411e9df9b6..97538ff24a19 100644
--- a/fs/erofs/decompressor.c
+++ b/fs/erofs/decompressor.c
@@ -29,9 +29,20 @@ struct z_erofs_decompressor {
 };
 
 int z_erofs_load_lz4_config(struct super_block *sb,
-   struct erofs_super_block *dsb)
+   struct erofs_super_block *dsb,
+   struct z_erofs_lz4_cfgs *lz4, int size)
 {
-   u16 distance = le16_to_cpu(dsb->lz4_max_distance);
+   u16 distance;
+
+   if (lz4) {
+   if (size < sizeof(struct z_erofs_lz4_cfgs)) {
+   erofs_err(sb, "invalid lz4 cfgs, size=%u", size);
+   return -EINVAL;
+   }
+   distance = le16_to_cpu(lz4->max_distance);
+   } else {
+   distance = le16_to_cpu(dsb->lz4_max_distance);
+   }
 
EROFS_SB(sb)->lz4.max_distance_pages = distance ?
DIV_ROUND_UP(distance, PAGE_SIZE) + 1 :
diff --git a/fs/erofs/erofs_fs.h b/fs/erofs/erofs_fs.h
index b27d0e4e4ab5..1322ae63944b 100644
--- a/fs/erofs/erofs_fs.h
+++ b/fs/erofs/erofs_fs.h
@@ -196,6 +196,12 @@ enum {
Z_EROFS_COMPRESSION_MAX
 };
 
+/* 14 bytes (+ length field = 16 bytes) */
+struct z_erofs_lz4_cfgs {
+   __le16 max_distance;
+   u8 reserved[12];
+} __packed;
+
 /*
  * bit 0 : COMPACTED_2B indexes (0 - off; 1 - on)
  *  e.g. for 4k logical cluster size,  4Bif compacted 2B is off;
diff --git a/fs/erofs/internal.h b/fs/erofs/internal.h
index 1de60992c3dd..46b977f348eb 100644
--- a/fs/erofs/internal.h
+++ b/fs/erofs/internal.h
@@ -441,7 +441,8 @@ int erofs_try_to_free_all_cached_pages(struct erofs_sb_info 
*sbi,
 int erofs_try_to_free_cached_page(struct address_space *mapping,
  struct page *page);
 int z_erofs_load_lz4_config(struct super_block *sb,
-   struct erofs_super_block *dsb);
+   struct erofs_super_block *dsb,
+   struct z_erofs_lz4_cfgs *lz4, int len);
 #else
 static inline void erofs_shrinker_register(struct super_block *sb) {}
 static inline void erofs_shrinker_unregister(struct super_block *sb) {}
@@ -450,9 +451,10 @@ static inline void erofs_exit_shrinker(void) {}
 static inline int z_erofs_init_zip_subsystem(void) { return 0; }
 static inline void z_erofs_exit_zip_subsystem(void) {}
 static inline int z_erofs_load_lz4_config(struct super_block *sb,
-   struct erofs_super_block *dsb)
+ struct erofs_super_block *dsb,
+ struct z_erofs_lz4_cfgs *lz4, int len)
 {
-   if (dsb->lz4_max_distance) {
+   if (lz4 || dsb->lz4_max_distance) {
erofs_err(sb, "lz4 algorithm isn't enabled");
return -EINVAL;
}
diff --git a/fs/erofs/super.c b/fs/erofs/super.c
index 3212e4f73f85..1ca8da3f2125 100644
--- a/fs/erofs/super.c
+++ b/fs/erofs/super.c
@@ -189,7 +189,7 @@ static int erofs_read_superblock(struct super_block *sb)
}
 
/* parse on-disk compression configurations */
-   ret = z_erofs_load_lz4_config(sb, dsb);
+   ret = z_erofs_load_lz4_config(sb, dsb, NULL, 0);
 out:
kunmap(page);
put_page(page);
-- 
2.20.1

[PATCH 2/4] erofs: support adjust lz4 history window size

From: Huang Jianan 

lz4 uses LZ4_DISTANCE_MAX to record history preservation. When
using rolling decompression, a block with a higher compression
ratio will cause a larger memory allocation (up to 64k). It may
cause a large resource burden in extreme cases on devices with
small memory and a large number of concurrent IOs. So appropriately
reducing this value can improve performance.

Decreasing this value will reduce the compression ratio (except
when input_size 
Signed-off-by: Guo Weichao 
[ Gao Xiang: introduce struct erofs_sb_lz4_info for configurations. ]
Signed-off-by: Gao Xiang 
---
 fs/erofs/decompressor.c | 21 +
 fs/erofs/erofs_fs.h |  3 ++-
 fs/erofs/internal.h | 19 +++
 fs/erofs/super.c|  4 +++-
 4 files changed, 41 insertions(+), 6 deletions(-)

diff --git a/fs/erofs/decompressor.c b/fs/erofs/decompressor.c
index 80e8871aef71..93411e9df9b6 100644
--- a/fs/erofs/decompressor.c
+++ b/fs/erofs/decompressor.c
@@ -28,6 +28,17 @@ struct z_erofs_decompressor {
char *name;
 };
 
+int z_erofs_load_lz4_config(struct super_block *sb,
+   struct erofs_super_block *dsb)
+{
+   u16 distance = le16_to_cpu(dsb->lz4_max_distance);
+
+   EROFS_SB(sb)->lz4.max_distance_pages = distance ?
+   DIV_ROUND_UP(distance, PAGE_SIZE) + 1 :
+   LZ4_MAX_DISTANCE_PAGES;
+   return 0;
+}
+
 static int z_erofs_lz4_prepare_destpages(struct z_erofs_decompress_req *rq,
 struct list_head *pagepool)
 {
@@ -36,6 +47,8 @@ static int z_erofs_lz4_prepare_destpages(struct 
z_erofs_decompress_req *rq,
struct page *availables[LZ4_MAX_DISTANCE_PAGES] = { NULL };
unsigned long bounced[DIV_ROUND_UP(LZ4_MAX_DISTANCE_PAGES,
   BITS_PER_LONG)] = { 0 };
+   unsigned int lz4_max_distance_pages =
+   EROFS_SB(rq->sb)->lz4.max_distance_pages;
void *kaddr = NULL;
unsigned int i, j, top;
 
@@ -44,14 +57,14 @@ static int z_erofs_lz4_prepare_destpages(struct 
z_erofs_decompress_req *rq,
struct page *const page = rq->out[i];
struct page *victim;
 
-   if (j >= LZ4_MAX_DISTANCE_PAGES)
+   if (j >= lz4_max_distance_pages)
j = 0;
 
/* 'valid' bounced can only be tested after a complete round */
if (test_bit(j, bounced)) {
-   DBG_BUGON(i < LZ4_MAX_DISTANCE_PAGES);
-   DBG_BUGON(top >= LZ4_MAX_DISTANCE_PAGES);
-   availables[top++] = rq->out[i - LZ4_MAX_DISTANCE_PAGES];
+   DBG_BUGON(i < lz4_max_distance_pages);
+   DBG_BUGON(top >= lz4_max_distance_pages);
+   availables[top++] = rq->out[i - lz4_max_distance_pages];
}
 
if (page) {
diff --git a/fs/erofs/erofs_fs.h b/fs/erofs/erofs_fs.h
index 9ad1615f4474..b27d0e4e4ab5 100644
--- a/fs/erofs/erofs_fs.h
+++ b/fs/erofs/erofs_fs.h
@@ -39,7 +39,8 @@ struct erofs_super_block {
__u8 uuid[16];  /* 128-bit uuid for volume */
__u8 volume_name[16];   /* volume name */
__le32 feature_incompat;
-   __u8 reserved2[44];
+   __le16 lz4_max_distance;
+   __u8 reserved2[42];
 };
 
 /*
diff --git a/fs/erofs/internal.h b/fs/erofs/internal.h
index d29fc0c56032..1de60992c3dd 100644
--- a/fs/erofs/internal.h
+++ b/fs/erofs/internal.h
@@ -59,6 +59,12 @@ struct erofs_fs_context {
unsigned int mount_opt;
 };
 
+/* all filesystem-wide lz4 configurations */
+struct erofs_sb_lz4_info {
+   /* # of pages needed for EROFS lz4 rolling decompression */
+   u16 max_distance_pages;
+};
+
 struct erofs_sb_info {
 #ifdef CONFIG_EROFS_FS_ZIP
/* list for all registered superblocks, mainly for shrinker */
@@ -72,6 +78,8 @@ struct erofs_sb_info {
 
/* pseudo inode to manage cached pages */
struct inode *managed_cache;
+
+   struct erofs_sb_lz4_info lz4;
 #endif /* CONFIG_EROFS_FS_ZIP */
u32 blocks;
u32 meta_blkaddr;
@@ -432,6 +440,8 @@ int erofs_try_to_free_all_cached_pages(struct erofs_sb_info 
*sbi,
   struct erofs_workgroup *egrp);
 int erofs_try_to_free_cached_page(struct address_space *mapping,
  struct page *page);
+int z_erofs_load_lz4_config(struct super_block *sb,
+   struct erofs_super_block *dsb);
 #else
 static inline void erofs_shrinker_register(struct super_block *sb) {}
 static inline void erofs_shrinker_unregister(struct super_block *sb) {}
@@ -439,6 +449,15 @@ static inline int erofs_init_shrinker(void) { return 0; }
 static inline void erofs_exit_shrinker(void) {}
 static inline int z_erofs_init_zip_subsystem(void) { return 0; }
 static inline void

[PATCH 0/4] erofs: introduce on-disk compression configurations

From: Gao Xiang 

Hi folks,

When we provides support for different algorithms or big pcluster, it'd
be necessary to record some configuration in the per-fs basis.

For example, when big pcluster feature for lz4 is enabled, we need to
know the largest pclustersize in the whole fs instance to adjust per-CPU
buffers in advance, which will be used to handle in-place decompression
failure for inplace IO then. And we also need to record global arguments
(e.g. dict_size) for the upcoming LZMA algorithm support.

Therefore, this patchset introduces a new INCOMPAT feature called
COMPR_CFGS, which provides an available algorithm bitmap in the sb
and a variable array list to store corresponding arguments for each
available algorithms.

Since such a INCOMPAT sb feature will be introduced, it'd be better to
reuse such bit for BIGPCLUSTER feature as well since BIGPCLUSTER feature
depends on COMPR_CFGS and will be released together with COMPR_CFGS.

If COMPR_CFGS is disabled, the field of available algorithm bitmap would
become a lz4_max_distance (which is now reserved as 0), and max_distance
can be safely ignored for old kernels since 64k lz4 dictionary is always
enough even new images could reduce the sliding window.

Thanks,
Gao Xiang

Gao Xiang (3):
  erofs: introduce erofs_sb_has_xxx() helpers
  erofs: introduce on-disk lz4 fs configurations
  erofs: add on-disk compression configurations

Huang Jianan (1):
  erofs: support adjust lz4 history window size

 fs/erofs/decompressor.c |  35 --
 fs/erofs/erofs_fs.h |  23 +--
 fs/erofs/internal.h |  33 +
 fs/erofs/super.c| 149 +++-
 4 files changed, 228 insertions(+), 12 deletions(-)

-- 
2.20.1

[PATCH 1/4] erofs: introduce erofs_sb_has_xxx() helpers

From: Gao Xiang 

Introduce erofs_sb_has_xxx() to make long checks short, especially
for later big pcluster & LZMA features.

Signed-off-by: Gao Xiang 
---
 fs/erofs/decompressor.c | 3 +--
 fs/erofs/internal.h | 9 +
 fs/erofs/super.c| 2 +-
 3 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/fs/erofs/decompressor.c b/fs/erofs/decompressor.c
index 34e73ff76f89..80e8871aef71 100644
--- a/fs/erofs/decompressor.c
+++ b/fs/erofs/decompressor.c
@@ -124,8 +124,7 @@ static int z_erofs_lz4_decompress(struct 
z_erofs_decompress_req *rq, u8 *out)
support_0padding = false;
 
/* decompression inplace is only safe when 0padding is enabled */
-   if (EROFS_SB(rq->sb)->feature_incompat &
-   EROFS_FEATURE_INCOMPAT_LZ4_0PADDING) {
+   if (erofs_sb_has_lz4_0padding(EROFS_SB(rq->sb))) {
support_0padding = true;
 
while (!src[inputmargin & ~PAGE_MASK])
diff --git a/fs/erofs/internal.h b/fs/erofs/internal.h
index 30e63b73a675..d29fc0c56032 100644
--- a/fs/erofs/internal.h
+++ b/fs/erofs/internal.h
@@ -218,6 +218,15 @@ static inline erofs_off_t iloc(struct erofs_sb_info *sbi, 
erofs_nid_t nid)
return blknr_to_addr(sbi->meta_blkaddr) + (nid << sbi->islotbits);
 }
 
+#define EROFS_FEATURE_FUNCS(name, compat, feature) \
+static inline bool erofs_sb_has_##name(struct erofs_sb_info *sbi) \
+{ \
+   return sbi->feature_##compat & EROFS_FEATURE_##feature; \
+}
+
+EROFS_FEATURE_FUNCS(lz4_0padding, incompat, INCOMPAT_LZ4_0PADDING)
+EROFS_FEATURE_FUNCS(sb_chksum, compat, COMPAT_SB_CHKSUM)
+
 /* atomic flag definitions */
 #define EROFS_I_EA_INITED_BIT  0
 #define EROFS_I_Z_INITED_BIT   1
diff --git a/fs/erofs/super.c b/fs/erofs/super.c
index 0445d09b6331..991b99eaf22a 100644
--- a/fs/erofs/super.c
+++ b/fs/erofs/super.c
@@ -149,7 +149,7 @@ static int erofs_read_superblock(struct super_block *sb)
}
 
sbi->feature_compat = le32_to_cpu(dsb->feature_compat);
-   if (sbi->feature_compat & EROFS_FEATURE_COMPAT_SB_CHKSUM) {
+   if (erofs_sb_has_sb_chksum(sbi)) {
ret = erofs_superblock_csum_verify(sb, data);
if (ret)
goto out;
-- 
2.20.1

[PATCH v2] ACPI: AC: fix some coding style issues

2021-03-26 Thread Xiaofei Tan

Fix some coding style issues reported by checkpatch.pl, including
following types:

ERROR: "foo * bar" should be "foo *bar"
ERROR: code indent should use tabs where possible
WARNING: Block comments use a trailing */ on a separate line
WARNING: braces {} are not necessary for single statement blocks
WARNING: void function return statements are not generally useful
WARNING: CVS style keyword markers, these will _not_ be updated

Signed-off-by: Xiaofei Tan 
---
 drivers/acpi/ac.c | 28 
 1 file changed, 8 insertions(+), 20 deletions(-)

diff --git a/drivers/acpi/ac.c b/drivers/acpi/ac.c
index b86ee6e..b0cb662 100644
--- a/drivers/acpi/ac.c
+++ b/drivers/acpi/ac.c
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0-or-later
 /*
- *  acpi_ac.c - ACPI AC Adapter Driver ($Revision: 27 $)
+ *  acpi_ac.c - ACPI AC Adapter Driver (Revision: 27)
  *
  *  Copyright (C) 2001, 2002 Andy Grover 
  *  Copyright (C) 2001, 2002 Paul Diefenbaugh 
@@ -78,17 +78,14 @@ static struct acpi_driver acpi_ac_driver = {
 struct acpi_ac {
struct power_supply *charger;
struct power_supply_desc charger_desc;
-   struct acpi_device * device;
+   struct acpi_device *device;
unsigned long long state;
struct notifier_block battery_nb;
 };
 
 #define to_acpi_ac(x) power_supply_get_drvdata(x)
 
-/* --
-   AC Adapter Management
-   -- 
*/
-
+/* AC Adapter Management */
 static int acpi_ac_get_state(struct acpi_ac *ac)
 {
acpi_status status = AE_OK;
@@ -109,9 +106,7 @@ static int acpi_ac_get_state(struct acpi_ac *ac)
return 0;
 }
 
-/* --
-sysfs I/F
-   -- 
*/
+/* sysfs I/F */
 static int get_ac_property(struct power_supply *psy,
   enum power_supply_property psp,
   union power_supply_propval *val)
@@ -138,10 +133,7 @@ static enum power_supply_property ac_props[] = {
POWER_SUPPLY_PROP_ONLINE,
 };
 
-/* --
-   Driver Model
-   -- 
*/
-
+/* Driver Model */
 static void acpi_ac_notify(struct acpi_device *device, u32 event)
 {
struct acpi_ac *ac = acpi_driver_data(device);
@@ -174,8 +166,6 @@ static void acpi_ac_notify(struct acpi_device *device, u32 
event)
acpi_notifier_call_chain(device, event, (u32) ac->state);
kobject_uevent(>charger->dev.kobj, KOBJ_CHANGE);
}
-
-   return;
 }
 
 static int acpi_ac_battery_notify(struct notifier_block *nb,
@@ -282,9 +272,8 @@ static int acpi_ac_add(struct acpi_device *device)
ac->battery_nb.notifier_call = acpi_ac_battery_notify;
register_acpi_notifier(>battery_nb);
 end:
-   if (result) {
+   if (result)
kfree(ac);
-   }
 
return result;
 }
@@ -293,7 +282,7 @@ static int acpi_ac_add(struct acpi_device *device)
 static int acpi_ac_resume(struct device *dev)
 {
struct acpi_ac *ac;
-   unsigned old_state;
+   unsigned int old_state;
 
if (!dev)
return -EINVAL;
@@ -352,9 +341,8 @@ static int __init acpi_ac_init(void)
}
 
result = acpi_bus_register_driver(_ac_driver);
-   if (result < 0) {
+   if (result < 0)
return -ENODEV;
-   }
 
return 0;
 }
-- 
2.8.1

Re: [PATCH v1 1/1] x86/tdx: Handle MWAIT, MONITOR and WBINVD

2021-03-26 Thread Kuppuswamy, Sathyanarayanan





On 3/26/21 7:40 PM, Andy Lutomirski wrote:




On Mar 26, 2021, at 5:18 PM, Kuppuswamy Sathyanarayanan 
 wrote:

In non-root TDX guest mode, MWAIT, MONITOR and WBINVD instructions
are not supported. So handle #VE due to these instructions as no ops.


These should at least be WARN.

I will change it to WARN.


Does TDX send #UD if these instructions have the wrong CPL?  

No, TDX does not trigger #UD for these instructions.
If the #VE came from user mode, we should send an appropriate signal instead.
It will be mapped into #GP(0) fault. This should be enough notification right?




Signed-off-by: Kuppuswamy Sathyanarayanan 

Reviewed-by: Andi Kleen 
---

Changes since previous series:
* Suppressed MWAIT feature as per Andi's comment.
* Added warning debug log for MWAIT #VE exception.

arch/x86/kernel/tdx.c | 23 +++
1 file changed, 23 insertions(+)

diff --git a/arch/x86/kernel/tdx.c b/arch/x86/kernel/tdx.c
index e936b2f88bf6..fb7d22b846fc 100644
--- a/arch/x86/kernel/tdx.c
+++ b/arch/x86/kernel/tdx.c
@@ -308,6 +308,9 @@ void __init tdx_early_init(void)

setup_force_cpu_cap(X86_FEATURE_TDX_GUEST);

+/* MWAIT is not supported in TDX platform, so suppress it */
+setup_clear_cpu_cap(X86_FEATURE_MWAIT);
+
tdg_get_info();

pv_ops.irq.safe_halt = tdg_safe_halt;
@@ -362,6 +365,26 @@ int tdg_handle_virtualization_exception(struct pt_regs 
*regs,
case EXIT_REASON_EPT_VIOLATION:
ve->instr_len = tdg_handle_mmio(regs, ve);
break;
+/*
+ * Per Guest-Host-Communication Interface (GHCI) for Intel Trust
+ * Domain Extensions (Intel TDX) specification, sec 2.4,
+ * some instructions that unconditionally cause #VE (such as WBINVD,
+ * MONITOR, MWAIT) do not have corresponding TDCALL
+ * [TDG.VP.VMCALL ] leaves, since the TD has been designed
+ * with no deterministic way to confirm the result of those operations
+ * performed by the host VMM.  In those cases, the goal is for the TD
+ * #VE handler to increment the RIP appropriately based on the VE
+ * information provided via TDCALL.
+ */
+case EXIT_REASON_WBINVD:
+pr_warn_once("WBINVD #VE Exception\n");
+case EXIT_REASON_MONITOR_INSTRUCTION:
+/* Handle as nops. */
+break;
+case EXIT_REASON_MWAIT_INSTRUCTION:
+/* MWAIT is supressed, not supposed to reach here. */
+pr_warn("MWAIT unexpected #VE Exception\n");
+return -EFAULT;
default:
pr_warn("Unexpected #VE: %d\n", ve->exit_reason);
return -EFAULT;
--
2.25.1



--
Sathyanarayanan Kuppuswamy
Linux Kernel Developer

Re: [PATCH v5 1/2] platform/x86: dell-privacy: Add support for Dell hardware privacy

2021-03-26 Thread Perry Yuan


Hi Pierre

Thanks for your review .

I changed the patch and explain the review comments as below

(Maybe the mail format has problem, sent from one new system thunderbird :)

On 3/23/21 2:57 PM, Pierre-Louis Bossart wrote:

Minor comments below.

On 3/22/21 4:38 AM, Perry Yuan wrote:

From: Perry Yuan 

add support for Dell privacy driver for the Dell units equipped
hardware privacy design, which protect users privacy of audio and
camera from hardware level. Once the audio or camera privacy mode
activated, any applications will not get any audio or video stream
when user pressed ctrl+F4 hotkey, audio privacy mode will be
enabled, micmute led will be also changed accordingly
The micmute led is fully controlled by hardware & EC(embedded 
controller)

and camera mute hotkey is Ctrl+F9. Currently design only emmits


typo: emits

fixed



SW_CAMERA_LENS_COVER event while the camera lens shutter will be
changed by EC & hw(hadware) control


typo: hardware

fixed


*The flow is like this:
1) User presses key. HW does stuff with this key (timeout timer is 
started)

2) WMI event is emitted from BIOS to kernel
3) WMI event is received by dell-privacy
4) KEY_MICMUTE emitted from dell-privacy
5) Userland picks up key and modifies kcontrol for SW mute
6) Codec kernel driver catches and calls ledtrig_audio_set, like this:
ledtrig_audio_set(LED_AUDIO_MICMUTE,
    rt715->micmute_led ? LED_ON :LED_OFF);
7) If "LED" is set to on dell-privacy notifies EC,
and timeout is cancelled, HW mic mute activated.


what happens if there is timeout? You have an explicit description of 
the timer handling in the success case, but not what happens on a 
timeout...



add more explicit description for timeout triggered case

7) If "LED" is set to on dell-privacy notifies EC, and timeout is cancelled.

    HW mic mute activated. If EC not notified,HW mic mute will also be

    activated when timeout used up, it is just later than active ack

diff --git 
a/Documentation/ABI/testing/sysfs-platform-dell-privacy-wmi 
b/Documentation/ABI/testing/sysfs-platform-dell-privacy-wmi

new file mode 100644
index ..20c15a51ec38
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-platform-dell-privacy-wmi
@@ -0,0 +1,32 @@
+What: 
/sys/bus/wmi/devices/6932965F-1671-4CEB-B988-D3AB0A901919/devices_supported

+Date:    Feb 2021
+KernelVersion:    5.12


5.13 now?

changed to 5.13



+static int dell_privacy_micmute_led_set(struct led_classdev *led_cdev,
+    enum led_brightness brightness)
+{
+    struct privacy_acpi_priv *priv = privacy_acpi;
+    acpi_status status;
+    acpi_handle handle;
+    static char *acpi_method = (char *)"ECAK";
+
+    handle = ec_get_handle();
+    if (!handle)
+    return -EIO;
+    if (!acpi_has_method(handle, acpi_method))
+    return -EIO;
+    status = acpi_evaluate_object(handle, acpi_method, NULL, NULL);
+    if (ACPI_FAILURE(status)) {
+    dev_err(priv->dev, "Error setting privacy EC ack value: %s\n",
+    acpi_format_exception(status));
+    return -EIO;
+    }
+    pr_debug("set dell privacy micmute ec ack event done\n");


can we use dev_dbg() here? Same for all occurrences of pr_debug and 
pr_err below, it's cleaner and easier to filter.


I changed some pr_xx to dev_xxx ,  but below code will be more complex 
to use dev_xxx to print the


log , because it need to get the priv->dev, but it is not registered at 
this time , I would prefer to keep use the pr_debug here.  and some 
other cases where  "priv->dev" cannot be used.



 static int __init init_dell_privacy(void)

{
    int ret;

    ret = wmi_has_guid(DELL_PRIVACY_GUID);
    if (!ret) {
    privacy_valid = -ENODEV;
    pr_debug("Unable to detect available Dell privacy 
devices: %d\n", ret);

    return privacy_valid;
    }


+    return 0;
+}
+
+static int dell_privacy_acpi_remove(struct platform_device *pdev)
+{
+    struct privacy_acpi_priv *priv = 
dev_get_drvdata(privacy_acpi->dev);

+
+    led_classdev_unregister(>cdev);
+
+    return 0;
+}
+/*
+ * Pressing the mute key activates a time delayed circuit to 
physically cut
+ * off the mute. The LED is in the same circuit, so it reflects the 
true
+ * state of the HW mute.  The reason for the EC "ack" is so that 
software
+ * can first invoke a SW mute before the HW circuit is cut off.  
Without SW
+ * cutting this off first does not affect the time delayed muting or 
status

+ * of the LED but there is a possibility of a "popping" noise.
+ *
+ * If the EC receives the SW ack, the circuit will be activated 
before the

+ * delay completed.
+ *
+ * Exposing as an LED device allows the codec drivers notification 
path to

+ * EC ACK to work
+ */
+static int dell_privacy_leds_setup(struct device *dev)
+{
+    struct privacy_acpi_priv *priv = dev_get_drvdata(dev);
+    int ret = 0;


useless init


Sorry, I do not get this point .

int should be needed to return error code if

Re: Candidate Linux ABI for Intel AMX and hypothetical new related features

2021-03-26 Thread Len Brown

Hi Andy,

Say a mainline links with a math library that uses AMX without the
knowledge of the mainline.
Say the mainline is also linked with a userspace threading library
that thinks it has a concept of XSAVE area size.

Wouldn't the change in XCR0, resulting in XSAVE size change, risk
confusing the threading library?

thanks,
Len Brown, Intel Open Source Technology Center

Re: [PATCH -next] mm, page_alloc: avoid page_to_pfn() in move_freepages()

2021-03-26 Thread Liu Shixin

Sorry to reply to you after a so long time and thanks for your advice. It 
does seem that your proposed change will make the code cleaner and more 
efficient.

I repeated move_freepages_block() 200 times on the VM and counted 
jiffies. The average value before and after the change was both about 12,000. I 
think it's probably because I'm using the Sparse Memory Model, so pfn_to_page() 
is not time-consuming.


On 2021/3/23 20:54, Matthew Wilcox wrote:
> On Tue, Mar 23, 2021 at 09:12:15PM +0800, Liu Shixin wrote:
>> From: Kefeng Wang 
>>
>> The start_pfn and end_pfn are already available in move_freepages_block(),
>> there is no need to go back and forth between page and pfn in move_freepages
>> and move_freepages_block, and pfn_valid_within() should validate pfn first
>> before touching the page.
> This looks good to me:
>
> Reviewed-by: Matthew Wilcox (Oracle) 
>
>>  static int move_freepages(struct zone *zone,
>> -  struct page *start_page, struct page *end_page,
>> +  unsigned long start_pfn, unsigned long end_pfn,
>>int migratetype, int *num_movable)
>>  {
>>  struct page *page;
>> +unsigned long pfn;
>>  unsigned int order;
>>  int pages_moved = 0;
>>  
>> -for (page = start_page; page <= end_page;) {
>> -if (!pfn_valid_within(page_to_pfn(page))) {
>> -page++;
>> +for (pfn = start_pfn; pfn <= end_pfn;) {
>> +if (!pfn_valid_within(pfn)) {
>> +pfn++;
>>  continue;
>>  }
>>  
>> +page = pfn_to_page(pfn);
> I wonder if this wouldn't be even better if we did:
>
>   struct page *start_page = pfn_to_page(start_pfn);
>
>   for (pfn = start_pfn; pfn <= end_pfn; pfn++) {
>   struct page *page = start_page + pfn - start_pfn;
>
>   if (!pfn_valid_within(pfn))
>   continue;
>
>> -
>> -page++;
>> +pfn++;
>>  continue;
> ... then we can drop the increment of pfn here
>
>>  }
>>  
>> @@ -2458,7 +2459,7 @@ static int move_freepages(struct zone *zone,
>>  
>>  order = buddy_order(page);
>>  move_to_free_list(page, zone, order, migratetype);
>> -page += 1 << order;
>> +pfn += 1 << order;
> ... and change this to pfn += (1 << order) - 1;
>
> Do you have any numbers to quantify the benefit of this change?
> .
>

Re: [Bug 212265] New: clock_gettime(CLOCK_TAI, ...) should return an error when TAI has not been configured

2021-03-26 Thread Richard Cochran

On Fri, Mar 26, 2021 at 12:13:43PM +0100, Thomas Gleixner wrote:
> On Sat, Mar 13 2021 at 17:44, bugzilla-daemon wrote:
> > Unfortunately, although the majority of distributions ship with a leap
> > second file from the zoneinfo database, many or most of them (I have
> > Arch here) do not configure ntpd to know about it, so ntpd does not
> > set things up properly for CLOCK_TAI to work.

I'm not sure about "many or most" distros.  In Debian, the ntp package
depends on tzdata, and the default /etc/ntp.conf does use the leap
seconds file.

> That would be a user visible change and might hit existing user space by
> surprise, so that's not a necessarily a good option.

Agreed.

> and the kernel on it's own has no way to check for and retrieve an
> up-to-date version. That's why it is delegated to user space.

Right, the kernel can't make any assumptions about the TAI-UTC offset.

> I hope the NTP/TAI wizards have some more insight/opinions on this.

I agree that ntpd and the current distros don't handle this very well,
but all the pieces are there to allow user space to handle TAI and
leap seconds as reasonably as possible.  The fundamental issue is that
there is no way to determine the TAI-UTC offset without some kind of
input from the real world.

Even with GPS, after a cold boot you cannot know the offset
immediately, because the leap second information is broadcast in the
almanac only every 12.5 minutes, and so you can be left in suspense
for a long time.

Using ntpd on Debian, the service will set the offset, but only after
synchronization with the upstream server has been established, and
this takes about five minutes, IIRC.

If waiting 5 or 12.5 minutes is too long for your requirements, you
can boot strap the time from RTC [1] and then consult the leap seconds
table [2] to set the TAI-UTC offset in the kernel via adjtimex().

Unfortunately there is no user space utility for setting TAI-UTC, but
I hacked one 'adjtimex' program for this purpose:

https://github.com/richardcochran/ntpclient-2015

Getting back to the original point of the kernel returning an error,
I don't see a need for this.  Applications that require correct leap
seconds can simply call adjtimex() and wait until the initial zero
value is changed by ntpd/etc to the correct offset.  That isn't
fundamentally harder than calling clock_gettime() and waiting until
the error would go away.

Thanks,
Richard

1. Assuming the RTC was set and has a fresh battery, and assuming no
   leap seconds occurred while your computer was off!

2. Assuming the RTC value is not newer than the expiration date of the
   leap seconds file.

Re: [PATCH resend 2/8] sched: core scheduling tagging infrastructure

2021-03-26 Thread Josh Don

Hi Peter,

On Fri, Mar 26, 2021 at 5:10 PM Peter Zijlstra  wrote:
>
> On Wed, Mar 24, 2021 at 05:40:14PM -0400, Joel Fernandes (Google) wrote:
> > From: Josh Don 
> >
> > A single unsigned long is insufficient as a cookie value for core
> > scheduling. We will minimally have cookie values for a per-task and a
> > per-group interface, which must be combined into an overall cookie.
> >
> > This patch adds the infrastructure necessary for setting task and group
> > cookie. Namely, it reworks the core_cookie into a struct, and provides
> > interfaces for setting task and group cookie, as well as other
> > operations (i.e. compare()). Subsequent patches will use these hooks to
> > provide an API for setting these cookies.
> >
>
> *urgh*... so I specifically wanted the task interface first to avoid /
> get-rid of all this madness. And then you keep it :-(

Sorry, I misunderstood the ask here :/ I had separated out the cgroup
interface parts of the patch, leaving (mostly) the parts which
introduced a compound cookie structure. I see now that you just wanted
the plain task interface to start, with no notion of group cookie.

> I've spend the past few hours rewriting patches #2 and #3, and adapting
> #4. The thing was working before I added SHARE_FROM back and introduced
> GET, but now I'm seeing a few FAILs from the selftest.
>
> I'm too tired to make sense of anything much, or even focus my eyes
> consistently, so I'll have to prod at it some more next week, but I've
> pushed out the lot to my queue.git:
>
>   
> https://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git/log/?h=sched/core-sched

Thanks, I'll take a look next week.

> Also, we really need a better name than coretag.c.

Yea, we don't really otherwise use the phrase "tagging". core_sched.c
is probably too confusing given we have sched/core.c.

[PATCH] virtio-balloon: fix a typo in comment of virtballoon_migratepage()

2021-03-26 Thread Liu Xiang

Typo: compation --> compaction

Signed-off-by: Liu Xiang 
---
 drivers/virtio/virtio_balloon.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index 7da25b87f..c25665802 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -734,7 +734,7 @@ static void report_free_page_func(struct work_struct *work)
 #ifdef CONFIG_BALLOON_COMPACTION
 /*
  * virtballoon_migratepage - perform the balloon page migration on behalf of
- *  a compation thread. (called under page lock)
+ *  a compaction thread. (called under page lock)
  * @vb_dev_info: the balloon device
  * @newpage: page that will replace the isolated page after migration finishes.
  * @page   : the isolated (old) page that is about to be migrated to newpage.
-- 
2.17.1

[PATCH] scsi: scsi_priv: Remove duplicate declaration

2021-03-26 Thread Wan Jiabing

struct request and struct request_queue have been
declared at forward struct declaration.
Remove the duplicate and reorder the forward declaration
to be in alphabetic order.

Signed-off-by: Wan Jiabing 
---
 drivers/scsi/scsi_priv.h | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/scsi/scsi_priv.h b/drivers/scsi/scsi_priv.h
index 180636d54982..811abc86f6d6 100644
--- a/drivers/scsi/scsi_priv.h
+++ b/drivers/scsi/scsi_priv.h
@@ -6,14 +6,14 @@
 #include 
 #include 
 
-struct request_queue;
 struct request;
+struct request_queue;
+struct Scsi_Host;
 struct scsi_cmnd;
 struct scsi_device;
-struct scsi_target;
 struct scsi_host_template;
-struct Scsi_Host;
 struct scsi_nl_hdr;
+struct scsi_target;
 
 #define SCSI_CMD_RETRIES_NO_LIMIT -1
 
@@ -96,8 +96,6 @@ extern int scsi_mq_setup_tags(struct Scsi_Host *shost);
 extern void scsi_mq_destroy_tags(struct Scsi_Host *shost);
 extern void scsi_exit_queue(void);
 extern void scsi_evt_thread(struct work_struct *work);
-struct request_queue;
-struct request;
 
 /* scsi_proc.c */
 #ifdef CONFIG_SCSI_PROC_FS
-- 
2.25.1

[PATCH v7 5/5] docs: ABI: Add sysfs documentation interface of dw-xdata-pcie driver

This patch describes the sysfs interface implemented on the dw-xdata-pcie
driver.

Signed-off-by: Gustavo Pimentel 
---
 Documentation/ABI/testing/sysfs-driver-xdata | 46 
 1 file changed, 46 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-driver-xdata

diff --git a/Documentation/ABI/testing/sysfs-driver-xdata 
b/Documentation/ABI/testing/sysfs-driver-xdata
new file mode 100644
index ..cb3ab7e
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-xdata
@@ -0,0 +1,46 @@
+What:  /sys/class/misc/drivers/dw-xdata-pcie/write
+Date:  April 2021
+KernelVersion: 5.12
+Contact:   Gustavo Pimentel 
+Description:   Allows the user to enable the PCIe traffic generator which
+   will create write TLPs frames - from the Root Complex to the
+   Endpoint direction.
+   Usage e.g.
+echo 1 > /sys/class/misc/dw-xdata-pcie/write
+
+   The user can read the current PCIe link throughput generated
+   through this generator in MB/s.
+   Usage e.g.
+cat /sys/class/misc/dw-xdata-pcie/write
+204
+
+   The file is read and write.
+
+What:  /sys/class/misc/dw-xdata-pcie/read
+Date:  April 2021
+KernelVersion: 5.12
+Contact:   Gustavo Pimentel 
+Description:   Allows the user to enable the PCIe traffic generator which
+   will create read TLPs frames - from the Endpoint to the Root
+   Complex direction.
+   Usage e.g.
+echo 1 > /sys/class/misc/dw-xdata-pcie/read
+
+   The user can read the current PCIe link throughput generated
+   through this generator in MB/s.
+   Usage e.g.
+cat /sys/class/misc/dw-xdata-pcie/read
+199
+
+   The file is read and write.
+
+What:  /sys/class/misc/dw-xdata-pcie/stop
+Date:  April 2021
+KernelVersion: 5.12
+Contact:   Gustavo Pimentel 
+Description:   Allows the user to disable the PCIe traffic generator in all
+   directions.
+   Usage e.g.
+echo 1 > /sys/class/misc/dw-xdata-pcie/stop
+
+   The file is write only.
-- 
2.7.4

[PATCH v7 4/5] MAINTAINERS: Add Synopsys xData IP driver maintainer

Add Synopsys xData IP driver maintainer.

This driver aims to support Synopsys xData IP and is normally distributed
along with Synopsys PCIe EndPoint IP as a PCIe traffic generator (depends
of the use and licensing agreement).

Signed-off-by: Gustavo Pimentel 
---
 MAINTAINERS | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 546aa66..f9d681b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5061,6 +5061,13 @@ S:   Maintained
 F: drivers/dma/dw-edma/
 F: include/linux/dma/edma.h
 
+DESIGNWARE XDATA IP DRIVER
+M: Gustavo Pimentel 
+L: linux-...@vger.kernel.org
+S: Maintained
+F: Documentation/misc-devices/dw-xdata-pcie.rst
+F: drivers/misc/dw-xdata-pcie.c
+
 DESIGNWARE USB2 DRD IP DRIVER
 M: Minas Harutyunyan 
 L: linux-...@vger.kernel.org
-- 
2.7.4

[PATCH v7 1/5] misc: Add Synopsys DesignWare xData IP driver

Add Synopsys DesignWare xData IP driver. This driver enables/disables
the PCI traffic generator module pertain to the Synopsys DesignWare
prototype.

Signed-off-by: Gustavo Pimentel 
---
 drivers/misc/dw-xdata-pcie.c | 401 +++
 1 file changed, 401 insertions(+)
 create mode 100644 drivers/misc/dw-xdata-pcie.c

diff --git a/drivers/misc/dw-xdata-pcie.c b/drivers/misc/dw-xdata-pcie.c
new file mode 100644
index ..43fdd35
--- /dev/null
+++ b/drivers/misc/dw-xdata-pcie.c
@@ -0,0 +1,401 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2020 Synopsys, Inc. and/or its affiliates.
+ * Synopsys DesignWare xData driver
+ *
+ * Author: Gustavo Pimentel 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DW_XDATA_DRIVER_NAME   "dw-xdata-pcie"
+
+#define DW_XDATA_EP_MEM_OFFSET 0x800
+
+struct dw_xdata_pcie_data {
+   /* xData registers location */
+   enum pci_barno  rg_bar;
+   off_t   rg_off;
+   size_t  rg_sz;
+};
+
+static const struct dw_xdata_pcie_data snps_edda_data = {
+   /* xData registers location */
+   .rg_bar = BAR_0,
+   .rg_off = 0x,   /*   0 Kbytes */
+   .rg_sz  = 0x012c,   /* 300  bytes */
+};
+
+#define STATUS_DONEBIT(0)
+
+#define CONTROL_DOORBELL   BIT(0)
+#define CONTROL_IS_WRITE   BIT(1)
+#define CONTROL_LENGTH(a)  FIELD_PREP(GENMASK(13, 2), a)
+#define CONTROL_PATTERN_INCBIT(16)
+#define CONTROL_NO_ADDR_INCBIT(18)
+
+#define XPERF_CONTROL_ENABLE   BIT(5)
+
+#define BURST_REPEAT   BIT(31)
+#define BURST_VALUE0x1001
+
+#define PATTERN_VALUE  0x0
+
+struct dw_xdata_regs {
+   u32 addr_lsb;   /* 0x000 */
+   u32 addr_msb;   /* 0x004 */
+   u32 burst_cnt;  /* 0x008 */
+   u32 control;/* 0x00c */
+   u32 pattern;/* 0x010 */
+   u32 status; /* 0x014 */
+   u32 RAM_addr;   /* 0x018 */
+   u32 RAM_port;   /* 0x01c */
+   u32 _reserved0[14]; /* 0x020..0x054 */
+   u32 perf_control;   /* 0x058 */
+   u32 _reserved1[41]; /* 0x05c..0x0fc */
+   u32 wr_cnt_lsb; /* 0x100 */
+   u32 wr_cnt_msb; /* 0x104 */
+   u32 rd_cnt_lsb; /* 0x108 */
+   u32 rd_cnt_msb; /* 0x10c */
+} __packed;
+
+struct dw_xdata_region {
+   phys_addr_t paddr;  /* physical address */
+   void __iomem *vaddr;/* virtual address */
+   size_t sz;  /* size */
+};
+
+struct dw_xdata {
+   struct dw_xdata_region rg_region;   /* registers */
+   size_t max_wr_len;  /* max wr xfer len */
+   size_t max_rd_len;  /* max rd xfer len */
+   struct mutex mutex;
+   struct pci_dev *pdev;
+   struct device *dev;
+   struct miscdevice misc_dev;
+};
+
+static inline struct dw_xdata_regs __iomem *__dw_regs(struct dw_xdata *dw)
+{
+   return dw->rg_region.vaddr;
+}
+
+static void dw_xdata_stop(struct dw_xdata *dw)
+{
+   u32 burst;
+
+   mutex_lock(>mutex);
+
+   burst = readl(&(__dw_regs(dw)->burst_cnt));
+
+   if (burst & BURST_REPEAT) {
+   burst &= ~(u32)BURST_REPEAT;
+   writel(burst, &(__dw_regs(dw)->burst_cnt));
+   }
+
+   mutex_unlock(>mutex);
+}
+
+static void dw_xdata_start(struct dw_xdata *dw, bool write)
+{
+   u32 control, status;
+
+   /* Stop first if xfer in progress */
+   dw_xdata_stop(dw);
+
+   mutex_lock(>mutex);
+
+   /* Clear status register */
+   writel(0x0, &(__dw_regs(dw)->status));
+
+   /* Burst count register set for continuous until stopped */
+   writel(BURST_REPEAT | BURST_VALUE, &(__dw_regs(dw)->burst_cnt));
+
+   /* Pattern register */
+   writel(PATTERN_VALUE, &(__dw_regs(dw)->pattern));
+
+   /* Control register */
+   control = CONTROL_DOORBELL | CONTROL_PATTERN_INC | CONTROL_NO_ADDR_INC;
+   if (write) {
+   control |= CONTROL_IS_WRITE;
+   control |= CONTROL_LENGTH(dw->max_wr_len);
+   } else {
+   control |= CONTROL_LENGTH(dw->max_rd_len);
+   }
+   writel(control,

[PATCH v7 3/5] Documentation: misc-devices: Add Documentation for dw-xdata-pcie driver

Add Documentation for dw-xdata-pcie driver.

Signed-off-by: Gustavo Pimentel 
---
 Documentation/misc-devices/dw-xdata-pcie.rst | 40 
 1 file changed, 40 insertions(+)
 create mode 100644 Documentation/misc-devices/dw-xdata-pcie.rst

diff --git a/Documentation/misc-devices/dw-xdata-pcie.rst 
b/Documentation/misc-devices/dw-xdata-pcie.rst
new file mode 100644
index ..fd75c93
--- /dev/null
+++ b/Documentation/misc-devices/dw-xdata-pcie.rst
@@ -0,0 +1,40 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+===
+Driver for Synopsys DesignWare PCIe traffic generator (also known as xData)
+===
+
+This driver should be used as a host-side (Root Complex) driver and Synopsys
+DesignWare prototype that includes this IP.
+
+The "dw-xdata-pcie" driver can be used to enable/disable PCIe traffic
+generator in either direction (mutual exclusion) besides allowing the
+PCIe link performance analysis.
+
+The interaction with this driver is done through the module parameter and
+can be changed in runtime. The driver outputs the requested command state
+information to /var/log/kern.log or dmesg.
+
+Request write TLPs traffic generation - Root Complex to Endpoint direction
+- Command:
+   echo 1 > /sys/class/misc/dw-xdata-pcie/write
+
+Get write TLPs traffic link throughput in MB/s
+- Command:
+cat /sys/class/misc/dw-xdata-pcie/write
+- Output example:
+   204
+
+Request read TLPs traffic generation - Endpoint to Root Complex direction:
+- Command:
+   echo 1 > /sys/class/misc/dw-xdata-pcie/read
+
+Get read TLPs traffic link throughput in MB/s
+- Command:
+cat /sys/class/misc/dw-xdata-pcie/read
+- Output example:
+   199
+
+Request to stop any current TLP transfer:
+- Command:
+   echo 1 > /sys/class/misc/dw-xdata-pcie/stop
-- 
2.7.4

[PATCH v7 0/5] misc: Add Add Synopsys DesignWare xData IP driver

This patch series adds a new driver called xData-pcie for the Synopsys
DesignWare PCIe prototype.

The driver configures and enables the Synopsys DesignWare PCIe traffic
generator IP inside of prototype Endpoint which will generate upstream
and downstream PCIe traffic. This allows to quickly test the PCIe link
throughput speed and check is the prototype solution has some limitation
or not.

Changes:
 V2: Rework driver according to Greg Kroah-Hartman' feedback
 V3: Fixed issues detected while running on 64 bits platforms
 Rebased patches on top of v5.11-rc1 version
 V4: Rework driver according to Greg Kroah-Hartman' feedback
 Add the ABI doc related to the sysfs implemented on this driver
 V5: Rework driver accordingly to Leon Romanovsky' feedback
 Rework driver accordingly to Krzysztof Wilczy??ski' feedback
 V6: Rework driver according to Greg Kroah-Hartman' feedback
 Rework driver accordingly to Krzysztof Wilczy??ski' feedback
 Rework driver accordingly to Leon Romanovsky' feedback
 V7: Rework driver according to Greg Kroah-Hartman' feedback

Cc: linux-...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Derek Kiernan 
Cc: Dragan Cvetic 
Cc: Arnd Bergmann 
Cc: Andrew Morton 
Cc: Greg Kroah-Hartman 
Cc: Jonathan Corbet 
Cc: Bjorn Helgaas 
Cc: Krzysztof Wilczy??ski 

Gustavo Pimentel (5):
  misc: Add Synopsys DesignWare xData IP driver
  misc: Add Synopsys DesignWare xData IP driver to Makefile and Kconfig
  Documentation: misc-devices: Add Documentation for dw-xdata-pcie
driver
  MAINTAINERS: Add Synopsys xData IP driver maintainer
  docs: ABI: Add sysfs documentation interface of dw-xdata-pcie driver

 Documentation/ABI/testing/sysfs-driver-xdata |  46 +++
 Documentation/misc-devices/dw-xdata-pcie.rst |  40 +++
 MAINTAINERS  |   7 +
 drivers/misc/Kconfig |  10 +
 drivers/misc/Makefile|   1 +
 drivers/misc/dw-xdata-pcie.c | 401 +++
 6 files changed, 505 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-driver-xdata
 create mode 100644 Documentation/misc-devices/dw-xdata-pcie.rst
 create mode 100644 drivers/misc/dw-xdata-pcie.c

-- 
2.7.4

[PATCH v7 2/5] misc: Add Synopsys DesignWare xData IP driver to Makefile and Kconfig

Add Synopsys DesignWare xData IP driver to Makefile and Kconfig.

This driver enables/disables the PCIe traffic generator module
pertain to the Synopsys DesignWare prototype.

Signed-off-by: Gustavo Pimentel 
---
 drivers/misc/Kconfig  | 10 ++
 drivers/misc/Makefile |  1 +
 2 files changed, 11 insertions(+)

diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index fafa8b0..e42b171 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -423,6 +423,16 @@ config SRAM
 config SRAM_EXEC
bool
 
+config DW_XDATA_PCIE
+   depends on PCI
+   tristate "Synopsys DesignWare xData PCIe driver"
+   help
+ This driver allows controlling Synopsys DesignWare PCIe traffic
+ generator IP also known as xData, present in Synopsys DesignWare
+ PCIe Endpoint prototype.
+
+ If unsure, say N.
+
 config PCI_ENDPOINT_TEST
depends on PCI
select CRC32
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index d23231e..bf22021 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -49,6 +49,7 @@ obj-$(CONFIG_SRAM_EXEC)   += sram-exec.o
 obj-$(CONFIG_GENWQE)   += genwqe/
 obj-$(CONFIG_ECHO) += echo/
 obj-$(CONFIG_CXL_BASE) += cxl/
+obj-$(CONFIG_DW_XDATA_PCIE)+= dw-xdata-pcie.o
 obj-$(CONFIG_PCI_ENDPOINT_TEST)+= pci_endpoint_test.o
 obj-$(CONFIG_OCXL) += ocxl/
 obj-y  += cardreader/
-- 
2.7.4

Re: [PATCH 4/4] crypto: hisilicon/zip - support new 'sqe' type in Kunpeng930

2021-03-26 Thread shenyang (M)





On 2021/3/26 17:14, Herbert Xu wrote:

On Fri, Mar 19, 2021 at 03:33:07PM +0800, Yang Shen wrote:


+const struct hisi_zip_sqe_ops hisi_zip_ops_v2 = {
+   .sqe_type   = 0x3,
+   .fill_addr  = hisi_zip_fill_addr,
+   .fill_buf_size  = hisi_zip_fill_buf_size,
+   .fill_buf_type  = hisi_zip_fill_buf_type,
+   .fill_req_type  = hisi_zip_fill_req_type,
+   .fill_tag   = hisi_zip_fill_tag_v2,
+   .fill_sqe_type  = hisi_zip_fill_sqe_type,
+   .get_tag= hisi_zip_get_tag_v2,
+   .get_status = hisi_zip_get_status,
+   .get_dstlen = hisi_zip_get_dstlen,
+};
+


This triggers a new warning:

  CHECK   ../drivers/crypto/hisilicon/zip/zip_crypto.c
  ../drivers/crypto/hisilicon/zip/zip_crypto.c:527:31: warning: symbol 
'hisi_zip_ops_v1' was not declared. Should it be static?
  ../drivers/crypto/hisilicon/zip/zip_crypto.c:540:31: warning: symbol 
'hisi_zip_ops_v2' was not declared. Should it be static?

Please fix.  Thanks.



Sorry， I'll fix this in next version.

Thanks.

[PATCH] netfilter: ipset: Remove duplicate declaration

2021-03-26 Thread Wan Jiabing

struct ip_set is declared twice. One is declared at 79th line,
so remove the duplicate.

Signed-off-by: Wan Jiabing 
---
 include/linux/netfilter/ipset/ip_set.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/include/linux/netfilter/ipset/ip_set.h 
b/include/linux/netfilter/ipset/ip_set.h
index 46d9a0c26c67..10279c4830ac 100644
--- a/include/linux/netfilter/ipset/ip_set.h
+++ b/include/linux/netfilter/ipset/ip_set.h
@@ -124,8 +124,6 @@ struct ip_set_ext {
bool target;
 };
 
-struct ip_set;
-
 #define ext_timeout(e, s)  \
 ((unsigned long *)(((void *)(e)) + (s)->offset[IPSET_EXT_ID_TIMEOUT]))
 #define ext_counter(e, s)  \
-- 
2.25.1

Re: A problem of Intel IOMMU hardware ？

2021-03-26 Thread Lu Baolu


Hi Nadav,

On 3/19/21 12:46 AM, Nadav Amit wrote:

So here is my guess:

Intel probably used as a basis for the IOTLB an implementation of
some other (regular) TLB design.

Intel SDM says regarding TLBs (4.10.4.2 “Recommended Invalidation”):

"Software wishing to prevent this uncertainty should not write to
a paging-structure entry in a way that would change, for any linear
address, both the page size and either the page frame, access rights,
or other attributes.”


Now the aforementioned uncertainty is a bit different (multiple
*valid*  translations of a single address). Yet, perhaps this is
yet another thing that might happen.

 From a brief look on the handling of MMU (not IOMMU) hugepages
in Linux, indeed the PMD is first cleared and flushed before a
new valid PMD is set. This is possible for MMUs since they
allow the software to handle spurious page-faults gracefully.
This is not the case for the IOMMU though (without PRI).

Not sure this explains everything though. If that is the problem,
then during a mapping that changes page-sizes, a TLB flush is
needed, similarly to the one Longpeng did manually.


I have been working with Longpeng on this issue these days. It turned
out that your guess is right. The PMD is first cleared but not flushed
before a new valid one is set. The previous entry might be cached in the
paging structure caches hence leads to disaster.

In __domain_mapping():

2352 /*
2353  * Ensure that old small page 
tables are
2354  * removed to make room for 
superpage(s).
2355  * We're adding new large pages, so 
make sure

2356  * we don't remove their parent tables.
2357  */
2358 dma_pte_free_pagetable(domain, 
iov_pfn, end_pfn,
2359 
largepage_lvl + 1);


I guess adding a cache flush operation after PMD switching should solve
the problem.

I am still not clear about this comment:

"
 This is possible for MMUs since they allow the software to handle
 spurious page-faults gracefully. This is not the case for the IOMMU
 though (without PRI).
"

Can you please shed more light on this?

Best regards,
baolu

Re: [PATCH v1 1/1] x86/tdx: Handle MWAIT, MONITOR and WBINVD

2021-03-26 Thread Andy Lutomirski




> On Mar 26, 2021, at 5:18 PM, Kuppuswamy Sathyanarayanan 
>  wrote:
> 
> In non-root TDX guest mode, MWAIT, MONITOR and WBINVD instructions
> are not supported. So handle #VE due to these instructions as no ops.

These should at least be WARN.

Does TDX send #UD if these instructions have the wrong CPL?  If the #VE came 
from user mode, we should send an appropriate signal instead.

> 
> Signed-off-by: Kuppuswamy Sathyanarayanan 
> 
> Reviewed-by: Andi Kleen 
> ---
> 
> Changes since previous series:
> * Suppressed MWAIT feature as per Andi's comment.
> * Added warning debug log for MWAIT #VE exception.
> 
> arch/x86/kernel/tdx.c | 23 +++
> 1 file changed, 23 insertions(+)
> 
> diff --git a/arch/x86/kernel/tdx.c b/arch/x86/kernel/tdx.c
> index e936b2f88bf6..fb7d22b846fc 100644
> --- a/arch/x86/kernel/tdx.c
> +++ b/arch/x86/kernel/tdx.c
> @@ -308,6 +308,9 @@ void __init tdx_early_init(void)
> 
>setup_force_cpu_cap(X86_FEATURE_TDX_GUEST);
> 
> +/* MWAIT is not supported in TDX platform, so suppress it */
> +setup_clear_cpu_cap(X86_FEATURE_MWAIT);
> +
>tdg_get_info();
> 
>pv_ops.irq.safe_halt = tdg_safe_halt;
> @@ -362,6 +365,26 @@ int tdg_handle_virtualization_exception(struct pt_regs 
> *regs,
>case EXIT_REASON_EPT_VIOLATION:
>ve->instr_len = tdg_handle_mmio(regs, ve);
>break;
> +/*
> + * Per Guest-Host-Communication Interface (GHCI) for Intel Trust
> + * Domain Extensions (Intel TDX) specification, sec 2.4,
> + * some instructions that unconditionally cause #VE (such as WBINVD,
> + * MONITOR, MWAIT) do not have corresponding TDCALL
> + * [TDG.VP.VMCALL ] leaves, since the TD has been designed
> + * with no deterministic way to confirm the result of those operations
> + * performed by the host VMM.  In those cases, the goal is for the TD
> + * #VE handler to increment the RIP appropriately based on the VE
> + * information provided via TDCALL.
> + */
> +case EXIT_REASON_WBINVD:
> +pr_warn_once("WBINVD #VE Exception\n");
> +case EXIT_REASON_MONITOR_INSTRUCTION:
> +/* Handle as nops. */
> +break;
> +case EXIT_REASON_MWAIT_INSTRUCTION:
> +/* MWAIT is supressed, not supposed to reach here. */
> +pr_warn("MWAIT unexpected #VE Exception\n");
> +return -EFAULT;
>default:
>pr_warn("Unexpected #VE: %d\n", ve->exit_reason);
>return -EFAULT;
> -- 
> 2.25.1
>

Re:[PATCH V3,RESEND] workqueue/watchdog: Make unbound workqueues aware of touch_softlockup_watchdog()

2021-03-26 Thread 王擎


>V3:
>- Modify the commit message clearly according to Petr's suggestion.
>
>Signed-off-by: Wang Qing 
>---
> kernel/watchdog.c  |  5 +++--
> kernel/workqueue.c | 17 ++---
> 2 files changed, 9 insertions(+), 13 deletions(-)
>
>diff --git a/kernel/watchdog.c b/kernel/watchdog.c
>index 7110906..107bc38
>--- a/kernel/watchdog.c
>+++ b/kernel/watchdog.c
>@@ -278,9 +278,10 @@ void touch_all_softlockup_watchdogs(void)
>* update as well, the only side effect might be a cycle delay for
>* the softlockup check.
>*/
>-  for_each_cpu(cpu, _allowed_mask)
>+  for_each_cpu(cpu, _allowed_mask) {
>   per_cpu(watchdog_touch_ts, cpu) = SOFTLOCKUP_RESET;
>-  wq_watchdog_touch(-1);
>+  wq_watchdog_touch(cpu);
>+  }
> }
> 
> void touch_softlockup_watchdog_sync(void)
>diff --git a/kernel/workqueue.c b/kernel/workqueue.c
>index 0d150da..be08295
>--- a/kernel/workqueue.c
>+++ b/kernel/workqueue.c
>@@ -5787,22 +5787,17 @@ static void wq_watchdog_timer_fn(struct timer_list 
>*unused)
>   continue;
> 
>   /* get the latest of pool and touched timestamps */
>+  if (pool->cpu >= 0)
>+  touched = READ_ONCE(per_cpu(wq_watchdog_touched_cpu, 
>pool->cpu));
>+  else
>+  touched = READ_ONCE(wq_watchdog_touched);
>   pool_ts = READ_ONCE(pool->watchdog_ts);
>-  touched = READ_ONCE(wq_watchdog_touched);
> 
>   if (time_after(pool_ts, touched))
>   ts = pool_ts;
>   else
>   ts = touched;
> 
>-  if (pool->cpu >= 0) {
>-  unsigned long cpu_touched =
>-  READ_ONCE(per_cpu(wq_watchdog_touched_cpu,
>-pool->cpu));
>-  if (time_after(cpu_touched, ts))
>-  ts = cpu_touched;
>-  }
>-
>   /* did we stall? */
>   if (time_after(jiffies, ts + thresh)) {
>   lockup_detected = true;
>@@ -5826,8 +5821,8 @@ notrace void wq_watchdog_touch(int cpu)
> {
>   if (cpu >= 0)
>   per_cpu(wq_watchdog_touched_cpu, cpu) = jiffies;
>-  else
>-  wq_watchdog_touched = jiffies;
>+
>+  wq_watchdog_touched = jiffies;
> }
> 
> static void wq_watchdog_set_thresh(unsigned long thresh)
>-- 
>2.7.4
>

Hi Petr:
Can you give a reviewed tag, or pick it up to workqueue tree?
Thanks,
Qing

[PATCH -next 3/3] net: vsock: Fix a typo

Modify "occured" to "occurred" in net/vmw_vsock/af_vsock.c.

Reported-by: Hulk Robot 
Signed-off-by: Lu Wei 
---
 net/vmw_vsock/af_vsock.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
index 5546710d8ac1..01eebfecf1d7 100644
--- a/net/vmw_vsock/af_vsock.c
+++ b/net/vmw_vsock/af_vsock.c
@@ -1854,7 +1854,7 @@ vsock_stream_recvmsg(struct socket *sock, struct msghdr 
*msg, size_t len,
if (!transport || sk->sk_state != TCP_ESTABLISHED) {
/* Recvmsg is supposed to return 0 if a peer performs an
 * orderly shutdown. Differentiate between that case and when a
-* peer has not connected or a local shutdown occured with the
+* peer has not connected or a local shutdown occurred with the
 * SOCK_DONE flag.
 */
if (sock_flag(sk, SOCK_DONE))
-- 
2.17.1

[PATCH -next 1/3] net: rds: Fix a typo

Modify "beween" to "between" in net/rds/send.c.

Reported-by: Hulk Robot 
Signed-off-by: Lu Wei 
---
 net/rds/send.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/rds/send.c b/net/rds/send.c
index 985d0b7713ac..53444397de66 100644
--- a/net/rds/send.c
+++ b/net/rds/send.c
@@ -1225,7 +1225,7 @@ int rds_sendmsg(struct socket *sock, struct msghdr *msg, 
size_t payload_len)
}
/* If the socket is already bound to a link local address,
 * it can only send to peers on the same link.  But allow
-* communicating beween link local and non-link local address.
+* communicating between link local and non-link local address.
 */
if (scope_id != rs->rs_bound_scope_id) {
if (!scope_id) {
-- 
2.17.1

[PATCH -next 2/3] net: sctp: Fix some typos

Modify "unkown" to "unknown" in net/sctp/sm_make_chunk.c and
Modify "orginal" to "original" in net/sctp/socket.c.

Reported-by: Hulk Robot 
Signed-off-by: Lu Wei 
---
 net/sctp/sm_make_chunk.c | 2 +-
 net/sctp/socket.c| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c
index f77484df097b..54e6a708d06e 100644
--- a/net/sctp/sm_make_chunk.c
+++ b/net/sctp/sm_make_chunk.c
@@ -3217,7 +3217,7 @@ bool sctp_verify_asconf(const struct sctp_association 
*asoc,
return false;
break;
default:
-   /* This is unkown to us, reject! */
+   /* This is unknown to us, reject! */
return false;
}
}
diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index a710917c5ac7..76a388b5021c 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -9327,7 +9327,7 @@ void sctp_copy_sock(struct sock *newsk, struct sock *sk,
if (newsk->sk_flags & SK_FLAGS_TIMESTAMP)
net_enable_timestamp();
 
-   /* Set newsk security attributes from orginal sk and connection
+   /* Set newsk security attributes from original sk and connection
 * security attribute from ep.
 */
security_sctp_sk_clone(ep, sk, newsk);
-- 
2.17.1

[PATCH -next 0/3] Fix some typos

Lu Wei (3):
  net: rds: Fix a typo
  net: sctp: Fix some typos
  net: vsock: Fix a typo

 net/rds/send.c   | 2 +-
 net/sctp/sm_make_chunk.c | 2 +-
 net/sctp/socket.c| 2 +-
 net/vmw_vsock/af_vsock.c | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

-- 
2.17.1

Re: arch/x86/kvm/hyperv.c failing to compile: frame size of 1048 bytes is larger than 1024 bytes

2021-03-26 Thread Randy Dunlap

On 3/26/21 7:18 PM, Logan Devine wrote:
> Compiling the kernel for the second time, and now kvm/hyperv.c is failing to 
> build:
> 
> 
>   AR  kernel/built-in.a
>   CC [M]  arch/x86/kvm/ioapic.o
>   CC [M]  arch/x86/kvm/irq_comm.o
>   CC [M]  arch/x86/kvm/cpuid.o
>   CC [M]  arch/x86/kvm/pmu.o
>   CC [M]  arch/x86/kvm/mtrr.o
>   CC [M]  arch/x86/kvm/hyperv.o
>   CC [M]  arch/x86/kvm/debugfs.o
>   CC [M]  arch/x86/kvm/mmu/mmu.o
>   CC [M]  arch/x86/kvm/mmu/page_track.o
> arch/x86/kvm/hyperv.c: In function ‘kvm_hv_send_ipi.isra’:
> arch/x86/kvm/hyperv.c:1799:1: error: the frame size of 1048 bytes is larger 
> than 1024 bytes [-Werror=frame-larger-than=]
>  1799 | }
>   | ^
>   CC [M]  arch/x86/kvm/mmu/spte.o
>   CC [M]  arch/x86/kvm/mmu/tdp_iter.o
>   CC [M]  arch/x86/kvm/mmu/tdp_mmu.o
> cc1: all warnings being treated as errors
> make[2]: *** [scripts/Makefile.build:271: arch/x86/kvm/hyperv.o] Error 1
> make[2]: *** Waiting for unfinished jobs
> make[1]: *** [scripts/Makefile.build:514: arch/x86/kvm] Error 2
> make: *** [Makefile:1851: arch/x86] Error 2
>   CC [M]  kernel/kheaders.o
> 
> 
> (Sorry if I did this wrong, it's my first time on the list.)
> 
> 
> I'm on gregkh/staging branch staging-testing.


Hi,
Just edit the kernel .config file and change
CONFIG_FRAME_WARN=1024
to
CONFIG_FRAME_WARN=2048

and it will be good.

-- 
~Randy

[PATCH 1/1] drm/amd/display: Remove duplicated header file inclusion

The header file "dce110/dce110_resource.h" is already included above and
can be removed here.

Signed-off-by: Zhen Lei 
---
 drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c 
b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
index 4a3df13c9e49add..c4fe21b3b23f65a 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
@@ -61,7 +61,6 @@
 #include "dcn21/dcn21_dccg.h"
 #include "dcn21_hubbub.h"
 #include "dcn10/dcn10_resource.h"
-#include "dce110/dce110_resource.h"
 #include "dce/dce_panel_cntl.h"
 
 #include "dcn20/dcn20_dwb.h"
-- 
1.8.3

arch/x86/kvm/hyperv.c failing to compile: frame size of 1048 bytes is larger than 1024 bytes

2021-03-26 Thread Logan Devine

Compiling the kernel for the second time, and now kvm/hyperv.c is 
failing to build:



  AR  kernel/built-in.a
  CC [M]  arch/x86/kvm/ioapic.o
  CC [M]  arch/x86/kvm/irq_comm.o
  CC [M]  arch/x86/kvm/cpuid.o
  CC [M]  arch/x86/kvm/pmu.o
  CC [M]  arch/x86/kvm/mtrr.o
  CC [M]  arch/x86/kvm/hyperv.o
  CC [M]  arch/x86/kvm/debugfs.o
  CC [M]  arch/x86/kvm/mmu/mmu.o
  CC [M]  arch/x86/kvm/mmu/page_track.o
arch/x86/kvm/hyperv.c: In function ‘kvm_hv_send_ipi.isra’:
arch/x86/kvm/hyperv.c:1799:1: error: the frame size of 1048 bytes is 
larger than 1024 bytes [-Werror=frame-larger-than=]

 1799 | }
  | ^
  CC [M]  arch/x86/kvm/mmu/spte.o
  CC [M]  arch/x86/kvm/mmu/tdp_iter.o
  CC [M]  arch/x86/kvm/mmu/tdp_mmu.o
cc1: all warnings being treated as errors
make[2]: *** [scripts/Makefile.build:271: arch/x86/kvm/hyperv.o] Error 1
make[2]: *** Waiting for unfinished jobs
make[1]: *** [scripts/Makefile.build:514: arch/x86/kvm] Error 2
make: *** [Makefile:1851: arch/x86] Error 2
  CC [M]  kernel/kheaders.o


(Sorry if I did this wrong, it's my first time on the list.)


I'm on gregkh/staging branch staging-testing.

Re: [PATCH v7] perf annotate: Fix sample events lost in stdio mode

2021-03-26 Thread Yang Jihong


Hello,

On 2021/3/26 20:06, Arnaldo Carvalho de Melo wrote:

Em Fri, Mar 26, 2021 at 12:25:37PM +0900, Namhyung Kim escreveu:

On Fri, Mar 26, 2021 at 11:24 AM Yang Jihong  wrote:

On 2021/3/19 20:35, Yang Jihong wrote:

In hist__find_annotations function, since different hist_entry may point to same
symbol, we free notes->src to signal already processed this symbol in stdio 
mode;
when annotate, entry will skipped if notes->src is NULL to avoid repeated 
output.

However, there is a problem, for example, run the following command:

   # perf record -e branch-misses -e branch-instructions -a sleep 1

perf.data file contains different types of sample event.

If the same IP sample event exists in branch-misses and branch-instructions,
this event uses the same symbol. When annotate branch-misses events, notes->src
corresponding to this event is set to null, as a result, when annotate
branch-instructions events, this event is skipped and no annotate is output.

Solution of this patch is to remove zfree in hists__find_annotations and
change sort order to "dso,symbol" to avoid duplicate output when different
processes correspond to the same symbol.



Signed-off-by: Yang Jihong 



Acked-by: Namhyung Kim 


Without looking at the patch, just at its description of the problem, I
tried to annotate two events in a group, to get the annotate group view
output with both events, and it seems I'm getting samples accounted for
both events:

[root@five ~]# perf record -e '{branch-misses,branch-instructions}' -a sleep 1
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 2.296 MB perf.data (2507 samples) ]
[root@five ~]#
[root@five ~]# perf report | grep -v '^#' | head -5
 17.49%  19.19%  ThreadPoolForeg  chromium-browser  [.] 
v8::internal::ConcurrentMarking::Run
 12.17%  17.04%  ThreadPoolForeg  chromium-browser  [.] 
v8::internal::Sweeper::RawSweep
 11.14%  11.63%  ThreadPoolForeg  chromium-browser  [.] 
v8::internal::MarkingVisitorBase::ProcessStrongHeapObject
  7.65%   7.84%  ThreadPoolForeg  chromium-browser  [.] 
v8::internal::ConcurrentMarkingVisitor::ShouldVisit
  5.66%   6.72%  ThreadPoolForeg  chromium-browser  [.] 
v8::internal::ConcurrentMarkingVisitor::VisitPointersInSnapshot

[root@five ~]# perf annotate --stdio2 v8::internal::ConcurrentMarking::Run
Samples: 444  of events 'anon group { branch-misses, branch-instructions }', 
4000 Hz, Event count (approx.): 596221, [percent: local period]
v8::internal::ConcurrentMarking::Run() 
/usr/lib64/chromium-browser/chromium-browser
Percent
  
  
  Disassembly of section .text:
  
  03290b30 :

  v8::internal::ConcurrentMarking::Run(v8::JobDelegate*, 
unsigned int, bool):
push   %rbp
mov%rsp,%rbp
push   %r15
push   %r14
mov%rdi,%r14
push   %r13
mov%edx,%r13d
push   %r12
mov%ecx,%r12d
push   %rbx
sub$0x1298,%rsp
mov%rsi,-0x1228(%rbp)
mov%fs:0x28,%rax
mov%rax,-0x38(%rbp)

movzwl 0x2(%rbx),%eax
test   %ax,%ax
  ↓ jne4a9
mov-0x10e8(%rbp),%rdx
cmpw   $0x0,0x2(%rdx)
   0.41   0.39↓ je 4b90
movq   %rbx,%xmm0
movq   %rdx,%xmm2
mov%rdx,%rbx
punpcklqdq %xmm2,%xmm0
movups %xmm0,-0x10e8(%rbp)
movzwl 0x2(%rdx),%eax
 4a9:   sub$0x1,%eax
mov%ax,0x2(%rbx)
   0.36   0.91  movzwl %ax,%eax
   0.60   0.00  mov0x10(%rbx,%rax,8),%rax
   3.44   2.46  mov%rax,-0x11e0(%rbp)
   0.00   0.34   4bf:   mov0x8(%r13),%rax
   0.00   0.36  add$0x1,%r15d
   0.00   0.34  mov0x110(%rax),%rax
mov0x128(%rax),%rcx
   0.88   0.36  mov0x8(%r13),%rax
mov0x110(%rax),%rdx
mov0x130(%rdx),%rdx
   0.00   0.48  mov0x140(%rax),%rax
mov0x110(%rax),%rsi
   0.61   0.47  mov-0x11e0(%rbp),%rax
   2.01   2.32  sub$0x1,%rax
cmp%rcx,%rax
   0.00   0.35

[PATCH 1/1] scsi: ufs: Remove duplicated header file inclusion

The header file  is already included above and can be
removed here.

Signed-off-by: Zhen Lei 
---
 drivers/scsi/ufs/ufshcd.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index c86760788c72c9a..e8aa7de17d0accd 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -24,7 +24,6 @@
 #include "ufs_bsg.h"
 #include "ufshcd-crypto.h"
 #include 
-#include 
 
 #define CREATE_TRACE_POINTS
 #include 
-- 
1.8.3

Re: [PATCH bpf-next 5/5] libbpf: add selftests for TC-BPF API

2021-03-26 Thread Alexei Starovoitov

On Thu, Mar 25, 2021 at 05:30:03PM +0530, Kumar Kartikeya Dwivedi wrote:
> This adds some basic tests for the low level bpf_tc_* API and its
> bpf_program__attach_tc_* wrapper on top.

*_block() apis from patch 3 and 4 are not covered by this selftest.
Why were they added ? And how were they tested?

Pls trim your cc. bpf@vger and netdev@vger would have been enough.

My main concern with this set is that it adds netlink apis to libbpf while
we already agreed to split xdp manipulation pieces out of libbpf.
It would be odd to add tc apis now only to split them later.
I think it's better to start with new library for tc/xdp and have
libbpf as a dependency on that new lib.
For example we can add it as subdir in tools/lib/bpf/.

Similarly I think integerating static linking into libbpf was a mistake.
It should be a sub library as well.

If we end up with core libbpf and ten sublibs for tc, xdp, af_xdp, linking,
whatever else the users would appreciate that we don't shove single libbpf
to them with a ton of features that they might never use.

[PATCH 1/1] drm/nouveau/nvenc: Remove duplicated header file inclusion

The header file "priv.h" is already included above and can be
removed here.

Signed-off-by: Zhen Lei 
---
 drivers/gpu/drm/nouveau/nvkm/engine/nvenc/base.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/nvenc/base.c 
b/drivers/gpu/drm/nouveau/nvkm/engine/nvenc/base.c
index c39e797dc7c9425..cf5dcfda7b2538f 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/nvenc/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/nvenc/base.c
@@ -21,7 +21,6 @@
  */
 #include "priv.h"
 
-#include "priv.h"
 #include 
 
 static void *
-- 
1.8.3

Re: [PATCH] riscv: Use $(LD) instead of $(CC) to link vDSO

2021-03-26 Thread Fangrui Song




On 2021-03-25, Nathan Chancellor wrote:

Currently, the VDSO is being linked through $(CC). This does not match
how the rest of the kernel links objects, which is through the $(LD)
variable.

When linking with clang, there are a couple of warnings about flags that
will not be used during the link:

clang-12: warning: argument unused during compilation: '-no-pie' 
[-Wunused-command-line-argument]
clang-12: warning: argument unused during compilation: '-pg' 
[-Wunused-command-line-argument]

'-no-pie' was added in commit 85602bea297f ("RISC-V: build vdso-dummy.o
with -no-pie") to override '-pie' getting added to the ld command from
distribution versions of GCC that enable PIE by default. It is
technically no longer needed after commit c2c81bb2f691 ("RISC-V: Fix the
VDSO symbol generaton for binutils-2.35+"), which removed vdso-dummy.o
in favor of generating vdso-syms.S from vdso.so with $(NM) but this also
resolves the issue in case it ever comes back due to having full control
over the $(LD) command. '-pg' is for function tracing, it is not used
during linking as clang states.


Looks good.

-pg affects the link action: it changes crt1.o to gcrt1.o.
Since the Makefile uses -nostdlib, crt1.o is suppressed, so -pg
is entirely unneeded.
(-nostdlib implies -nostartfiles so the previous usage has a redundant
option.)


These flags could be removed/filtered to fix the warnings but it is
easier to just match the rest of the kernel and use $(LD) directly for
linking. See commits

 fe00e50b2db8 ("ARM: 8858/1: vdso: use $(LD) instead of $(CC) to link VDSO")
 691efbedc60d ("arm64: vdso: use $(LD) instead of $(CC) to link VDSO")
 2ff906994b6c ("MIPS: VDSO: Use $(LD) instead of $(CC) to link VDSO")
 2b2a25845d53 ("s390/vdso: Use $(LD) instead of $(CC) to link vDSO")

for more information.

The flags are converted to linker flags and '--eh-frame-hdr' is added to
match what is added by GCC implicitly, which can be seen by adding '-v'
to GCC's invocation.


Another minor change which may be shipped together: --hash-style=both
can be --hash-style=gnu. We don't need sysv .hash . The glibc/musl
support for .gnu.hash has been there for years. .gnu.hash is often
smaller than .hash .

Reviewed-by: Fangrui Song 


Additionally, since this area is being modified, use the $(OBJCOPY)
variable instead of an open coded $(CROSS_COMPILE)objcopy so that the
user's choice of objcopy binary is respected.

Link: https://github.com/ClangBuiltLinux/linux/issues/803
Link: https://github.com/ClangBuiltLinux/linux/issues/970
Signed-off-by: Nathan Chancellor 
---
arch/riscv/kernel/vdso/Makefile | 12 
1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/arch/riscv/kernel/vdso/Makefile b/arch/riscv/kernel/vdso/Makefile
index 71a315e73cbe..ca2b40dfd24b 100644
--- a/arch/riscv/kernel/vdso/Makefile
+++ b/arch/riscv/kernel/vdso/Makefile
@@ -41,11 +41,10 @@ KASAN_SANITIZE := n
$(obj)/vdso.o: $(obj)/vdso.so

# link rule for the .so file, .lds has to be first
-SYSCFLAGS_vdso.so.dbg = $(c_flags)
$(obj)/vdso.so.dbg: $(src)/vdso.lds $(obj-vdso) FORCE
$(call if_changed,vdsold)
-SYSCFLAGS_vdso.so.dbg = -shared -s -Wl,-soname=linux-vdso.so.1 \
-   -Wl,--build-id=sha1 -Wl,--hash-style=both
+LDFLAGS_vdso.so.dbg = -shared -s -soname=linux-vdso.so.1 \
+   --build-id=sha1 --hash-style=both --eh-frame-hdr

# We also create a special relocatable object that should mirror the symbol
# table and layout of the linked DSO. With ld --just-symbols we can then
@@ -60,13 +59,10 @@ $(obj)/%.so: $(obj)/%.so.dbg FORCE

# actual build commands
# The DSO images are built using a special linker script
-# Add -lgcc so rv32 gets static muldi3 and lshrdi3 definitions.
# Make sure only to export the intended __vdso_xxx symbol offsets.
quiet_cmd_vdsold = VDSOLD  $@
-  cmd_vdsold = $(CC) $(KBUILD_CFLAGS) $(call cc-option, -no-pie) -nostdlib 
-nostartfiles $(SYSCFLAGS_$(@F)) \
-   -Wl,-T,$(filter-out FORCE,$^) -o $@.tmp && \
-   $(CROSS_COMPILE)objcopy \
-   $(patsubst %, -G __vdso_%, $(vdso-syms)) $@.tmp $@ 
&& \
+  cmd_vdsold = $(LD) $(ld_flags) -T $(filter-out FORCE,$^) -o $@.tmp && \
+   $(OBJCOPY) $(patsubst %, -G __vdso_%, $(vdso-syms)) $@.tmp $@ 
&& \
   rm $@.tmp

# Extracts symbol offsets from the VDSO, converting them into an assembly file
--
2.31.0

--
You received this message because you are subscribed to the Google Groups "Clang 
Built Linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clang-built-linux+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clang-built-linux/20210325215156.1986901-1-nathan%40kernel.org.

[PATCH 1/1] drm/nouveau/dmem: Remove duplicated header file inclusion

The header file  is already included above and can be
removed here.

Signed-off-by: Zhen Lei 
---
 drivers/gpu/drm/nouveau/nouveau_dmem.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_dmem.c 
b/drivers/gpu/drm/nouveau/nouveau_dmem.c
index 92987daa5e17d02..f5cc057b123b8b0 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dmem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dmem.c
@@ -33,7 +33,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include 
 
-- 
1.8.3

Re: [PATCH] riscv: Use $(LD) instead of $(CC) to link vDSO

2021-03-26 Thread Fangrui Song

On 2021-03-26, Nathan Chancellor wrote:

On Sat, Mar 27, 2021 at 12:05:34AM +0800, kernel test robot wrote:

Hi Nathan,

I love your patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v5.12-rc4 next-20210326]
[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/Nathan-Chancellor/riscv-Use-LD-instead-of-CC-to-link-vDSO/20210326-055421
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
002322402dafd846c424ffa9240a937f49b48c42
config: riscv-randconfig-r032-20210326 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project
f490a5969bd52c8a48586f134ff8f02ccbb295b3)
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 riscv cross compiling tool for clang build
# apt-get install binutils-riscv64-linux-gnu
#
https://github.com/0day-ci/linux/commit/dfdcaf93f40f0d15ffc3f25128442c1688e612d6
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Nathan-Chancellor/riscv-Use-LD-instead-of-CC-to-link-vDSO/20210326-055421
git checkout dfdcaf93f40f0d15ffc3f25128442c1688e612d6
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=riscv

For the record, I tried to use this script to reproduce but it has a
couple of bugs:

1. It does not download the right version of clang. This report says
that it is clang-13 but the one that the script downloaded is clang-12.

2. It does not download it to the right location. The script expects
~/0day/clang-latest but it is downloaded to ~/0day/clang it seems. I
symlinked it to get around it.

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

All errors (new ones prefixed by >>):

>> riscv64-linux-gnu-objcopy: 'arch/riscv/kernel/vdso/vdso.so.dbg': No such file

This error only occurs because of errors before it that are not shown
due to a denylist:

ld.lld: error: arch/riscv/kernel/vdso/rt_sigreturn.o:(.text+0x0): relocation
R_RISCV_ALIGN requires unimplemented linker relaxation; recompile with
-mno-relax
ld.lld: error: arch/riscv/kernel/vdso/getcpu.o:(.text+0x0): relocation
R_RISCV_ALIGN requires unimplemented linker relaxation; recompile with
-mno-relax
ld.lld: error: arch/riscv/kernel/vdso/flush_icache.o:(.text+0x0): relocation
R_RISCV_ALIGN requires unimplemented linker relaxation; recompile with
-mno-relax

My patch only adds another occurrence of this error because we move from
$(CC)'s default linker (in clang's case, ld.bfd) to $(LD), which in the
case of 0day appears to be ld.lld. ld.lld should not be used with RISC-V
in its current form due to errors of this nature, which happen without
my patch as well:

https://github.com/ClangBuiltLinux/linux/issues/1020

Linker relaxation in ld.lld for RISC-V is an ongoing debate/process.
Please give RISC-V the current treatment as s390 with ld.lld for the
time being to get meaningful reports. We will reach out once that issue
has been resolved.

TL;DR: Patch exposes existing issue with LD=ld.lld that would have
happened without it in different areas, the report can be ignored.

Yes, lkp frequently reports this error. It can be suppressed by using
-mno-relax... if ld.lld is picked.

Hmm. This motivated me to file
https://github.com/riscv/riscv-elf-psabi-doc/issues/183
R_RISCV_ALIGN friendly to linkers not supporting relaxation
(riscv_relax_delete_bytes).

Cheers!
Nathan

--
You received this message because you are subscribed to the Google Groups "Clang
Built Linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clang-built-linux+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/clang-built-linux/20210326235839.zgfvmtfxrb3hy6i4%40archlinux-ax161.

Re: [PATCH] clk: qcom: camcc: Update the clock ops for the SC7180

2021-03-26 Thread Taniya Das




Thanks Stephen for the review.

On 3/23/2021 12:59 PM, Stephen Boyd wrote:

Quoting Taniya Das (2021-03-19 00:47:34)

Update the RCGs to use shared ops to park the RCGs at XO.


s/Update/fix/?

Can you also elaborate more on why we need to park the RCGs here for all
these different clks? Is the camera driver supposed to not touch these
and let the firmware take over? Is there zero coordination between the
kernel and the firmware?



Updated the patch with details.



Fixes: 15d09e830bbc ("clk: qcom: camcc: Add camera clock controller driver for 
SC7180")
Signed-off-by: Taniya Das 


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

--

Re: [f2fs-dev] [PATCH] Revert "f2fs: give a warning only for readonly partition"

2021-03-26 Thread Chao Yu


On 2021/3/27 1:30, Jaegeuk Kim wrote:

On 03/26, Chao Yu wrote:

On 2021/3/26 9:19, Jaegeuk Kim wrote:

On 03/26, Chao Yu wrote:

On 2021/3/25 9:59, Chao Yu wrote:

On 2021/3/25 6:44, Jaegeuk Kim wrote:

On 03/24, Chao Yu wrote:

On 2021/3/24 12:22, Jaegeuk Kim wrote:

On 03/24, Chao Yu wrote:

On 2021/3/24 2:39, Jaegeuk Kim wrote:

On 03/23, Chao Yu wrote:

This reverts commit 938a184265d75ea474f1c6fe1da96a5196163789.

Because that commit fails generic/050 testcase which expect failure
during mount a recoverable readonly partition.


I think we need to change generic/050, since f2fs can recover this partition,


Well, not sure we can change that testcase, since it restricts all generic
filesystems behavior. At least, ext4's behavior makes sense to me:

journal_dev_ro = bdev_read_only(journal->j_dev);
really_read_only = bdev_read_only(sb->s_bdev) | journal_dev_ro;

if (journal_dev_ro && !sb_rdonly(sb)) {
ext4_msg(sb, KERN_ERR,
 "journal device read-only, try mounting with '-o ro'");
err = -EROFS;
goto err_out;
}

if (ext4_has_feature_journal_needs_recovery(sb)) {
if (sb_rdonly(sb)) {
ext4_msg(sb, KERN_INFO, "INFO: recovery "
"required on readonly filesystem");
if (really_read_only) {
ext4_msg(sb, KERN_ERR, "write access "
"unavailable, cannot proceed "
"(try mounting with noload)");
err = -EROFS;
goto err_out;
}
ext4_msg(sb, KERN_INFO, "write access will "
   "be enabled during recovery");
}
}


even though using it as readonly. And, valid checkpoint can allow for user to
read all the data without problem.



if (f2fs_hw_is_readonly(sbi)) {


Since device is readonly now, all write to the device will fail, checkpoint can
not persist recovered data, after page cache is expired, user can see stale 
data.


My point is, after mount with ro, there'll be no data write which preserves the
current status. So, in the next time, we can recover fsync'ed data later, if
user succeeds to mount as rw. Another point is, with the current checkpoint, we
should not have any corrupted metadata. So, why not giving a chance to show what
data remained to user? I think this can be doable only with CoW filesystems.


I guess we're talking about the different things...

Let me declare two different readonly status:

1. filesystem readonly: file system is mount with ro mount option, and
app from userspace can not modify any thing of filesystem, but filesystem
itself can modify data on device since device may be writable.

2. device readonly: device is set to readonly status via 'blockdev --setro'
command, and then filesystem should never issue any write IO to the device.

So, what I mean is, *when device is readonly*, rather than f2fs mountpoint
is readonly (f2fs_hw_is_readonly() returns true as below code, instead of
f2fs_readonly() returns true), in this condition, we should not issue any
write IO to device anyway, because, AFAIK, write IO will fail due to
bio_check_ro() check.


In that case, mount(2) will try readonly, no?


Yes, if device is readonly, mount (2) can not mount/remount device to rw
mountpoint.


Any other concern about this patch?


Indeed we're talking about different things. :)

This case is mount(ro) with device(ro) having some data to recover.
My point is why not giving a chance to mount(ro) to show the current data
covered by a valid checkpoint. This doesn't change anything in the disk,

Got your idea.

IMO, it has potential issue in above condition:


Since device is readonly now, all write to the device will fail, checkpoint can
not persist recovered data, after page cache is expired, user can see stale 
data.


e.g.

Recovery writes one inode and then triggers a checkpoint, all writes fail


I'm confused. Currently we don't trigger the roll-forward recovery.


Oh, my miss, sorry. :-P

My point is in this condition we can return error and try to notice user to
mount with disable_roll_forward or norecovery option, then at least user can
know he should not expect last fsynced data in newly mounted image.

Or we can use f2fs_recover_fsync_data() to check whether there is fsynced data,
if there is no such data, then let mount() succeed.

Thanks,




due to device is readonly, once inode cache is reclaimed by vm, user will see
old inode when reloading it, or even see corrupted fs if partial meta inode's
cache is expired.

Thoughts?

Thanks,


and in the next time, it allows mount(rw|ro) with device(rw) to recover
the data seamlessly.



Thanks,



Thanks,



# blockdev --setro /dev/vdb
# mount -t f2fs /dev/vdb

[PATCH 1/1] drm/amd/display: Remove duplicated header file inclusion

The header file  is included in the following common
section and can be removed here.

Signed-off-by: Zhen Lei 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 573cf17262da4e1..74989ed502016ee 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -44,7 +44,6 @@
 #include "amdgpu_dm.h"
 #ifdef CONFIG_DRM_AMD_DC_HDCP
 #include "amdgpu_dm_hdcp.h"
-#include 
 #endif
 #include "amdgpu_pm.h"
 
-- 
1.8.3

Re: [PATCH 0/6] Allow signals for IO threads

2021-03-26 Thread Stefan Metzmacher



Hi Jens,

> root@ub1704-166:~# LANG=C gdb --pid 1320
> GNU gdb (Ubuntu 9.2-0ubuntu1~20.04) 9.2
> Copyright (C) 2020 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> Type "show copying" and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
> .
> 
> For help, type "help".
> Type "apropos word" to search for commands related to "word".
> Attaching to process 1320
> [New LWP 1321]
> [New LWP 1322]
> 
> warning: Selected architecture i386:x86-64 is not compatible with reported 
> target architecture i386
> 
> warning: Architecture rejected target-supplied description
> syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
> 38  ../sysdeps/unix/sysv/linux/x86_64/syscall.S: No such file or 
> directory.
> (gdb)

Ok, the following makes gdb happy again:

--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -163,6 +163,8 @@ int copy_thread(unsigned long clone_flags, unsigned long 
sp, unsigned long arg,
/* Kernel thread ? */
if (unlikely(p->flags & (PF_KTHREAD | PF_IO_WORKER))) {
memset(childregs, 0, sizeof(struct pt_regs));
+   if (p->flags & PF_IO_WORKER)
+   childregs->cs = current_pt_regs()->cs;
kthread_frame_init(frame, sp, arg);
return 0;
}

I'm wondering if we should decouple the PF_KTHREAD and PF_IO_WORKER cases even 
more
and keep as much of a userspace-like copy_thread as possible.

metze

[PATCH v2] clk: qcom: camcc: Update the clock ops for the SC7180

2021-03-26 Thread Taniya Das

Some of the RCGs could be always ON from the XO source and could be used
as the clock on signal for the GDSC to be operational. In the cases where
the GDSCs are parked at different source with the source clock disabled,
it could lead to the GDSC to be stuck at ON/OFF during gdsc disable/enable.
Thus park the RCGs at XO during clock disable and update the rcg_ops to
use the shared_ops.

Fixes: 15d09e830bbc ("clk: qcom: camcc: Add camera clock controller driver for 
SC7180")
Signed-off-by: Taniya Das 
---
 drivers/clk/qcom/camcc-sc7180.c | 50 -
 1 file changed, 25 insertions(+), 25 deletions(-)

diff --git a/drivers/clk/qcom/camcc-sc7180.c b/drivers/clk/qcom/camcc-sc7180.c
index dbac565..9bcf2f8 100644
--- a/drivers/clk/qcom/camcc-sc7180.c
+++ b/drivers/clk/qcom/camcc-sc7180.c
@@ -304,7 +304,7 @@ static struct clk_rcg2 cam_cc_bps_clk_src = {
.name = "cam_cc_bps_clk_src",
.parent_data = cam_cc_parent_data_2,
.num_parents = 5,
-   .ops = _rcg2_ops,
+   .ops = _rcg2_shared_ops,
},
 };

@@ -325,7 +325,7 @@ static struct clk_rcg2 cam_cc_cci_0_clk_src = {
.name = "cam_cc_cci_0_clk_src",
.parent_data = cam_cc_parent_data_5,
.num_parents = 3,
-   .ops = _rcg2_ops,
+   .ops = _rcg2_shared_ops,
},
 };

@@ -339,7 +339,7 @@ static struct clk_rcg2 cam_cc_cci_1_clk_src = {
.name = "cam_cc_cci_1_clk_src",
.parent_data = cam_cc_parent_data_5,
.num_parents = 3,
-   .ops = _rcg2_ops,
+   .ops = _rcg2_shared_ops,
},
 };

@@ -360,7 +360,7 @@ static struct clk_rcg2 cam_cc_cphy_rx_clk_src = {
.name = "cam_cc_cphy_rx_clk_src",
.parent_data = cam_cc_parent_data_3,
.num_parents = 6,
-   .ops = _rcg2_ops,
+   .ops = _rcg2_shared_ops,
},
 };

@@ -379,7 +379,7 @@ static struct clk_rcg2 cam_cc_csi0phytimer_clk_src = {
.name = "cam_cc_csi0phytimer_clk_src",
.parent_data = cam_cc_parent_data_0,
.num_parents = 4,
-   .ops = _rcg2_ops,
+   .ops = _rcg2_shared_ops,
},
 };

@@ -393,7 +393,7 @@ static struct clk_rcg2 cam_cc_csi1phytimer_clk_src = {
.name = "cam_cc_csi1phytimer_clk_src",
.parent_data = cam_cc_parent_data_0,
.num_parents = 4,
-   .ops = _rcg2_ops,
+   .ops = _rcg2_shared_ops,
},
 };

@@ -407,7 +407,7 @@ static struct clk_rcg2 cam_cc_csi2phytimer_clk_src = {
.name = "cam_cc_csi2phytimer_clk_src",
.parent_data = cam_cc_parent_data_0,
.num_parents = 4,
-   .ops = _rcg2_ops,
+   .ops = _rcg2_shared_ops,
},
 };

@@ -421,7 +421,7 @@ static struct clk_rcg2 cam_cc_csi3phytimer_clk_src = {
.name = "cam_cc_csi3phytimer_clk_src",
.parent_data = cam_cc_parent_data_0,
.num_parents = 4,
-   .ops = _rcg2_ops,
+   .ops = _rcg2_shared_ops,
},
 };

@@ -443,7 +443,7 @@ static struct clk_rcg2 cam_cc_fast_ahb_clk_src = {
.name = "cam_cc_fast_ahb_clk_src",
.parent_data = cam_cc_parent_data_0,
.num_parents = 4,
-   .ops = _rcg2_ops,
+   .ops = _rcg2_shared_ops,
},
 };

@@ -466,7 +466,7 @@ static struct clk_rcg2 cam_cc_icp_clk_src = {
.name = "cam_cc_icp_clk_src",
.parent_data = cam_cc_parent_data_2,
.num_parents = 5,
-   .ops = _rcg2_ops,
+   .ops = _rcg2_shared_ops,
},
 };

@@ -488,7 +488,7 @@ static struct clk_rcg2 cam_cc_ife_0_clk_src = {
.name = "cam_cc_ife_0_clk_src",
.parent_data = cam_cc_parent_data_4,
.num_parents = 4,
-   .ops = _rcg2_ops,
+   .ops = _rcg2_shared_ops,
},
 };

@@ -510,7 +510,7 @@ static struct clk_rcg2 cam_cc_ife_0_csid_clk_src = {
.name = "cam_cc_ife_0_csid_clk_src",
.parent_data = cam_cc_parent_data_3,
.num_parents = 6,
-   .ops = _rcg2_ops,
+   .ops = _rcg2_shared_ops,
},
 };

@@ -524,7 +524,7 @@ static struct clk_rcg2 cam_cc_ife_1_clk_src = {
.name = "cam_cc_ife_1_clk_src",
.parent_data = cam_cc_parent_data_4,
.num_parents = 4,
-   .ops = _rcg2_ops,
+   .ops = _rcg2_shared_ops,
},
 };

@@ -538,7 +538,7 @@ static struct clk_rcg2 cam_cc_ife_1_csid_clk_src = {
.name = "cam_cc_ife_1_csid_clk_src",
.parent_data = cam_cc_parent_data_3,
.num_parents = 6,
-   .ops = _rcg2_ops,
+   .ops =

Re: [PATCH 4/8] hugetlb: create remove_hugetlb_page() to separate functionality

2021-03-26 Thread Miaohe Lin

On 2021/3/27 3:57, Mike Kravetz wrote:
> On 3/25/21 7:10 PM, Miaohe Lin wrote:
>> On 2021/3/25 8:28, Mike Kravetz wrote:
>>> The new remove_hugetlb_page() routine is designed to remove a hugetlb
>>> page from hugetlbfs processing.  It will remove the page from the active
>>> or free list, update global counters and set the compound page
>>> destructor to NULL so that PageHuge() will return false for the 'page'.
>>> After this call, the 'page' can be treated as a normal compound page or
>>> a collection of base size pages.
>>>
>>> remove_hugetlb_page is to be called with the hugetlb_lock held.
>>>
>>> Creating this routine and separating functionality is in preparation for
>>> restructuring code to reduce lock hold times.
>>>
>>> Signed-off-by: Mike Kravetz 
>>> ---
>>>  mm/hugetlb.c | 70 +---
>>>  1 file changed, 45 insertions(+), 25 deletions(-)
>>>
>>> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
>>> index 404b0b1c5258..3938ec086b5c 100644
>>> --- a/mm/hugetlb.c
>>> +++ b/mm/hugetlb.c
>>> @@ -1327,6 +1327,46 @@ static inline void 
>>> destroy_compound_gigantic_page(struct page *page,
>>> unsigned int order) { }
>>>  #endif
>>>  
>>> +/*
>>> + * Remove hugetlb page from lists, and update dtor so that page appears
>>> + * as just a compound page.  A reference is held on the page.
>>> + * NOTE: hugetlb specific page flags stored in page->private are not
>>> + *  automatically cleared.  These flags may be used in routines
>>> + *  which operate on the resulting compound page.
>>
>> It seems HPageFreed and HPageTemporary is cleared. Which hugetlb specific 
>> page flags
>> is reserverd here and why? Could you please give a simple example to clarify
>> this in the comment to help understand this NOTE?
>>
> 
> I will remove that NOTE: in the comment to avoid any confusion.
> 
> The NOTE was add in the RFC that contained a separate patch to add a flag
> that tracked huge pages allocated from CMA.  That flag needed to remain
> for subsequent freeing of such pages.  This is no longer needed.
> 

Many thanks for explaination. I was confused about that NOTE. :)

>> The code looks good to me. Many thanks!
>> Reviewed-by: Miaohe Lin 
> 
> Thanks,
>

[PATCH 1/1] thermal: ti-soc-thermal: Remove duplicated header file inclusion

The header file  is already included above and can be
removed here.

Signed-off-by: Zhen Lei 
---
 drivers/thermal/ti-soc-thermal/ti-bandgap.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.c 
b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
index 8a3646e26ddd208..d81af89166d2360 100644
--- a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
+++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
@@ -32,7 +32,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include "ti-bandgap.h"
 
-- 
1.8.3

[PATCH 1/1] pinctrl: Remove duplicated header file inclusion

The header file  is already included above and can be
removed here.

Signed-off-by: Zhen Lei 
---
 drivers/pinctrl/pinctrl-k210.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/pinctrl/pinctrl-k210.c b/drivers/pinctrl/pinctrl-k210.c
index 8a733cf77ba0522..f831526d06ff68f 100644
--- a/drivers/pinctrl/pinctrl-k210.c
+++ b/drivers/pinctrl/pinctrl-k210.c
@@ -15,7 +15,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include 
 
-- 
1.8.3

Re: [PATCH v2] drivers/clocksource/mediatek: Ack and disable interrupts on shutdown

2021-03-26 Thread Evan Benn

Hi Daniel,

That is a good point, and I did try that at first and it works fine. I
uploaded this version because the suspend/resume callbacks were
undocumented and mostly not used by other clocksource drivers. I
thought a smaller diff might be preferable.
I also thought it would be better to shut off the interrupt as soon as
it is not needed, avoiding any other potential bugs, instead of just
fixing the one we know about with suspend. I'm not sure how the other
driver / timer disable flows are intended to work for example
(shutdown, detach, etc).

That said I am happy to upload that version if people think it is better.

https://elixir.bootlin.com/linux/latest/source/include/linux/clockchips.h#L120


On Thu, 25 Mar 2021 at 19:10, Daniel Lezcano  wrote:
>
> On 25/03/2021 02:35, Evan Benn wrote:
> > set_state_shutdown is called during system suspend after interrupts have
> > been disabled. If the timer has fired in the meantime, there will be
> > a pending IRQ. So we ack that now and disable the timer. Without this
> > ARM trusted firmware will abort the suspend due to the pending
> > interrupt.
> >
> > Now always disable the IRQ in state transitions, and re-enable in
> > set_periodic and next_event.
>
> Why not put add the suspend/resume callbacks and put there the specific
> code and let the irq untouched in the normal flow ?
>
> > Signed-off-by: Evan Benn 
> > ---
> >
> > Changes in v2:
> > Remove the patch that splits the drivers into 2 files.
> >
> >  drivers/clocksource/timer-mediatek.c | 49 +---
> >  1 file changed, 30 insertions(+), 19 deletions(-)
> >
> > diff --git a/drivers/clocksource/timer-mediatek.c 
> > b/drivers/clocksource/timer-mediatek.c
> > index 9318edcd8963..fba2f9494d90 100644
> > --- a/drivers/clocksource/timer-mediatek.c
> > +++ b/drivers/clocksource/timer-mediatek.c
> > @@ -132,13 +132,33 @@ static u64 notrace mtk_gpt_read_sched_clock(void)
> >   return readl_relaxed(gpt_sched_reg);
> >  }
> >
> > +static void mtk_gpt_disable_ack_interrupts(struct timer_of *to, u8 timer)
> > +{
> > + u32 val;
> > +
> > + /* Disable interrupts */
> > + val = readl(timer_of_base(to) + GPT_IRQ_EN_REG);
> > + writel(val & ~GPT_IRQ_ENABLE(timer), timer_of_base(to) +
> > +GPT_IRQ_EN_REG);
> > +
> > + /* Ack interrupts */
> > + writel(GPT_IRQ_ACK(timer), timer_of_base(to) + GPT_IRQ_ACK_REG);
> > +}
> > +
> >  static void mtk_gpt_clkevt_time_stop(struct timer_of *to, u8 timer)
> >  {
> >   u32 val;
> >
> > + /* Disable timer */
> >   val = readl(timer_of_base(to) + GPT_CTRL_REG(timer));
> >   writel(val & ~GPT_CTRL_ENABLE, timer_of_base(to) +
> >  GPT_CTRL_REG(timer));
> > +
> > + /* This may be called with interrupts disabled,
> > +  * so we need to ack any interrupt that is pending
> > +  * Or for example ATF will prevent a suspend from completing.
> > +  */
> > + mtk_gpt_disable_ack_interrupts(to, timer);
> >  }
> >
> >  static void mtk_gpt_clkevt_time_setup(struct timer_of *to,
> > @@ -152,8 +172,10 @@ static void mtk_gpt_clkevt_time_start(struct timer_of 
> > *to,
> >  {
> >   u32 val;
> >
> > - /* Acknowledge interrupt */
> > - writel(GPT_IRQ_ACK(timer), timer_of_base(to) + GPT_IRQ_ACK_REG);
> > + /* Enable interrupts */
> > + val = readl(timer_of_base(to) + GPT_IRQ_EN_REG);
> > + writel(val | GPT_IRQ_ENABLE(timer),
> > +timer_of_base(to) + GPT_IRQ_EN_REG);
> >
> >   val = readl(timer_of_base(to) + GPT_CTRL_REG(timer));
> >
> > @@ -226,21 +248,6 @@ __init mtk_gpt_setup(struct timer_of *to, u8 timer, u8 
> > option)
> >  timer_of_base(to) + GPT_CTRL_REG(timer));
> >  }
> >
> > -static void mtk_gpt_enable_irq(struct timer_of *to, u8 timer)
> > -{
> > - u32 val;
> > -
> > - /* Disable all interrupts */
> > - writel(0x0, timer_of_base(to) + GPT_IRQ_EN_REG);
> > -
> > - /* Acknowledge all spurious pending interrupts */
> > - writel(0x3f, timer_of_base(to) + GPT_IRQ_ACK_REG);
> > -
> > - val = readl(timer_of_base(to) + GPT_IRQ_EN_REG);
> > - writel(val | GPT_IRQ_ENABLE(timer),
> > -timer_of_base(to) + GPT_IRQ_EN_REG);
> > -}
> > -
> >  static struct timer_of to = {
> >   .flags = TIMER_OF_IRQ | TIMER_OF_BASE | TIMER_OF_CLOCK,
> >
> > @@ -292,6 +299,12 @@ static int __init mtk_gpt_init(struct device_node 
> > *node)
> >   if (ret)
> >   return ret;
> >
> > + /* In case the firmware left the interrupts enabled
> > +  * disable and ack those now
> > +  */
> > + mtk_gpt_disable_ack_interrupts(, TIMER_CLK_SRC);
> > + mtk_gpt_disable_ack_interrupts(, TIMER_CLK_EVT);
> > +
> >   /* Configure clock source */
> >   mtk_gpt_setup(, TIMER_CLK_SRC, GPT_CTRL_OP_FREERUN);
> >   clocksource_mmio_init(timer_of_base() + GPT_CNT_REG(TIMER_CLK_SRC),
> > @@ -305,8 +318,6 @@ static int __init mtk_gpt_init(struct device_node *node)
> >   clockevents_config_and_register(,

[PATCH 1/1] soc: litex: Remove duplicated header file inclusion

The header file  is already included above and can be
removed here.

Signed-off-by: Zhen Lei 
---
 drivers/soc/litex/litex_soc_ctrl.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/soc/litex/litex_soc_ctrl.c 
b/drivers/soc/litex/litex_soc_ctrl.c
index 6268bfa7f0d6088..c3e379a990f2cc9 100644
--- a/drivers/soc/litex/litex_soc_ctrl.c
+++ b/drivers/soc/litex/litex_soc_ctrl.c
@@ -13,7 +13,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
-- 
1.8.3

[PATCH 1/1] watchdog: dw_wdt: Remove duplicated header file inclusion

The header file  is already included above and can be
removed here.

Signed-off-by: Zhen Lei 
---
 drivers/watchdog/dw_wdt.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/watchdog/dw_wdt.c b/drivers/watchdog/dw_wdt.c
index 32d0e1781e63c4e..b1642e2d9175584 100644
--- a/drivers/watchdog/dw_wdt.c
+++ b/drivers/watchdog/dw_wdt.c
@@ -19,7 +19,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
-- 
1.8.3

[tip:x86/build] BUILD SUCCESS 58d746c119dfa28e72fc35aacaf3d2a3ac625cd0

2021-03-26 Thread kernel test robot

 eseries_pxa_defconfig
shtitan_defconfig
arm  imote2_defconfig
mips   mtx1_defconfig
sh shx3_defconfig
xtensa  cadence_csp_defconfig
arm palmz72_defconfig
arm mv78xx0_defconfig
mipsgpr_defconfig
alphaallyesconfig
powerpc powernv_defconfig
powerpc tqm5200_defconfig
um   allyesconfig
powerpc   maple_defconfig
powerpcsocrates_defconfig
powerpc  bamboo_defconfig
m68kdefconfig
sh   se7206_defconfig
sh   sh2007_defconfig
powerpc mpc834x_mds_defconfig
nios2alldefconfig
mips   capcella_defconfig
i386 alldefconfig
mips   ip22_defconfig
armtrizeps4_defconfig
powerpc  mpc885_ads_defconfig
mipsomega2p_defconfig
powerpc  katmai_defconfig
powerpc mpc8315_rdb_defconfig
ia64 allmodconfig
ia64defconfig
m68k allyesconfig
nios2   defconfig
arc  allyesconfig
nds32 allnoconfig
nds32   defconfig
nios2allyesconfig
cskydefconfig
alpha   defconfig
xtensa   allyesconfig
h8300allyesconfig
arc defconfig
sh   allmodconfig
parisc  defconfig
s390 allyesconfig
s390 allmodconfig
parisc   allyesconfig
s390defconfig
sparcallyesconfig
i386   tinyconfig
i386defconfig
mips allyesconfig
powerpc   allnoconfig
i386 randconfig-a004-20210326
i386 randconfig-a003-20210326
i386 randconfig-a001-20210326
i386 randconfig-a002-20210326
i386 randconfig-a006-20210326
i386 randconfig-a005-20210326
x86_64   randconfig-a012-20210326
x86_64   randconfig-a015-20210326
x86_64   randconfig-a014-20210326
x86_64   randconfig-a013-20210326
x86_64   randconfig-a016-20210326
x86_64   randconfig-a011-20210326
i386 randconfig-a014-20210326
i386 randconfig-a011-20210326
i386 randconfig-a015-20210326
i386 randconfig-a016-20210326
i386 randconfig-a012-20210326
i386 randconfig-a013-20210326
riscvnommu_k210_defconfig
riscvnommu_virt_defconfig
riscv allnoconfig
riscv   defconfig
riscv  rv32_defconfig
um   allmodconfig
umallnoconfig
um  defconfig
x86_64rhel-8.3-kselftests
x86_64  defconfig
x86_64   rhel-8.3
x86_64  rhel-8.3-kbuiltin
x86_64  kexec

clang tested configs:
x86_64   randconfig-a002-20210326
x86_64   randconfig-a003-20210326
x86_64   randconfig-a001-20210326
x86_64   randconfig-a006-20210326
x86_64   randconfig-a004-20210326
x86_64   randconfig-a005-20210326

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

回复: [PATCH v2] loop: call __loop_clr_fd() with lo_mutex locked to avoid autoclear race

2021-03-26 Thread Zhang, Qiang




发件人: Pavel Tatashin 
发送时间: 2021年3月27日 5:41
收件人: Zhang, Qiang
抄送: Jens Axboe; linux-bl...@vger.kernel.org; LKML
主题: Re: [PATCH v2] loop: call __loop_clr_fd() with lo_mutex locked to avoid 
autoclear race

[Please note: This e-mail is from an EXTERNAL e-mail address]

On Fri, Mar 26, 2021 at 5:00 AM  wrote:
>
> From: Zqiang 
>
> lo->lo_refcnt = 0
>
> CPU0 CPU1
> lo_open()lo_open()
>  mutex_lock(>lo_mutex)
>  atomic_inc(>lo_refcnt)
>  lo_refcnt == 1
>  mutex_unlock(>lo_mutex)
>  mutex_lock(>lo_mutex)
>  atomic_inc(>lo_refcnt)
>  lo_refcnt == 2
>  mutex_unlock(>lo_mutex)
> loop_clr_fd()
>  mutex_lock(>lo_mutex)
>  atomic_read(>lo_refcnt) > 1
>  lo->lo_flags |= LO_FLAGS_AUTOCLEARlo_release()
>  mutex_unlock(>lo_mutex)
>  return  mutex_lock(>lo_mutex)
>atomic_dec_return(>lo_refcnt)
>  lo_refcnt == 1
>  mutex_unlock(>lo_mutex)
>  return
>
> lo_release()
>  mutex_lock(>lo_mutex)
>  atomic_dec_return(>lo_refcnt)
>  lo_refcnt == 0
>  lo->lo_flags & LO_FLAGS_AUTOCLEAR
>   == true
>  mutex_unlock(>lo_mutex)  loop_control_ioctl()
>case LOOP_CTL_REMOVE:
> mutex_lock(>lo_mutex)
> atomic_read(>lo_refcnt)==0
>   __loop_clr_fd(lo, true)   mutex_unlock(>lo_mutex)
> mutex_lock(>lo_mutex)loop_remove(lo)
>mutex_destroy(>lo_mutex)
>   ..   kfree(lo)
>data race
>
> When different tasks on two CPUs perform the above operations on the same
> lo device, data race may be occur, Do not drop lo->lo_mutex before calling
>  __loop_clr_fd(), so refcnt and LO_FLAGS_AUTOCLEAR check in lo_release
> stay in sync.
>
>There is a race with autoclear logic where use after free may >occur as
>shown in the above scenario. Do not drop lo->lo_mutex >before calling
>__loop_clr_fd(), so refcnt and LO_FLAGS_AUTOCLEAR check >in lo_release
>stay in sync.

Hi Pasha

this patch is incorrect,  lo->lo_state status detection is ignored by me,
in lo_release()  the lo_state is set Lo_rundown, when call LOOP_CTL_REMOVE , if 
lo->lo_state != Lo_unbound will directly return, not call loop_remove().
 I'm sorry to mislead you.

>
>Reviewed-by: Pavel Tatashin 

>
> Fixes: 6cc8e7430801 ("loop: scale loop device by introducing per device lock")
> Signed-off-by: Zqiang 
> ---
>  v1->v2:
>  Modify the title and commit message.
>
>  drivers/block/loop.c | 11 ---
>  1 file changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/block/loop.c b/drivers/block/loop.c
> index d58d68f3c7cd..5712f1698a66 100644
> --- a/drivers/block/loop.c
> +++ b/drivers/block/loop.c
> @@ -1201,7 +1201,6 @@ static int __loop_clr_fd(struct loop_device *lo, bool 
> release)
> bool partscan = false;
> int lo_number;
>
> -   mutex_lock(>lo_mutex);
> if (WARN_ON_ONCE(lo->lo_state != Lo_rundown)) {
> err = -ENXIO;
> goto out_unlock;
> @@ -1257,7 +1256,6 @@ static int __loop_clr_fd(struct loop_device *lo, bool 
> release)
> lo_number = lo->lo_number;
> loop_unprepare_queue(lo);
>  out_unlock:
> -   mutex_unlock(>lo_mutex);
> if (partscan) {
> /*
>  * bd_mutex has been held already in release path, so don't
> @@ -1288,12 +1286,11 @@ static int __loop_clr_fd(struct loop_device *lo, bool 
> release)
>  * protects us from all the other places trying to change the 'lo'
>  * device.
>  */
> -   mutex_lock(>lo_mutex);
> +
> lo->lo_flags = 0;
> if (!part_shift)
> lo->lo_disk->flags |= GENHD_FL_NO_PART_SCAN;
> lo->lo_state = Lo_unbound;
> -   mutex_unlock(>lo_mutex);
>
> /*
>  * Need not hold lo_mutex to fput backing file. Calling fput holding
> @@ -1332,9 +1329,10 @@ static int loop_clr_fd(struct loop_device *lo)
> return 0;
> }
> lo->lo_state = Lo_rundown;
> +   err = __loop_clr_fd(lo, false);
> mutex_unlock(>lo_mutex);
>
> -   return __loop_clr_fd(lo, false);
> +   return err;
>  }
>
>  static int
> @@ -1916,13 +1914,12 @@ static void lo_release(struct gendisk *disk, fmode_t 
> mode)
> if (lo->lo_state != Lo_bound)
> goto out_unlock;
> lo->lo_state = Lo_rundown;
> -

[PATCH 1/1] bus: bt1-apb: Remove duplicated header file inclusion

The header file  is already included above and can be
removed here.

Signed-off-by: Zhen Lei 
---
 drivers/bus/bt1-apb.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/bus/bt1-apb.c b/drivers/bus/bt1-apb.c
index b25ff941e7c7f52..74b1b712ef3a804 100644
--- a/drivers/bus/bt1-apb.c
+++ b/drivers/bus/bt1-apb.c
@@ -22,7 +22,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #define APB_EHB_ISR0x00
-- 
1.8.3

Re: [PATCH] usb: cdns3: delete repeated clear operations

2021-03-26 Thread Peter Chen

On 21-03-22 07:19:46, Pawel Laszczak wrote:
> Hi Peter,
> 
> Can you add this patch to for-usb-next branch.
> 

Feel free add your ACK base on this patch.

Peter
> Thanks.
> 
> >
> >
> >dma_alloc_coherent already zeroes out memory, so memset is not needed.
> >
> >Signed-off-by: Wang Qing 
> 
> Reviewed-by: Pawel Laszczak 
> 
> >---
> > drivers/usb/cdns3/cdnsp-mem.c | 1 -
> > 1 file changed, 1 deletion(-)
> >
> >diff --git a/drivers/usb/cdns3/cdnsp-mem.c b/drivers/usb/cdns3/cdnsp-mem.c
> >index 7a84e92..1d1b9a4
> >--- a/drivers/usb/cdns3/cdnsp-mem.c
> >+++ b/drivers/usb/cdns3/cdnsp-mem.c
> >@@ -1231,7 +1231,6 @@ int cdnsp_mem_init(struct cdnsp_device *pdev)
> > if (!pdev->dcbaa)
> > return -ENOMEM;
> >
> >-memset(pdev->dcbaa, 0, sizeof(*pdev->dcbaa));
> > pdev->dcbaa->dma = dma;
> >
> > cdnsp_write_64(dma, >op_regs->dcbaa_ptr);
> >--
> >2.7.4
> 
> Regards,
> Pawel Laszczak

-- 

Thanks,
Peter Chen

Re: [PATCH] usb: cdnsp: Fixes issue with Configure Endpoint command

2021-03-26 Thread Peter Chen

On 21-03-22 07:09:02, Pawel Laszczak wrote:
> From: Pawel Laszczak 
> 
> Patch adds flag EP_UNCONFIGURED to detect whether endpoint was
> unconfigured. This flag is set in cdnsp_reset_device after Reset Device
> command. Among others this command disables all non control endpoints.
> Flag is used in cdnsp_gadget_ep_disable to protect controller against
> invoking Configure Endpoint command on disabled endpoint. Lack of this
> protection in some cases caused that Configure Endpoint command completed
> with Context State Error code completion.
> 
> Fixes: 3d82904559f4 ("usb: cdnsp: cdns3 Add main part of Cadence USBSSP DRD 
> Driver")
> Signed-off-by: Pawel Laszczak 
> ---
>  drivers/usb/cdns3/cdnsp-gadget.c | 18 +-
>  drivers/usb/cdns3/cdnsp-gadget.h | 11 ++-
>  2 files changed, 19 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/usb/cdns3/cdnsp-gadget.c 
> b/drivers/usb/cdns3/cdnsp-gadget.c
> index d7d4bdd57f46..de17cc4ad91a 100644
> --- a/drivers/usb/cdns3/cdnsp-gadget.c
> +++ b/drivers/usb/cdns3/cdnsp-gadget.c
> @@ -727,7 +727,7 @@ int cdnsp_reset_device(struct cdnsp_device *pdev)
>* are in Disabled state.
>*/
>   for (i = 1; i < CDNSP_ENDPOINTS_NUM; ++i)
> - pdev->eps[i].ep_state |= EP_STOPPED;
> + pdev->eps[i].ep_state |= EP_STOPPED | EP_UNCONFIGURED;
>  
>   trace_cdnsp_handle_cmd_reset_dev(slot_ctx);
>  
> @@ -942,6 +942,7 @@ static int cdnsp_gadget_ep_enable(struct usb_ep *ep,
>  
>   pep = to_cdnsp_ep(ep);
>   pdev = pep->pdev;
> + pep->ep_state &= ~EP_UNCONFIGURED;
>  
>   if (dev_WARN_ONCE(pdev->dev, pep->ep_state & EP_ENABLED,
> "%s is already enabled\n", pep->name))
> @@ -1023,9 +1024,13 @@ static int cdnsp_gadget_ep_disable(struct usb_ep *ep)
>   goto finish;
>   }
>  
> - cdnsp_cmd_stop_ep(pdev, pep);
>   pep->ep_state |= EP_DIS_IN_RROGRESS;
> - cdnsp_cmd_flush_ep(pdev, pep);
> +
> + /* Endpoint was unconfigured by Reset Device command. */
> + if (!(pep->ep_state & EP_UNCONFIGURED)) {
> + cdnsp_cmd_stop_ep(pdev, pep);
> + cdnsp_cmd_flush_ep(pdev, pep);
> + }
>  
>   /* Remove all queued USB requests. */
>   while (!list_empty(>pending_list)) {
> @@ -1036,6 +1041,7 @@ static int cdnsp_gadget_ep_disable(struct usb_ep *ep)
>   cdnsp_invalidate_ep_events(pdev, pep);
>  
>   pep->ep_state &= ~EP_DIS_IN_RROGRESS;
> +

Useless blank line

>   drop_flag = cdnsp_get_endpoint_flag(pep->endpoint.desc);
>   ctrl_ctx = cdnsp_get_input_control_ctx(>in_ctx);
>   ctrl_ctx->drop_flags = cpu_to_le32(drop_flag);
> @@ -1043,10 +1049,12 @@ static int cdnsp_gadget_ep_disable(struct usb_ep *ep)
>  
>   cdnsp_endpoint_zero(pdev, pep);
>  
> - ret = cdnsp_update_eps_configuration(pdev, pep);
> + if (!(pep->ep_state & EP_UNCONFIGURED))
> + ret = cdnsp_update_eps_configuration(pdev, pep);
> +
>   cdnsp_free_endpoint_rings(pdev, pep);
>  
> - pep->ep_state &= ~EP_ENABLED;
> + pep->ep_state &= ~(EP_ENABLED | EP_UNCONFIGURED);
>   pep->ep_state |= EP_STOPPED;
>  
>  finish:
> diff --git a/drivers/usb/cdns3/cdnsp-gadget.h 
> b/drivers/usb/cdns3/cdnsp-gadget.h
> index 6bbb26548c04..e628bd539e23 100644
> --- a/drivers/usb/cdns3/cdnsp-gadget.h
> +++ b/drivers/usb/cdns3/cdnsp-gadget.h
> @@ -830,11 +830,12 @@ struct cdnsp_ep {
>   unsigned int ep_state;
>  #define EP_ENABLED   BIT(0)
>  #define EP_DIS_IN_RROGRESS   BIT(1)
> -#define EP_HALTEDBIT(2)
> -#define EP_STOPPED   BIT(3)
> -#define EP_WEDGE BIT(4)
> -#define EP0_HALTED_STATUSBIT(5)
> -#define EP_HAS_STREAMS   BIT(6)
> +#define EP_UNCONFIGURED  BIT(2)

Why add new flag as BIT(2), it causes many changes in this patch?

> +#define EP_HALTEDBIT(3)
> +#define EP_STOPPED   BIT(4)
> +#define EP_WEDGE BIT(5)
> +#define EP0_HALTED_STATUSBIT(6)
> +#define EP_HAS_STREAMS   BIT(7)
>  
>   bool skip;
>  };
> -- 
> 2.25.1
> 

-- 

Thanks,
Peter Chen

Re: [PATCH v2] usb: cdnsp: Fixes issue with dequeuing requests after disabling endpoint

2021-03-26 Thread Peter Chen

On 21-03-22 06:47:14, Pawel Laszczak wrote:
> From: Pawel Laszczak 
> 
> Patch fixes the bug:
> BUG: kernel NULL pointer dereference, address: 0050
> PGD 0 P4D 0
> Oops: 0002 [#1] SMP PTI
> CPU: 0 PID: 4137 Comm: uvc-gadget Tainted: G   OE 
> 5.10.0-next-20201214+ #3
> Hardware name: ASUS All Series/Q87T, BIOS 0908 07/22/2014
> RIP: 0010:cdnsp_remove_request+0xe9/0x530 [cdnsp_udc_pci]
> Code: 01 00 00 31 f6 48 89 df e8 64 d4 ff ff 48 8b 43 08 48 8b 13 45 31 f6 48 
> 89 42 08 48 89 10 b8 98 ff ff ff 48 89 1b 48 89 5b 08 <41> 83 6d 50 01 41 83 
> af d0 00 00 00 01 41 f6 84 24 78 20 00 00 08
> RSP: 0018:b68d00d07b60 EFLAGS: 00010046
> RAX: ff98 RBX: 9d29c57fbf00 RCX: 1400
> RDX: 9d29c57fbf00 RSI:  RDI: 9d29c57fbf00
> RBP: b68d00d07bb0 R08: 9d2ad9510a00 R09: 9d2ac011c000
> R10: 9d2a12b6e760 R11:  R12: 9d29d3fb8000
> R13:  R14:  R15: 9d29d3fb88c0
> FS:  () GS:9d2adba0() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 0050 CR3: 000102164005 CR4: 001706f0
> Call Trace:
>  cdnsp_ep_dequeue+0x3c/0x90 [cdnsp_udc_pci]
>  cdnsp_gadget_ep_dequeue+0x3f/0x80 [cdnsp_udc_pci]
>  usb_ep_dequeue+0x21/0x70 [udc_core]
>  uvcg_video_enable+0x19d/0x220 [usb_f_uvc]
>  uvc_v4l2_release+0x49/0x90 [usb_f_uvc]
>  v4l2_release+0xa5/0x100 [videodev]
>  __fput+0x99/0x250
>  fput+0xe/0x10
>  task_work_run+0x75/0xb0
>  do_exit+0x370/0xb80
>  do_group_exit+0x43/0xa0
>  get_signal+0x12d/0x820
>  arch_do_signal_or_restart+0xb2/0x870
>  ? __switch_to_asm+0x36/0x70
>  ? kern_select+0xc6/0x100
>  exit_to_user_mode_prepare+0xfc/0x170
>  syscall_exit_to_user_mode+0x2a/0x40
>  do_syscall_64+0x43/0x80
>  entry_SYSCALL_64_after_hwframe+0x44/0xa9
> RIP: 0033:0x7fe969cf5dd7
> Code: Unable to access opcode bytes at RIP 0x7fe969cf5dad.
> 
> Problem occurs for UVC class. During disconnecting the UVC class disable
> endpoints and then start dequeuing all requests. This leads to situation
> where requests are removed twice. The first one in
> cdnsp_gadget_ep_disable and the second in cdnsp_gadget_ep_dequeue
> function.
> Patch adds condition in cdnsp_gadget_ep_dequeue function which allows
> dequeue requests only from enabled endpoint.
> 
> Fixes: 3d82904559f4 ("usb: cdnsp: cdns3 Add main part of Cadence USBSSP DRD 
> Driver")
> Signed-off-by: Pawel Laszczak 
> 
> ---
> Changelog:
> v2:
> - removed unexpected 'commit' word from fixes tag

Acked-by: Peter Chen 

Greg, would you help queue it to your usb-linus branch?

> 
>  drivers/usb/cdns3/cdnsp-gadget.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/usb/cdns3/cdnsp-gadget.c 
> b/drivers/usb/cdns3/cdnsp-gadget.c
> index f2ebbacd932e..d7d4bdd57f46 100644
> --- a/drivers/usb/cdns3/cdnsp-gadget.c
> +++ b/drivers/usb/cdns3/cdnsp-gadget.c
> @@ -1128,6 +1128,10 @@ static int cdnsp_gadget_ep_dequeue(struct usb_ep *ep,
>   return -ESHUTDOWN;
>   }
>  
> + /* Requests has been dequeued during disabling endpoint. */
> + if (!(pep->ep_state & EP_ENABLED))
> + return 0;
> +
>   spin_lock_irqsave(>lock, flags);
>   ret = cdnsp_ep_dequeue(pep, to_cdnsp_request(request));
>   spin_unlock_irqrestore(>lock, flags);
> -- 
> 2.25.1
> 

-- 

Thanks,
Peter Chen

Re: [RFC PATCH 1/3] dt-bindings: display: simple: Add the panel on sc7180-trogdor-pompom

2021-03-26 Thread Rob Clark

On Fri, Mar 26, 2021 at 5:33 PM Rob Clark  wrote:
>
> On Fri, Mar 26, 2021 at 4:48 PM Rob Herring  wrote:
> >
> > On Fri, Mar 26, 2021 at 4:13 PM Rob Clark  wrote:
> > >
> > > On Fri, Mar 26, 2021 at 12:48 PM Rob Herring  wrote:
> > > >
> > > > On Fri, Mar 26, 2021 at 9:20 AM Rob Clark  wrote:
> > > > >
> > > > > On Fri, Mar 26, 2021 at 8:18 AM Rob Clark  wrote:
> > > > > >
> > > > > > On Fri, Mar 26, 2021 at 5:38 AM Thierry Reding 
> > > > > >  wrote:
> > > > > > >
> > > > > > > On Wed, Mar 17, 2021 at 06:53:04PM -0700, Rob Clark wrote:
> > > > > > > > On Wed, Mar 17, 2021 at 4:27 PM Matthias Kaehlcke 
> > > > > > > >  wrote:
> > > > > > > > >
> > > > > > > > > On Tue, Mar 16, 2021 at 02:08:19PM -0700, Douglas Anderson 
> > > > > > > > > wrote:
> > > > > > > > > > The sc7180-trogdor-pompom board might be attached to any 
> > > > > > > > > > number of a
> > > > > > > > > > pile of eDP panels. At the moment I'm told that the list 
> > > > > > > > > > might include:
> > > > > > > > > > - KD KD116N21-30NV-A010
> > > > > > > > > > - KD KD116N09-30NH-A016
> > > > > > > > > > - Starry 2081116HHD028001-51D
> > > > > > > > > > - Sharp LQ116M1JW10
> > > > > > > > > >
> > > > > > > > > > It should be noted that while the EDID programmed in the 
> > > > > > > > > > first 3
> > > > > > > > > > panels indicates that they should run with exactly the same 
> > > > > > > > > > timing (to
> > > > > > > > > > keep things simple), the 4th panel not only needs different 
> > > > > > > > > > timing but
> > > > > > > > > > has a different resolution.
> > > > > > > > > >
> > > > > > > > > > As is true in general with eDP panels, we can figure out 
> > > > > > > > > > which panel
> > > > > > > > > > we have and all the info needed to drive its pixel clock by 
> > > > > > > > > > reading
> > > > > > > > > > the EDID. However, we can do this only after we've powered 
> > > > > > > > > > the panel
> > > > > > > > > > on. Powering on the panels requires following the timing 
> > > > > > > > > > diagram in
> > > > > > > > > > each panel's datasheet which specifies delays between 
> > > > > > > > > > certain
> > > > > > > > > > actions. This means that, while we can be quite dynamic 
> > > > > > > > > > about handling
> > > > > > > > > > things we can't just totally skip out on describing the 
> > > > > > > > > > panel like we
> > > > > > > > > > could do if it was connected to an external-facing DP port.
> > > > > > > > > >
> > > > > > > > > > While the different panels have slightly different delays, 
> > > > > > > > > > it's
> > > > > > > > > > possible to come up with a set of unified delays that will 
> > > > > > > > > > work on all
> > > > > > > > > > the panels. From reading the datasheets:
> > > > > > > > > > * KD KD116N21-30NV-A010 and KD KD116N09-30NH-A016
> > > > > > > > > >   - HPD absent delay: 200 ms
> > > > > > > > > >   - Unprepare delay: 150 ms (datasheet is confusing, might 
> > > > > > > > > > be 500 ms)
> > > > > > > > > > * Starry 2081116HHD028001-51D
> > > > > > > > > >   - HPD absent delay: 100 ms
> > > > > > > > > >   - Enable delay: (link training done till enable BL): 200 
> > > > > > > > > > ms
> > > > > > > > > >   - Unprepare delay: 500 ms
> > > > > > > > > > * Sharp LQ116M1JW10
> > > > > > > > > >   - HPD absent delay: 200 ms
> > > > > > > > > >   - Unprepare delay: 500 ms
> > > > > > > > > >   - Prepare to enable delay (power on till backlight): 100 
> > > > > > > > > > ms
> > > > > > > > > >
> > > > > > > > > > Unified:
> > > > > > > > > > - HPD absent delay: 200 ms
> > > > > > > > > > - Unprepare delay: 500 ms
> > > > > > > > > > - Enable delay: 200 ms
> > > > > > > > > >
> > > > > > > > > > NOTE: in theory the only thing that we _really_ need unity 
> > > > > > > > > > on is the
> > > > > > > > > > "HPD absent delay" since once the panel asserts HPD we can 
> > > > > > > > > > read the
> > > > > > > > > > EDID and could make per-panel decisions if we wanted.
> > > > > > > > > >
> > > > > > > > > > Let's create a definition of "a panel that can be attached 
> > > > > > > > > > to pompom"
> > > > > > > > > > as a panel that provides a valid EDID and can work with the 
> > > > > > > > > > standard
> > > > > > > > > > pompom power sequencing. If more panels are later attached 
> > > > > > > > > > to pompom
> > > > > > > > > > then it's fine as long as they work in a compatible way.
> > > > > > > > > >
> > > > > > > > > > One might ask why we can't just use a generic string here 
> > > > > > > > > > and provide
> > > > > > > > > > the timings directly in the device tree file. As I 
> > > > > > > > > > understand it,
> > > > > > > > > > trying to describe generic power sequencing in the device 
> > > > > > > > > > tree is
> > > > > > > > > > frowned upon and the one instance (SD/MMC) is regarded as a 
> > > > > > > > > > mistake
> > > > > > > > > > that shouldn't be repeated. Specifying a power sequence per 
> > > > > > > > > > board (or
> > > > > > > > > > per board class) feels like a reasonable

Re: Linux 4.19.183

2021-03-26 Thread Samuel Zou





On 2021/3/24 18:23, Greg Kroah-Hartman wrote:

I'm announcing the release of the 4.19.183 kernel.

All users of the 4.19 kernel series must upgrade.

The updated 4.19.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.19.y
and can be browsed at the normal kernel.org git web browser:

https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,



Tested on arm64 and x86 for 4.19.183,

Kernel repo:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Branch: linux-4.19.y
Version: 4.19.183
Commit: 78fec1611cbf7b0bdaddfdbf174a3a2463663bff
Compiler: gcc version 7.3.0 (GCC)

arm64:

Testcase Result Summary:
total: 4679
passed: 4679
failed: 0
timeout: 0


x86:

Testcase Result Summary:
total: 4679
passed: 4679
failed: 0
timeout: 0


Tested-by: Hulk Robot

Re: [PATCH 1/4] arm64: expose orig_x0 in the user_pt_regs structure

2021-03-26 Thread Andrei Vagin

On Fri, Mar 26, 2021 at 11:28 AM Catalin Marinas
 wrote:
>
> On Mon, Mar 22, 2021 at 03:50:50PM -0700, Andrei Vagin wrote:
> > diff --git a/arch/arm64/include/uapi/asm/ptrace.h 
> > b/arch/arm64/include/uapi/asm/ptrace.h
> > index 758ae984ff97..3c118c5b0893 100644
> > --- a/arch/arm64/include/uapi/asm/ptrace.h
> > +++ b/arch/arm64/include/uapi/asm/ptrace.h
> > @@ -90,6 +90,7 @@ struct user_pt_regs {
> >   __u64   sp;
> >   __u64   pc;
> >   __u64   pstate;
> > + __u64   orig_x0;
> >  };
>
> That's a UAPI change, likely to go wrong. For example, a
> ptrace(PTRACE_GETREGSET, pid, REGSET_GPR, data) would write past the end
> of an old struct user_pt_regs in the debugger.

ptrace(PTRACE_GETREGSET, ...) receives iovec:
ptrace(PTRACE_GETREGSET, pid, NT_PRSTATUS, )

iov contains a pointer to a buffer and its size and the kernel fills
only the part that fits the buffer.
I think this interface was invented to allow extending structures
without breaking backward compatibility.

>
> --
> Catalin

Re: [RFC PATCH 1/3] dt-bindings: display: simple: Add the panel on sc7180-trogdor-pompom

2021-03-26 Thread Rob Clark

On Fri, Mar 26, 2021 at 4:48 PM Rob Herring  wrote:
>
> On Fri, Mar 26, 2021 at 4:13 PM Rob Clark  wrote:
> >
> > On Fri, Mar 26, 2021 at 12:48 PM Rob Herring  wrote:
> > >
> > > On Fri, Mar 26, 2021 at 9:20 AM Rob Clark  wrote:
> > > >
> > > > On Fri, Mar 26, 2021 at 8:18 AM Rob Clark  wrote:
> > > > >
> > > > > On Fri, Mar 26, 2021 at 5:38 AM Thierry Reding 
> > > > >  wrote:
> > > > > >
> > > > > > On Wed, Mar 17, 2021 at 06:53:04PM -0700, Rob Clark wrote:
> > > > > > > On Wed, Mar 17, 2021 at 4:27 PM Matthias Kaehlcke 
> > > > > > >  wrote:
> > > > > > > >
> > > > > > > > On Tue, Mar 16, 2021 at 02:08:19PM -0700, Douglas Anderson 
> > > > > > > > wrote:
> > > > > > > > > The sc7180-trogdor-pompom board might be attached to any 
> > > > > > > > > number of a
> > > > > > > > > pile of eDP panels. At the moment I'm told that the list 
> > > > > > > > > might include:
> > > > > > > > > - KD KD116N21-30NV-A010
> > > > > > > > > - KD KD116N09-30NH-A016
> > > > > > > > > - Starry 2081116HHD028001-51D
> > > > > > > > > - Sharp LQ116M1JW10
> > > > > > > > >
> > > > > > > > > It should be noted that while the EDID programmed in the 
> > > > > > > > > first 3
> > > > > > > > > panels indicates that they should run with exactly the same 
> > > > > > > > > timing (to
> > > > > > > > > keep things simple), the 4th panel not only needs different 
> > > > > > > > > timing but
> > > > > > > > > has a different resolution.
> > > > > > > > >
> > > > > > > > > As is true in general with eDP panels, we can figure out 
> > > > > > > > > which panel
> > > > > > > > > we have and all the info needed to drive its pixel clock by 
> > > > > > > > > reading
> > > > > > > > > the EDID. However, we can do this only after we've powered 
> > > > > > > > > the panel
> > > > > > > > > on. Powering on the panels requires following the timing 
> > > > > > > > > diagram in
> > > > > > > > > each panel's datasheet which specifies delays between certain
> > > > > > > > > actions. This means that, while we can be quite dynamic about 
> > > > > > > > > handling
> > > > > > > > > things we can't just totally skip out on describing the panel 
> > > > > > > > > like we
> > > > > > > > > could do if it was connected to an external-facing DP port.
> > > > > > > > >
> > > > > > > > > While the different panels have slightly different delays, 
> > > > > > > > > it's
> > > > > > > > > possible to come up with a set of unified delays that will 
> > > > > > > > > work on all
> > > > > > > > > the panels. From reading the datasheets:
> > > > > > > > > * KD KD116N21-30NV-A010 and KD KD116N09-30NH-A016
> > > > > > > > >   - HPD absent delay: 200 ms
> > > > > > > > >   - Unprepare delay: 150 ms (datasheet is confusing, might be 
> > > > > > > > > 500 ms)
> > > > > > > > > * Starry 2081116HHD028001-51D
> > > > > > > > >   - HPD absent delay: 100 ms
> > > > > > > > >   - Enable delay: (link training done till enable BL): 200 ms
> > > > > > > > >   - Unprepare delay: 500 ms
> > > > > > > > > * Sharp LQ116M1JW10
> > > > > > > > >   - HPD absent delay: 200 ms
> > > > > > > > >   - Unprepare delay: 500 ms
> > > > > > > > >   - Prepare to enable delay (power on till backlight): 100 ms
> > > > > > > > >
> > > > > > > > > Unified:
> > > > > > > > > - HPD absent delay: 200 ms
> > > > > > > > > - Unprepare delay: 500 ms
> > > > > > > > > - Enable delay: 200 ms
> > > > > > > > >
> > > > > > > > > NOTE: in theory the only thing that we _really_ need unity on 
> > > > > > > > > is the
> > > > > > > > > "HPD absent delay" since once the panel asserts HPD we can 
> > > > > > > > > read the
> > > > > > > > > EDID and could make per-panel decisions if we wanted.
> > > > > > > > >
> > > > > > > > > Let's create a definition of "a panel that can be attached to 
> > > > > > > > > pompom"
> > > > > > > > > as a panel that provides a valid EDID and can work with the 
> > > > > > > > > standard
> > > > > > > > > pompom power sequencing. If more panels are later attached to 
> > > > > > > > > pompom
> > > > > > > > > then it's fine as long as they work in a compatible way.
> > > > > > > > >
> > > > > > > > > One might ask why we can't just use a generic string here and 
> > > > > > > > > provide
> > > > > > > > > the timings directly in the device tree file. As I understand 
> > > > > > > > > it,
> > > > > > > > > trying to describe generic power sequencing in the device 
> > > > > > > > > tree is
> > > > > > > > > frowned upon and the one instance (SD/MMC) is regarded as a 
> > > > > > > > > mistake
> > > > > > > > > that shouldn't be repeated. Specifying a power sequence per 
> > > > > > > > > board (or
> > > > > > > > > per board class) feels like a reasonable compromise. We're 
> > > > > > > > > not trying
> > > > > > > > > to define fully generic power sequence bindings but we can 
> > > > > > > > > also take
> > > > > > > > > advantage of the semi-probable properties of the attached 
> > > > > > > > > device.
> > > > > > > > >
> > > > > > > > > NOTE: I believe that past

[PATCH v1 1/1] x86/tdx: Handle MWAIT, MONITOR and WBINVD

2021-03-26 Thread Kuppuswamy Sathyanarayanan

In non-root TDX guest mode, MWAIT, MONITOR and WBINVD instructions
are not supported. So handle #VE due to these instructions as no ops.

Signed-off-by: Kuppuswamy Sathyanarayanan 

Reviewed-by: Andi Kleen 
---

Changes since previous series:
 * Suppressed MWAIT feature as per Andi's comment.
 * Added warning debug log for MWAIT #VE exception.

 arch/x86/kernel/tdx.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/arch/x86/kernel/tdx.c b/arch/x86/kernel/tdx.c
index e936b2f88bf6..fb7d22b846fc 100644
--- a/arch/x86/kernel/tdx.c
+++ b/arch/x86/kernel/tdx.c
@@ -308,6 +308,9 @@ void __init tdx_early_init(void)
 
setup_force_cpu_cap(X86_FEATURE_TDX_GUEST);
 
+   /* MWAIT is not supported in TDX platform, so suppress it */
+   setup_clear_cpu_cap(X86_FEATURE_MWAIT);
+
tdg_get_info();
 
pv_ops.irq.safe_halt = tdg_safe_halt;
@@ -362,6 +365,26 @@ int tdg_handle_virtualization_exception(struct pt_regs 
*regs,
case EXIT_REASON_EPT_VIOLATION:
ve->instr_len = tdg_handle_mmio(regs, ve);
break;
+   /*
+* Per Guest-Host-Communication Interface (GHCI) for Intel Trust
+* Domain Extensions (Intel TDX) specification, sec 2.4,
+* some instructions that unconditionally cause #VE (such as WBINVD,
+* MONITOR, MWAIT) do not have corresponding TDCALL
+* [TDG.VP.VMCALL ] leaves, since the TD has been designed
+* with no deterministic way to confirm the result of those operations
+* performed by the host VMM.  In those cases, the goal is for the TD
+* #VE handler to increment the RIP appropriately based on the VE
+* information provided via TDCALL.
+*/
+   case EXIT_REASON_WBINVD:
+   pr_warn_once("WBINVD #VE Exception\n");
+   case EXIT_REASON_MONITOR_INSTRUCTION:
+   /* Handle as nops. */
+   break;
+   case EXIT_REASON_MWAIT_INSTRUCTION:
+   /* MWAIT is supressed, not supposed to reach here. */
+   pr_warn("MWAIT unexpected #VE Exception\n");
+   return -EFAULT;
default:
pr_warn("Unexpected #VE: %d\n", ve->exit_reason);
return -EFAULT;
-- 
2.25.1

Re: [PATCH] PCI: Disallow retraining link for Atheros QCA98xx chips on non-Gen1 PCIe bridges

2021-03-26 Thread Krzysztof Wilczyński

Hi Pali,

Thank you for sending the patch over!

[...]
> +static int pcie_change_tls_to_gen1(struct pci_dev *parent)

Just a nitpick, so feel free to ignore it.  I would just call the
variable "dev" as we pass a pointer to a particular device, but it does
not matter as much, so I am leaving this to you.

[...]
> + if (ret == 0) {

You prefer this style over "if (!ret)"?  Just asking in the view of the
style that seem to be preferred in the code base at the moment.

> + /* Verify that new value was really set */
> + pcie_capability_read_word(parent, PCI_EXP_LNKCTL2, );
> + if ((reg16 & PCI_EXP_LNKCTL2_TLS) != PCI_EXP_LNKCTL2_TLS_2_5GT)
> + ret = -EINVAL;

I am wondering about this verification - did you have a case where the
device would not properly set its capability, or accept the write and do
nothing?

> + if (ret != 0)

I think "if (ret)" would be fine to use here, unless you prefer being
more explicit.  See my question about style above.

>  static bool pcie_retrain_link(struct pcie_link_state *link)
>  {
>   struct pci_dev *parent = link->pdev;
>   unsigned long end_jiffies;
>   u16 reg16;
> + u32 reg32;
> +
> + /* Check if link is capable of higher speed than 2.5 GT/s and 
> needs quirk */
> + pcie_capability_read_dword(parent, PCI_EXP_LNKCAP, );
> + if ((reg32 & PCI_EXP_LNKCAP_SLS) > PCI_EXP_LNKCAP_SLS_2_5GB) {

I wonder if moving this check to pcie_change_tls_to_gen1() would make
more sense?  It would then make this function a little cleaner.  What do
you think?

[...]
> +static void quirk_no_bus_reset_and_no_retrain_link(struct pci_dev *dev)
> +{
> + dev->dev_flags |= PCI_DEV_FLAGS_NO_BUS_RESET | 
> PCI_DEV_FLAGS_NO_RETRAIN_LINK_WHEN_NOT_GEN1;
> +}
[...]

I know that the style has been changed to allow 100 characters width and
that checkpatch.pl now also does not warn about line length, as per
commit bdc48fa11e46 ("checkpatch/coding-style: deprecate 80-column
warning"), but I think Bjorn still prefers 80 characters, thus this line
above might have to be aligned.

Krzysztof

Re: [PATCH resend 2/8] sched: core scheduling tagging infrastructure

2021-03-26 Thread Peter Zijlstra

On Wed, Mar 24, 2021 at 05:40:14PM -0400, Joel Fernandes (Google) wrote:
> From: Josh Don 
> 
> A single unsigned long is insufficient as a cookie value for core
> scheduling. We will minimally have cookie values for a per-task and a
> per-group interface, which must be combined into an overall cookie.
> 
> This patch adds the infrastructure necessary for setting task and group
> cookie. Namely, it reworks the core_cookie into a struct, and provides
> interfaces for setting task and group cookie, as well as other
> operations (i.e. compare()). Subsequent patches will use these hooks to
> provide an API for setting these cookies.
> 

*urgh*... so I specifically wanted the task interface first to avoid /
get-rid of all this madness. And then you keep it :-(

I've spend the past few hours rewriting patches #2 and #3, and adapting
#4. The thing was working before I added SHARE_FROM back and introduced
GET, but now I'm seeing a few FAILs from the selftest.

I'm too tired to make sense of anything much, or even focus my eyes
consistently, so I'll have to prod at it some more next week, but I've
pushed out the lot to my queue.git:

  
https://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git/log/?h=sched/core-sched

Also, we really need a better name than coretag.c.

[PATCH v2 1/3] drm/nouveau: Use helper to convert nouveau_drm to drm_device

2021-03-26 Thread Lyude Paul

From: Jeremy Cline 

In order to use the resource-managed allocation of a struct drm_device
instance, it is recommended to embed the drm_device instance within the
driver-specific structure.

As there is already a helper to convert a drm_device to a nouveau_drm
struct, this adds an inverse function and changes all direct references
to the pointer within nouveau_drm to use the function. It also adds a
helper to convert directly to a generic device structure.

This allows us to switch from maintaining a pointer in nouveau_drm to
embedding the structure by simply altering the helper function
implementations.

This patch should introduce no functional changes.

Signed-off-by: Jeremy Cline 
Reviewed-by: Lyude Paul 
Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/nouveau/dispnv04/crtc.c | 10 +++---
 drivers/gpu/drm/nouveau/dispnv50/base.c |  2 +-
 drivers/gpu/drm/nouveau/dispnv50/base507c.c |  7 ++--
 drivers/gpu/drm/nouveau/dispnv50/core.c |  2 +-
 drivers/gpu/drm/nouveau/dispnv50/core507d.c |  2 +-
 drivers/gpu/drm/nouveau/dispnv50/curs.c |  2 +-
 drivers/gpu/drm/nouveau/dispnv50/curs507a.c |  5 +--
 drivers/gpu/drm/nouveau/dispnv50/disp.c | 16 +
 drivers/gpu/drm/nouveau/dispnv50/oimm.c |  2 +-
 drivers/gpu/drm/nouveau/dispnv50/oimm507b.c |  2 +-
 drivers/gpu/drm/nouveau/dispnv50/ovly.c |  2 +-
 drivers/gpu/drm/nouveau/dispnv50/ovly507e.c |  5 +--
 drivers/gpu/drm/nouveau/dispnv50/wimm.c |  2 +-
 drivers/gpu/drm/nouveau/dispnv50/wimmc37b.c |  2 +-
 drivers/gpu/drm/nouveau/dispnv50/wndw.c |  2 +-
 drivers/gpu/drm/nouveau/dispnv50/wndwc37e.c |  5 +--
 drivers/gpu/drm/nouveau/nouveau_bo.c| 14 
 drivers/gpu/drm/nouveau/nouveau_debugfs.c   |  9 +++---
 drivers/gpu/drm/nouveau/nouveau_display.c   | 16 -
 drivers/gpu/drm/nouveau/nouveau_dmem.c  | 17 +-
 drivers/gpu/drm/nouveau/nouveau_drm.c   |  2 +-
 drivers/gpu/drm/nouveau/nouveau_drv.h   | 36 -
 drivers/gpu/drm/nouveau/nouveau_fbcon.c | 19 +--
 drivers/gpu/drm/nouveau/nouveau_gem.c   |  8 ++---
 drivers/gpu/drm/nouveau/nouveau_svm.c   |  4 +--
 drivers/gpu/drm/nouveau/nouveau_ttm.c   | 10 +++---
 drivers/gpu/drm/nouveau/nouveau_vga.c   |  8 ++---
 27 files changed, 128 insertions(+), 83 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c 
b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
index f9e962fd94d0..3e1b00f3086e 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
@@ -915,7 +915,7 @@ nv04_crtc_mode_set_base_atomic(struct drm_crtc *crtc,
   int x, int y, enum mode_set_atomic state)
 {
struct nouveau_drm *drm = nouveau_drm(crtc->dev);
-   struct drm_device *dev = drm->dev;
+   struct drm_device *dev = nouveau_to_drm_dev(drm);
 
if (state == ENTER_ATOMIC_MODE_SET)
nouveau_fbcon_accel_save_disable(dev);
@@ -990,7 +990,7 @@ nv04_crtc_cursor_set(struct drm_crtc *crtc, struct drm_file 
*file_priv,
 uint32_t buffer_handle, uint32_t width, uint32_t height)
 {
struct nouveau_drm *drm = nouveau_drm(crtc->dev);
-   struct drm_device *dev = drm->dev;
+   struct drm_device *dev = nouveau_to_drm_dev(drm);
struct nouveau_crtc *nv_crtc = nouveau_crtc(crtc);
struct nouveau_bo *cursor = NULL;
struct drm_gem_object *gem;
@@ -1050,7 +1050,7 @@ nv04_finish_page_flip(struct nouveau_channel *chan,
 {
struct nouveau_fence_chan *fctx = chan->fence;
struct nouveau_drm *drm = chan->drm;
-   struct drm_device *dev = drm->dev;
+   struct drm_device *dev = nouveau_to_drm_dev(drm);
struct nv04_page_flip_state *s;
unsigned long flags;
 
@@ -1088,7 +1088,7 @@ nv04_flip_complete(struct nvif_notify *notify)
struct nv04_page_flip_state state;
 
if (!nv04_finish_page_flip(chan, )) {
-   nv_set_crtc_base(drm->dev, drm_crtc_index(state.crtc),
+   nv_set_crtc_base(nouveau_to_drm_dev(drm), 
drm_crtc_index(state.crtc),
 state.offset + state.crtc->y *
 state.pitch + state.crtc->x *
 state.bpp / 8);
@@ -1106,7 +1106,7 @@ nv04_page_flip_emit(struct nouveau_channel *chan,
 {
struct nouveau_fence_chan *fctx = chan->fence;
struct nouveau_drm *drm = chan->drm;
-   struct drm_device *dev = drm->dev;
+   struct drm_device *dev = nouveau_to_drm_dev(drm);
struct nvif_push *push = chan->chan.push;
unsigned long flags;
int ret;
diff --git a/drivers/gpu/drm/nouveau/dispnv50/base.c 
b/drivers/gpu/drm/nouveau/dispnv50/base.c
index 7c752acf2b48..cd70456dd37f 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/base.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/base.c
@@ -40,7 +40,7 @@ nv50_base_new(struct nouveau_drm *drm, int head, struct 
nv50_wndw **pwndw)
{

[PATCH v2 3/3] drm/nouveau: begin documenting core nouveau structures

2021-03-26 Thread Lyude Paul

From: Jeremy Cline 

Start on documentation for the Nouveau device structure and the NVIF
client structure it uses. This documentation is not complete as the
structures are non-trivial and I am not familiar with large portions of
them.

Signed-off-by: Jeremy Cline 
Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/nouveau/nouveau_drv.h | 67 +++
 1 file changed, 67 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h 
b/drivers/gpu/drm/nouveau/nouveau_drv.h
index 8eb133fd6df0..43d751d2445f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
@@ -88,8 +88,20 @@ enum nouveau_drm_handle {
NVDRM_NVSW= 0x,
 };
 
+/**
+ * struct nouveau_cli - A DRM-specific NVIF client.
+ *
+ * This encapsulates a NVIF client and is intended to be the sole interface
+ * between the DRM APIs and NVKM. An instance of this structure is allocated
+ * for each userspace client when they open the device file. Additionally,
+ * there are several allocated strictly for the kernel's use.
+ */
 struct nouveau_cli {
struct nvif_client base;
+
+   /**
+* @drm: A reference to the device that the client is associated with.
+*/
struct nouveau_drm *drm;
struct mutex mutex;
 
@@ -99,6 +111,9 @@ struct nouveau_cli {
struct nouveau_vmm svm;
const struct nvif_mclass *mem;
 
+   /**
+* @head: The list entry for this client in the @drm device's list of 
clients.
+*/
struct list_head head;
void *abi16;
struct list_head objects;
@@ -106,13 +121,36 @@ struct nouveau_cli {
char name[32];
 
struct work_struct work;
+
+   /**
+* @worker: List of pending  nouveau_cli_work associated with 
this client.
+*/
struct list_head worker;
+
+   /**
+* @lock: Protects the @worker list. Additionally, this lock on the
+* @drm.master instance is used to serialize destruction of the @base
+* member in this structure, as well as the destruction of the 
+* nvif_mem embedded in  nouveau_mem instances.
+*/
struct mutex lock;
 };
 
+/**
+ * struct nouveau_cli_work - A pending work item for an NVIF client.
+ */
 struct nouveau_cli_work {
void (*func)(struct nouveau_cli_work *);
+
+   /**
+* @cli: Reference to the NVIF client this work belongs to.
+*/
struct nouveau_cli *cli;
+
+   /**
+* @head: The list entry for this work item in the  nouveau_cli
+* worker list.
+*/
struct list_head head;
 
struct dma_fence *fence;
@@ -131,9 +169,32 @@ nouveau_cli(struct drm_file *fpriv)
 #include 
 #include 
 
+/**
+ * struct nouveau_drm - The nouveau-specific device structure.
+ *
+ * This structure is allocated for a device when it is probed and keeps track
+ * of all the nouveau-specific device details. The lifetime of this structure
+ * is the same as the lifetime of a  drm_device and is managed by the
+ * DRM layer.
+ */
 struct nouveau_drm {
+   /**
+* @parent: Implementation of the interface required to use the 
NVIF_DEBUG
+* and NVIF_ERROR macros
+*/
struct nvif_parent parent;
+
+   /**
+* @master: This NVIF client is used to initialize the NVIF driver and 
used
+* for TTM memory allocations. It is the root of the NVIF object tree.
+*/
struct nouveau_cli master;
+
+   /**
+* @client: This NVIF client is used by the DRM layer to interact with
+* the NVKM layer for everything except TTM memory allocations. It, and
+* all other clients, are children of the primary (@master) client.
+*/
struct nouveau_cli client;
 
/**
@@ -141,6 +202,12 @@ struct nouveau_drm {
 */
struct drm_device drm_dev;
 
+   /**
+* @clients: List of all  nouveau_cli allocated for userspace
+* associated with this DRM device. Clients are allocated when the DRM
+* file is opened and deallocated when the file is closed. This list is
+* protected by the mutex in @client.
+*/
struct list_head clients;
 
u8 old_pm_cap;
-- 
2.30.2

[PATCH v2 2/3] drm/nouveau: manage nouveau_drm lifetime with devres

2021-03-26 Thread Lyude Paul

From: Jeremy Cline 

Make use of the devm_drm_dev_alloc() API to bind the lifetime of
nouveau_drm structure to the drm_device. This is important because a
reference to nouveau_drm is accessible from drm_device, which is
provided to a number of DRM layer callbacks that can run after the
deallocation of nouveau_drm currently occurs.

Signed-off-by: Jeremy Cline 
Reviewed-by: Lyude Paul 
Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/nouveau/nouveau_drm.c | 44 ---
 drivers/gpu/drm/nouveau/nouveau_drv.h | 10 --
 2 files changed, 26 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index bce1abea0d58..1285631c6797 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -30,9 +30,11 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -532,13 +534,8 @@ nouveau_parent = {
 static int
 nouveau_drm_device_init(struct drm_device *dev)
 {
-   struct nouveau_drm *drm;
int ret;
-
-   if (!(drm = kzalloc(sizeof(*drm), GFP_KERNEL)))
-   return -ENOMEM;
-   dev->dev_private = drm;
-   drm->dev = dev;
+   struct nouveau_drm *drm = nouveau_drm(dev);
 
nvif_parent_ctor(_parent, >parent);
drm->master.base.object.parent = >parent;
@@ -620,7 +617,6 @@ nouveau_drm_device_init(struct drm_device *dev)
nouveau_cli_fini(>master);
 fail_alloc:
nvif_parent_dtor(>parent);
-   kfree(drm);
return ret;
 }
 
@@ -654,7 +650,6 @@ nouveau_drm_device_fini(struct drm_device *dev)
nouveau_cli_fini(>client);
nouveau_cli_fini(>master);
nvif_parent_dtor(>parent);
-   kfree(drm);
 }
 
 /*
@@ -720,6 +715,7 @@ static int nouveau_drm_probe(struct pci_dev *pdev,
 {
struct nvkm_device *device;
struct drm_device *drm_dev;
+   struct nouveau_drm *nv_dev;
int ret;
 
if (vga_switcheroo_client_probe_defer(pdev))
@@ -750,15 +746,16 @@ static int nouveau_drm_probe(struct pci_dev *pdev,
if (nouveau_atomic)
driver_pci.driver_features |= DRIVER_ATOMIC;
 
-   drm_dev = drm_dev_alloc(_pci, >dev);
-   if (IS_ERR(drm_dev)) {
-   ret = PTR_ERR(drm_dev);
+   nv_dev = devm_drm_dev_alloc(>dev, _stub, typeof(*nv_dev), 
drm_dev);
+   if (IS_ERR(nv_dev)) {
+   ret = PTR_ERR(nv_dev);
goto fail_nvkm;
}
+   drm_dev = nouveau_to_drm_dev(nv_dev);
 
ret = pci_enable_device(pdev);
if (ret)
-   goto fail_drm;
+   goto fail_nvkm;
 
pci_set_drvdata(pdev, drm_dev);
 
@@ -777,8 +774,6 @@ static int nouveau_drm_probe(struct pci_dev *pdev,
nouveau_drm_device_fini(drm_dev);
 fail_pci:
pci_disable_device(pdev);
-fail_drm:
-   drm_dev_put(drm_dev);
 fail_nvkm:
nvkm_device_del();
return ret;
@@ -798,7 +793,6 @@ nouveau_drm_device_remove(struct drm_device *dev)
device = nvkm_device_find(client->device);
 
nouveau_drm_device_fini(dev);
-   drm_dev_put(dev);
nvkm_device_del();
 }
 
@@ -1284,7 +1278,8 @@ nouveau_platform_device_create(const struct 
nvkm_device_tegra_func *func,
   struct platform_device *pdev,
   struct nvkm_device **pdevice)
 {
-   struct drm_device *drm;
+   struct nouveau_drm *nv_dev;
+   struct drm_device *drm_dev;
int err;
 
err = nvkm_device_tegra_new(func, pdev, nouveau_config, nouveau_debug,
@@ -1292,22 +1287,21 @@ nouveau_platform_device_create(const struct 
nvkm_device_tegra_func *func,
if (err)
goto err_free;
 
-   drm = drm_dev_alloc(_platform, >dev);
-   if (IS_ERR(drm)) {
-   err = PTR_ERR(drm);
+   nv_dev = devm_drm_dev_alloc(>dev, _platform, 
typeof(*nv_dev), drm_dev);
+   if (IS_ERR(nv_dev)) {
+   err = PTR_ERR(nv_dev);
goto err_free;
}
+   drm_dev = nouveau_to_drm_dev(nv_dev);
 
-   err = nouveau_drm_device_init(drm);
+   err = nouveau_drm_device_init(drm_dev);
if (err)
-   goto err_put;
+   goto err_free;
 
-   platform_set_drvdata(pdev, drm);
+   platform_set_drvdata(pdev, drm_dev);
 
-   return drm;
+   return drm_dev;
 
-err_put:
-   drm_dev_put(drm);
 err_free:
nvkm_device_del(pdevice);
 
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h 
b/drivers/gpu/drm/nouveau/nouveau_drv.h
index 526e110b52ac..8eb133fd6df0 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
@@ -135,7 +135,11 @@ struct nouveau_drm {
struct nvif_parent parent;
struct nouveau_cli master;
struct nouveau_cli client;
-   struct drm_device *dev;
+
+   /**
+* @drm_dev: The parent DRM device object.
+*/
+   struct

Re: [PATCH] riscv: Use $(LD) instead of $(CC) to link vDSO

2021-03-26 Thread Nathan Chancellor

On Sat, Mar 27, 2021 at 12:05:34AM +0800, kernel test robot wrote:
> Hi Nathan,
> 
> I love your patch! Yet something to improve:
> 
> [auto build test ERROR on linus/master]
> [also build test ERROR on v5.12-rc4 next-20210326]
> [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/Nathan-Chancellor/riscv-Use-LD-instead-of-CC-to-link-vDSO/20210326-055421
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
> 002322402dafd846c424ffa9240a937f49b48c42
> config: riscv-randconfig-r032-20210326 (attached as .config)
> compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 
> f490a5969bd52c8a48586f134ff8f02ccbb295b3)
> 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 riscv cross compiling tool for clang build
> # apt-get install binutils-riscv64-linux-gnu
> # 
> https://github.com/0day-ci/linux/commit/dfdcaf93f40f0d15ffc3f25128442c1688e612d6
> git remote add linux-review https://github.com/0day-ci/linux
> git fetch --no-tags linux-review 
> Nathan-Chancellor/riscv-Use-LD-instead-of-CC-to-link-vDSO/20210326-055421
> git checkout dfdcaf93f40f0d15ffc3f25128442c1688e612d6
> # save the attached .config to linux build tree
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=riscv 

For the record, I tried to use this script to reproduce but it has a
couple of bugs:

1. It does not download the right version of clang. This report says
that it is clang-13 but the one that the script downloaded is clang-12.

2. It does not download it to the right location. The script expects
~/0day/clang-latest but it is downloaded to ~/0day/clang it seems. I
symlinked it to get around it.

> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot 
> 
> All errors (new ones prefixed by >>):
> 
> >> riscv64-linux-gnu-objcopy: 'arch/riscv/kernel/vdso/vdso.so.dbg': No such 
> >> file

This error only occurs because of errors before it that are not shown
due to a denylist:

ld.lld: error: arch/riscv/kernel/vdso/rt_sigreturn.o:(.text+0x0): relocation 
R_RISCV_ALIGN requires unimplemented linker relaxation; recompile with 
-mno-relax
ld.lld: error: arch/riscv/kernel/vdso/getcpu.o:(.text+0x0): relocation 
R_RISCV_ALIGN requires unimplemented linker relaxation; recompile with 
-mno-relax
ld.lld: error: arch/riscv/kernel/vdso/flush_icache.o:(.text+0x0): relocation 
R_RISCV_ALIGN requires unimplemented linker relaxation; recompile with 
-mno-relax

My patch only adds another occurrence of this error because we move from
$(CC)'s default linker (in clang's case, ld.bfd) to $(LD), which in the
case of 0day appears to be ld.lld. ld.lld should not be used with RISC-V
in its current form due to errors of this nature, which happen without
my patch as well:

https://github.com/ClangBuiltLinux/linux/issues/1020

Linker relaxation in ld.lld for RISC-V is an ongoing debate/process.
Please give RISC-V the current treatment as s390 with ld.lld for the
time being to get meaningful reports. We will reach out once that issue
has been resolved.

TL;DR: Patch exposes existing issue with LD=ld.lld that would have
happened without it in different areas, the report can be ignored.

Cheers!
Nathan

RE: [PATCH] net: intel: Remove unused function pointer typedef ixgbe_mc_addr_itr

2021-03-26 Thread Switzer, David




>-Original Message-
>From: Chen Lin 
>Sent: Monday, February 15, 2021 4:05 AM
>To: da...@davemloft.net; k...@kernel.org
>Cc: Brandeburg, Jesse ; Nguyen, Anthony L
>; intel-wired-...@lists.osuosl.org;
>net...@vger.kernel.org; linux-kernel@vger.kernel.org; Chen Lin
>
>Subject: [PATCH] net: intel: Remove unused function pointer typedef
>ixgbe_mc_addr_itr
>
>From: Chen Lin 
>
>Remove the 'ixgbe_mc_addr_itr' typedef as it is not used.
>
>Signed-off-by: Chen Lin 
>---
> drivers/net/ethernet/intel/ixgbe/ixgbe_type.h |4 
> drivers/net/ethernet/intel/ixgbevf/vf.h   |3 ---
> 2 files changed, 7 deletions(-)
>
Tested-by: Dave Switzer

Re: [PATCH bpf-next 2/5] libbpf: add helpers for preparing netlink attributes

2021-03-26 Thread Andrii Nakryiko

On Thu, Mar 25, 2021 at 5:01 AM Kumar Kartikeya Dwivedi
 wrote:
>
> This change introduces a few helpers to wrap open coded attribute
> preparation in netlink.c.
>
> Every nested attribute's closure must happen using the helper
> end_nlattr_nested, which sets its length properly. NLA_F_NESTED is
> enforeced using begin_nlattr_nested helper. Other simple attributes
> can be added directly.
>
> The maxsz parameter corresponds to the size of the request structure
> which is being filled in, so for instance with req being:
>
> struct {
> struct nlmsghdr nh;
> struct tcmsg t;
> char buf[4096];
> } req;
>
> Then, maxsz should be sizeof(req).
>
> This change also converts the open coded attribute preparation with the
> helpers. Note that the only failure the internal call to add_nlattr
> could result in the nested helper would be -EMSGSIZE, hence that is what
> we return to our caller.
>
> Reviewed-by: Toke Høiland-Jørgensen 
> Signed-off-by: Kumar Kartikeya Dwivedi 
> ---
>  tools/lib/bpf/netlink.c | 37 +++
>  tools/lib/bpf/nlattr.h  | 43 +
>  2 files changed, 59 insertions(+), 21 deletions(-)
>
> diff --git a/tools/lib/bpf/netlink.c b/tools/lib/bpf/netlink.c
> index 4dd73de00b6f..f448c29de76d 100644
> --- a/tools/lib/bpf/netlink.c
> +++ b/tools/lib/bpf/netlink.c
> @@ -135,7 +135,7 @@ static int __bpf_set_link_xdp_fd_replace(int ifindex, int 
> fd, int old_fd,
>  __u32 flags)
>  {
> int sock, seq = 0, ret;
> -   struct nlattr *nla, *nla_xdp;
> +   struct nlattr *nla;
> struct {
> struct nlmsghdr  nh;
> struct ifinfomsg ifinfo;
> @@ -157,36 +157,31 @@ static int __bpf_set_link_xdp_fd_replace(int ifindex, 
> int fd, int old_fd,
> req.ifinfo.ifi_index = ifindex;
>
> /* started nested attribute for XDP */
> -   nla = (struct nlattr *)(((char *))
> -   + NLMSG_ALIGN(req.nh.nlmsg_len));
> -   nla->nla_type = NLA_F_NESTED | IFLA_XDP;
> -   nla->nla_len = NLA_HDRLEN;
> +   nla = begin_nlattr_nested(, sizeof(req), IFLA_XDP);
> +   if (!nla) {
> +   ret = -EMSGSIZE;
> +   goto cleanup;
> +   }
>
> /* add XDP fd */
> -   nla_xdp = (struct nlattr *)((char *)nla + nla->nla_len);
> -   nla_xdp->nla_type = IFLA_XDP_FD;
> -   nla_xdp->nla_len = NLA_HDRLEN + sizeof(int);
> -   memcpy((char *)nla_xdp + NLA_HDRLEN, , sizeof(fd));
> -   nla->nla_len += nla_xdp->nla_len;
> +   ret = add_nlattr(, sizeof(req), IFLA_XDP_FD, , sizeof(fd));
> +   if (ret < 0)
> +   goto cleanup;
>
> /* if user passed in any flags, add those too */
> if (flags) {
> -   nla_xdp = (struct nlattr *)((char *)nla + nla->nla_len);
> -   nla_xdp->nla_type = IFLA_XDP_FLAGS;
> -   nla_xdp->nla_len = NLA_HDRLEN + sizeof(flags);
> -   memcpy((char *)nla_xdp + NLA_HDRLEN, , sizeof(flags));
> -   nla->nla_len += nla_xdp->nla_len;
> +   ret = add_nlattr(, sizeof(req), IFLA_XDP_FLAGS, 
> , sizeof(flags));
> +   if (ret < 0)
> +   goto cleanup;
> }
>
> if (flags & XDP_FLAGS_REPLACE) {
> -   nla_xdp = (struct nlattr *)((char *)nla + nla->nla_len);
> -   nla_xdp->nla_type = IFLA_XDP_EXPECTED_FD;
> -   nla_xdp->nla_len = NLA_HDRLEN + sizeof(old_fd);
> -   memcpy((char *)nla_xdp + NLA_HDRLEN, _fd, sizeof(old_fd));
> -   nla->nla_len += nla_xdp->nla_len;
> +   ret = add_nlattr(, sizeof(req), IFLA_XDP_EXPECTED_FD, 
> , sizeof(flags));
> +   if (ret < 0)
> +   goto cleanup;
> }
>
> -   req.nh.nlmsg_len += NLA_ALIGN(nla->nla_len);
> +   end_nlattr_nested(, nla);
>
> if (send(sock, , req.nh.nlmsg_len, 0) < 0) {
> ret = -errno;
> diff --git a/tools/lib/bpf/nlattr.h b/tools/lib/bpf/nlattr.h
> index 6cc3ac91690f..463a53bf3022 100644
> --- a/tools/lib/bpf/nlattr.h
> +++ b/tools/lib/bpf/nlattr.h
> @@ -10,7 +10,10 @@
>  #define __LIBBPF_NLATTR_H
>
>  #include 
> +#include 
> +#include 
>  #include 
> +
>  /* avoid multiple definition of netlink features */
>  #define __LINUX_NETLINK_H
>
> @@ -103,4 +106,44 @@ int libbpf_nla_parse_nested(struct nlattr *tb[], int 
> maxtype,
>
>  int libbpf_nla_dump_errormsg(struct nlmsghdr *nlh);
>
> +
> +/* Helpers for preparing/consuming attributes */
> +
> +#define NLA_DATA(nla) ((struct nlattr *)((char *)(nla) + NLA_HDRLEN))

`((char *)nh + NLMSG_ALIGN(nh->nlmsg_len))` seems to be another
popular one (three occurrences in this file), maybe extract that one
as well?

And can you please use functions, not macros? This way you can specify
what types you expect, as one of the benefits.

> +
> +static inline int add_nlattr(struct nlmsghdr *nh, size_t

xilinx_emaclite.c:undefined reference to `devm_ioremap_resource'

2021-03-26 Thread kernel test robot

Hi Gary,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   0f4498cef9f5cd18d7c6639a2a902ec1edc5be4e
commit: 18af77c50fede5b3fc22aa9f0a9b255a5c5285c9 drivers: net: xilinx_emaclite: 
remove arch limitation
date:   5 weeks ago
config: um-randconfig-r001-20210327 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
# 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=18af77c50fede5b3fc22aa9f0a9b255a5c5285c9
git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 18af77c50fede5b3fc22aa9f0a9b255a5c5285c9
# save the attached .config to linux build tree
make W=1 ARCH=um 

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

All errors (new ones prefixed by >>):

   /usr/bin/ld: drivers/net/ethernet/xilinx/xilinx_emaclite.o: in function 
`xemaclite_of_probe':
>> xilinx_emaclite.c:(.text.unlikely+0x2da): undefined reference to 
>> `devm_ioremap_resource'
   collect2: error: ld returned 1 exit status

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


.config.gz
Description: application/gzip

Re: [PATCH -tip v5 00/12] kprobes: Fix stacktrace with kretprobes on x86

2021-03-26 Thread Masami Hiramatsu

On Fri, 26 Mar 2021 21:28:26 +0900
Masami Hiramatsu  wrote:

> Hello,
> 
> Here is the 5th version of the series to fix the stacktrace with kretprobe
> on x86. After merging this, I'll fix other architectures.
> 
> The previous version is;
> 
> https://lore.kernel.org/bpf/161639518354.895304.15627519393073806809.stgit@devnote2/
> 
> This version fixes a build error from a typo in [1/12] and the
> case of interrupt happens on kretprobe_trampoline+0 in [11/12].
> 
> With this series, unwinder can unwind stack correctly from ftrace as below;
> 
>   # cd /sys/kernel/debug/tracing
>   # echo > trace
>   # echo r vfs_read >> kprobe_events
>   # echo r full_proxy_read >> kprobe_events
>   # echo traceoff:1 > events/kprobes/r_vfs_read_0/trigger
>   # echo stacktrace:1 > events/kprobes/r_full_proxy_read_0/trigger
>   # echo 1 > events/kprobes/enable
>   # echo 1 > options/sym-offset
>   # cat /sys/kernel/debug/kprobes/list
> 8133b740  r  full_proxy_read+0x0[FTRACE]
> 812560b0  r  vfs_read+0x0[FTRACE]
>   # echo 0 > events/kprobes/enable
>   # cat trace
> # tracer: nop
> #
> # entries-in-buffer/entries-written: 3/3   #P:8
> #
> #_-=> irqs-off
> #   / _=> need-resched
> #  | / _---=> hardirq/softirq
> #  || / _--=> preempt-depth
> #  ||| / delay
> #   TASK-PID CPU#     TIMESTAMP  FUNCTION
> #  | | |     | |
><...>-135 [005] ...1 9.422114: r_full_proxy_read_0: 
> (vfs_read+0xab/0x1a0 <- full_proxy_read)
><...>-135 [005] ...1 9.422158: 
>  => kretprobe_trace_func+0x209/0x2f0
>  => kretprobe_dispatcher+0x4a/0x70
>  => __kretprobe_trampoline_handler+0xca/0x150
>  => trampoline_handler+0x44/0x70
>  => kretprobe_trampoline+0x2a/0x50
>  => vfs_read+0xab/0x1a0
>  => ksys_read+0x5f/0xe0
>  => do_syscall_64+0x33/0x40
>  => entry_SYSCALL_64_after_hwframe+0x44/0xae
>  => 0
> 
> This shows the double return probes (vfs_read and full_proxy_read) on the 
> stack
> correctly unwinded. (vfs_read was called from ksys_read+0x5f and 
> full_proxy_read
> was called from vfs_read+0xab)

BTW, this is only for the kretprobe on x86. ORC unwinder (without pt_regs)
still stopped when the kprobe is optimized.


# entries-in-buffer/entries-written: 4/4   #P:8
#
#_-=> irqs-off
#   / _=> need-resched
#  | / _---=> hardirq/softirq
#  || / _--=> preempt-depth
#  ||| / delay
#   TASK-PID CPU#     TIMESTAMP  FUNCTION
#  | | |     | |
 cat-138 [005] ...1 9.501630: p_full_proxy_read_5: 
(full_proxy_read+0x5/0x80)
 cat-138 [005] ...1 9.501675: 
 => kprobe_trace_func+0x1d0/0x2c0
 => kprobe_dispatcher+0x39/0x60
 => opt_pre_handler+0x4f/0x80
 => optimized_callback+0xc3/0xf0
 => 0xa0006032
 => 0

This requires another fix. I think the unwinder can refer the ORC info
(as a bias from the original function) from optprobe_template_func if
it finds the frame address is in the optprobe trampoline buffer.
Note that this is a bit different from the kretprobe_trampoline, because
optprobe trampoline code is cloned for each probed address.

Thank you,

-- 
Masami Hiramatsu

Re: [RFC PATCH 1/3] dt-bindings: display: simple: Add the panel on sc7180-trogdor-pompom

2021-03-26 Thread Rob Herring

On Fri, Mar 26, 2021 at 4:13 PM Rob Clark  wrote:
>
> On Fri, Mar 26, 2021 at 12:48 PM Rob Herring  wrote:
> >
> > On Fri, Mar 26, 2021 at 9:20 AM Rob Clark  wrote:
> > >
> > > On Fri, Mar 26, 2021 at 8:18 AM Rob Clark  wrote:
> > > >
> > > > On Fri, Mar 26, 2021 at 5:38 AM Thierry Reding 
> > > >  wrote:
> > > > >
> > > > > On Wed, Mar 17, 2021 at 06:53:04PM -0700, Rob Clark wrote:
> > > > > > On Wed, Mar 17, 2021 at 4:27 PM Matthias Kaehlcke 
> > > > > >  wrote:
> > > > > > >
> > > > > > > On Tue, Mar 16, 2021 at 02:08:19PM -0700, Douglas Anderson wrote:
> > > > > > > > The sc7180-trogdor-pompom board might be attached to any number 
> > > > > > > > of a
> > > > > > > > pile of eDP panels. At the moment I'm told that the list might 
> > > > > > > > include:
> > > > > > > > - KD KD116N21-30NV-A010
> > > > > > > > - KD KD116N09-30NH-A016
> > > > > > > > - Starry 2081116HHD028001-51D
> > > > > > > > - Sharp LQ116M1JW10
> > > > > > > >
> > > > > > > > It should be noted that while the EDID programmed in the first 3
> > > > > > > > panels indicates that they should run with exactly the same 
> > > > > > > > timing (to
> > > > > > > > keep things simple), the 4th panel not only needs different 
> > > > > > > > timing but
> > > > > > > > has a different resolution.
> > > > > > > >
> > > > > > > > As is true in general with eDP panels, we can figure out which 
> > > > > > > > panel
> > > > > > > > we have and all the info needed to drive its pixel clock by 
> > > > > > > > reading
> > > > > > > > the EDID. However, we can do this only after we've powered the 
> > > > > > > > panel
> > > > > > > > on. Powering on the panels requires following the timing 
> > > > > > > > diagram in
> > > > > > > > each panel's datasheet which specifies delays between certain
> > > > > > > > actions. This means that, while we can be quite dynamic about 
> > > > > > > > handling
> > > > > > > > things we can't just totally skip out on describing the panel 
> > > > > > > > like we
> > > > > > > > could do if it was connected to an external-facing DP port.
> > > > > > > >
> > > > > > > > While the different panels have slightly different delays, it's
> > > > > > > > possible to come up with a set of unified delays that will work 
> > > > > > > > on all
> > > > > > > > the panels. From reading the datasheets:
> > > > > > > > * KD KD116N21-30NV-A010 and KD KD116N09-30NH-A016
> > > > > > > >   - HPD absent delay: 200 ms
> > > > > > > >   - Unprepare delay: 150 ms (datasheet is confusing, might be 
> > > > > > > > 500 ms)
> > > > > > > > * Starry 2081116HHD028001-51D
> > > > > > > >   - HPD absent delay: 100 ms
> > > > > > > >   - Enable delay: (link training done till enable BL): 200 ms
> > > > > > > >   - Unprepare delay: 500 ms
> > > > > > > > * Sharp LQ116M1JW10
> > > > > > > >   - HPD absent delay: 200 ms
> > > > > > > >   - Unprepare delay: 500 ms
> > > > > > > >   - Prepare to enable delay (power on till backlight): 100 ms
> > > > > > > >
> > > > > > > > Unified:
> > > > > > > > - HPD absent delay: 200 ms
> > > > > > > > - Unprepare delay: 500 ms
> > > > > > > > - Enable delay: 200 ms
> > > > > > > >
> > > > > > > > NOTE: in theory the only thing that we _really_ need unity on 
> > > > > > > > is the
> > > > > > > > "HPD absent delay" since once the panel asserts HPD we can read 
> > > > > > > > the
> > > > > > > > EDID and could make per-panel decisions if we wanted.
> > > > > > > >
> > > > > > > > Let's create a definition of "a panel that can be attached to 
> > > > > > > > pompom"
> > > > > > > > as a panel that provides a valid EDID and can work with the 
> > > > > > > > standard
> > > > > > > > pompom power sequencing. If more panels are later attached to 
> > > > > > > > pompom
> > > > > > > > then it's fine as long as they work in a compatible way.
> > > > > > > >
> > > > > > > > One might ask why we can't just use a generic string here and 
> > > > > > > > provide
> > > > > > > > the timings directly in the device tree file. As I understand 
> > > > > > > > it,
> > > > > > > > trying to describe generic power sequencing in the device tree 
> > > > > > > > is
> > > > > > > > frowned upon and the one instance (SD/MMC) is regarded as a 
> > > > > > > > mistake
> > > > > > > > that shouldn't be repeated. Specifying a power sequence per 
> > > > > > > > board (or
> > > > > > > > per board class) feels like a reasonable compromise. We're not 
> > > > > > > > trying
> > > > > > > > to define fully generic power sequence bindings but we can also 
> > > > > > > > take
> > > > > > > > advantage of the semi-probable properties of the attached 
> > > > > > > > device.
> > > > > > > >
> > > > > > > > NOTE: I believe that past instances of supporting this type of 
> > > > > > > > thing
> > > > > > > > have used the "white lie" approach. One representative panel was
> > > > > > > > listed in the device tree. The power sequencings of this
> > > > > > > > representative panel were OK to use across all panels that 
> > > > > > > > might be

Re: [PATCH v8 3/3] lib: zstd: Upgrade to latest upstream zstd version 1.4.10

2021-03-26 Thread Nick Terrell

On Fri, Mar 26, 2021 at 3:02 PM kernel test robot  wrote:
>
> Hi Nick,
>
> Thank you for the patch! Perhaps something to improve:
>
> [auto build test WARNING on cryptodev/master]
> [also build test WARNING on kdave/for-next f2fs/dev-test linus/master 
> v5.12-rc4 next-20210326]
> [cannot apply to crypto/master kees/for-next/pstore squashfs/master]
> [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/Nick-Terrell/Update-to-zstd-1-4-10/20210327-031827
> base:   
> https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git 
> master
> config: um-allmodconfig (attached as .config)
> compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
> reproduce (this is a W=1 build):
> # 
> https://github.com/0day-ci/linux/commit/ebbff13fa6a537fb8b3dc6b42c3093f9ce4358f8
> git remote add linux-review https://github.com/0day-ci/linux
> git fetch --no-tags linux-review 
> Nick-Terrell/Update-to-zstd-1-4-10/20210327-031827
> git checkout ebbff13fa6a537fb8b3dc6b42c3093f9ce4358f8
> # save the attached .config to linux build tree
> make W=1 ARCH=um
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot 
>
> All warnings (new ones prefixed by >>):
>
>lib/zstd/compress/zstd_compress_sequences.c:17: warning: Cannot understand 
>  * -log2(x / 256) lookup table for x in [0, 256).
> on line 17 - I thought it was a doc line
>lib/zstd/compress/zstd_compress_sequences.c:58: warning: Function 
> parameter or member 'nbSeq' not described in 'ZSTD_useLowProbCount'
> >> lib/zstd/compress/zstd_compress_sequences.c:58: warning: expecting 
> >> prototype for 1 else we should(). Prototype was for ZSTD_useLowProbCount() 
> >> instead
> >> lib/zstd/compress/zstd_compress_sequences.c:67: warning: wrong kernel-doc 
> >> identifier on line:
> * Returns the cost in bytes of encoding the normalized count header.
>lib/zstd/compress/zstd_compress_sequences.c:85: warning: Function 
> parameter or member 'count' not described in 'ZSTD_entropyCost'
>lib/zstd/compress/zstd_compress_sequences.c:85: warning: Function 
> parameter or member 'max' not described in 'ZSTD_entropyCost'
>lib/zstd/compress/zstd_compress_sequences.c:85: warning: Function 
> parameter or member 'total' not described in 'ZSTD_entropyCost'
> >> lib/zstd/compress/zstd_compress_sequences.c:85: warning: expecting 
> >> prototype for Returns the cost in bits of encoding the distribution 
> >> described by count(). Prototype was for ZSTD_entropyCost() instead
>lib/zstd/compress/zstd_compress_sequences.c:99: warning: wrong kernel-doc 
> identifier on line:
> * Returns the cost in bits of encoding the distribution in count using 
> ctable.
>lib/zstd/compress/zstd_compress_sequences.c:139: warning: Function 
> parameter or member 'norm' not described in 'ZSTD_crossEntropyCost'
>lib/zstd/compress/zstd_compress_sequences.c:139: warning: Function 
> parameter or member 'accuracyLog' not described in 'ZSTD_crossEntropyCost'
>lib/zstd/compress/zstd_compress_sequences.c:139: warning: Function 
> parameter or member 'count' not described in 'ZSTD_crossEntropyCost'
>lib/zstd/compress/zstd_compress_sequences.c:139: warning: Function 
> parameter or member 'max' not described in 'ZSTD_crossEntropyCost'
> >> lib/zstd/compress/zstd_compress_sequences.c:139: warning: expecting 
> >> prototype for Returns the cost in bits of encoding the distribution in 
> >> count using the(). Prototype was for ZSTD_crossEntropyCost() instead
> --
>lib/zstd/compress/zstd_ldm.c:584: warning: Function parameter or member 
> 'rawSeqStore' not described in 'maybeSplitSequence'
>lib/zstd/compress/zstd_ldm.c:584: warning: Function parameter or member 
> 'remaining' not described in 'maybeSplitSequence'
>lib/zstd/compress/zstd_ldm.c:584: warning: Function parameter or member 
> 'minMatch' not described in 'maybeSplitSequence'
> >> lib/zstd/compress/zstd_ldm.c:584: warning: expecting prototype for If the 
> >> sequence length is longer than remaining then the sequence is split(). 
> >> Prototype was for maybeSplitSequence() instead
> --
> >> lib/zstd/decompress/zstd_decompress.c:992: warning: wrong kernel-doc 
> >> identifier on line:
> * Similar to ZSTD_nextSrcSizeToDecompress(), but when when a block input 
> can be streamed,
> --
>lib/zstd/decompress/huf_decompress.c:122: warning: Function parameter or 
> member 'symb

[PATCH v2 1/1] x86/tdx: Add tdcall() and tdvmcall() helper functions

2021-03-26 Thread Kuppuswamy Sathyanarayanan

Implement common helper functions to communicate with
the TDX Module and VMM (using TDCALL instruction).

__tdvmcall() function can be used to request services
from VMM.

__tdcall() function can be used to communicate with the
TDX Module.

Using common helper functions makes the code more readable
and less error prone compared to distributed and use case
specific inline assembly code. Only downside in using this
approach is, it adds a few extra instructions for every
TDCALL use case when compared to distributed checks. Although
it's a bit less efficient, it's worth it to make the code more
readable.

Originally-by: Sean Christopherson 
Signed-off-by: Kuppuswamy Sathyanarayanan 

---

Hi All,

Please let me know your review comments. If you agree with this patch
and want to see the use of these APIs in rest of the patches, I will
re-send the patch series with updated code. Please let me know.

Changes since v1:
 * Implemented tdvmcall and tdcall helper functions as assembly code.
 * Followed suggestion provided by Sean & Dave.

 arch/x86/include/asm/tdx.h|  23 +
 arch/x86/kernel/Makefile  |   2 +-
 arch/x86/kernel/asm-offsets.c |  22 +
 arch/x86/kernel/tdcall.S  | 163 ++
 arch/x86/kernel/tdx.c |  30 +++
 5 files changed, 239 insertions(+), 1 deletion(-)
 create mode 100644 arch/x86/kernel/tdcall.S

diff --git a/arch/x86/include/asm/tdx.h b/arch/x86/include/asm/tdx.h
index 69af72d08d3d..ce6212ce5f45 100644
--- a/arch/x86/include/asm/tdx.h
+++ b/arch/x86/include/asm/tdx.h
@@ -8,12 +8,35 @@
 #ifdef CONFIG_INTEL_TDX_GUEST
 
 #include 
+#include 
+
+struct tdcall_output {
+   u64 rcx;
+   u64 rdx;
+   u64 r8;
+   u64 r9;
+   u64 r10;
+   u64 r11;
+};
+
+struct tdvmcall_output {
+   u64 r11;
+   u64 r12;
+   u64 r13;
+   u64 r14;
+   u64 r15;
+};
 
 /* Common API to check TDX support in decompression and common kernel code. */
 bool is_tdx_guest(void);
 
 void __init tdx_early_init(void);
 
+u64 __tdcall(u64 fn, u64 rcx, u64 rdx, struct tdcall_output *out);
+
+u64 __tdvmcall(u64 fn, u64 r12, u64 r13, u64 r14, u64 r15,
+  struct tdvmcall_output *out);
+
 #else // !CONFIG_INTEL_TDX_GUEST
 
 static inline bool is_tdx_guest(void)
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index ea111bf50691..7966c10ea8d1 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -127,7 +127,7 @@ obj-$(CONFIG_PARAVIRT_CLOCK)+= pvclock.o
 obj-$(CONFIG_X86_PMEM_LEGACY_DEVICE) += pmem.o
 
 obj-$(CONFIG_JAILHOUSE_GUEST)  += jailhouse.o
-obj-$(CONFIG_INTEL_TDX_GUEST)  += tdx.o
+obj-$(CONFIG_INTEL_TDX_GUEST)  += tdcall.o tdx.o
 
 obj-$(CONFIG_EISA) += eisa.o
 obj-$(CONFIG_PCSPKR_PLATFORM)  += pcspeaker.o
diff --git a/arch/x86/kernel/asm-offsets.c b/arch/x86/kernel/asm-offsets.c
index 60b9f42ce3c1..72de0b49467e 100644
--- a/arch/x86/kernel/asm-offsets.c
+++ b/arch/x86/kernel/asm-offsets.c
@@ -23,6 +23,10 @@
 #include 
 #endif
 
+#ifdef CONFIG_INTEL_TDX_GUEST
+#include 
+#endif
+
 #ifdef CONFIG_X86_32
 # include "asm-offsets_32.c"
 #else
@@ -75,6 +79,24 @@ static void __used common(void)
OFFSET(XEN_vcpu_info_arch_cr2, vcpu_info, arch.cr2);
 #endif
 
+#ifdef CONFIG_INTEL_TDX_GUEST
+   BLANK();
+   /* Offset for fields in tdcall_output */
+   OFFSET(TDCALL_rcx, tdcall_output, rcx);
+   OFFSET(TDCALL_rdx, tdcall_output, rdx);
+   OFFSET(TDCALL_r8, tdcall_output, r8);
+   OFFSET(TDCALL_r9, tdcall_output, r9);
+   OFFSET(TDCALL_r10, tdcall_output, r10);
+   OFFSET(TDCALL_r11, tdcall_output, r11);
+
+   /* Offset for fields in tdvmcall_output */
+   OFFSET(TDVMCALL_r11, tdvmcall_output, r11);
+   OFFSET(TDVMCALL_r12, tdvmcall_output, r12);
+   OFFSET(TDVMCALL_r13, tdvmcall_output, r13);
+   OFFSET(TDVMCALL_r14, tdvmcall_output, r14);
+   OFFSET(TDVMCALL_r15, tdvmcall_output, r15);
+#endif
+
BLANK();
OFFSET(BP_scratch, boot_params, scratch);
OFFSET(BP_secure_boot, boot_params, secure_boot);
diff --git a/arch/x86/kernel/tdcall.S b/arch/x86/kernel/tdcall.S
new file mode 100644
index ..a73b67c0b407
--- /dev/null
+++ b/arch/x86/kernel/tdcall.S
@@ -0,0 +1,163 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define TDVMCALL_EXPOSE_REGS_MASK  0xfc00
+
+/*
+ * TDCALL instruction is newly added in TDX architecture,
+ * used by TD for requesting the host VMM to provide
+ * (untrusted) services. Supported in Binutils >= 2.36
+ */
+#define tdcall .byte 0x66,0x0f,0x01,0xcc
+
+/* Only for non TDVMCALL use cases */
+SYM_FUNC_START(__tdcall)
+   FRAME_BEGIN
+
+   /* Save/restore non-volatile GPRs that are exposed to the VMM. */
+   push %r15
+   push %r14
+   push %r13
+   push %r12
+
+   /*
+* RDI  => RAX = TDCALL leaf
+* RSI  => RCX = input param 1
+* RDX  => RDX = input param 2
+

Re: [PATCH v5 1/1] fs: Allow no_new_privs tasks to call chroot(2)

2021-03-26 Thread Askar Safin

Hi. Unprivileged users already can do chroot. He should simply create userns 
and then call "chroot" inside. As an LWN commenter noted, you can simply run 
"unshare -r /usr/sbin/chroot some-dir". (I recommend reading all comments: 
https://lwn.net/Articles/849125/ .)

Also: if you need chroot for path resolving only, consider openat2 with 
RESOLVE_IN_ROOT ( https://lwn.net/Articles/796868/ ).


==
Askar Safin
https://github.com/safinaskar

Re: [PATCH bpf-next 1/5] tools pkt_cls.h: sync with kernel sources

2021-03-26 Thread Andrii Nakryiko

On Thu, Mar 25, 2021 at 5:01 AM Kumar Kartikeya Dwivedi
 wrote:
>
> Update the header file so we can use the new defines in subsequent
> patches.
>
> Reviewed-by: Toke Høiland-Jørgensen 
> Signed-off-by: Kumar Kartikeya Dwivedi 
> ---
>  tools/include/uapi/linux/pkt_cls.h | 174 -

If libbpf is going to rely on this UAPI header, we probably need to
add this header to the list of headers that are checked for being up
to date. See Makefile, roughly at line 140.

>  1 file changed, 170 insertions(+), 4 deletions(-)
>

[...]

Re: [PATCH v9 0/3] J7200: Add support for GPIO and higher speed modes in MMCSD subsystems

2021-03-26 Thread Nishanth Menon

On Fri, 26 Mar 2021 12:11:17 +0530, Aswath Govindraju wrote:
> The following series of patches
> - Add support for GPIO subsystem in main and wakeup domains.
> - Add voltage regulator device tree nodes and their corresponding pinmux
>   to support power cycle and voltage switch required for UHS-I modes
> - sets respective tags in sdhci0 node to support higher speeds
> - remove no-1-8-v tag from sdhci1 node to support UHS-I modes
> - Update delay values for various speed modes supported.
> 
> [...]

Hi Aswath Govindraju,

I have applied the following to branch ti-k3-dts-next on [1].
Thank you!

[1/3] arm64: dts: ti: k3-j7200: Add gpio nodes
  commit: e0b2e6af39ea94a6fdba53571e6711df49b6ee8d
[2/3] arm64: dts: ti: k3-j7200-common-proc-board: Disable unused gpio modules
  commit: f4cc7daf460b285d3b318496654dab01472df8e4
[3/3] arm64: dts: ti: k3-j7200: Add support for higher speed modes and update 
delay select values for MMCSD subsystems
  commit: 9437499086c24abf298bc3c3a053faedfc19bab1

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent up the chain during
the next merge window (or sooner if it is a relevant bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

[1] git://git.kernel.org/pub/scm/linux/kernel/git/nmenon/linux.git
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 
849D 1736 249D

[PATCH 19/19] ipv4: tcp_lp.c: Couple of typo fixes

s/resrved/reserved/
s/whithin/within/

Signed-off-by: Bhaskar Chowdhury 
---
 net/ipv4/tcp_lp.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/ipv4/tcp_lp.c b/net/ipv4/tcp_lp.c
index e6459537d4d2..82b36ec3f2f8 100644
--- a/net/ipv4/tcp_lp.c
+++ b/net/ipv4/tcp_lp.c
@@ -63,7 +63,7 @@ enum tcp_lp_state {
  * @sowd: smoothed OWD << 3
  * @owd_min: min OWD
  * @owd_max: max OWD
- * @owd_max_rsv: resrved max owd
+ * @owd_max_rsv: reserved max owd
  * @remote_hz: estimated remote HZ
  * @remote_ref_time: remote reference time
  * @local_ref_time: local reference time
@@ -305,7 +305,7 @@ static void tcp_lp_pkts_acked(struct sock *sk, const struct 
ack_sample *sample)

/* FIXME: try to reset owd_min and owd_max here
 * so decrease the chance the min/max is no longer suitable
-* and will usually within threshold when whithin inference */
+* and will usually within threshold when within inference */
lp->owd_min = lp->sowd >> 3;
lp->owd_max = lp->sowd >> 2;
lp->owd_max_rsv = lp->sowd >> 2;
--
2.26.2

Re: Candidate Linux ABI for Intel AMX and hypothetical new related features

2021-03-26 Thread Andy Lutomirski

Sigh, cc linux-api, not linux-abi.

On Fri, Mar 26, 2021 at 4:12 PM Andy Lutomirski  wrote:
>
> Hi all-
>
> After some discussion on IRC, I have a proposal for a Linux ABI for
> using Intel AMX and other similar features.  It works like this:
>
> First, we make XCR0 dynamic.  This looks a lot like Keno's patch but
> with a different API, outlined below.  Different tasks can have
> different XCR0 values.  The default XCR0 for new tasks does not
> include big features like AMX.  XMM and YMM are still there.  The AVX2
> states are debatable -- see below.
>
> To detect features and control XCR0, we add some new arch_prctls:
>
> arch_prctl(ARCH_GET_XCR0_SUPPORT, 0, ...);
>
> returns the set of XCR0 bits supported on the current kernel.
>
> arch_prctl(ARCH_GET_XCR0_LAZY_SUPPORT, 0, ...);
>
> returns 0.  See below.
>
> arch_prctl(ARCH_SET_XCR0, xcr0, lazy_states, sigsave_states,
> sigclear_states, 0);
>
> Sets xcr0.  All states are preallocated except that states in
> lazy_states may be unallocated in the kernel until used.  (Not
> supported at all in v1.  lazy_states & ~xcr0 != 0 is illegal.)  States
> in sigsave_states are saved in the signal frame.  States in
> sigclear_states are reset to the init state on signal delivery.
> States in sigsave_states are restored by sigreturn, and states not in
> sigsave_states are left alone by sigreturn.
>
> Optionally we do not support PKRU at all in XCR0 -- it doesn't make
> that much sense as an XSAVE feature, and I'm not convinced that trying
> to correctly context switch XINUSE[PKRU] is worthwhile.  I doubt we
> get it right today.
>
> Optionally we come up with a new format for new features in the signal
> frame, since the current format is showing its age.  Taking 8kB for a
> signal with AMX is one thing.  Taking another 8kB for a nested signal
> if AMX is not in use is worse.
>
> Optionally we make AVX-512 also default off, which fixes what is
> arguably a serious ABI break with AVX-512: lots of programs, following
> POSIX (!), seem to think that they know much much space to allocate
> for sigaltstack().   AVX-512 is too big.
>
> Thoughts?
>
> --Andy

[PATCH 18/19] ipv4: ip_output.c: Couple of typo fixes

s/readibility/readability/
s/insufficent/insufficient/

Signed-off-by: Bhaskar Chowdhury 
---
 net/ipv4/ip_output.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
index 3aab53beb4ea..c3efc7d658f6 100644
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -34,7 +34,7 @@
  * Andi Kleen  :   Replace ip_reply with ip_send_reply.
  * Andi Kleen  :   Split fast and slow ip_build_xmit path
  * for decreased register pressure on x86
- * and more readibility.
+ * and more readability.
  * Marc Boucher:   When call_out_firewall returns FW_QUEUE,
  * silently drop skb instead of failing 
with -EPERM.
  * Detlev Wengorz  :   Copy protocol for fragments.
@@ -262,7 +262,7 @@ static int ip_finish_output_gso(struct net *net, struct 
sock *sk,
 *interface with a smaller MTU.
 *  - Arriving GRO skb (or GSO skb in a virtualized environment) that is
 *bridged to a NETIF_F_TSO tunnel stacked over an interface with an
-*insufficent MTU.
+*insufficient MTU.
 */
features = netif_skb_features(skb);
BUILD_BUG_ON(sizeof(*IPCB(skb)) > SKB_GSO_CB_OFFSET);
--
2.26.2

[PATCH 17/19] ipv6: addrconf.c: Fix a typo

s/Identifers/Identifiers/

Signed-off-by: Bhaskar Chowdhury 
---
 net/ipv6/addrconf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index f2337fb756ac..8421f58ea6ea 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -2358,7 +2358,7 @@ static void ipv6_gen_rnd_iid(struct in6_addr *addr)
/* , Section 3.3.1:
 * check if generated address is not inappropriate:
 *
-* - Reserved IPv6 Interface Identifers
+* - Reserved IPv6 Interface Identifiers
 * - XXX: already assigned to an address on the device
 */

--
2.26.2

[PATCH 15/19] kcm: kcmsock.c: Couple of typo fixes

s/synchonization/synchronization/
s/aready/already/

Signed-off-by: Bhaskar Chowdhury 
---
 net/kcm/kcmsock.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/kcm/kcmsock.c b/net/kcm/kcmsock.c
index d0b56ffbb057..6201965bd822 100644
--- a/net/kcm/kcmsock.c
+++ b/net/kcm/kcmsock.c
@@ -663,7 +663,7 @@ static int kcm_write_msgs(struct kcm_sock *kcm)

/* Hard failure in sending message, abort this
 * psock since it has lost framing
-* synchonization and retry sending the
+* synchronization and retry sending the
 * message from the beginning.
 */
kcm_abort_tx_psock(psock, ret ? -ret : EPIPE,
@@ -1419,7 +1419,7 @@ static int kcm_attach(struct socket *sock, struct socket 
*csock,

write_lock_bh(>sk_callback_lock);

-   /* Check if sk_user_data is aready by KCM or someone else.
+   /* Check if sk_user_data is already by KCM or someone else.
 * Must be done under lock to prevent race conditions.
 */
if (csk->sk_user_data) {
--
2.26.2

[PATCH 16/19] ipv6: route.c: A spello fix

s/notfication/notification/

Signed-off-by: Bhaskar Chowdhury 
---
 net/ipv6/route.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 1536f4948e86..dfe5fb260e4c 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -6093,7 +6093,7 @@ void fib6_info_hw_flags_set(struct net *net, struct 
fib6_info *f6i,

if (!rcu_access_pointer(f6i->fib6_node))
/* The route was removed from the tree, do not send
-* notfication.
+* notification.
 */
return;

--
2.26.2

[PATCH 14/19] iucv: af_iucv.c: Couple of typo fixes

s/unitialized/uninitialized/
s/notifcations/notifications/

Signed-off-by: Bhaskar Chowdhury 
---
 net/iucv/af_iucv.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/iucv/af_iucv.c b/net/iucv/af_iucv.c
index 6092d5cb7168..0fdb389c3390 100644
--- a/net/iucv/af_iucv.c
+++ b/net/iucv/af_iucv.c
@@ -621,7 +621,7 @@ static int iucv_sock_bind(struct socket *sock, struct 
sockaddr *addr,
for_each_netdev_rcu(_net, dev) {
if (!memcmp(dev->perm_addr, uid, 8)) {
memcpy(iucv->src_user_id, sa->siucv_user_id, 8);
-   /* Check for unitialized siucv_name */
+   /* Check for uninitialized siucv_name */
if (strncmp(sa->siucv_name, "", 8) == 0)
__iucv_auto_name(iucv);
else
@@ -2134,7 +2134,7 @@ static int afiucv_hs_rcv(struct sk_buff *skb, struct 
net_device *dev,
 }

 /**
- * afiucv_hs_callback_txnotify() - handle send notifcations from HiperSockets
+ * afiucv_hs_callback_txnotify() - handle send notifications from HiperSockets
  * transport
  **/
 static void afiucv_hs_callback_txnotify(struct sock *sk, enum iucv_tx_notify n)
--
2.26.2

[PATCH 12/19] mac80211: cfg.c: A typo fix

s/assocaited/associated/

Signed-off-by: Bhaskar Chowdhury 
---
 net/mac80211/cfg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index c4c70e30ad7f..62f2f356d401 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -1486,7 +1486,7 @@ static int sta_apply_parameters(struct ieee80211_local 
*local,
sta->sta.wme = set & BIT(NL80211_STA_FLAG_WME);

/* auth flags will be set later for TDLS,
-* and for unassociated stations that move to assocaited */
+* and for unassociated stations that move to associated */
if (!test_sta_flag(sta, WLAN_STA_TDLS_PEER) &&
!((mask & BIT(NL80211_STA_FLAG_ASSOCIATED)) &&
  (set & BIT(NL80211_STA_FLAG_ASSOCIATED {
--
2.26.2

[PATCH 11/19] ncsi: internal.h: Fix a spello

s/Firware/Firmware/

Signed-off-by: Bhaskar Chowdhury 
---
 net/ncsi/internal.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/ncsi/internal.h b/net/ncsi/internal.h
index e37102546be6..49031f804276 100644
--- a/net/ncsi/internal.h
+++ b/net/ncsi/internal.h
@@ -100,7 +100,7 @@ enum {
 struct ncsi_channel_version {
u32 version;/* Supported BCD encoded NCSI version */
u32 alpha2; /* Supported BCD encoded NCSI version */
-   u8  fw_name[12];/* Firware name string*/
+   u8  fw_name[12];/* Firmware name string*/
u32 fw_version; /* Firmware version   */
u16 pci_ids[4]; /* PCI identification */
u32 mf_id;  /* Manufacture ID */
--
2.26.2

[PATCH 13/19] llc: llc_core.c: COuple of typo fixes