[PATCH 1/1] staging: exfat: Update MAINTAINERS file

[Valdis Kletnieks]

Add a L: tag so get_maintainers.pl output includes the linux-fsdevel list

Signed-off-by: Valdis Kletnieks 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 3d09efe69508..188435ae 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6186,6 +6186,7 @@ F:include/uapi/linux/mii.h
 
 EXFAT FILE SYSTEM
 M: Valdis Kletnieks 
+L: linux-fsde...@vger.kernel.org
 S: Maintained
 F: drivers/staging/exfat/
 
-- 
2.23.0

[PATCH 1/8] staging: exfat: Clean up namespace pollution, part 1

[Valdis Kletnieks]

Make as much as possible static.  We're over-exuberant here for the benefit
of a following patch, as the compiler will flag now-unused static code

Signed-off-by: Valdis Kletnieks 
---
 drivers/staging/exfat/exfat.h  | 156 ++---
 drivers/staging/exfat/exfat_core.c | 142 +-
 2 files changed, 149 insertions(+), 149 deletions(-)

diff --git a/drivers/staging/exfat/exfat.h b/drivers/staging/exfat/exfat.h
index 3abab33e932c..0c779c8dd858 100644
--- a/drivers/staging/exfat/exfat.h
+++ b/drivers/staging/exfat/exfat.h
@@ -768,107 +768,107 @@ void buf_init(struct super_block *sb);
 void buf_shutdown(struct super_block *sb);
 int FAT_read(struct super_block *sb, u32 loc, u32 *content);
 s32 FAT_write(struct super_block *sb, u32 loc, u32 content);
-u8 *FAT_getblk(struct super_block *sb, sector_t sec);
-void FAT_modify(struct super_block *sb, sector_t sec);
+static u8 *FAT_getblk(struct super_block *sb, sector_t sec);
+static void FAT_modify(struct super_block *sb, sector_t sec);
 void FAT_release_all(struct super_block *sb);
-void FAT_sync(struct super_block *sb);
+static void FAT_sync(struct super_block *sb);
 u8 *buf_getblk(struct super_block *sb, sector_t sec);
 void buf_modify(struct super_block *sb, sector_t sec);
 void buf_lock(struct super_block *sb, sector_t sec);
 void buf_unlock(struct super_block *sb, sector_t sec);
 void buf_release(struct super_block *sb, sector_t sec);
 void buf_release_all(struct super_block *sb);
-void buf_sync(struct super_block *sb);
+static void buf_sync(struct super_block *sb);
 
 /* fs management functions */
 void fs_set_vol_flags(struct super_block *sb, u32 new_flag);
-void fs_error(struct super_block *sb);
+static void fs_error(struct super_block *sb);
 
 /* cluster management functions */
-s32 clear_cluster(struct super_block *sb, u32 clu);
-s32 fat_alloc_cluster(struct super_block *sb, s32 num_alloc,
+static s32 clear_cluster(struct super_block *sb, u32 clu);
+static s32 fat_alloc_cluster(struct super_block *sb, s32 num_alloc,
  struct chain_t *p_chain);
-s32 exfat_alloc_cluster(struct super_block *sb, s32 num_alloc,
+static s32 exfat_alloc_cluster(struct super_block *sb, s32 num_alloc,
struct chain_t *p_chain);
-void fat_free_cluster(struct super_block *sb, struct chain_t *p_chain,
+static void fat_free_cluster(struct super_block *sb, struct chain_t *p_chain,
  s32 do_relse);
-void exfat_free_cluster(struct super_block *sb, struct chain_t *p_chain,
+static void exfat_free_cluster(struct super_block *sb, struct chain_t *p_chain,
s32 do_relse);
-u32 find_last_cluster(struct super_block *sb, struct chain_t *p_chain);
+static u32 find_last_cluster(struct super_block *sb, struct chain_t *p_chain);
 s32 count_num_clusters(struct super_block *sb, struct chain_t *dir);
-s32 fat_count_used_clusters(struct super_block *sb);
-s32 exfat_count_used_clusters(struct super_block *sb);
+static s32 fat_count_used_clusters(struct super_block *sb);
+static s32 exfat_count_used_clusters(struct super_block *sb);
 void exfat_chain_cont_cluster(struct super_block *sb, u32 chain, s32 len);
 
 /* allocation bitmap management functions */
 s32 load_alloc_bitmap(struct super_block *sb);
 void free_alloc_bitmap(struct super_block *sb);
-s32 set_alloc_bitmap(struct super_block *sb, u32 clu);
-s32 clr_alloc_bitmap(struct super_block *sb, u32 clu);
-u32 test_alloc_bitmap(struct super_block *sb, u32 clu);
-void sync_alloc_bitmap(struct super_block *sb);
+static s32 set_alloc_bitmap(struct super_block *sb, u32 clu);
+static s32 clr_alloc_bitmap(struct super_block *sb, u32 clu);
+static u32 test_alloc_bitmap(struct super_block *sb, u32 clu);
+static void sync_alloc_bitmap(struct super_block *sb);
 
 /* upcase table management functions */
 s32 load_upcase_table(struct super_block *sb);
 void free_upcase_table(struct super_block *sb);
 
 /* dir entry management functions */
-u32 fat_get_entry_type(struct dentry_t *p_entry);
-u32 exfat_get_entry_type(struct dentry_t *p_entry);
-void fat_set_entry_type(struct dentry_t *p_entry, u32 type);
-void exfat_set_entry_type(struct dentry_t *p_entry, u32 type);
-u32 fat_get_entry_attr(struct dentry_t *p_entry);
-u32 exfat_get_entry_attr(struct dentry_t *p_entry);
-void fat_set_entry_attr(struct dentry_t *p_entry, u32 attr);
-void exfat_set_entry_attr(struct dentry_t *p_entry, u32 attr);
-u8 fat_get_entry_flag(struct dentry_t *p_entry);
-u8 exfat_get_entry_flag(struct dentry_t *p_entry);
-void fat_set_entry_flag(struct dentry_t *p_entry, u8 flag);
-void exfat_set_entry_flag(struct dentry_t *p_entry, u8 flag);
-u32 fat_get_entry_clu0(struct dentry_t *p_entry);
-u32 exfat_get_entry_clu0(struct dentry_t *p_entry);
-void fat_set_entry_clu0(struct dentry_t *p_entry, u32 start_clu);
-void exfat_set_entry_clu0(struct dentry_t *p_entry, u32 start_clu);
-u64 fat_get_entry_size(struct dentry_t *p_entry);
-u64 exfat_get_entry_size(struct

[PATCH 6/8] staging: exfat: More static cleanups for exfat_core.c

[Valdis Kletnieks]

Move static function bodies before first use, remove the definition in exfat.h

Signed-off-by: Valdis Kletnieks 
---
 drivers/staging/exfat/exfat.h  |   6 -
 drivers/staging/exfat/exfat_core.c | 500 ++---
 2 files changed, 250 insertions(+), 256 deletions(-)

diff --git a/drivers/staging/exfat/exfat.h b/drivers/staging/exfat/exfat.h
index 654a0c46c1a0..b93df526355b 100644
--- a/drivers/staging/exfat/exfat.h
+++ b/drivers/staging/exfat/exfat.h
@@ -786,10 +786,6 @@ void exfat_chain_cont_cluster(struct super_block *sb, u32 
chain, s32 len);
 /* allocation bitmap management functions */
 s32 load_alloc_bitmap(struct super_block *sb);
 void free_alloc_bitmap(struct super_block *sb);
-static s32 set_alloc_bitmap(struct super_block *sb, u32 clu);
-static s32 clr_alloc_bitmap(struct super_block *sb, u32 clu);
-static u32 test_alloc_bitmap(struct super_block *sb, u32 clu);
-static void sync_alloc_bitmap(struct super_block *sb);
 
 /* upcase table management functions */
 s32 load_upcase_table(struct super_block *sb);
@@ -812,8 +808,6 @@ void release_entry_set(struct entry_set_cache_t *es);
 static s32 write_whole_entry_set(struct super_block *sb, struct 
entry_set_cache_t *es);
 s32 count_dos_name_entries(struct super_block *sb, struct chain_t *p_dir,
   u32 type);
-static void update_dir_checksum(struct super_block *sb, struct chain_t *p_dir,
-s32 entry);
 void update_dir_checksum_with_entry_set(struct super_block *sb,
struct entry_set_cache_t *es);
 bool is_dir_empty(struct super_block *sb, struct chain_t *p_dir);
diff --git a/drivers/staging/exfat/exfat_core.c 
b/drivers/staging/exfat/exfat_core.c
index dd69a9a6dddc..1a49da231946 100644
--- a/drivers/staging/exfat/exfat_core.c
+++ b/drivers/staging/exfat/exfat_core.c
@@ -132,6 +132,199 @@ static void fs_error(struct super_block *sb)
}
 }
 
+/*
+ *  Allocation Bitmap Management Functions
+ */
+
+s32 load_alloc_bitmap(struct super_block *sb)
+{
+   int i, j, ret;
+   u32 map_size;
+   u32 type;
+   sector_t sector;
+   struct chain_t clu;
+   struct bmap_dentry_t *ep;
+   struct fs_info_t *p_fs = &(EXFAT_SB(sb)->fs_info);
+   struct bd_info_t *p_bd = &(EXFAT_SB(sb)->bd_info);
+
+   clu.dir = p_fs->root_dir;
+   clu.flags = 0x01;
+
+   while (clu.dir != CLUSTER_32(~0)) {
+   if (p_fs->dev_ejected)
+   break;
+
+   for (i = 0; i < p_fs->dentries_per_clu; i++) {
+   ep = (struct bmap_dentry_t *)get_entry_in_dir(sb, ,
+ i, NULL);
+   if (!ep)
+   return FFS_MEDIAERR;
+
+   type = p_fs->fs_func->get_entry_type((struct dentry_t 
*)ep);
+
+   if (type == TYPE_UNUSED)
+   break;
+   if (type != TYPE_BITMAP)
+   continue;
+
+   if (ep->flags == 0x0) {
+   p_fs->map_clu  = GET32_A(ep->start_clu);
+   map_size = (u32)GET64_A(ep->size);
+
+   p_fs->map_sectors = ((map_size - 1) >> 
p_bd->sector_size_bits) + 1;
+
+   p_fs->vol_amap = 
kmalloc_array(p_fs->map_sectors,
+  sizeof(struct 
buffer_head *),
+  GFP_KERNEL);
+   if (!p_fs->vol_amap)
+   return FFS_MEMORYERR;
+
+   sector = START_SECTOR(p_fs->map_clu);
+
+   for (j = 0; j < p_fs->map_sectors; j++) {
+   p_fs->vol_amap[j] = NULL;
+   ret = sector_read(sb, sector + j, 
&(p_fs->vol_amap[j]), 1);
+   if (ret != FFS_SUCCESS) {
+   /*  release all buffers and 
free vol_amap */
+   i = 0;
+   while (i < j)
+   
brelse(p_fs->vol_amap[i++]);
+
+   kfree(p_fs->vol_amap);
+   p_fs->vol_amap = NULL;
+   return ret;
+   }
+   }
+
+   p_fs->pbr_bh = NULL;
+   return FFS_SUCCESS;
+   }
+   }
+
+   if (FAT_read(sb, clu.dir, ) != 0

[PATCH 7/8] staging: exfat: Finished code movement for static cleanups in exfat_core.c

[Valdis Kletnieks]

Move static function bodies before first use, remove the definition in exfat.h

Signed-off-by: Valdis Kletnieks 
---
 drivers/staging/exfat/exfat.h  |  10 -
 drivers/staging/exfat/exfat_core.c | 661 ++---
 2 files changed, 330 insertions(+), 341 deletions(-)

diff --git a/drivers/staging/exfat/exfat.h b/drivers/staging/exfat/exfat.h
index b93df526355b..8738e41dd5a5 100644
--- a/drivers/staging/exfat/exfat.h
+++ b/drivers/staging/exfat/exfat.h
@@ -793,10 +793,6 @@ void free_upcase_table(struct super_block *sb);
 
 /* dir entry management functions */
 struct timestamp_t *tm_current(struct timestamp_t *tm);
-static void init_file_entry(struct file_dentry_t *ep, u32 type);
-static void init_strm_entry(struct strm_dentry_t *ep, u8 flags, u32 start_clu,
-u64 size);
-static void init_name_entry(struct name_dentry_t *ep, u16 *uniname);
 
 struct dentry_t *get_entry_in_dir(struct super_block *sb, struct chain_t 
*p_dir,
  s32 entry, sector_t *sector);
@@ -805,7 +801,6 @@ struct entry_set_cache_t *get_entry_set_in_dir(struct 
super_block *sb,
   u32 type,
   struct dentry_t **file_ep);
 void release_entry_set(struct entry_set_cache_t *es);
-static s32 write_whole_entry_set(struct super_block *sb, struct 
entry_set_cache_t *es);
 s32 count_dos_name_entries(struct super_block *sb, struct chain_t *p_dir,
   u32 type);
 void update_dir_checksum_with_entry_set(struct super_block *sb,
@@ -819,11 +814,6 @@ s32 get_num_entries_and_dos_name(struct super_block *sb, 
struct chain_t *p_dir,
 void get_uni_name_from_dos_entry(struct super_block *sb,
 struct dos_dentry_t *ep,
 struct uni_name_t *p_uniname, u8 mode);
-static s32 extract_uni_name_from_name_entry(struct name_dentry_t *ep, u16 
*uniname,
-   s32 order);
-static s32 fat_generate_dos_name(struct super_block *sb, struct chain_t *p_dir,
- struct dos_name_t *p_dosname);
-static void fat_attach_count_to_dos_name(u8 *dosname, s32 count);
 u16 calc_checksum_2byte(void *data, s32 len, u16 chksum, s32 type);
 
 /* name resolution functions */
diff --git a/drivers/staging/exfat/exfat_core.c 
b/drivers/staging/exfat/exfat_core.c
index 1a49da231946..7332e69fcbcd 100644
--- a/drivers/staging/exfat/exfat_core.c
+++ b/drivers/staging/exfat/exfat_core.c
@@ -791,6 +791,168 @@ void free_upcase_table(struct super_block *sb)
p_fs->vol_utbl = NULL;
 }
 
+static s32 __write_partial_entries_in_entry_set(struct super_block *sb,
+   struct entry_set_cache_t *es,
+   sector_t sec, s32 off, u32 
count)
+{
+   s32 num_entries, buf_off = (off - es->offset);
+   u32 remaining_byte_in_sector, copy_entries;
+   struct fs_info_t *p_fs = &(EXFAT_SB(sb)->fs_info);
+   struct bd_info_t *p_bd = &(EXFAT_SB(sb)->bd_info);
+   u32 clu;
+   u8 *buf, *esbuf = (u8 *)&(es->__buf);
+
+   pr_debug("%s entered es %p sec %llu off %d count %d\n",
+   __func__, es, (unsigned long long)sec, off, count);
+   num_entries = count;
+
+   while (num_entries) {
+   /* white per sector base */
+   remaining_byte_in_sector = (1 << p_bd->sector_size_bits) - off;
+   copy_entries = min_t(s32,
+remaining_byte_in_sector >> 
DENTRY_SIZE_BITS,
+num_entries);
+   buf = buf_getblk(sb, sec);
+   if (!buf)
+   goto err_out;
+   pr_debug("es->buf %p buf_off %u\n", esbuf, buf_off);
+   pr_debug("copying %d entries from %p to sector %llu\n",
+   copy_entries, (esbuf + buf_off),
+   (unsigned long long)sec);
+   memcpy(buf + off, esbuf + buf_off,
+  copy_entries << DENTRY_SIZE_BITS);
+   buf_modify(sb, sec);
+   num_entries -= copy_entries;
+
+   if (num_entries) {
+   /* get next sector */
+   if (IS_LAST_SECTOR_IN_CLUSTER(sec)) {
+   clu = GET_CLUSTER_FROM_SECTOR(sec);
+   if (es->alloc_flag == 0x03) {
+   clu++;
+   } else {
+   if (FAT_read(sb, clu, ) == -1)
+   goto err_out;
+   }
+   sec = START_SECTOR(clu);
+   } else {
+   sec++;
+   }
+   

[PATCH 4/8] staging: exfat: Cleanup static entries in exfat.h

[Valdis Kletnieks]

Many of the static definitions that remain are not needed, as the function
definition is already before the first use.

Signed-off-by: Valdis Kletnieks 
---
 drivers/staging/exfat/exfat.h | 53 ---
 1 file changed, 53 deletions(-)

diff --git a/drivers/staging/exfat/exfat.h b/drivers/staging/exfat/exfat.h
index 9cd78b6417d0..dbd86a6cdc95 100644
--- a/drivers/staging/exfat/exfat.h
+++ b/drivers/staging/exfat/exfat.h
@@ -782,17 +782,9 @@ static void buf_sync(struct super_block *sb);
 
 /* fs management functions */
 void fs_set_vol_flags(struct super_block *sb, u32 new_flag);
-static void fs_error(struct super_block *sb);
 
 /* cluster management functions */
-static s32 clear_cluster(struct super_block *sb, u32 clu);
-static s32 exfat_alloc_cluster(struct super_block *sb, s32 num_alloc,
-   struct chain_t *p_chain);
-static void exfat_free_cluster(struct super_block *sb, struct chain_t *p_chain,
-   s32 do_relse);
-static u32 find_last_cluster(struct super_block *sb, struct chain_t *p_chain);
 s32 count_num_clusters(struct super_block *sb, struct chain_t *dir);
-static s32 exfat_count_used_clusters(struct super_block *sb);
 void exfat_chain_cont_cluster(struct super_block *sb, u32 chain, s32 len);
 
 /* allocation bitmap management functions */
@@ -808,36 +800,12 @@ s32 load_upcase_table(struct super_block *sb);
 void free_upcase_table(struct super_block *sb);
 
 /* dir entry management functions */
-static u32 exfat_get_entry_type(struct dentry_t *p_entry);
-static void exfat_set_entry_type(struct dentry_t *p_entry, u32 type);
-static u32 exfat_get_entry_attr(struct dentry_t *p_entry);
-static void exfat_set_entry_attr(struct dentry_t *p_entry, u32 attr);
-static u8 exfat_get_entry_flag(struct dentry_t *p_entry);
-static void exfat_set_entry_flag(struct dentry_t *p_entry, u8 flag);
-static u32 exfat_get_entry_clu0(struct dentry_t *p_entry);
-static void exfat_set_entry_clu0(struct dentry_t *p_entry, u32 start_clu);
-static u64 exfat_get_entry_size(struct dentry_t *p_entry);
-static void exfat_set_entry_size(struct dentry_t *p_entry, u64 size);
 struct timestamp_t *tm_current(struct timestamp_t *tm);
-static void exfat_get_entry_time(struct dentry_t *p_entry, struct timestamp_t 
*tp,
- u8 mode);
-static void exfat_set_entry_time(struct dentry_t *p_entry, struct timestamp_t 
*tp,
- u8 mode);
-static s32 exfat_init_dir_entry(struct super_block *sb, struct chain_t *p_dir,
-s32 entry, u32 type, u32 start_clu, u64 size);
-static s32 exfat_init_ext_dir_entry(struct super_block *sb, struct chain_t 
*p_dir,
-s32 entry, s32 num_entries,
-struct uni_name_t *p_uniname,
-   struct dos_name_t *p_dosname);
 static void init_file_entry(struct file_dentry_t *ep, u32 type);
 static void init_strm_entry(struct strm_dentry_t *ep, u8 flags, u32 start_clu,
 u64 size);
 static void init_name_entry(struct name_dentry_t *ep, u16 *uniname);
-static void exfat_delete_dir_entry(struct super_block *sb, struct chain_t 
*p_dir,
-   s32 entry, s32 order, s32 num_entries);
 
-static s32 find_location(struct super_block *sb, struct chain_t *p_dir, s32 
entry,
- sector_t *sector, s32 *offset);
 struct dentry_t *get_entry_in_dir(struct super_block *sb, struct chain_t 
*p_dir,
  s32 entry, sector_t *sector);
 struct entry_set_cache_t *get_entry_set_in_dir(struct super_block *sb,
@@ -846,18 +814,6 @@ struct entry_set_cache_t *get_entry_set_in_dir(struct 
super_block *sb,
   struct dentry_t **file_ep);
 void release_entry_set(struct entry_set_cache_t *es);
 static s32 write_whole_entry_set(struct super_block *sb, struct 
entry_set_cache_t *es);
-static s32 write_partial_entries_in_entry_set(struct super_block *sb,
-  struct entry_set_cache_t *es,
-  struct dentry_t *ep, u32 count);
-static s32 search_deleted_or_unused_entry(struct super_block *sb,
-  struct chain_t *p_dir, s32 num_entries);
-static s32 find_empty_entry(struct inode *inode, struct chain_t *p_dir,
-s32 num_entries);
-static s32 exfat_find_dir_entry(struct super_block *sb, struct chain_t *p_dir,
-struct uni_name_t *p_uniname, s32 num_entries,
-struct dos_name_t *p_dosname, u32 type);
-static s32 exfat_count_ext_entries(struct super_block *sb, struct chain_t 
*p_dir,
-   s32 entry, struct dentry_t *p_entry);
 s32 count_dos_name_entries(struct super_block *sb, struct chain_t *p_dir,
   u32 type);
 static void update_dir_checksum(struct super_block *sb, struct chain_t *p_dir,
@@ -873,25 +829,16 @@ s32

[PATCH 8/8] staging: exfat: Update TODO

[Valdis Kletnieks]

Signed-off-by: Valdis Kletnieks 
---
 drivers/staging/exfat/TODO | 20 
 1 file changed, 8 insertions(+), 12 deletions(-)

diff --git a/drivers/staging/exfat/TODO b/drivers/staging/exfat/TODO
index b60e50b9cf4e..110c30834bd2 100644
--- a/drivers/staging/exfat/TODO
+++ b/drivers/staging/exfat/TODO
@@ -1,21 +1,17 @@
 exfat_core.c - ffsReadFile - the goto err_out seem to leak a brelse().
 same for ffsWriteFile.
 
-exfat_core.c - fs_sync(sb,0) all over the place looks fishy as hell.
-There's only one place that calls it with a non-zero argument.
-Randomly removing fs_sync() calls is *not* the right answer, especially
-if the removal then leaves a call to fs_set_vol_flags(VOL_CLEAN), as that
-says the file system is clean and synced when we *know* it isn't.
-The proper fix here is to go through and actually analyze how DELAYED_SYNC
-should work, and any time we're setting VOL_CLEAN, ensure the file system
-has in fact been synced to disk.  In other words, changing the 'false' to
-'true' is probably more correct. Also, it's likely that the one current
-place where it actually does an bdev_sync isn't sufficient in the DELAYED_SYNC
-case.
-
 ffsTruncateFile -  if (old_size <= new_size) {
 That doesn't look right. How did it ever work? Are they relying on lazy
 block allocation when actual writes happen? If nothing else, it never
 does the 'fid->size = new_size' and do the inode update
 
 ffsSetAttr() is just dangling in the breeze, not wired up at all...
+
+exfat_core.c - The original code called fs_sync(sb,0) all over the place,
+with only one place that calls it with a non-zero argument. That's now been
+reversed, but a proper audit of sync and flush-to-disk is certainly needed.
+
+buf_sync(), sync_alloc_bitmap(), and FAT_sync() aren't actually used
+anyplace.  This is probably related to the borked original implementatin
+of fs_sync() that didn't actually do anything either.
-- 
2.23.0

[PATCH 5/8] staging: exfat: Clean up static definitions in exfat_cache.c

[Valdis Kletnieks]

Move static function bodies before first use, remove the definition in exfat.h

Signed-off-by: Valdis Kletnieks 
---
 drivers/staging/exfat/exfat.h   |  4 --
 drivers/staging/exfat/exfat_cache.c | 94 +++--
 2 files changed, 48 insertions(+), 50 deletions(-)

diff --git a/drivers/staging/exfat/exfat.h b/drivers/staging/exfat/exfat.h
index dbd86a6cdc95..654a0c46c1a0 100644
--- a/drivers/staging/exfat/exfat.h
+++ b/drivers/staging/exfat/exfat.h
@@ -768,17 +768,13 @@ void buf_init(struct super_block *sb);
 void buf_shutdown(struct super_block *sb);
 int FAT_read(struct super_block *sb, u32 loc, u32 *content);
 s32 FAT_write(struct super_block *sb, u32 loc, u32 content);
-static u8 *FAT_getblk(struct super_block *sb, sector_t sec);
-static void FAT_modify(struct super_block *sb, sector_t sec);
 void FAT_release_all(struct super_block *sb);
-static void FAT_sync(struct super_block *sb);
 u8 *buf_getblk(struct super_block *sb, sector_t sec);
 void buf_modify(struct super_block *sb, sector_t sec);
 void buf_lock(struct super_block *sb, sector_t sec);
 void buf_unlock(struct super_block *sb, sector_t sec);
 void buf_release(struct super_block *sb, sector_t sec);
 void buf_release_all(struct super_block *sb);
-static void buf_sync(struct super_block *sb);
 
 /* fs management functions */
 void fs_set_vol_flags(struct super_block *sb, u32 new_flag);
diff --git a/drivers/staging/exfat/exfat_cache.c 
b/drivers/staging/exfat/exfat_cache.c
index e1b001718709..e9ad0353b4e5 100644
--- a/drivers/staging/exfat/exfat_cache.c
+++ b/drivers/staging/exfat/exfat_cache.c
@@ -193,6 +193,50 @@ void buf_shutdown(struct super_block *sb)
 {
 }
 
+static u8 *FAT_getblk(struct super_block *sb, sector_t sec)
+{
+   struct buf_cache_t *bp;
+   struct fs_info_t *p_fs = &(EXFAT_SB(sb)->fs_info);
+
+   bp = FAT_cache_find(sb, sec);
+   if (bp) {
+   move_to_mru(bp, _fs->FAT_cache_lru_list);
+   return bp->buf_bh->b_data;
+   }
+
+   bp = FAT_cache_get(sb, sec);
+
+   FAT_cache_remove_hash(bp);
+
+   bp->drv = p_fs->drv;
+   bp->sec = sec;
+   bp->flag = 0;
+
+   FAT_cache_insert_hash(sb, bp);
+
+   if (sector_read(sb, sec, >buf_bh, 1) != FFS_SUCCESS) {
+   FAT_cache_remove_hash(bp);
+   bp->drv = -1;
+   bp->sec = ~0;
+   bp->flag = 0;
+   bp->buf_bh = NULL;
+
+   move_to_lru(bp, _fs->FAT_cache_lru_list);
+   return NULL;
+   }
+
+   return bp->buf_bh->b_data;
+}
+
+static void FAT_modify(struct super_block *sb, sector_t sec)
+{
+   struct buf_cache_t *bp;
+
+   bp = FAT_cache_find(sb, sec);
+   if (bp)
+   sector_write(sb, sec, bp->buf_bh, 0);
+}
+
 static int __FAT_read(struct super_block *sb, u32 loc, u32 *content)
 {
s32 off;
@@ -441,50 +485,6 @@ int FAT_write(struct super_block *sb, u32 loc, u32 content)
return ret;
 }
 
-u8 *FAT_getblk(struct super_block *sb, sector_t sec)
-{
-   struct buf_cache_t *bp;
-   struct fs_info_t *p_fs = &(EXFAT_SB(sb)->fs_info);
-
-   bp = FAT_cache_find(sb, sec);
-   if (bp) {
-   move_to_mru(bp, _fs->FAT_cache_lru_list);
-   return bp->buf_bh->b_data;
-   }
-
-   bp = FAT_cache_get(sb, sec);
-
-   FAT_cache_remove_hash(bp);
-
-   bp->drv = p_fs->drv;
-   bp->sec = sec;
-   bp->flag = 0;
-
-   FAT_cache_insert_hash(sb, bp);
-
-   if (sector_read(sb, sec, >buf_bh, 1) != FFS_SUCCESS) {
-   FAT_cache_remove_hash(bp);
-   bp->drv = -1;
-   bp->sec = ~0;
-   bp->flag = 0;
-   bp->buf_bh = NULL;
-
-   move_to_lru(bp, _fs->FAT_cache_lru_list);
-   return NULL;
-   }
-
-   return bp->buf_bh->b_data;
-}
-
-void FAT_modify(struct super_block *sb, sector_t sec)
-{
-   struct buf_cache_t *bp;
-
-   bp = FAT_cache_find(sb, sec);
-   if (bp)
-   sector_write(sb, sec, bp->buf_bh, 0);
-}
-
 void FAT_release_all(struct super_block *sb)
 {
struct buf_cache_t *bp;
@@ -510,7 +510,8 @@ void FAT_release_all(struct super_block *sb)
up(_sem);
 }
 
-void FAT_sync(struct super_block *sb)
+/* FIXME - this function is not used anyplace. See TODO */
+static void FAT_sync(struct super_block *sb)
 {
struct buf_cache_t *bp;
struct fs_info_t *p_fs = &(EXFAT_SB(sb)->fs_info);
@@ -704,7 +705,8 @@ void buf_release_all(struct super_block *sb)
up(_sem);
 }
 
-void buf_sync(struct super_block *sb)
+/* FIXME - this function is not used anyplace. See TODO */
+static void buf_sync(struct super_block *sb)
 {
struct buf_cache_t *bp;
struct fs_info_t *p_fs = &(EXFAT_SB(sb)->fs_info);
-- 
2.23.0

[PATCH 3/8] staging: exfat: Remove FAT/VFAT mount support, part 2

[Valdis Kletnieks]

Remove no longer referenced FAT/VFAT routines.

Signed-off-by: Valdis Kletnieks 
---
 drivers/staging/exfat/exfat.h  |  49 +-
 drivers/staging/exfat/exfat_core.c | 755 -
 2 files changed, 2 insertions(+), 802 deletions(-)

diff --git a/drivers/staging/exfat/exfat.h b/drivers/staging/exfat/exfat.h
index c2db3e9e9785..9cd78b6417d0 100644
--- a/drivers/staging/exfat/exfat.h
+++ b/drivers/staging/exfat/exfat.h
@@ -786,17 +786,12 @@ static void fs_error(struct super_block *sb);
 
 /* cluster management functions */
 static s32 clear_cluster(struct super_block *sb, u32 clu);
-static s32 fat_alloc_cluster(struct super_block *sb, s32 num_alloc,
- struct chain_t *p_chain);
 static s32 exfat_alloc_cluster(struct super_block *sb, s32 num_alloc,
struct chain_t *p_chain);
-static void fat_free_cluster(struct super_block *sb, struct chain_t *p_chain,
- s32 do_relse);
 static void exfat_free_cluster(struct super_block *sb, struct chain_t *p_chain,
s32 do_relse);
 static u32 find_last_cluster(struct super_block *sb, struct chain_t *p_chain);
 s32 count_num_clusters(struct super_block *sb, struct chain_t *dir);
-static s32 fat_count_used_clusters(struct super_block *sb);
 static s32 exfat_count_used_clusters(struct super_block *sb);
 void exfat_chain_cont_cluster(struct super_block *sb, u32 chain, s32 len);
 
@@ -813,63 +808,36 @@ s32 load_upcase_table(struct super_block *sb);
 void free_upcase_table(struct super_block *sb);
 
 /* dir entry management functions */
-static u32 fat_get_entry_type(struct dentry_t *p_entry);
 static u32 exfat_get_entry_type(struct dentry_t *p_entry);
-static void fat_set_entry_type(struct dentry_t *p_entry, u32 type);
 static void exfat_set_entry_type(struct dentry_t *p_entry, u32 type);
-static u32 fat_get_entry_attr(struct dentry_t *p_entry);
 static u32 exfat_get_entry_attr(struct dentry_t *p_entry);
-static void fat_set_entry_attr(struct dentry_t *p_entry, u32 attr);
 static void exfat_set_entry_attr(struct dentry_t *p_entry, u32 attr);
-static u8 fat_get_entry_flag(struct dentry_t *p_entry);
 static u8 exfat_get_entry_flag(struct dentry_t *p_entry);
-static void fat_set_entry_flag(struct dentry_t *p_entry, u8 flag);
 static void exfat_set_entry_flag(struct dentry_t *p_entry, u8 flag);
-static u32 fat_get_entry_clu0(struct dentry_t *p_entry);
 static u32 exfat_get_entry_clu0(struct dentry_t *p_entry);
-static void fat_set_entry_clu0(struct dentry_t *p_entry, u32 start_clu);
 static void exfat_set_entry_clu0(struct dentry_t *p_entry, u32 start_clu);
-static u64 fat_get_entry_size(struct dentry_t *p_entry);
 static u64 exfat_get_entry_size(struct dentry_t *p_entry);
-static void fat_set_entry_size(struct dentry_t *p_entry, u64 size);
 static void exfat_set_entry_size(struct dentry_t *p_entry, u64 size);
 struct timestamp_t *tm_current(struct timestamp_t *tm);
-static void fat_get_entry_time(struct dentry_t *p_entry, struct timestamp_t 
*tp,
-   u8 mode);
 static void exfat_get_entry_time(struct dentry_t *p_entry, struct timestamp_t 
*tp,
  u8 mode);
-static void fat_set_entry_time(struct dentry_t *p_entry, struct timestamp_t 
*tp,
-   u8 mode);
 static void exfat_set_entry_time(struct dentry_t *p_entry, struct timestamp_t 
*tp,
  u8 mode);
-static s32 fat_init_dir_entry(struct super_block *sb, struct chain_t *p_dir, 
s32 entry,
-  u32 type, u32 start_clu, u64 size);
 static s32 exfat_init_dir_entry(struct super_block *sb, struct chain_t *p_dir,
 s32 entry, u32 type, u32 start_clu, u64 size);
-static s32 fat_init_ext_dir_entry(struct super_block *sb, struct chain_t 
*p_dir,
-  s32 entry, s32 num_entries,
-  struct uni_name_t *p_uniname,
-  struct dos_name_t *p_dosname);
 static s32 exfat_init_ext_dir_entry(struct super_block *sb, struct chain_t 
*p_dir,
 s32 entry, s32 num_entries,
 struct uni_name_t *p_uniname,
struct dos_name_t *p_dosname);
-static void init_dos_entry(struct dos_dentry_t *ep, u32 type, u32 start_clu);
-static void init_ext_entry(struct ext_dentry_t *ep, s32 order, u8 chksum,
-   u16 *uniname);
 static void init_file_entry(struct file_dentry_t *ep, u32 type);
 static void init_strm_entry(struct strm_dentry_t *ep, u8 flags, u32 start_clu,
 u64 size);
 static void init_name_entry(struct name_dentry_t *ep, u16 *uniname);
-static void fat_delete_dir_entry(struct super_block *sb, struct chain_t *p_dir,
- s32 entry, s32 order, s32 num_entries);
 static void exfat_delete_dir_entry(struct super_block *sb, struct chain_t 
*p_dir,
s32 entry, s32 order, s32 num_entries);
 
 static s32 find_location(struct

[PATCH 2/8] staging: exfat: Remove FAT/VFAT mount support, part 1

[Valdis Kletnieks]

Remove the top-level mount functionality, to make this driver handle
only exfat file systems.

Signed-off-by: Valdis Kletnieks 
---
 drivers/staging/exfat/Kconfig   |   9 --
 drivers/staging/exfat/exfat.h   |   2 -
 drivers/staging/exfat/exfat_core.c  | 142 
 drivers/staging/exfat/exfat_super.c |   8 +-
 4 files changed, 1 insertion(+), 160 deletions(-)

diff --git a/drivers/staging/exfat/Kconfig b/drivers/staging/exfat/Kconfig
index ce32dfe33bec..0130019cbec2 100644
--- a/drivers/staging/exfat/Kconfig
+++ b/drivers/staging/exfat/Kconfig
@@ -6,15 +6,6 @@ config EXFAT_FS
help
  This adds support for the exFAT file system.
 
-config EXFAT_DONT_MOUNT_VFAT
-   bool "Prohibit mounting of fat/vfat filesystems by exFAT"
-   depends on EXFAT_FS
-   default y
-   help
- By default, the exFAT driver will only mount exFAT filesystems, and 
refuse
- to mount fat/vfat filesystems.  Set this to 'n' to allow the exFAT 
driver
- to mount these filesystems.
-
 config EXFAT_DISCARD
bool "enable discard support"
depends on EXFAT_FS
diff --git a/drivers/staging/exfat/exfat.h b/drivers/staging/exfat/exfat.h
index 0c779c8dd858..c2db3e9e9785 100644
--- a/drivers/staging/exfat/exfat.h
+++ b/drivers/staging/exfat/exfat.h
@@ -935,8 +935,6 @@ s32 resolve_path(struct inode *inode, char *path, struct 
chain_t *p_dir,
 static s32 resolve_name(u8 *name, u8 **arg);
 
 /* file operation functions */
-static s32 fat16_mount(struct super_block *sb, struct pbr_sector_t *p_pbr);
-static s32 fat32_mount(struct super_block *sb, struct pbr_sector_t *p_pbr);
 s32 exfat_mount(struct super_block *sb, struct pbr_sector_t *p_pbr);
 s32 create_dir(struct inode *inode, struct chain_t *p_dir,
   struct uni_name_t *p_uniname, struct file_id_t *fid);
diff --git a/drivers/staging/exfat/exfat_core.c 
b/drivers/staging/exfat/exfat_core.c
index 0260e4fe3762..fd481b21f8b6 100644
--- a/drivers/staging/exfat/exfat_core.c
+++ b/drivers/staging/exfat/exfat_core.c
@@ -2980,148 +2980,6 @@ s32 resolve_path(struct inode *inode, char *path, 
struct chain_t *p_dir,
 /*
  *  File Operation Functions
  */
-static struct fs_func fat_fs_func = {
-   .alloc_cluster = fat_alloc_cluster,
-   .free_cluster = fat_free_cluster,
-   .count_used_clusters = fat_count_used_clusters,
-
-   .init_dir_entry = fat_init_dir_entry,
-   .init_ext_entry = fat_init_ext_entry,
-   .find_dir_entry = fat_find_dir_entry,
-   .delete_dir_entry = fat_delete_dir_entry,
-   .get_uni_name_from_ext_entry = fat_get_uni_name_from_ext_entry,
-   .count_ext_entries = fat_count_ext_entries,
-   .calc_num_entries = fat_calc_num_entries,
-
-   .get_entry_type = fat_get_entry_type,
-   .set_entry_type = fat_set_entry_type,
-   .get_entry_attr = fat_get_entry_attr,
-   .set_entry_attr = fat_set_entry_attr,
-   .get_entry_flag = fat_get_entry_flag,
-   .set_entry_flag = fat_set_entry_flag,
-   .get_entry_clu0 = fat_get_entry_clu0,
-   .set_entry_clu0 = fat_set_entry_clu0,
-   .get_entry_size = fat_get_entry_size,
-   .set_entry_size = fat_set_entry_size,
-   .get_entry_time = fat_get_entry_time,
-   .set_entry_time = fat_set_entry_time,
-};
-
-static s32 fat16_mount(struct super_block *sb, struct pbr_sector_t *p_pbr)
-{
-   s32 num_reserved, num_root_sectors;
-   struct bpb16_t *p_bpb = (struct bpb16_t *)p_pbr->bpb;
-   struct fs_info_t *p_fs = &(EXFAT_SB(sb)->fs_info);
-   struct bd_info_t *p_bd = &(EXFAT_SB(sb)->bd_info);
-
-   if (p_bpb->num_fats == 0)
-   return FFS_FORMATERR;
-
-   num_root_sectors = GET16(p_bpb->num_root_entries) << DENTRY_SIZE_BITS;
-   num_root_sectors = ((num_root_sectors - 1) >>
-   p_bd->sector_size_bits) + 1;
-
-   p_fs->sectors_per_clu = p_bpb->sectors_per_clu;
-   p_fs->sectors_per_clu_bits = ilog2(p_bpb->sectors_per_clu);
-   p_fs->cluster_size_bits = p_fs->sectors_per_clu_bits +
- p_bd->sector_size_bits;
-   p_fs->cluster_size = 1 << p_fs->cluster_size_bits;
-
-   p_fs->num_FAT_sectors = GET16(p_bpb->num_fat_sectors);
-
-   p_fs->FAT1_start_sector = p_fs->PBR_sector + GET16(p_bpb->num_reserved);
-   if (p_bpb->num_fats == 1)
-   p_fs->FAT2_start_sector = p_fs->FAT1_start_sector;
-   else
-   p_fs->FAT2_start_sector = p_fs->FAT1_start_sector +
- p_fs->num_FAT_sectors;
-
-   p_fs->root_start_sector = p_fs->FAT2_start_sector +
- p_fs->num_FAT_sectors;
-   p_fs->data_start_sector = p_fs->root_start_sector + num_root_sectors;
-
-   p_fs->num_sectors = GET16(p_bpb->num_sectors);
-   if (p_fs->num_s

[PATCH 0/8] staging: exfat: Code cleanups

[Valdis Kletnieks]

Two main goals here - remove the code to mount FAT and VFAT filesystes,
and make a lot of functions static to reduce namespace pollution.

Valdis Kletnieks (8):
  staging: exfat: Clean up namespace pollution, part 1
  staging: exfat: Remove FAT/VFAT mount support, part 1
  staging: exfat: Remove FAT/VFAT mount support, part 2
  staging: exfat: Cleanup static entries in exfat.h
  staging: exfat: Clean up static definitions in exfat_cache.c
  staging: exfat: More static cleanups for exfat_core.c
  staging: exfat: Finished code movement for static cleanups in exfat_core.c
  staging: exfat: Update TODO

 drivers/staging/exfat/Kconfig   |9 -
 drivers/staging/exfat/TODO  |   20 +-
 drivers/staging/exfat/exfat.h   |  122 +-
 drivers/staging/exfat/exfat_cache.c |   94 +-
 drivers/staging/exfat/exfat_core.c  | 2162 ---
 drivers/staging/exfat/exfat_super.c |8 +-
 6 files changed, 690 insertions(+), 1725 deletions(-)

-- 
2.23.0

[tip:ras/core] RAS: Build debugfs.o only when enabled in Kconfig

[tip-bot for Valdis Kletnieks]

Commit-ID:  b6ff24f7b5101101ff897dfdde3f37924e676bc2
Gitweb: https://git.kernel.org/tip/b6ff24f7b5101101ff897dfdde3f37924e676bc2
Author: Valdis Kletnieks 
AuthorDate: Thu, 8 Aug 2019 16:32:27 +0200
Committer:  Borislav Petkov 
CommitDate: Thu, 8 Aug 2019 17:44:02 +0200

RAS: Build debugfs.o only when enabled in Kconfig

In addition, the 0day bot reported this build error:

  >> drivers/ras/debugfs.c:10:5: error: redefinition of 
'ras_userspace_consumers'
  int ras_userspace_consumers(void)
  ^~~
 In file included from drivers/ras/debugfs.c:3:0:
 include/linux/ras.h:14:19: note: previous definition of 
'ras_userspace_consumers' was here
  static inline int ras_userspace_consumers(void) { return 0; }
  ^~~

for a riscv-specific .config where CONFIG_DEBUG_FS is not set. Fix all
that by making debugfs.o depend on that define.

 [ bp: Rewrite commit message. ]

Reported-by: kbuild test robot 
Signed-off-by: Valdis Kletnieks 
Signed-off-by: Borislav Petkov 
Cc: Tony Luck 
Cc: linux-e...@vger.kernel.org
Cc: x...@kernel.org
Link: http://lkml.kernel.org/r/7053.1565218556@turing-police
---
 drivers/ras/Makefile | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/ras/Makefile b/drivers/ras/Makefile
index ef6777e14d3d..6f0404f50107 100644
--- a/drivers/ras/Makefile
+++ b/drivers/ras/Makefile
@@ -1,3 +1,4 @@
 # SPDX-License-Identifier: GPL-2.0-only
-obj-$(CONFIG_RAS)  += ras.o debugfs.o
+obj-$(CONFIG_RAS)  += ras.o
+obj-$(CONFIG_DEBUG_FS) += debugfs.o
 obj-$(CONFIG_RAS_CEC)  += cec.o

[tip:perf/core] perf/core: Make perf_swevent_init_cpu() static

[tip-bot for Valdis Kletnieks]

Commit-ID:  d18bf4229b1772e91c0c36772737c01cf9726720
Gitweb: https://git.kernel.org/tip/d18bf4229b1772e91c0c36772737c01cf9726720
Author: Valdis Kletnieks 
AuthorDate: Tue, 12 Mar 2019 04:06:37 -0400
Committer:  Ingo Molnar 
CommitDate: Wed, 3 Apr 2019 09:52:34 +0200

perf/core: Make perf_swevent_init_cpu() static

'make W=1' causes GCC to complain:

  kernel/events/core.c:11877:6: warning: no previous prototype for 
'perf_swevent_init_cpu' [-Wmissing-prototypes]

It's not referenced anywhere else, make it static.

Signed-off-by: Valdis Kletnieks 
Signed-off-by: Peter Zijlstra (Intel) 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: https://lkml.kernel.org/r/28974.1552377997@turing-police
Signed-off-by: Ingo Molnar 
---
 kernel/events/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/events/core.c b/kernel/events/core.c
index 72d06e302e99..dfc4bab0b02b 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -11878,7 +11878,7 @@ static void __init perf_event_init_all_cpus(void)
}
 }
 
-void perf_swevent_init_cpu(unsigned int cpu)
+static void perf_swevent_init_cpu(unsigned int cpu)
 {
struct swevent_htable *swhash = _cpu(swevent_htable, cpu);
 

[tip:x86/urgent] x86/mm/pti: Make local symbols static

[tip-bot for Valdis Kletnieks]

Commit-ID:  4fe64a62e04cfb2dc1daab0d8f05d212aa014161
Gitweb: https://git.kernel.org/tip/4fe64a62e04cfb2dc1daab0d8f05d212aa014161
Author: Valdis Kletnieks 
AuthorDate: Tue, 12 Mar 2019 03:47:53 -0400
Committer:  Thomas Gleixner 
CommitDate: Fri, 22 Mar 2019 13:31:28 +0100

x86/mm/pti: Make local symbols static

With 'make C=2 W=1', sparse and gcc both complain:

  CHECK   arch/x86/mm/pti.c
arch/x86/mm/pti.c:84:3: warning: symbol 'pti_mode' was not declared. Should it 
be static?
arch/x86/mm/pti.c:605:6: warning: symbol 'pti_set_kernel_image_nonglobal' was 
not declared. Should it be static?
  CC  arch/x86/mm/pti.o
arch/x86/mm/pti.c:605:6: warning: no previous prototype for 
'pti_set_kernel_image_nonglobal' [-Wmissing-prototypes]
  605 | void pti_set_kernel_image_nonglobal(void)
  |  ^~

pti_set_kernel_image_nonglobal() is only used locally. 'pti_mode' exists in
drivers/hwtracing/intel_th/pti.c as well, but it's a completely unrelated
local (static) symbol.

Make both static.

Signed-off-by: Valdis Kletnieks 
Signed-off-by: Thomas Gleixner 
Cc: Dave Hansen 
Cc: Andy Lutomirski 
Cc: Peter Zijlstra 
Link: https://lkml.kernel.org/r/27680.1552376873@turing-police


---
 arch/x86/mm/pti.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/mm/pti.c b/arch/x86/mm/pti.c
index 4fee5c3003ed..139b28a01ce4 100644
--- a/arch/x86/mm/pti.c
+++ b/arch/x86/mm/pti.c
@@ -77,7 +77,7 @@ static void __init pti_print_if_secure(const char *reason)
pr_info("%s\n", reason);
 }
 
-enum pti_mode {
+static enum pti_mode {
PTI_AUTO = 0,
PTI_FORCE_OFF,
PTI_FORCE_ON
@@ -602,7 +602,7 @@ static void pti_clone_kernel_text(void)
set_memory_global(start, (end_global - start) >> PAGE_SHIFT);
 }
 
-void pti_set_kernel_image_nonglobal(void)
+static void pti_set_kernel_image_nonglobal(void)
 {
/*
 * The identity map is created with PMDs, regardless of the

[tip:core/urgent] watchdog/core: Make variables static

[tip-bot for Valdis Kletnieks]

Commit-ID:  48084abf212052ca1d39fae064c581b1ce5b1fdf
Gitweb: https://git.kernel.org/tip/48084abf212052ca1d39fae064c581b1ce5b1fdf
Author: Valdis Kletnieks 
AuthorDate: Tue, 12 Mar 2019 05:33:48 -0400
Committer:  Thomas Gleixner 
CommitDate: Fri, 22 Mar 2019 13:40:17 +0100

watchdog/core: Make variables static

sparse complains:
  CHECK   kernel/watchdog.c
kernel/watchdog.c:45:19: warning: symbol 'nmi_watchdog_available'
  was not declared. Should it be static?
kernel/watchdog.c:47:16: warning: symbol 'watchdog_allowed_mask'
  was not declared. Should it be static?

They're not referenced by name from anyplace else, make them static.

Signed-off-by: Valdis Kletnieks 
Signed-off-by: Thomas Gleixner 
Link: https://lkml.kernel.org/r/7855.1552383228@turing-police


---
 kernel/watchdog.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/watchdog.c b/kernel/watchdog.c
index 8fbfda94a67b..403c9bd90413 100644
--- a/kernel/watchdog.c
+++ b/kernel/watchdog.c
@@ -42,9 +42,9 @@ int __read_mostly watchdog_user_enabled = 1;
 int __read_mostly nmi_watchdog_user_enabled = NMI_WATCHDOG_DEFAULT;
 int __read_mostly soft_watchdog_user_enabled = 1;
 int __read_mostly watchdog_thresh = 10;
-int __read_mostly nmi_watchdog_available;
+static int __read_mostly nmi_watchdog_available;
 
-struct cpumask watchdog_allowed_mask __read_mostly;
+static struct cpumask watchdog_allowed_mask __read_mostly;
 
 struct cpumask watchdog_cpumask __read_mostly;
 unsigned long *watchdog_cpumask_bits = cpumask_bits(_cpumask);

[tip:timers/urgent] time/jiffies: Make refined_jiffies static

[tip-bot for Valdis Kletnieks]

Commit-ID:  e8750053d64a3317cbc15f8341f0f11ca751bfeb
Gitweb: https://git.kernel.org/tip/e8750053d64a3317cbc15f8341f0f11ca751bfeb
Author: Valdis Kletnieks 
AuthorDate: Tue, 12 Mar 2019 04:38:35 -0400
Committer:  Thomas Gleixner 
CommitDate: Fri, 22 Mar 2019 13:38:26 +0100

time/jiffies: Make refined_jiffies static

sparse complains:

  CHECK   kernel/time/jiffies.c
kernel/time/jiffies.c:92:20: warning: symbol 'refined_jiffies' was not
  declared. Should it be static?

Its only used in file scope. Make it static.

Signed-off-by: Valdis Kletnieks 
Signed-off-by: Thomas Gleixner 
Link: https://lkml.kernel.org/r/32342.1552379915@turing-police

---
 kernel/time/jiffies.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/time/jiffies.c b/kernel/time/jiffies.c
index dc1b6f1929f9..ac9c03dd6c7d 100644
--- a/kernel/time/jiffies.c
+++ b/kernel/time/jiffies.c
@@ -89,7 +89,7 @@ struct clocksource * __init __weak 
clocksource_default_clock(void)
return _jiffies;
 }
 
-struct clocksource refined_jiffies;
+static struct clocksource refined_jiffies;
 
 int register_refined_jiffies(long cycles_per_second)
 {

[tip:irq/urgent] genirq/devres: Remove excess parameter from kernel doc

[tip-bot for Valdis Kletnieks]

Commit-ID:  bb2e320565f997273fe04035bb6c17f643da6f8a
Gitweb: https://git.kernel.org/tip/bb2e320565f997273fe04035bb6c17f643da6f8a
Author: Valdis Kletnieks 
AuthorDate: Tue, 12 Mar 2019 04:17:56 -0400
Committer:  Thomas Gleixner 
CommitDate: Fri, 22 Mar 2019 13:34:12 +0100

genirq/devres: Remove excess parameter from kernel doc

Building with 'make W=1' complains:

  CC  kernel/irq/devres.o
kernel/irq/devres.c:104: warning: Excess function parameter 'thread_fn'
 description in 'devm_request_any_context_irq'

Remove it.

Signed-off-by: Valdis Kletnieks 
Signed-off-by: Thomas Gleixner 
Link: https://lkml.kernel.org/r/31207.1552378676@turing-police


---
 kernel/irq/devres.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/kernel/irq/devres.c b/kernel/irq/devres.c
index 5d5378ea0afe..f808c6a97dcc 100644
--- a/kernel/irq/devres.c
+++ b/kernel/irq/devres.c
@@ -84,8 +84,6 @@ EXPORT_SYMBOL(devm_request_threaded_irq);
  * @dev: device to request interrupt for
  * @irq: Interrupt line to allocate
  * @handler: Function to be called when the IRQ occurs
- * @thread_fn: function to be called in a threaded interrupt context. NULL
- * for devices which handle everything in @handler
  * @irqflags: Interrupt type flags
  * @devname: An ascii name for the claiming device, dev_name(dev) if NULL
  * @dev_id: A cookie passed back to the handler function

Re: [PATCH] drivers/platform/x86/dell-rbtn.c - add missing #include

[valdis . kletnieks]

On Tue, 12 Mar 2019 23:46:11 +0100, Pali Rohar said:

> Can you identify in which commit was introduced this problem? If yes,
> then Fixes: keyword should be added into commit message.

I admit not knowing how long that's been there - I mostly found myself
with a large amount of free time, a good supply of caffeine, and I got
irritated with how many warnings 'make C=2 W=1' throws, so I decided
to start going through and beating things into shape.  For those issues
where I can easily identify the regression point, I will include a Fixes: as I 
go..

Re: [bpf] 568f196756: BUG:assuming_atomic_context_at_kernel/seccomp.c

[valdis . kletnieks]

On Sat, 23 Feb 2019 00:15:38 +0100, Jann Horn said:
> On Fri, Feb 22, 2019 at 11:42 PM  wrote:
> > Is there a reason this commit appeared in next-20190221 but did not seem to 
> > be
> > in next-20190222 (confirmed via 'git tag --contains')?y ast@, he wanted to 
> > fix it in a different way:
> https://lore.kernel.org/netdev/20190221192916.2mcd4fmxbdj2j...@ast-mbp.dhcp.thefacebook.com/

Aha.  That was cc:ed to netdev, but not to lkml.  Explains why I missed that 
piece
of the story

Re: [bpf] 568f196756: BUG:assuming_atomic_context_at_kernel/seccomp.c

[valdis . kletnieks]

On Thu, 21 Feb 2019 14:39:27 +0100, Daniel Borkmann said:
> Fyi, false positive and already fixed in bpf-next.
>
> (https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=435b3ff5b08a99a15647be32735abf8db66cea9a)

Is there a reason this commit appeared in next-20190221 but did not seem to be
in next-20190222 (confirmed via 'git tag --contains')?

[/usr/src/linux-next] git tag -l next-20190222
next-20190222
 [/usr/src/linux-next] git tag --contains 
435b3ff5b08a99a15647be32735abf8db66cea9a
next-20190221

(I went ahead and 'git cherry-pick -n' it on top of 0222)

Re: [regression -next0117] What is kcompactd and why is he eating 100% of my cpu?

[valdis . kletnieks]

On Tue, 29 Jan 2019 20:06:39 -0500, valdis.kletni...@vt.edu said:
> On Mon, 28 Jan 2019 10:16:27 +0100, Jan Kara said:
>
> > So my buffer_migrate_page_norefs() is certainly buggy in its current
> > incarnation (as a result block device page cache is not migratable at all).
> > I've sent Andrew a patch over week ago but so far it got ignored. The patch
> > is attached, can you give it a try whether it changes something for you?
> > Thanks!
>
> Been running with the patch for about 24 hours, haven't seen kcompactd
> misbehave.  I even fired up a Chrome with a lot of tabs open, a Firefox, and a
> kernel build, intentionally drove the system into swapping, and kcompactd
> didn't make it into the top 10 on 'top'.
>
> I'm willing to say put a "tested-by:" on that one,  it looks fixed from here.
> If there's any remaining bugs, they're ones I can't seem to trigger...

Spoke too soon.  Sitting here not stressing the laptop at all, plenty of free
memory, and ka-blam.

Will keep my eyes open and do the data gathering Mel Gorban wanted - I 
discovered
too late that trace-cmd wasn't installed, and things broke free by themselves 
(probably
not coincidence that I launched a terminal window and then it cleared)

top - 23:24:03 up  2:19,  1 user,  load average: 2.70, 2.00, 1.55
Tasks: 221 total,   3 running, 218 sleeping,   0 stopped,   0 zombie
%Cpu(s): 15.6 us, 67.3 sy,  0.0 ni,  9.5 id,  0.0 wa,  5.6 hi,  2.0 si,  0.0 st
GiB Mem :  7.6 total,  2.7 free,  3.1 used,  1.8 buff/cache
GiB Swap:  8.0 total,  8.0 free,  0.0 used.  4.1 avail Mem 

  PID  PPID  %MEM  PR  NI SVIRTRESSHR   SWAP   UID  %CPU TIME+ 
COMMAND 
   27 2   0.0  20   0 R0.0m   0.0m   0.0m   0.0m 0  78.5   2:11.91 
kcompactd0

Re: [regression -next0117] What is kcompactd and why is he eating 100% of my cpu?

[valdis . kletnieks]

On Mon, 28 Jan 2019 10:16:27 +0100, Jan Kara said:

> So my buffer_migrate_page_norefs() is certainly buggy in its current
> incarnation (as a result block device page cache is not migratable at all).
> I've sent Andrew a patch over week ago but so far it got ignored. The patch
> is attached, can you give it a try whether it changes something for you?
> Thanks!

Been running with the patch for about 24 hours, haven't seen kcompactd
misbehave.  I even fired up a Chrome with a lot of tabs open, a Firefox, and a
kernel build, intentionally drove the system into swapping, and kcompactd
didn't make it into the top 10 on 'top'.

I'm willing to say put a "tested-by:" on that one,  it looks fixed from here.
If there's any remaining bugs, they're ones I can't seem to trigger...

[PATCH] init/calibrate.c - provide proper prototype.

[valdis . kletnieks]

Sparse issues a warning:

  CHECK   init/calibrate.c
init/calibrate.c:271:28: warning: symbol 'calibration_delay_done' was not 
declared. Should it be static?

The actual issue is that it's a __weak symbol that archs can override (in fact,
ARM does so), but no prototype is provided. Let's provide one to prevent
surprises.

Signed-off-by: Valdis Kletnieks 

diff --git a/include/linux/delay.h b/include/linux/delay.h
index b78bab4395d8..8e6828094c1e 100644
--- a/include/linux/delay.h
+++ b/include/linux/delay.h
@@ -55,6 +55,7 @@ static inline void ndelay(unsigned long x)
 
 extern unsigned long lpj_fine;
 void calibrate_delay(void);
+void __attribute__((weak)) calibration_delay_done(void);
 void msleep(unsigned int msecs);
 unsigned long msleep_interruptible(unsigned int msecs);
 void usleep_range(unsigned long min, unsigned long max);

[PATCH] kernel/bpf/cgroup.c - clean up kerneldoc warnings

[valdis . kletnieks]

Building with W=1 reveals some bitrot 

  CC  kernel/bpf/cgroup.o
kernel/bpf/cgroup.c:238: warning: Function parameter or member 'flags' not 
described in '__cgroup_bpf_attach'
kernel/bpf/cgroup.c:367: warning: Function parameter or member 'unused_flags' 
not described in '__cgroup_bpf_detach'

Add a kerneldoc line for 'flags'.

Fixing the warning for 'unused_flags' is best approached by
removing the unused parameter on the function call.

Signed-off-by: Valdis Kletnieks 

diff --git a/include/linux/bpf-cgroup.h b/include/linux/bpf-cgroup.h
index 588dd5f0bd85..695b2a880d9a 100644
--- a/include/linux/bpf-cgroup.h
+++ b/include/linux/bpf-cgroup.h
@@ -78,7 +78,7 @@ int cgroup_bpf_inherit(struct cgroup *cgrp);
 int __cgroup_bpf_attach(struct cgroup *cgrp, struct bpf_prog *prog,
enum bpf_attach_type type, u32 flags);
 int __cgroup_bpf_detach(struct cgroup *cgrp, struct bpf_prog *prog,
-   enum bpf_attach_type type, u32 flags);
+   enum bpf_attach_type type);
 int __cgroup_bpf_query(struct cgroup *cgrp, const union bpf_attr *attr,
   union bpf_attr __user *uattr);
 
diff --git a/kernel/bpf/cgroup.c b/kernel/bpf/cgroup.c
index ab612fe9862f..d78cfec5807d 100644
--- a/kernel/bpf/cgroup.c
+++ b/kernel/bpf/cgroup.c
@@ -230,6 +230,7 @@ static int update_effective_progs(struct cgroup *cgrp,
  * @cgrp: The cgroup which descendants to traverse
  * @prog: A program to attach
  * @type: Type of attach operation
+ * @flags: Option flags
  *
  * Must be called with cgroup_mutex held.
  */
@@ -363,7 +364,7 @@ int __cgroup_bpf_attach(struct cgroup *cgrp, struct 
bpf_prog *prog,
  * Must be called with cgroup_mutex held.
  */
 int __cgroup_bpf_detach(struct cgroup *cgrp, struct bpf_prog *prog,
-   enum bpf_attach_type type, u32 unused_flags)
+   enum bpf_attach_type type)
 {
struct list_head *progs = >bpf.progs[type];
enum bpf_cgroup_storage_type stype;
diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
index 6d03a27918f4..9802ab424397 100644
--- a/kernel/cgroup/cgroup.c
+++ b/kernel/cgroup/cgroup.c
@@ -6059,7 +6059,7 @@ int cgroup_bpf_detach(struct cgroup *cgrp, struct 
bpf_prog *prog,
int ret;
 
mutex_lock(_mutex);
-   ret = __cgroup_bpf_detach(cgrp, prog, type, flags);
+   ret = __cgroup_bpf_detach(cgrp, prog, type);
mutex_unlock(_mutex);
return ret;
 }

[PATCH] include/linux/bpf.h - fix missing prototype warnings...

[valdis . kletnieks]

Compiling with W=1 generates warnings:

  CC  kernel/bpf/core.o
kernel/bpf/core.c:721:12: warning: no previous prototype for 
?bpf_jit_alloc_exec_limit? [-Wmissing-prototypes]
  721 | u64 __weak bpf_jit_alloc_exec_limit(void)
  |^~~~
kernel/bpf/core.c:757:14: warning: no previous prototype for 
?bpf_jit_alloc_exec? [-Wmissing-prototypes]
  757 | void *__weak bpf_jit_alloc_exec(unsigned long size)
  |  ^~
kernel/bpf/core.c:762:13: warning: no previous prototype for 
?bpf_jit_free_exec? [-Wmissing-prototypes]
  762 | void __weak bpf_jit_free_exec(void *addr)
  | ^

All three are weak functions that archs can override, although none do so
currently.  Provide prototypes for when a new arch provides its own.

Signed-off-by: Valdis Kletnieks 

diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index 3851529062ec..99e55313123f 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -472,6 +472,10 @@ _out:  
\
 #define BPF_PROG_RUN_ARRAY_CHECK(array, ctx, func) \
__BPF_PROG_RUN_ARRAY(array, ctx, func, true)
 
+u64 __weak bpf_jit_alloc_exec_limit(void);
+void *__weak bpf_jit_alloc_exec(unsigned long size);
+void __weak bpf_jit_free_exec(void *addr);
+
 #ifdef CONFIG_BPF_SYSCALL
 DECLARE_PER_CPU(int, bpf_prog_active);
 

[PATCH] kernel/bpf/core.c - fix bitrotted kerneldoc.

[valdis . kletnieks]

Over the years, the function signature has changed, the kerneldoc block hasn't.

Signed-off-by: Valdis Kletnieks 

diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
index 2a81b8af3748..2728b6247091 100644
--- a/kernel/bpf/core.c
+++ b/kernel/bpf/core.c
@@ -1216,8 +1216,9 @@ bool bpf_opcode_in_insntable(u8 code)
 #ifndef CONFIG_BPF_JIT_ALWAYS_ON
 /**
  * __bpf_prog_run - run eBPF program on a given context
- * @ctx: is the data we are operating on
+ * @regs: is the array of MAX_BPF_EXT_REG eBPF pseudo-registers
  * @insn: is the array of eBPF instructions
+ * @stack: is the eBPF storage stack
  *
  * Decode and execute eBPF instructions.
  */

Re: [PATCH] bpf/core.c - silence warning messages

[valdis . kletnieks]

On Tue, 29 Jan 2019 00:22:26 +0100, Daniel Borkmann said:
> I think moving in separate file would be overkill, imho. However, lets get
> the kdoc and prototype warning fixed.

I have a bunch of spare time at the moment, so the kdoc and prototype
warnings are on my to-do list.

Re: [PATCH] bpf/core.c - silence warning messages

[valdis . kletnieks]

On Mon, 28 Jan 2019 09:18:45 -0800, Song Liu said:
> On Sun, Jan 27, 2019 at 8:43 PM  wrote:

> > The attached patch silences the warnings, because we *know* we're 
> > overwriting
> > the default initializer. That leaves bpf/core.c with only 6 other warnings,
> > which become more visible in comparison.
>
> My concern is that this will also mute the warning for other parts of
> bpf/core.c.

I checked and there weren't any warnings for other parts of the file.  Also, 
this message
doesn't even happen unless you build with W=1, which apparently happens so 
rarely
that nobody else has submitted a patch.

Is there a high likelihood that another overwrite of an initializer is going to
be included in the source?

> Maybe we should move bpf_opcode_in_insntable() to a separate file, and mute
> warning for that file?

Seems to be overkill - the intent of this patch was mostly to make the *other*
warnings issued with W=1 more noticable.

Re: next-20190125 - objtool complains about dumpstack

[valdis . kletnieks]

On Sun, 27 Jan 2019 22:18:25 -0600, Josh Poimboeuf said:
> On Sun, Jan 27, 2019 at 10:45:03PM -0500, valdis.kletni...@vt.edu wrote:
> > Seen in a build:
> > 
> >   CC  arch/x86/kernel/dumpstack.o
> > arch/x86/kernel/dumpstack.o: warning: objtool: oops_begin()+0x9: undefined 
> > stack state
> > arch/x86/kernel/dumpstack.o: warning: objtool: oops_begin()+0x0: stack 
> > state mismatch: cfa1=6+16 cfa2=7+8
> > 
> > Probably a gcc9 code generation that objtool doesn't know about?
>
> Can you share the .o file?

Sure.  Attached.


ELF


>
€@@)(èUH‰åATA‰ÔSH‰û1ÿè¾
¿Çèƒ-
uÆSè¾HÇÇèE
…äu[A\]Ãe‹©ÿ…ƒ=…
D‰çèDèUH‰åAVAUATSèœA]úè‹1öHÇÇA‰Ä…
Û@•Æ1É1Òè…Û…
–‰Øº
ð±”Ã@•ÆHÇÇ1É1Ò@¶öèD¶ó1ɺ
D‰öHÇÇè1ɺ
D‰öHÇÇè„Ût8‹D‰%ƒ

…Àt
Ç¿
èL‰è[A\A]A^]ÃD9%t¿E1öº
D‰ðð±@•Æ•ÃHÇÇ1É1Ò@¶öA‰Æè„Ûu51ɺ
¾
HÇÇè1ɺ
¾
HÇÇèéUÿÿÿ1É1öº
HÇÇè1ö1ɺ
HÇÇèD‰öHÇÇèéÿÿÿfèUH‰åAUI‰õATI‰üSH‰ÓI‹
…
è
I9Är.H@L9âv"H‰C¸
Ç
H‰SHÇC[A\A]]Ã[1ÀA\A]]ÃfDèUH‰åATI‰üSH‰óè‰ÇèHHI9Ôr%L9àv
 
H‰C¸
ÇH‰SHÇC[A\]Ã[1ÀA\]Ã@èUH‰åAUI‰õATSH‰ûHƒìHeH‹%(H‰Eà1ÀH‹ƒ€öƒˆL`ÖuH}
 º@L‰æèH…À…
éH»Àïÿÿÿ1öHÇÇI9Ü@—Æ1É1ÒèI9܇별èUH‰åAUI‰õATI‰üI‹Œ$€L‰îHÇÇA‹”$ˆèL‰îL‰çèA\A]]Ãff.„fèUH‰åSH‰ûH‰ßHÇÆèH‹‹HÇÇH‹“˜H‹³
 è[]ÃèUH‰åAUI‰õATI‰üM…ät0M…
íueH‹%I9ÄuI‰íL‰êL‰çHÇÁ1öèA\A]]ÃeL‹$%ëÅff.„fèUH‰åATI‰üHÇÇè1öL‰çAö„$ˆ@”ƃÆ
èAö„$ˆ„A\]Ãf„èUH‰åAVI‰ÖAUI‰ýATI‰ôS‹
…Û…
º¨L‰æHÇÇèéèUH‰åAWI‰×AVI‰þAUATI‰ôèL‰úL‰æL‰÷I‰ÅèL‰æL‰ïƒø
҃â
èA\A]A^A_]ÃFatal exception in 
interruptFatal exception%sCode: Bad RIP value.
%sCode: %42ph <%02x> %21ph
%sRIP: %04x:%pS

d? %sCall Trace:
%s <%s>
%s %s%pB
%s 
 PTI NOPTI SMP PREEMPT
d%s: %04lx [#%d]%s%s%s%s%s
arch/x86/include/asm/atomic.hHÇÇèHÇÇèL‰îHÇÇèH‹EàeH3%(u(HƒÄH[A\A]]öMÊLEËL‰îHÇÇHU
 èëÉèèUH‰åATI‰ôSH‰ûƒ;t.H‹SH‹KL9âw!L9ávI„$¨H9ÁrH9Âs
1öL‰çè[A\]ÃèUH‰åAWAVI‰ÎAUI‰õATI‰üSH‰ÓHì¨eH‹%(H‰EÐ1Àè1À¹L‰öH½xÿÿÿHÇ
…Pÿÿÿó«¹DžLÿÿÿH½Xÿÿÿó«HÇÇèH…ÛH‰Ùu'M…ít  
I‹˜ëeH‹%I9ÄH‰étI‹Œ$X&H½xÿÿÿL‰êL‰æèH…Ûu'M…ít   
I‹˜ëeH‹%I9ÄH‰ëtI‹œ$X&E1탽xÿÿÿ„ŸL‹mÈé–HPÿÿÿL‰æH‰ßH•Xÿÿÿè
…À…ƒ‹½XÿÿÿèH…ÀH‰…@ÿÿÿtH‰ÂL‰öHÇÇèM…
ítH½XÿÿÿL‰îèWþÿÿH9hÿÿÿwqHƒ½@ÿÿÿtH‹•@ÿÿÿL‰öHÇÇèH‹…pÿÿÿHXHƒãøH…
Û„=
é\ÿÿÿHÃÿL‰æHPÿÿÿHãðÿÿH•XÿÿÿH‰ßè…
À„Nÿÿÿé
L‹;H½xÿÿÿèH‰…8ÿÿÿL‰ÿè…À„ÕM…ít-I…
€H9Ãu!H½xÿÿÿE1í能xÿÿÿ„¨é‹H‰ÙL‰úL‰çHµLÿÿÿèL9øH‰…
0ÿÿÿt#èèL‰ùL‰öHÇÂHÇÇèèèH;8ÿÿÿL‰öHÇÀH‹0ÿÿÿHÇÂHÇÇHDÐèH;8ÿÿÿuéTÿÿÿL‹mÈM
…
ítH½XÿÿÿL‰îèâüÿÿHƒÃé‚þÿÿH‹EÐeH3%(tèHÄ¨[A\A]A^A_]ÃèUH‰åATI‰üL‰æHÇÁ1ÒeH‹<%èA\]ÃHÇÁ1ÒL‰æeH‹<%èéH‹K
HÇÂL‰îIÇÁIÇÀHÇlj
HÁè+¨
HÇÀHDÂA·ÖPhhèL‰çèèL‰ñL‰âL‰îeH‹%D‹€°&A¹

¿
èHƒÄ=
€”ÀHeà¶À[A\A]A^]Ã
dRSP:
 %04x:%016lx EFLAGS: 

[PATCH] kernel/hung_task.c - fix sparse warnings

[valdis . kletnieks]

sparse complains:

  CHECK   kernel/hung_task.c
kernel/hung_task.c:28:19: warning: symbol 'sysctl_hung_task_check_count' was 
not declared. Should it be static?
kernel/hung_task.c:42:29: warning: symbol 'sysctl_hung_task_timeout_secs' was 
not declared. Should it be static?
kernel/hung_task.c:47:29: warning: symbol 
'sysctl_hung_task_check_interval_secs' was not declared. Should it be static?
kernel/hung_task.c:49:19: warning: symbol 'sysctl_hung_task_warnings' was not 
declared. Should it be static?
kernel/hung_task.c:61:28: warning: symbol 'sysctl_hung_task_panic' was not 
declared. Should it be static?
kernel/hung_task.c:219:5: warning: symbol 'proc_dohung_task_timeout_secs' was 
not declared. Should it be static?

Add the appropriate header file to provide declarations.

Signed-off-by: Valdis Kletnieks 

diff --git a/kernel/hung_task.c b/kernel/hung_task.c
index 4a9191617076..0c11216171c9 100644
--- a/kernel/hung_task.c
+++ b/kernel/hung_task.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 

[PATCH] bpf/core.c - silence warning messages

[valdis . kletnieks]

Compiling kernel/bpf/core.c with W=1 causes a flood of warnings:

kernel/bpf/core.c:1198:65: warning: initialized field overwritten 
[-Woverride-init]
 1198 | #define BPF_INSN_3_TBL(x, y, z) [BPF_##x | BPF_##y | BPF_##z] = true
  | ^~~~
kernel/bpf/core.c:1087:2: note: in expansion of macro 'BPF_INSN_3_TBL'
 1087 |  INSN_3(ALU, ADD,  X),   \
  |  ^~
kernel/bpf/core.c:1202:3: note: in expansion of macro 'BPF_INSN_MAP'
 1202 |   BPF_INSN_MAP(BPF_INSN_2_TBL, BPF_INSN_3_TBL),
  |   ^~~~
kernel/bpf/core.c:1198:65: note: (near initialization for 
'public_insntable[12]')
 1198 | #define BPF_INSN_3_TBL(x, y, z) [BPF_##x | BPF_##y | BPF_##z] = true
  | ^~~~
kernel/bpf/core.c:1087:2: note: in expansion of macro 'BPF_INSN_3_TBL'
 1087 |  INSN_3(ALU, ADD,  X),   \
  |  ^~
kernel/bpf/core.c:1202:3: note: in expansion of macro 'BPF_INSN_MAP'
 1202 |   BPF_INSN_MAP(BPF_INSN_2_TBL, BPF_INSN_3_TBL),
  |   ^~~~

98 copies of the above.

The attached patch silences the warnings, because we *know* we're overwriting
the default initializer. That leaves bpf/core.c with only 6 other warnings,
which become more visible in comparison.

Signed-off-by: Valdis Kletnieks 

diff --git a/kernel/bpf/Makefile b/kernel/bpf/Makefile
index 4c2fa3ac56f6..2606665f2cb5 100644
--- a/kernel/bpf/Makefile
+++ b/kernel/bpf/Makefile
@@ -21,3 +21,4 @@ obj-$(CONFIG_CGROUP_BPF) += cgroup.o
 ifeq ($(CONFIG_INET),y)
 obj-$(CONFIG_BPF_SYSCALL) += reuseport_array.o
 endif
+CFLAGS_core.o  += $(call cc-disable-warning, override-init)

next-20190125 - objtool complains about dumpstack

[valdis . kletnieks]

Seen in a build:

  CC  arch/x86/kernel/dumpstack.o
arch/x86/kernel/dumpstack.o: warning: objtool: oops_begin()+0x9: undefined 
stack state
arch/x86/kernel/dumpstack.o: warning: objtool: oops_begin()+0x0: stack state 
mismatch: cfa1=6+16 cfa2=7+8

Probably a gcc9 code generation that objtool doesn't know about?

Re: [PATCH] staging:iio:ad7152: Rename misspelled RESEVERD -> RESERVED

[valdis . kletnieks]

On Fri, 25 Jan 2019 22:14:32 -0200, Rodrigo Ribeiro said:
> Maybe, one checkstyle patch is enough, right? Which drivers can I truly
> contribute to?

I'll give you a pointer to the "How to contribute" the Kernel Newbies list and 
IRC
channel uses:

https://lists.kernelnewbies.org/pipermail/kernelnewbies/2017-April/017765.html

Re: [PATCH] drivers: iio: industrialio-core: add check when kzalloc fails

[valdis . kletnieks]

On Thu, 24 Jan 2019 19:58:00 +0530, Bharath Vedartham said:
> add code to handle the case when kzalloc fails to allocate memory to dev
>
> Signed-off-by: Bharath Vedartham 

>   dev_set_name(>dev, "iio:device%d", dev->id);
>   INIT_LIST_HEAD(>buffer_list);
> + } else {
> + return NULL;
>   }
>  
>   return dev;

Not needed, as the 'if (dev)' statement fails, dev is already null.

Re: [regression -next0117] What is kcompactd and why is he eating 100% of my cpu?

[valdis . kletnieks]

On Sun, 27 Jan 2019 17:00:27 +0100, Pavel Machek said:
> > > I've noticed this as well on earlier kernels (next-20181224 to 20190115)
> > > Some more info:
> > > 1) echo 3 > /proc/sys/vm/drop_caches  unwedges kcompactd in 1-3 seconds.
> > This aspect is curious as it indicates that kcompactd could potentially
> > be infinite looping but it's not something I've experienced myself. By
> > any chance is there a preditable reproduction case for this?
>
> I seen it exactly once, so not sure how reproducible this is. x86-32
> machine, running chromium browser, so yes, there was some swapping
> involved.

I don't have a surefire replicator, but my laptop (x86_64, so it's not a 32-bit
only issue) triggers it fairly often, up to multiple times a day. Doesn't seem 
to
be just the Chrome browser that triggers it - usually I'm doing other stuff as
well, like a compile or similar.  The fact that 'drop_caches' clears it  makes 
me
wonder if we're hitting a corner case where cache data isn't being automatically
cleared and clogging something up.

Any particular diagnostic info you want me to get next time it hits?  (Am
currently on next-20190125, if that matters).

Re: [regression -next0117] What is kcompactd and why is he eating 100% of my cpu?

[valdis . kletnieks]

On Sat, 26 Jan 2019 21:00:05 +0100, Pavel Machek said:

> top - 13:38:51 up  1:42, 16 users,  load average: 1.41, 1.93, 1.62
> Tasks: 182 total,   3 running, 138 sleeping,   0 stopped,   0 zombie
> %Cpu(s):  2.3 us, 57.8 sy,  0.0 ni, 39.9 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 
> st
> KiB Mem:   3020044 total,  2429420 used,   590624 free,27468 buffers
> KiB Swap:  2097148 total,0 used,  2097148 free.  1924268 cached Mem
>
>   PID USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+ COMMAND
>   608 root  20   0   0  0  0 R  99.6  0.0  11:34.38 kcompactd0
>  9782 root  20   0   0  0  0 I   7.9  0.0   0:59.02 kworker/0:
>  2971 root  20   0   46624  23076  13576 S   4.3  0.8   2:50.22 Xorg

I've noticed this as well on earlier kernels (next-20181224 to 20190115)

Some more info:

1) echo 3 > /proc/sys/vm/drop_caches  unwedges kcompactd in 1-3 seconds.

2) Typical kcompactd traceback:

cat /proc/27/stack
[<0>] retint_kernel+0x1b/0x2d
[<0>] lock_is_held_type+0x1b/0x50
[<0>] ___might_sleep+0xad/0x220
[<0>] __might_sleep+0x113/0x130
[<0>] on_each_cpu_cond_mask+0x12a/0x140
[<0>] on_each_cpu_cond+0x18/0x20
[<0>] invalidate_bh_lrus+0x29/0x30
[<0>] __buffer_migrate_page+0x154/0x340
[<0>] buffer_migrate_page_norefs+0x14/0x20
[<0>] move_to_new_page+0x8e/0x360
[<0>] migrate_pages+0x3cc/0xfd8
[<0>] compact_zone+0xb70/0x1380
[<0>] kcompactd_do_work+0x15b/0x500
[<0>] kcompactd+0x74/0x340
[<0>] kthread+0x158/0x170
[<0>] ret_from_fork+0x3a/0x50
[<0>] 0x

I've also seen khugepaged hung up:

cat /proc/29/stack
[<0>] ___preempt_schedule+0x16/0x18
[<0>] page_vma_mapped_walk+0x60/0x840
[<0>] remove_migration_pte+0x67/0x390
[<0>] rmap_walk_file+0x186/0x380
[<0>] rmap_walk+0xa3/0xd0
[<0>] remove_migration_ptes+0x69/0x70
[<0>] migrate_pages+0xb6d/0xfd8
[<0>] compact_zone+0xb70/0x1370
[<0>] compact_zone_order+0xd8/0x120
[<0>] try_to_compact_pages+0xe5/0x550
[<0>] __alloc_pages_direct_compact+0x6d/0x1a0
[<0>] __alloc_pages_slowpath+0x6c9/0x1640
[<0>] __alloc_pages_nodemask+0x558/0x5b0
[<0>] khugepaged+0x499/0x810
[<0>] kthread+0x158/0x170
[<0>] ret_from_fork+0x3a/0x50
[<0>] 0x

Looks like something has gone astray with compact_zone.

Re: Heads up: next-20190115 and GCC 9.0 don't play nice.

[valdis . kletnieks]

On Fri, 25 Jan 2019 22:02:05 -0500, valdis.kletni...@vt.edu said:
> So a GCC 9 escaped to Fedora Rawhide in the last few days, and things didn't
> go well. Fortunately, I had the 8.2.1-7 RPMs still around.
>
> Issue 1: There's a new warning added for taking the address of a member of
> a packed array. It wasn't *too* noisy.
>
> Issue 2: Looks like it's not ready for prime time.

Jakub Jelinek informed me that gcc-9.0.1-0.1.fc30.x86_64 was out, and
I've confirmed that *this* issue is fixed.  Off to go see what breaks next. :)

Heads up: next-20190115 and GCC 9.0 don't play nice.

[valdis . kletnieks]

So a GCC 9 escaped to Fedora Rawhide in the last few days, and things didn't
go well. Fortunately, I had the 8.2.1-7 RPMs still around.

Issue 1: There's a new warning added for taking the address of a member of
a packed array. It wasn't *too* noisy.

Issue 2: Looks like it's not ready for prime time.

  CC [M]  fs/ntfs/super.o
fs/ntfs/super.c: In function 'is_boot_sector_ntfs':
fs/ntfs/super.c:597:3: warning: converting a packed 'const NTFS_BOOT_SECTOR *' 
{aka 'const struct  *'} pointer (alignment 1) to 'le32' {aka 
'unsigned int'} (alignment 4) may result in an unaligned pointer value 
[-Waddress-of-packed-member]
  597 |   for (i = 0, u = (le32*)b; u < (le32*)(>checksum); ++u)
  |   ^~~
fs/ntfs/super.c:597:3: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Preprocessed source stored into /tmp/cc0KDLoH.out file, please attach this to 
your bugreport.
make[2]: *** [scripts/Makefile.build:277: fs/ntfs/super.o] Error 1
make[1]: *** [scripts/Makefile.build:491: fs/ntfs] Error 2
make: *** [Makefile:1044: fs] Error 2

I've reported this to the RedHat/Fedora crew as:
https://bugzilla.redhat.com/show_bug.cgi?id=1669696

Re: [PATCH v3 1/2] mm: Add an F_SEAL_FUTURE_WRITE seal to memfd

[valdis . kletnieks]

On Fri, 19 Oct 2018 10:57:31 -0700, Joel Fernandes said:
> On Fri, Oct 19, 2018 at 10:32 AM,   wrote:
> > What is supposed to happen if some other process has an already existing R/W
> > mmap of the region?  (For that matter, the test program doesn't seem to
> > actually test that the existing mmap region remains writable?)

> Why would it not remain writable? We don't change anything in the
> mapping that prevents it from being writable, in the patch.

OK, if the meaning here is "if another process races and gets its own R/W mmap
before we seal our mmap, it's OK".  Seems like somewhat shaky security-wise - a
possibly malicious process can fail to get a R/W map because we just sealed it,
but if it had done the attempt a few milliseconds earlier it would have its own
R/W mmap to do as it pleases...

On the other hand, decades of trying have proven that trying to do any sort
of revoke() is a lot harder to do than it looks...

> We do test that existing writable mmaps can continue to exist after
> the seal is set, in a way, because we test that setting of the seal
> succeeds.

Well, if the semantics are "We don't bother trying to deal with existing R/W
maps", then it doesn't really matter - I was thinking along the lines of "If 
we're
revoking other R/W accesses, we should test that we didn't nuke *this* one in
the bargain"


pgpEQueRIE3QI.pgp
Description: PGP signature

Re: [PATCH v3 1/2] mm: Add an F_SEAL_FUTURE_WRITE seal to memfd

[valdis . kletnieks]

On Fri, 19 Oct 2018 10:57:31 -0700, Joel Fernandes said:
> On Fri, Oct 19, 2018 at 10:32 AM,   wrote:
> > What is supposed to happen if some other process has an already existing R/W
> > mmap of the region?  (For that matter, the test program doesn't seem to
> > actually test that the existing mmap region remains writable?)

> Why would it not remain writable? We don't change anything in the
> mapping that prevents it from being writable, in the patch.

OK, if the meaning here is "if another process races and gets its own R/W mmap
before we seal our mmap, it's OK".  Seems like somewhat shaky security-wise - a
possibly malicious process can fail to get a R/W map because we just sealed it,
but if it had done the attempt a few milliseconds earlier it would have its own
R/W mmap to do as it pleases...

On the other hand, decades of trying have proven that trying to do any sort
of revoke() is a lot harder to do than it looks...

> We do test that existing writable mmaps can continue to exist after
> the seal is set, in a way, because we test that setting of the seal
> succeeds.

Well, if the semantics are "We don't bother trying to deal with existing R/W
maps", then it doesn't really matter - I was thinking along the lines of "If 
we're
revoking other R/W accesses, we should test that we didn't nuke *this* one in
the bargain"


pgpEQueRIE3QI.pgp
Description: PGP signature

Re: [PATCH v3 1/2] mm: Add an F_SEAL_FUTURE_WRITE seal to memfd

[valdis . kletnieks]

On Wed, 17 Oct 2018 23:59:07 -0700, "Joel Fernandes (Google)" said:
> This usecase cannot be implemented with the existing F_SEAL_WRITE seal.
> To support the usecase, this patch adds a new F_SEAL_FUTURE_WRITE seal
> which prevents any future mmap and write syscalls from succeeding while
> keeping the existing mmap active. The following program shows the seal
> working in action:

What is supposed to happen if some other process has an already existing R/W
mmap of the region?  (For that matter, the test program doesn't seem to
actually test that the existing mmap region remains writable?)



pgp4RRGD0zTrw.pgp
Description: PGP signature

Re: [PATCH v3 1/2] mm: Add an F_SEAL_FUTURE_WRITE seal to memfd

[valdis . kletnieks]

On Wed, 17 Oct 2018 23:59:07 -0700, "Joel Fernandes (Google)" said:
> This usecase cannot be implemented with the existing F_SEAL_WRITE seal.
> To support the usecase, this patch adds a new F_SEAL_FUTURE_WRITE seal
> which prevents any future mmap and write syscalls from succeeding while
> keeping the existing mmap active. The following program shows the seal
> working in action:

What is supposed to happen if some other process has an already existing R/W
mmap of the region?  (For that matter, the test program doesn't seem to
actually test that the existing mmap region remains writable?)



pgp4RRGD0zTrw.pgp
Description: PGP signature

Re: [PATCH v2] of: overlay: user space synchronization

[valdis . kletnieks]

On Mon, 15 Oct 2018 17:27:01 -0700, frowand.l...@gmail.com said:
> From: Frank Rowand 
>
> When an overlay is applied or removed, the live devicetree visible in
> /proc/device-tree/, aka /sys/firmware/devicetree/base/, reflects the
> changes.  There is no method for user space to determine whether the
> live devicetree was modified by overlay actions.
>
> Provide a sysfs file, /sys/firmware/devicetree/tree_version,  to allow
> user space to determine if the live devicetree has remained unchanged
> while a series of one or more accesses of /proc/device-tree/ occur.
>
> The use of both dynamic devicetree modifications and overlay apply and
> removal are not supported during the same boot cycle.  Thus non-overlay
> dynamic modifications are not reflected in the value of tree_version.

Is there an easy way from userspace to detect "yes/no dynamic modifications
have been done since boot"?


pgpSbaqLTN9rx.pgp
Description: PGP signature

Re: [PATCH v2] of: overlay: user space synchronization

[valdis . kletnieks]

On Mon, 15 Oct 2018 17:27:01 -0700, frowand.l...@gmail.com said:
> From: Frank Rowand 
>
> When an overlay is applied or removed, the live devicetree visible in
> /proc/device-tree/, aka /sys/firmware/devicetree/base/, reflects the
> changes.  There is no method for user space to determine whether the
> live devicetree was modified by overlay actions.
>
> Provide a sysfs file, /sys/firmware/devicetree/tree_version,  to allow
> user space to determine if the live devicetree has remained unchanged
> while a series of one or more accesses of /proc/device-tree/ occur.
>
> The use of both dynamic devicetree modifications and overlay apply and
> removal are not supported during the same boot cycle.  Thus non-overlay
> dynamic modifications are not reflected in the value of tree_version.

Is there an easy way from userspace to detect "yes/no dynamic modifications
have been done since boot"?


pgpSbaqLTN9rx.pgp
Description: PGP signature

Re: [PATCH] kernel/signal: Signal-based pre-coredump notification

[valdis . kletnieks]

On Mon, 15 Oct 2018 18:28:03 -0500, Eric W. Biederman said:
> Enke Chen  writes:
>
> > For simplicity and consistency, this patch provides an implementation
> > for signal-based fault notification prior to the coredump of a child
> > process. A new prctl command, PR_SET_PREDUMP_SIG, is defined that can
> > be used by an application to express its interest and to specify the
> > signal (SIGCHLD or SIGUSR1 or SIGUSR2) for such a notification. A new
> > signal code (si_code), CLD_PREDUMP, is also defined for SIGCHLD.
> >
> > Background:
> >
> > As the coredump of a process may take time, in certain time-sensitive
> > applications it is necessary for a parent process (e.g., a process
> > manager) to be notified of a child's imminent death before the coredump
> > so that the parent process can act sooner, such as re-spawning an
> > application process, or initiating a control-plane fail-over.
>
> You talk about time senstive and then you talk about bash scripts.
> I don't think your definition of time-sensitive and my definition match.

When the process image is measured in hundreds of gigabytes, the corefile can
take a while even by /bin/bash standards.  You want fun, watch an HPC process
manage to OOM a machine with 3T of RAM in a way that produces a full image
coredump.

To network storage.



pgpfkOg6G86es.pgp
Description: PGP signature

Re: [PATCH] kernel/signal: Signal-based pre-coredump notification

[valdis . kletnieks]

On Mon, 15 Oct 2018 18:28:03 -0500, Eric W. Biederman said:
> Enke Chen  writes:
>
> > For simplicity and consistency, this patch provides an implementation
> > for signal-based fault notification prior to the coredump of a child
> > process. A new prctl command, PR_SET_PREDUMP_SIG, is defined that can
> > be used by an application to express its interest and to specify the
> > signal (SIGCHLD or SIGUSR1 or SIGUSR2) for such a notification. A new
> > signal code (si_code), CLD_PREDUMP, is also defined for SIGCHLD.
> >
> > Background:
> >
> > As the coredump of a process may take time, in certain time-sensitive
> > applications it is necessary for a parent process (e.g., a process
> > manager) to be notified of a child's imminent death before the coredump
> > so that the parent process can act sooner, such as re-spawning an
> > application process, or initiating a control-plane fail-over.
>
> You talk about time senstive and then you talk about bash scripts.
> I don't think your definition of time-sensitive and my definition match.

When the process image is measured in hundreds of gigabytes, the corefile can
take a while even by /bin/bash standards.  You want fun, watch an HPC process
manage to OOM a machine with 3T of RAM in a way that produces a full image
coredump.

To network storage.



pgpfkOg6G86es.pgp
Description: PGP signature

[BUG] ext4 null pointer crash in linux-next

[valdis . kletnieks]

I'm seeing a fairly replicable crash/hang with a traceback implicating ext4 (or
possibly the block layer). next-20180918 seemed stable, but next-20180926 and
-next-20181005 have a habit of crashing while dnf is updating software (so far,
I've hit it 6 times with identical tracebacks while attempting to update 
software

This ringing any bells, or did I just buy myself another git bisect? Google says
that ext4_mpage_readpages from the traceback hasn't been referenced in the
last 2 months...

[  680.692888] BUG: unable to handle kernel NULL pointer dereference at 

[  680.692895] PGD 0 P4D 0
[  680.692901] Oops:  [#1] PREEMPT SMP PTI
[  680.692905] CPU: 3 PID: 15464 Comm: sh Tainted: G   OT 
4.19.0-rc6-next-20181005-dirty #621
[  680.692908] Hardware name: Dell Inc. Latitude E6530/07Y85M, BIOS A21 
02/21/2018
[  680.692915] RIP: 0010:__get_request+0x31/0x7e0
[  680.692918] Code: 89 e5 41 57 41 56 41 55 49 89 fd 41 54 41 89 f4 53 48 83 
ec 50 48 8b 1f 48 85 d2 48 89 55 b8 89 4d c0 44 89 45 c4 48 8b 43 18 <48> 8b 00 
48 89 45 b0 0f 84 ba 03 00 00 48 8b 42 58 48 85 c0 48 89
[  680.692921] RSP: 0018:9fa98d93f578 EFLAGS: 00010086
[  680.692925] RAX:  RBX: 975ad40e7040 RCX: 
[  680.692927] RDX: 975aac306e00 RSI: 0008 RDI: 975acce39840
[  680.692930] RBP: 9fa98d93f5f0 R08: 0060 R09: 0001
[  680.692933] R10:  R11:  R12: 0008
[  680.692935] R13: 975acce39840 R14: 975aac306e00 R15: 975acce398c0
[  680.692938] FS:  7f8fb7876740() GS:975adda0() 
knlGS:
[  680.692941] CS:  0010 DS:  ES:  CR0: 80050033
[  680.692944] CR2:  CR3: 0003ebc64006 CR4: 001606e0
[  680.692946] Call Trace:
[  680.692957]  get_request+0x214/0x8b0
[  680.692964]  ? remove_wait_queue+0x70/0x70
[  680.692971]  blk_queue_bio+0x23b/0x760
[  680.692977]  generic_make_request+0x2fe/0x570
[  680.692983]  submit_bio+0x4d/0x190
[  680.692987]  ? submit_bio+0x4d/0x190
[  680.692992]  ? bio_add_page+0x4b/0x60
[  680.692997]  ext4_mpage_readpages+0x814/0xed4
[  680.693002]  ? get_page_from_freelist+0x42c/0x1bd0
[  680.693015]  ext4_readpages+0x55/0x60
[  680.693020]  read_pages+0x72/0x190
[  680.693031]  __do_page_cache_readahead+0x1f6/0x220
[  680.693045]  ondemand_readahead+0x2ae/0x4f0
[  680.693055]  page_cache_sync_readahead+0x112/0x250
[  680.693065]  generic_file_buffered_read+0x542/0xf70
[  680.693079]  ? _raw_spin_unlock_irqrestore+0x78/0xa0
[  680.693087]  ? avc_update_node+0x1b6/0x2c0
[  680.693095]  generic_file_read_iter+0xd0/0x140
[  680.693102]  ext4_file_read_iter+0x6c/0x80
[  680.693107]  new_sync_read+0x121/0x1a0
[  680.693116]  __vfs_read+0x49/0x60
[  680.693120]  vfs_read+0x152/0x250
[  680.693126]  kernel_read+0x43/0x60
[  680.693131]  prepare_binprm+0x19b/0x1f0
[  680.693136]  __do_execve_file+0x5ca/0xbc0
[  680.693142]  __x64_sys_execve+0x38/0x50
[  680.693148]  do_syscall_64+0x8f/0xa52
[  680.693152]  ? trace_hardirqs_off_caller+0x22/0x150
[  680.693156]  ? trace_hardirqs_off_thunk+0x1a/0x1c
[  680.693162]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
[  680.693165] RIP: 0033:0x7f8fb7942b5b
[  680.693169] Code: 41 89 01 eb da 66 2e 0f 1f 84 00 00 00 00 00 f7 d8 64 41 
89 01 eb d6 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 3b 00 00 00 0f 05 <48> 3d 01 
f0 ff ff 73 01 c3 48 8b 0d fd 62 0f 00 f7 d8 64 89 01 48




pgpDBACIQBpxu.pgp
Description: PGP signature

[BUG] ext4 null pointer crash in linux-next

[valdis . kletnieks]

I'm seeing a fairly replicable crash/hang with a traceback implicating ext4 (or
possibly the block layer). next-20180918 seemed stable, but next-20180926 and
-next-20181005 have a habit of crashing while dnf is updating software (so far,
I've hit it 6 times with identical tracebacks while attempting to update 
software

This ringing any bells, or did I just buy myself another git bisect? Google says
that ext4_mpage_readpages from the traceback hasn't been referenced in the
last 2 months...

[  680.692888] BUG: unable to handle kernel NULL pointer dereference at 

[  680.692895] PGD 0 P4D 0
[  680.692901] Oops:  [#1] PREEMPT SMP PTI
[  680.692905] CPU: 3 PID: 15464 Comm: sh Tainted: G   OT 
4.19.0-rc6-next-20181005-dirty #621
[  680.692908] Hardware name: Dell Inc. Latitude E6530/07Y85M, BIOS A21 
02/21/2018
[  680.692915] RIP: 0010:__get_request+0x31/0x7e0
[  680.692918] Code: 89 e5 41 57 41 56 41 55 49 89 fd 41 54 41 89 f4 53 48 83 
ec 50 48 8b 1f 48 85 d2 48 89 55 b8 89 4d c0 44 89 45 c4 48 8b 43 18 <48> 8b 00 
48 89 45 b0 0f 84 ba 03 00 00 48 8b 42 58 48 85 c0 48 89
[  680.692921] RSP: 0018:9fa98d93f578 EFLAGS: 00010086
[  680.692925] RAX:  RBX: 975ad40e7040 RCX: 
[  680.692927] RDX: 975aac306e00 RSI: 0008 RDI: 975acce39840
[  680.692930] RBP: 9fa98d93f5f0 R08: 0060 R09: 0001
[  680.692933] R10:  R11:  R12: 0008
[  680.692935] R13: 975acce39840 R14: 975aac306e00 R15: 975acce398c0
[  680.692938] FS:  7f8fb7876740() GS:975adda0() 
knlGS:
[  680.692941] CS:  0010 DS:  ES:  CR0: 80050033
[  680.692944] CR2:  CR3: 0003ebc64006 CR4: 001606e0
[  680.692946] Call Trace:
[  680.692957]  get_request+0x214/0x8b0
[  680.692964]  ? remove_wait_queue+0x70/0x70
[  680.692971]  blk_queue_bio+0x23b/0x760
[  680.692977]  generic_make_request+0x2fe/0x570
[  680.692983]  submit_bio+0x4d/0x190
[  680.692987]  ? submit_bio+0x4d/0x190
[  680.692992]  ? bio_add_page+0x4b/0x60
[  680.692997]  ext4_mpage_readpages+0x814/0xed4
[  680.693002]  ? get_page_from_freelist+0x42c/0x1bd0
[  680.693015]  ext4_readpages+0x55/0x60
[  680.693020]  read_pages+0x72/0x190
[  680.693031]  __do_page_cache_readahead+0x1f6/0x220
[  680.693045]  ondemand_readahead+0x2ae/0x4f0
[  680.693055]  page_cache_sync_readahead+0x112/0x250
[  680.693065]  generic_file_buffered_read+0x542/0xf70
[  680.693079]  ? _raw_spin_unlock_irqrestore+0x78/0xa0
[  680.693087]  ? avc_update_node+0x1b6/0x2c0
[  680.693095]  generic_file_read_iter+0xd0/0x140
[  680.693102]  ext4_file_read_iter+0x6c/0x80
[  680.693107]  new_sync_read+0x121/0x1a0
[  680.693116]  __vfs_read+0x49/0x60
[  680.693120]  vfs_read+0x152/0x250
[  680.693126]  kernel_read+0x43/0x60
[  680.693131]  prepare_binprm+0x19b/0x1f0
[  680.693136]  __do_execve_file+0x5ca/0xbc0
[  680.693142]  __x64_sys_execve+0x38/0x50
[  680.693148]  do_syscall_64+0x8f/0xa52
[  680.693152]  ? trace_hardirqs_off_caller+0x22/0x150
[  680.693156]  ? trace_hardirqs_off_thunk+0x1a/0x1c
[  680.693162]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
[  680.693165] RIP: 0033:0x7f8fb7942b5b
[  680.693169] Code: 41 89 01 eb da 66 2e 0f 1f 84 00 00 00 00 00 f7 d8 64 41 
89 01 eb d6 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 3b 00 00 00 0f 05 <48> 3d 01 
f0 ff ff 73 01 c3 48 8b 0d fd 62 0f 00 f7 d8 64 89 01 48




pgpDBACIQBpxu.pgp
Description: PGP signature

Re: [PATCH 11/11] ASoC: wm8994: Mark expected switch fall-through

[valdis . kletnieks]

On Fri, 03 Aug 2018 11:56:12 -0500, "Gustavo A. R. Silva" said:
> On 08/03/2018 11:45 AM, Mark Brown wrote:
> > Basically nobody ever uses OPCLK so I'd be susprised if anyone ever
> > noticed.

I wonder if nobody uses it because any attempts to do so get an error? :)

> I see. I wonder what's the best approach in this case. Should that code be
> removed instead of 'fixed'?

I'm thinking that's a spot that needs a 'break;' added.

Of course, my understanding of that code is limited to looking at the first 10
patches and the fall-through hit something reasonable, and then the last
one did a fall-through to an error return.


pgp7XmtJgZBV7.pgp
Description: PGP signature

Re: [PATCH 11/11] ASoC: wm8994: Mark expected switch fall-through

[valdis . kletnieks]

On Fri, 03 Aug 2018 11:56:12 -0500, "Gustavo A. R. Silva" said:
> On 08/03/2018 11:45 AM, Mark Brown wrote:
> > Basically nobody ever uses OPCLK so I'd be susprised if anyone ever
> > noticed.

I wonder if nobody uses it because any attempts to do so get an error? :)

> I see. I wonder what's the best approach in this case. Should that code be
> removed instead of 'fixed'?

I'm thinking that's a spot that needs a 'break;' added.

Of course, my understanding of that code is limited to looking at the first 10
patches and the fall-through hit something reasonable, and then the last
one did a fall-through to an error return.


pgp7XmtJgZBV7.pgp
Description: PGP signature

Re: [PATCH 11/11] ASoC: wm8994: Mark expected switch fall-through

[valdis . kletnieks]

On Wed, 01 Aug 2018 14:56:16 -0500, "Gustavo A. R. Silva" said:

> diff --git a/sound/soc/codecs/wm8994.c b/sound/soc/codecs/wm8994.c
> index 7fdfdf3..62f8c5b 100644
> --- a/sound/soc/codecs/wm8994.c
> +++ b/sound/soc/codecs/wm8994.c
> @@ -2432,6 +2432,7 @@ static int wm8994_set_dai_sysclk(struct snd_soc_dai 
> *dai,
>   snd_soc_component_update_bits(component, 
> WM8994_POWER_MANAGEMENT_2,
>   WM8994_OPCLK_ENA, 0);
>   }
> + /* fall through */
>
>   default:
>   return -EINVAL;

Wait, what? This looks like the sort of bug -Wimplicit-fallthrough is supposed
to catch.  Unless for 'case WM8994_SYSCLK_OPCLK:' we actually do want to do a
whole bunch of snd_soc_component_update_bits() calls and then return -EINVAL
whether or not that case succeeded?




pgpDgYKeTAoYz.pgp
Description: PGP signature

Re: [PATCH 11/11] ASoC: wm8994: Mark expected switch fall-through

[valdis . kletnieks]

On Wed, 01 Aug 2018 14:56:16 -0500, "Gustavo A. R. Silva" said:

> diff --git a/sound/soc/codecs/wm8994.c b/sound/soc/codecs/wm8994.c
> index 7fdfdf3..62f8c5b 100644
> --- a/sound/soc/codecs/wm8994.c
> +++ b/sound/soc/codecs/wm8994.c
> @@ -2432,6 +2432,7 @@ static int wm8994_set_dai_sysclk(struct snd_soc_dai 
> *dai,
>   snd_soc_component_update_bits(component, 
> WM8994_POWER_MANAGEMENT_2,
>   WM8994_OPCLK_ENA, 0);
>   }
> + /* fall through */
>
>   default:
>   return -EINVAL;

Wait, what? This looks like the sort of bug -Wimplicit-fallthrough is supposed
to catch.  Unless for 'case WM8994_SYSCLK_OPCLK:' we actually do want to do a
whole bunch of snd_soc_component_update_bits() calls and then return -EINVAL
whether or not that case succeeded?




pgpDgYKeTAoYz.pgp
Description: PGP signature

Re: [PATCH] radix-tree: avoid NULL dereference

[valdis . kletnieks]

On Fri, 06 Jul 2018 14:41:44 +0100, Mark Rutland said:

> I beleive this is what Valdis hit [1] back in March. I spotted this while
> booting an arm64 machine.

Yes, the stack trace is the same.  The odd part is that I was consistently
seeing it until next-20180626, but it evaporated in sometime between that and
next-20180703. I suspect it has to do with the fact that -0626 was compiled
with gcc 8.1.1-3.fc29, but -0703 with 8.1.1.-4.fc29. As such, I probably won't
be able to test the patch without downgrading gcc



pgprGSpnvHUZv.pgp
Description: PGP signature

Re: [PATCH] radix-tree: avoid NULL dereference

[valdis . kletnieks]

On Fri, 06 Jul 2018 14:41:44 +0100, Mark Rutland said:

> I beleive this is what Valdis hit [1] back in March. I spotted this while
> booting an arm64 machine.

Yes, the stack trace is the same.  The odd part is that I was consistently
seeing it until next-20180626, but it evaporated in sometime between that and
next-20180703. I suspect it has to do with the fact that -0626 was compiled
with gcc 8.1.1-3.fc29, but -0703 with 8.1.1.-4.fc29. As such, I probably won't
be able to test the patch without downgrading gcc



pgprGSpnvHUZv.pgp
Description: PGP signature

Re: [PATCH v2 1/4] vt: preserve unicode values corresponding to screen characters

[valdis . kletnieks]

On Sun, 17 Jun 2018 19:17:51 -0400, Nicolas Pitre said:
> On Sun, 17 Jun 2018, valdis.kletni...@vt.edu wrote:

> > This preprocessor variable seems to be dangling in the breeze, with
> > no way for it to get set?  As a result, we pick up the #else define by
> > default.
>
> That's actually what's intended here.
>
> If vc_screen.c ever becomes configurable then this could be used to
> compile out this code. Or if someone wants to disable it for some
> debugging reasons. For now it is just a self-explanatory placeholder
> with very little chance of being set by mistake for any other purpose.

Oh, OK.  It's code that makes sense if it's intentional - but could just as
easily been an unintended debugging/whatever leftover...


pgp3IC9_SYZp7.pgp
Description: PGP signature

Re: [PATCH v2 1/4] vt: preserve unicode values corresponding to screen characters

[valdis . kletnieks]

On Sun, 17 Jun 2018 19:17:51 -0400, Nicolas Pitre said:
> On Sun, 17 Jun 2018, valdis.kletni...@vt.edu wrote:

> > This preprocessor variable seems to be dangling in the breeze, with
> > no way for it to get set?  As a result, we pick up the #else define by
> > default.
>
> That's actually what's intended here.
>
> If vc_screen.c ever becomes configurable then this could be used to
> compile out this code. Or if someone wants to disable it for some
> debugging reasons. For now it is just a self-explanatory placeholder
> with very little chance of being set by mistake for any other purpose.

Oh, OK.  It's code that makes sense if it's intentional - but could just as
easily been an unintended debugging/whatever leftover...


pgp3IC9_SYZp7.pgp
Description: PGP signature

Re: wmi: usercopy: Kernel memory overwrite attempt detected to spans multiple pages (offset 0, size 4104)

[valdis . kletnieks]

On Sun, 17 Jun 2018 22:30:27 +0300, Mihai Donțu said:

> Your patch works OK for me, thank you. The libsmbios tool, however, not
> so much. It appears to be behind latest developments.
>
> # echo "+keyboard" >/sys/class/leds/dell\:\:kbd_backlight/start_triggers
>
> is all that is needed today.

If you're ever in this remote corner of southwest Virginia, I owe you a 
beverage.
I was going bonkers trying to figure out why my Dell Latitude's keyboard no
longer had a backlight... (and wondering if I was going to need to replace it
*again* - this laptop is 5 years old and on its third keyboard already)


pgpj8OHD4mHGb.pgp
Description: PGP signature

Re: wmi: usercopy: Kernel memory overwrite attempt detected to spans multiple pages (offset 0, size 4104)

[valdis . kletnieks]

On Sun, 17 Jun 2018 22:30:27 +0300, Mihai Donțu said:

> Your patch works OK for me, thank you. The libsmbios tool, however, not
> so much. It appears to be behind latest developments.
>
> # echo "+keyboard" >/sys/class/leds/dell\:\:kbd_backlight/start_triggers
>
> is all that is needed today.

If you're ever in this remote corner of southwest Virginia, I owe you a 
beverage.
I was going bonkers trying to figure out why my Dell Latitude's keyboard no
longer had a backlight... (and wondering if I was going to need to replace it
*again* - this laptop is 5 years old and on its third keyboard already)


pgpj8OHD4mHGb.pgp
Description: PGP signature

Re: [PATCH v2 1/4] vt: preserve unicode values corresponding to screen characters

[valdis . kletnieks]

On Sun, 17 Jun 2018 15:07:03 -0400, Nicolas Pitre said:

> diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
> index 1eb1a376a0..7b636638b3 100644
> --- a/drivers/tty/vt/vt.c
> +++ b/drivers/tty/vt/vt.c
> @@ -317,6 +317,171 @@ void schedule_console_callback(void)
>   schedule_work(_work);
>  }
>
> +/*
> + * Code to manage unicode-based screen buffers
> + */
> +
> +#ifdef NO_VC_UNI_SCREEN

This preprocessor variable seems to be dangling in the breeze, with
no way for it to get set?  As a result, we pick up the #else define by
default.


pgpOfrCGm5EYX.pgp
Description: PGP signature

Re: [PATCH v2 1/4] vt: preserve unicode values corresponding to screen characters

[valdis . kletnieks]

On Sun, 17 Jun 2018 15:07:03 -0400, Nicolas Pitre said:

> diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
> index 1eb1a376a0..7b636638b3 100644
> --- a/drivers/tty/vt/vt.c
> +++ b/drivers/tty/vt/vt.c
> @@ -317,6 +317,171 @@ void schedule_console_callback(void)
>   schedule_work(_work);
>  }
>
> +/*
> + * Code to manage unicode-based screen buffers
> + */
> +
> +#ifdef NO_VC_UNI_SCREEN

This preprocessor variable seems to be dangling in the breeze, with
no way for it to get set?  As a result, we pick up the #else define by
default.


pgpOfrCGm5EYX.pgp
Description: PGP signature

Re: [PATCH] staging: rtl8192u: fix line over 80 characters

[valdis . kletnieks]

On Sat, 16 Jun 2018 15:00:31 +0900, Hyunil Kim said:
> *fix checkpatch.pl warnings:
>  WARNING: line over 80 characters

> + if (((ieee->wpa_ie[0] == 0xdd) &&
> + (!memcmp(&(ieee->wpa_ie[14]), ccmp_ie, 4))) ||
> + ((ieee->wpa_ie[0] == 0x30) &&
> + (!memcmp(>wpa_ie[10], ccmp_rsn_ie, 4

Ouch. The && and || at ends of line mean a lot of parenthesis counting to
figure out which goes with which.  Use additional indentation to help
understanding.

+   if (((ieee->wpa_ie[0] == 0xdd) &&
+   (!memcmp(&(ieee->wpa_ie[14]), ccmp_ie, 4))) ||
+   ((ieee->wpa_ie[0] == 0x30) &&
+   (!memcmp(>wpa_ie[10], ccmp_rsn_ie, 4

Or perhaps

+   if (((ieee->wpa_ie[0] == 0xdd) &&
+   (!memcmp(&(ieee->wpa_ie[14]), ccmp_ie, 4)))
+|| ((ieee->wpa_ie[0] == 0x30) &&
+   (!memcmp(>wpa_ie[10], ccmp_rsn_ie, 4





pgpxUh_FNECk5.pgp
Description: PGP signature

Re: [PATCH] staging: rtl8192u: fix line over 80 characters

[valdis . kletnieks]

On Sat, 16 Jun 2018 15:00:31 +0900, Hyunil Kim said:
> *fix checkpatch.pl warnings:
>  WARNING: line over 80 characters

> + if (((ieee->wpa_ie[0] == 0xdd) &&
> + (!memcmp(&(ieee->wpa_ie[14]), ccmp_ie, 4))) ||
> + ((ieee->wpa_ie[0] == 0x30) &&
> + (!memcmp(>wpa_ie[10], ccmp_rsn_ie, 4

Ouch. The && and || at ends of line mean a lot of parenthesis counting to
figure out which goes with which.  Use additional indentation to help
understanding.

+   if (((ieee->wpa_ie[0] == 0xdd) &&
+   (!memcmp(&(ieee->wpa_ie[14]), ccmp_ie, 4))) ||
+   ((ieee->wpa_ie[0] == 0x30) &&
+   (!memcmp(>wpa_ie[10], ccmp_rsn_ie, 4

Or perhaps

+   if (((ieee->wpa_ie[0] == 0xdd) &&
+   (!memcmp(&(ieee->wpa_ie[14]), ccmp_ie, 4)))
+|| ((ieee->wpa_ie[0] == 0x30) &&
+   (!memcmp(>wpa_ie[10], ccmp_rsn_ie, 4





pgpxUh_FNECk5.pgp
Description: PGP signature

Re: [PATCH v2 6/7] vmw_balloon: update copyright message

[valdis . kletnieks]

On Thu, 14 Jun 2018 05:33:46 -, Nadav Amit said:

> >> In addition, updating the year and adding a license tag.

> >> +// SPDX-License-Identifier: GPL-2.0

> > You still have a lot of boiler-plate text in here that can be removed.
> > Please do so.

> But what else do you want me to remove? This is a standard GPL license. If I
> am required to remove the GPL license, I will have to run checks to ensure
> it is appropriate.

You mean the checks that you should have done when you stuck the SPDX
tag on the file?

(Hint: Think of the SPDX tag as a '#include gplv2.license.blurb" :)


pgpTbI8AAoIqV.pgp
Description: PGP signature

Re: [PATCH v2 6/7] vmw_balloon: update copyright message

[valdis . kletnieks]

On Thu, 14 Jun 2018 05:33:46 -, Nadav Amit said:

> >> In addition, updating the year and adding a license tag.

> >> +// SPDX-License-Identifier: GPL-2.0

> > You still have a lot of boiler-plate text in here that can be removed.
> > Please do so.

> But what else do you want me to remove? This is a standard GPL license. If I
> am required to remove the GPL license, I will have to run checks to ensure
> it is appropriate.

You mean the checks that you should have done when you stuck the SPDX
tag on the file?

(Hint: Think of the SPDX tag as a '#include gplv2.license.blurb" :)


pgpTbI8AAoIqV.pgp
Description: PGP signature

Re: linux-next 20180515 - ACPI disabled..

[valdis . kletnieks]

On Wed, 16 May 2018 13:58:04 +0200, "Rafael J. Wysocki" said:
> On Wednesday, May 16, 2018 12:25:30 AM CEST valdis.kletni...@vt.edu wrote:
> > On Tue, 15 May 2018 15:49:15 -0600, Al Stone said:
> > 
> > > Not off-hand.  Could you please send me a copy of 
> > > /sys/firmware/acpi/tables/APIC

> There was one commit that I had to drop.
>
> Please try linux-next tomorrow and let me know if it works for you.

Confirming that linux-next 20180517 works as expected, thanks.

Re: linux-next 20180515 - ACPI disabled..

[valdis . kletnieks]

On Wed, 16 May 2018 13:58:04 +0200, "Rafael J. Wysocki" said:
> On Wednesday, May 16, 2018 12:25:30 AM CEST valdis.kletni...@vt.edu wrote:
> > On Tue, 15 May 2018 15:49:15 -0600, Al Stone said:
> > 
> > > Not off-hand.  Could you please send me a copy of 
> > > /sys/firmware/acpi/tables/APIC

> There was one commit that I had to drop.
>
> Please try linux-next tomorrow and let me know if it works for you.

Confirming that linux-next 20180517 works as expected, thanks.

Re: linux-next 20180515 - ACPI disabled..

[valdis . kletnieks]

On Tue, 15 May 2018 15:49:15 -0600, Al Stone said:

> Not off-hand.  Could you please send me a copy of 
> /sys/firmware/acpi/tables/APIC

cat /sys/firmware/acpi/tables/APIC | od -x
000 5041 4349 0072  3903 4544 4c4c 2020
020 4243 3358 2020 0020 2009 0107 4d41 2049
040 0013 0001  fee0 0001  0800 0001
060 0001  0800 0202 0001  0800 0103
100 0001  0800 0304 0001  0c01 0002
120  fec0   0a02  0002 
140  0a02 0900 0009  000d 0604 05ff
160 0100
162

> on this machine?  The commit cd8c65a6442b that I wrote looks like it got 
> pulled
> in on 20180430, which if I'm understanding correctly, seems to have fixed the
> problem.  Did this work before 20180415?  I assume it did.

0430 is what I'm running right ow, and it works.  Everything before that too.
It fell over sometime between 0430 and 0515,

> What puzzles me is that this message:
>
>ACPI: [APIC:0x05] Invalid zero length
>
> should only have shown up if the MADT has a broken subtable, and I think that
> bit of code has been that way for quite some time (git blame says somewhere
> around 2012 when the test for this condition was put in).



pgpucsiI1okrR.pgp
Description: PGP signature

Re: linux-next 20180515 - ACPI disabled..

[valdis . kletnieks]

On Tue, 15 May 2018 15:49:15 -0600, Al Stone said:

> Not off-hand.  Could you please send me a copy of 
> /sys/firmware/acpi/tables/APIC

cat /sys/firmware/acpi/tables/APIC | od -x
000 5041 4349 0072  3903 4544 4c4c 2020
020 4243 3358 2020 0020 2009 0107 4d41 2049
040 0013 0001  fee0 0001  0800 0001
060 0001  0800 0202 0001  0800 0103
100 0001  0800 0304 0001  0c01 0002
120  fec0   0a02  0002 
140  0a02 0900 0009  000d 0604 05ff
160 0100
162

> on this machine?  The commit cd8c65a6442b that I wrote looks like it got 
> pulled
> in on 20180430, which if I'm understanding correctly, seems to have fixed the
> problem.  Did this work before 20180415?  I assume it did.

0430 is what I'm running right ow, and it works.  Everything before that too.
It fell over sometime between 0430 and 0515,

> What puzzles me is that this message:
>
>ACPI: [APIC:0x05] Invalid zero length
>
> should only have shown up if the MADT has a broken subtable, and I think that
> bit of code has been that way for quite some time (git blame says somewhere
> around 2012 when the test for this condition was put in).



pgpucsiI1okrR.pgp
Description: PGP signature

linux-next 20180515 - ACPI disabled..

[valdis . kletnieks]

Seeing this at boot with linux-next 20180415.  ACPI gets disabled, hilarity and 
hijinks
result - everything from a lot of stuff can't find an IRQ to the dual-core w/ 
HT CPU
coming up as just 1 core no HT. 20180430 works just fine...

[0.00] ACPI: Early table checksum verification disabled
[0.00] ACPI: RSDP 0xCB7F1000 24 (v02 DELL  )
[0.00] ACPI: XSDT 0xCB7F1088 94 (v01 DELL   CBX3 
01072009 AMI  00010013)
[0.00] ACPI: FACP 0xCB7FB720 00010C (v05 DELL   CBX3 
01072009 AMI  00010013)
[0.00] ACPI: DSDT 0xCB7F11B0 00A56F (v02 DELL   CBX3 
0021 INTL 20091112)
[0.00] ACPI: FACS 0xCCFED080 40
[0.00] ACPI: APIC 0xCB7FB830 72 (v03 DELL   CBX3 
01072009 AMI  00010013)
[0.00] ACPI: FPDT 0xCB7FB8A8 44 (v01 DELL   CBX3 
01072009 AMI  00010013)
[0.00] ACPI: TCPA 0xCB7FB8F0 32 (v02 APTIO4 NAPAASF  
0001 MSFT 0113)
[0.00] ACPI: MCFG 0xCB7FB928 3C (v01 DELL   CBX3 
01072009 MSFT 0097)
[0.00] ACPI: HPET 0xCB7FB968 38 (v01 DELL   CBX3 
01072009 AMI. 0005)
[0.00] ACPI: SSDT 0xCB7FB9A0 000415 (v01 SataRe SataTabl 
1000 INTL 20091112)
[0.00] ACPI: SSDT 0xCB7FBDB8 0009B9 (v01 PmRef  Cpu0Ist  
3000 INTL 20051117)
[0.00] ACPI: SSDT 0xCB7FC778 000B22 (v01 PmRef  CpuPm
3000 INTL 20051117)
[0.00] ACPI: DMAR 0xCB7FD2A0 80 (v01 INTEL  SNB  
0001 INTL 0001)
[0.00] ACPI: ASF! 0xCB7FD320 A5 (v32 INTEL   HCG 
0001 TFSM 000F4240)
[0.00] ACPI: SSDT 0xCB7FD3C8 000579 (v01 AMITCG PROC 
0001 INTL 20051117)
[0.00] ACPI: BGRT 0xCB7FD948 38 (v00 ??  
01072009 AMI  00010013)
[0.00] ACPI: SSDT 0xCB7FD980 00198A (v01 NvdRef NvdTabl  
1000 INTL 20091112)
[0.00] ACPI: Local APIC address 0xfee0
[0.00] ACPI: [APIC:0x05] Invalid zero length
[0.00] ACPI: Error parsing LAPIC address override entry
[0.00] ACPI: Invalid BIOS MADT, disabling ACPI
[0.00] tsc: Fast TSC calibration using PIT

On next-20180430, the boot goes like this, and continues properly:

[0.00] ACPI: SSDT 0xCB7FD980 00198A (v01 NvdRef NvdTabl  
1000 INTL 20091112)
[0.00] ACPI: Local APIC address 0xfee0
[0.00] tsc: Fast TSC calibration using PIT

Not seeing any commits to drivers/acpi/tables.c other than Al Stone's.

This ringing any bells before I go bisecting?



pgpy6Ljw8q5ox.pgp
Description: PGP signature

linux-next 20180515 - ACPI disabled..

[valdis . kletnieks]

Seeing this at boot with linux-next 20180415.  ACPI gets disabled, hilarity and 
hijinks
result - everything from a lot of stuff can't find an IRQ to the dual-core w/ 
HT CPU
coming up as just 1 core no HT. 20180430 works just fine...

[0.00] ACPI: Early table checksum verification disabled
[0.00] ACPI: RSDP 0xCB7F1000 24 (v02 DELL  )
[0.00] ACPI: XSDT 0xCB7F1088 94 (v01 DELL   CBX3 
01072009 AMI  00010013)
[0.00] ACPI: FACP 0xCB7FB720 00010C (v05 DELL   CBX3 
01072009 AMI  00010013)
[0.00] ACPI: DSDT 0xCB7F11B0 00A56F (v02 DELL   CBX3 
0021 INTL 20091112)
[0.00] ACPI: FACS 0xCCFED080 40
[0.00] ACPI: APIC 0xCB7FB830 72 (v03 DELL   CBX3 
01072009 AMI  00010013)
[0.00] ACPI: FPDT 0xCB7FB8A8 44 (v01 DELL   CBX3 
01072009 AMI  00010013)
[0.00] ACPI: TCPA 0xCB7FB8F0 32 (v02 APTIO4 NAPAASF  
0001 MSFT 0113)
[0.00] ACPI: MCFG 0xCB7FB928 3C (v01 DELL   CBX3 
01072009 MSFT 0097)
[0.00] ACPI: HPET 0xCB7FB968 38 (v01 DELL   CBX3 
01072009 AMI. 0005)
[0.00] ACPI: SSDT 0xCB7FB9A0 000415 (v01 SataRe SataTabl 
1000 INTL 20091112)
[0.00] ACPI: SSDT 0xCB7FBDB8 0009B9 (v01 PmRef  Cpu0Ist  
3000 INTL 20051117)
[0.00] ACPI: SSDT 0xCB7FC778 000B22 (v01 PmRef  CpuPm
3000 INTL 20051117)
[0.00] ACPI: DMAR 0xCB7FD2A0 80 (v01 INTEL  SNB  
0001 INTL 0001)
[0.00] ACPI: ASF! 0xCB7FD320 A5 (v32 INTEL   HCG 
0001 TFSM 000F4240)
[0.00] ACPI: SSDT 0xCB7FD3C8 000579 (v01 AMITCG PROC 
0001 INTL 20051117)
[0.00] ACPI: BGRT 0xCB7FD948 38 (v00 ??  
01072009 AMI  00010013)
[0.00] ACPI: SSDT 0xCB7FD980 00198A (v01 NvdRef NvdTabl  
1000 INTL 20091112)
[0.00] ACPI: Local APIC address 0xfee0
[0.00] ACPI: [APIC:0x05] Invalid zero length
[0.00] ACPI: Error parsing LAPIC address override entry
[0.00] ACPI: Invalid BIOS MADT, disabling ACPI
[0.00] tsc: Fast TSC calibration using PIT

On next-20180430, the boot goes like this, and continues properly:

[0.00] ACPI: SSDT 0xCB7FD980 00198A (v01 NvdRef NvdTabl  
1000 INTL 20091112)
[0.00] ACPI: Local APIC address 0xfee0
[0.00] tsc: Fast TSC calibration using PIT

Not seeing any commits to drivers/acpi/tables.c other than Al Stone's.

This ringing any bells before I go bisecting?



pgpy6Ljw8q5ox.pgp
Description: PGP signature

Re: next-20180416 - warnings from 'make tools/perf'

[valdis . kletnieks]

On Mon, 23 Apr 2018 08:52:04 +0200, Ingo Molnar said:

> The warnings are harmless, and they should be fixed in v4.17-rc2.

Having been burnt all too many times over the past 4 decades by mismatched
headers, I figured I should mention it...

I see that in next-20180423 it's down to 2 warnings (prctl.h and if_link.h)



pgpz3Jm86ecu8.pgp
Description: PGP signature

Re: next-20180416 - warnings from 'make tools/perf'

[valdis . kletnieks]

On Mon, 23 Apr 2018 08:52:04 +0200, Ingo Molnar said:

> The warnings are harmless, and they should be fixed in v4.17-rc2.

Having been burnt all too many times over the past 4 decades by mismatched
headers, I figured I should mention it...

I see that in next-20180423 it's down to 2 warnings (prctl.h and if_link.h)



pgpz3Jm86ecu8.pgp
Description: PGP signature

next-20180416 - warnings from 'make tools/perf'

[valdis . kletnieks]

Seeing these warnings.  'diff' tells me that the files
are in fact significantly different.

Warning: Kernel ABI header at 'tools/include/uapi/linux/kvm.h' differs from 
latest version at 'include/uapi/linux/kvm.h'
Warning: Kernel ABI header at 'tools/include/uapi/linux/prctl.h' differs from 
latest version at 'include/uapi/linux/prctl.h'
Warning: Kernel ABI header at 'tools/include/uapi/sound/asound.h' differs from 
latest version at 'include/uapi/sound/asound.h'
Warning: Kernel ABI header at 'tools/arch/x86/include/asm/required-features.h' 
differs from latest version at 'arch/x86/include/asm/required-features.h'
Warning: Kernel ABI header at 'tools/arch/x86/include/uapi/asm/kvm.h' differs 
from latest version at 'arch/x86/include/uapi/asm/kvm.h'
Warning: Kernel ABI header at 'tools/arch/arm/include/uapi/asm/kvm.h' differs 
from latest version at 'arch/arm/include/uapi/asm/kvm.h'
Warning: Kernel ABI header at 'tools/include/uapi/asm-generic/mman-common.h' 
differs from latest version at 'include/uapi/asm-generic/mman-common.h'
Warning: Kernel ABI header at 'tools/include/uapi/linux/bpf.h' differs from 
latest version at 'include/uapi/linux/bpf.h'
Warning: Kernel ABI header at 'tools/include/uapi/linux/if_link.h' differs from 
latest version at 'include/uapi/linux/if_link.h'

I even tried removing the tools/include versions and then doing a git 
reset--hard,
and the issue persists.  Looking at kvm.h, it appears at least two commits hit
the include/uapi version and failed to be applied to the tools/include/uapi 
copy.

Running 'diff' on the first:

diff -u 'tools/include/uapi/linux/kvm.h' 'include/uapi/linux/kvm.h'
--- tools/include/uapi/linux/kvm.h  2018-04-23 01:40:20.259290792 -0400
+++ include/uapi/linux/kvm.h2018-04-16 18:41:38.735881690 -0400
@@ -396,6 +396,10 @@
char padding[256];
};

+   /* 2048 is the size of the char array used to bound/pad the size
+* of the union that holds sync regs.
+*/
+   #define SYNC_REGS_SIZE_BYTES 2048
/*
 * shared registers between kvm and userspace.
 * kvm_valid_regs specifies the register classes set by the host
@@ -407,7 +411,7 @@
__u64 kvm_dirty_regs;
union {
struct kvm_sync_regs regs;
-   char padding[2048];
+   char padding[SYNC_REGS_SIZE_BYTES];
} s;
 };

@@ -936,6 +940,7 @@
 #define KVM_CAP_PPC_GET_CPU_CHAR 151
 #define KVM_CAP_S390_BPB 152
 #define KVM_CAP_GET_MSR_FEATURES 153
+#define KVM_CAP_HYPERV_EVENTFD 154

 #ifdef KVM_CAP_IRQ_ROUTING

@@ -1375,6 +1380,10 @@
 #define KVM_MEMORY_ENCRYPT_REG_REGION_IOR(KVMIO, 0xbb, struct 
kvm_enc_region)
 #define KVM_MEMORY_ENCRYPT_UNREG_REGION  _IOR(KVMIO, 0xbc, struct 
kvm_enc_region)

+/* Available with KVM_CAP_HYPERV_EVENTFD */
+#define KVM_HYPERV_EVENTFD_IOW(KVMIO,  0xbd, struct kvm_hyperv_eventfd)
+
+
 /* Secure Encrypted Virtualization command */
 enum sev_cmd_id {
/* Guest initialization commands */
@@ -1515,4 +1524,14 @@
 #define KVM_ARM_DEV_EL1_PTIMER (1 << 1)
 #define KVM_ARM_DEV_PMU(1 << 2)

+struct kvm_hyperv_eventfd {
+   __u32 conn_id;
+   __s32 fd;
+   __u32 flags;
+   __u32 padding[3];
+};
+
+#define KVM_HYPERV_CONN_ID_MASK0x00ff
+#define KVM_HYPERV_EVENTFD_DEASSIGN(1 << 0)
+
 #endif /* __LINUX_KVM_H */



pgpg7FPeR91Q8.pgp
Description: PGP signature

next-20180416 - warnings from 'make tools/perf'

[valdis . kletnieks]

Seeing these warnings.  'diff' tells me that the files
are in fact significantly different.

Warning: Kernel ABI header at 'tools/include/uapi/linux/kvm.h' differs from 
latest version at 'include/uapi/linux/kvm.h'
Warning: Kernel ABI header at 'tools/include/uapi/linux/prctl.h' differs from 
latest version at 'include/uapi/linux/prctl.h'
Warning: Kernel ABI header at 'tools/include/uapi/sound/asound.h' differs from 
latest version at 'include/uapi/sound/asound.h'
Warning: Kernel ABI header at 'tools/arch/x86/include/asm/required-features.h' 
differs from latest version at 'arch/x86/include/asm/required-features.h'
Warning: Kernel ABI header at 'tools/arch/x86/include/uapi/asm/kvm.h' differs 
from latest version at 'arch/x86/include/uapi/asm/kvm.h'
Warning: Kernel ABI header at 'tools/arch/arm/include/uapi/asm/kvm.h' differs 
from latest version at 'arch/arm/include/uapi/asm/kvm.h'
Warning: Kernel ABI header at 'tools/include/uapi/asm-generic/mman-common.h' 
differs from latest version at 'include/uapi/asm-generic/mman-common.h'
Warning: Kernel ABI header at 'tools/include/uapi/linux/bpf.h' differs from 
latest version at 'include/uapi/linux/bpf.h'
Warning: Kernel ABI header at 'tools/include/uapi/linux/if_link.h' differs from 
latest version at 'include/uapi/linux/if_link.h'

I even tried removing the tools/include versions and then doing a git 
reset--hard,
and the issue persists.  Looking at kvm.h, it appears at least two commits hit
the include/uapi version and failed to be applied to the tools/include/uapi 
copy.

Running 'diff' on the first:

diff -u 'tools/include/uapi/linux/kvm.h' 'include/uapi/linux/kvm.h'
--- tools/include/uapi/linux/kvm.h  2018-04-23 01:40:20.259290792 -0400
+++ include/uapi/linux/kvm.h2018-04-16 18:41:38.735881690 -0400
@@ -396,6 +396,10 @@
char padding[256];
};

+   /* 2048 is the size of the char array used to bound/pad the size
+* of the union that holds sync regs.
+*/
+   #define SYNC_REGS_SIZE_BYTES 2048
/*
 * shared registers between kvm and userspace.
 * kvm_valid_regs specifies the register classes set by the host
@@ -407,7 +411,7 @@
__u64 kvm_dirty_regs;
union {
struct kvm_sync_regs regs;
-   char padding[2048];
+   char padding[SYNC_REGS_SIZE_BYTES];
} s;
 };

@@ -936,6 +940,7 @@
 #define KVM_CAP_PPC_GET_CPU_CHAR 151
 #define KVM_CAP_S390_BPB 152
 #define KVM_CAP_GET_MSR_FEATURES 153
+#define KVM_CAP_HYPERV_EVENTFD 154

 #ifdef KVM_CAP_IRQ_ROUTING

@@ -1375,6 +1380,10 @@
 #define KVM_MEMORY_ENCRYPT_REG_REGION_IOR(KVMIO, 0xbb, struct 
kvm_enc_region)
 #define KVM_MEMORY_ENCRYPT_UNREG_REGION  _IOR(KVMIO, 0xbc, struct 
kvm_enc_region)

+/* Available with KVM_CAP_HYPERV_EVENTFD */
+#define KVM_HYPERV_EVENTFD_IOW(KVMIO,  0xbd, struct kvm_hyperv_eventfd)
+
+
 /* Secure Encrypted Virtualization command */
 enum sev_cmd_id {
/* Guest initialization commands */
@@ -1515,4 +1524,14 @@
 #define KVM_ARM_DEV_EL1_PTIMER (1 << 1)
 #define KVM_ARM_DEV_PMU(1 << 2)

+struct kvm_hyperv_eventfd {
+   __u32 conn_id;
+   __s32 fd;
+   __u32 flags;
+   __u32 padding[3];
+};
+
+#define KVM_HYPERV_CONN_ID_MASK0x00ff
+#define KVM_HYPERV_EVENTFD_DEASSIGN(1 << 0)
+
 #endif /* __LINUX_KVM_H */



pgpg7FPeR91Q8.pgp
Description: PGP signature

Re: Softlockup and Hardlockup sample test module

[valdis . kletnieks]

On Sun, 15 Apr 2018 13:17:27 +0530, Ivid Suvarna said:

> I had tried with the module where I put a busy loop inside spinlock
> but was not able to cause any lockups. Maybe this is because of SMP
> which schedule the job to other CPU. "How do I make a task to run on
> single CPU only?"

So you get a kernel thread that's taken a lock and will busy-loop and not free
it.  What sort of lockup do you expect will be detected from this? Would the
results be any different if you didn't take a lock before busy-looping?

For bonus points - what additional things have to happen before a livelock
happens?

And before a deadlock happens?


pgp5UHAJhB8G4.pgp
Description: PGP signature

Re: Softlockup and Hardlockup sample test module

[valdis . kletnieks]

On Sun, 15 Apr 2018 13:17:27 +0530, Ivid Suvarna said:

> I had tried with the module where I put a busy loop inside spinlock
> but was not able to cause any lockups. Maybe this is because of SMP
> which schedule the job to other CPU. "How do I make a task to run on
> single CPU only?"

So you get a kernel thread that's taken a lock and will busy-loop and not free
it.  What sort of lockup do you expect will be detected from this? Would the
results be any different if you didn't take a lock before busy-looping?

For bonus points - what additional things have to happen before a livelock
happens?

And before a deadlock happens?


pgp5UHAJhB8G4.pgp
Description: PGP signature

Re: linux-next 20180327 - "SELinux: (dev dm-3, type ext4) getxattr errno 34"

[valdis . kletnieks]

On Thu, 29 Mar 2018 21:32:21 -0400, "Theodore Y. Ts'o" said:

> Yes, the breakage is my fault; my apologies.  The new version of the
> patch is already posted in bugzilla (and on linux-ext4).  I'll be
> pushing out a refreshed ext4.git branch shortly.

Confirming that reverting de57a63ea4389e39b1cdd1cef15e1ec9b58a964c
and applying the new version from the bugzilla results in a clean boot.



pgpviSZYDm_s9.pgp
Description: PGP signature

Re: linux-next 20180327 - "SELinux: (dev dm-3, type ext4) getxattr errno 34"

[valdis . kletnieks]

On Thu, 29 Mar 2018 21:32:21 -0400, "Theodore Y. Ts'o" said:

> Yes, the breakage is my fault; my apologies.  The new version of the
> patch is already posted in bugzilla (and on linux-ext4).  I'll be
> pushing out a refreshed ext4.git branch shortly.

Confirming that reverting de57a63ea4389e39b1cdd1cef15e1ec9b58a964c
and applying the new version from the bugzilla results in a clean boot.



pgpviSZYDm_s9.pgp
Description: PGP signature

linux-next 20180327 - "SELinux: (dev dm-3, type ext4) getxattr errno 34"

[valdis . kletnieks]

Seeing this error trying to mount ext4 disks. next-20180320 was OK.

SELinux: (dev dm-3, type ext4) getxattr errno 34

and for /var, it refused to mount entirely (which brought the boot
process to a screeching halt).

git log shows commits in the past few days against both selinux and ext4,
but nothing obvious.

This ring any bells, or is it time to start bisecting?

dmesg follows...

[0.00] microcode: microcode updated early to revision 0x1f, date = 
2018-02-07
[0.00] Linux version 4.16.0-rc7-next-20180327-dirty 
(sou...@turing-police.cc.vt.edu) (gcc version 8.0.1 20180317 (Red Hat 
8.0.1-0.19) (GCC)) #565 SMP PREEMPT Wed Mar 28 01:01:48 EDT 2018
[0.00] Command line: BOOT_IMAGE=/vmlinuz-4.16.0-rc7-next-20180327-dirty 
root=/dev/mapper/turing--police-root ro rd.md=0 rd.dm=0 
rd.lvm.lv=turing-police/00 console.keymap= 
rd.luks.uuid=luks-665bb147-9e39-4003-b3ae-7be925f51a97 
rd.lvm.lv=turing-police/swap rd.lvm.lv=turing-police/root quiet 
LANG=en_US.UTF-8 nouveau.modeset=0 rd.driver.blacklist=nouveau video=vesa:off 
modprobe.blacklist=nouveau nvidia-drm.modeset=1 single
[0.00] KERNEL supported cpus:
[0.00]   Intel GenuineIntel
[0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point 
registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, 
using 'standard' format.
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009cfff] usable
[0.00] BIOS-e820: [mem 0x0009d000-0x0009efff] reserved
[0.00] BIOS-e820: [mem 0x0009f000-0x0009] usable
[0.00] BIOS-e820: [mem 0x0010-0xca709fff] usable
[0.00] BIOS-e820: [mem 0xca70a000-0xca7f] reserved
[0.00] BIOS-e820: [mem 0xca80-0xcaf52fff] usable
[0.00] BIOS-e820: [mem 0xcaf53000-0xcaff] reserved
[0.00] BIOS-e820: [mem 0xcb00-0xcb7b1fff] usable
[0.00] BIOS-e820: [mem 0xcb7b2000-0xcb7f] ACPI data
[0.00] BIOS-e820: [mem 0xcb80-0xccefdfff] usable
[0.00] BIOS-e820: [mem 0xccefe000-0xccff] ACPI NVS
[0.00] BIOS-e820: [mem 0xcd00-0xce5aefff] usable
[0.00] BIOS-e820: [mem 0xce5af000-0xcefa5fff] reserved
[0.00] BIOS-e820: [mem 0xcefa6000-0xcefe8fff] ACPI NVS
[0.00] BIOS-e820: [mem 0xcefe9000-0xcf2b1fff] usable
[0.00] BIOS-e820: [mem 0xcf2b2000-0xcf7e] reserved
[0.00] BIOS-e820: [mem 0xcf7f-0xcf7f] usable
[0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
[0.00] BIOS-e820: [mem 0xfed0-0xfed03fff] reserved
[0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xff00-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00040dfacfff] usable
[0.00] BIOS-e820: [mem 0x00040dfad000-0x00040dfadfff] unusable
[0.00] BIOS-e820: [mem 0x00040dfae000-0x00040dfaefff] usable
[0.00] BIOS-e820: [mem 0x00040dfaf000-0x00040dfa] unusable
[0.00] BIOS-e820: [mem 0x00040dfb-0x00040dfeafff] usable
[0.00] BIOS-e820: [mem 0x00040dfeb000-0x00040dfebfff] unusable
[0.00] BIOS-e820: [mem 0x00040dfec000-0x00042dff] usable
[0.00] NX (Execute Disable) protection: active
[0.00] e820: update [mem 0xc7b50018-0xc7b6ce57] usable ==> usable
[0.00] e820: update [mem 0xc7b50018-0xc7b6ce57] usable ==> usable
[0.00] extended physical RAM map:
[0.00] reserve setup_data: [mem 0x-0x0009cfff] 
usable
[0.00] reserve setup_data: [mem 0x0009d000-0x0009efff] 
reserved
[0.00] reserve setup_data: [mem 0x0009f000-0x0009] 
usable
[0.00] reserve setup_data: [mem 0x0010-0xc7b50017] 
usable
[0.00] reserve setup_data: [mem 0xc7b50018-0xc7b6ce57] 
usable
[0.00] reserve setup_data: [mem 0xc7b6ce58-0xca709fff] 
usable
[0.00] reserve setup_data: [mem 0xca70a000-0xca7f] 
reserved
[0.00] reserve setup_data: [mem 0xca80-0xcaf52fff] 
usable
[0.00] reserve setup_data: [mem 

linux-next 20180327 - "SELinux: (dev dm-3, type ext4) getxattr errno 34"

[valdis . kletnieks]

Seeing this error trying to mount ext4 disks. next-20180320 was OK.

SELinux: (dev dm-3, type ext4) getxattr errno 34

and for /var, it refused to mount entirely (which brought the boot
process to a screeching halt).

git log shows commits in the past few days against both selinux and ext4,
but nothing obvious.

This ring any bells, or is it time to start bisecting?

dmesg follows...

[0.00] microcode: microcode updated early to revision 0x1f, date = 
2018-02-07
[0.00] Linux version 4.16.0-rc7-next-20180327-dirty 
(sou...@turing-police.cc.vt.edu) (gcc version 8.0.1 20180317 (Red Hat 
8.0.1-0.19) (GCC)) #565 SMP PREEMPT Wed Mar 28 01:01:48 EDT 2018
[0.00] Command line: BOOT_IMAGE=/vmlinuz-4.16.0-rc7-next-20180327-dirty 
root=/dev/mapper/turing--police-root ro rd.md=0 rd.dm=0 
rd.lvm.lv=turing-police/00 console.keymap= 
rd.luks.uuid=luks-665bb147-9e39-4003-b3ae-7be925f51a97 
rd.lvm.lv=turing-police/swap rd.lvm.lv=turing-police/root quiet 
LANG=en_US.UTF-8 nouveau.modeset=0 rd.driver.blacklist=nouveau video=vesa:off 
modprobe.blacklist=nouveau nvidia-drm.modeset=1 single
[0.00] KERNEL supported cpus:
[0.00]   Intel GenuineIntel
[0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point 
registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, 
using 'standard' format.
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009cfff] usable
[0.00] BIOS-e820: [mem 0x0009d000-0x0009efff] reserved
[0.00] BIOS-e820: [mem 0x0009f000-0x0009] usable
[0.00] BIOS-e820: [mem 0x0010-0xca709fff] usable
[0.00] BIOS-e820: [mem 0xca70a000-0xca7f] reserved
[0.00] BIOS-e820: [mem 0xca80-0xcaf52fff] usable
[0.00] BIOS-e820: [mem 0xcaf53000-0xcaff] reserved
[0.00] BIOS-e820: [mem 0xcb00-0xcb7b1fff] usable
[0.00] BIOS-e820: [mem 0xcb7b2000-0xcb7f] ACPI data
[0.00] BIOS-e820: [mem 0xcb80-0xccefdfff] usable
[0.00] BIOS-e820: [mem 0xccefe000-0xccff] ACPI NVS
[0.00] BIOS-e820: [mem 0xcd00-0xce5aefff] usable
[0.00] BIOS-e820: [mem 0xce5af000-0xcefa5fff] reserved
[0.00] BIOS-e820: [mem 0xcefa6000-0xcefe8fff] ACPI NVS
[0.00] BIOS-e820: [mem 0xcefe9000-0xcf2b1fff] usable
[0.00] BIOS-e820: [mem 0xcf2b2000-0xcf7e] reserved
[0.00] BIOS-e820: [mem 0xcf7f-0xcf7f] usable
[0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
[0.00] BIOS-e820: [mem 0xfed0-0xfed03fff] reserved
[0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xff00-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00040dfacfff] usable
[0.00] BIOS-e820: [mem 0x00040dfad000-0x00040dfadfff] unusable
[0.00] BIOS-e820: [mem 0x00040dfae000-0x00040dfaefff] usable
[0.00] BIOS-e820: [mem 0x00040dfaf000-0x00040dfa] unusable
[0.00] BIOS-e820: [mem 0x00040dfb-0x00040dfeafff] usable
[0.00] BIOS-e820: [mem 0x00040dfeb000-0x00040dfebfff] unusable
[0.00] BIOS-e820: [mem 0x00040dfec000-0x00042dff] usable
[0.00] NX (Execute Disable) protection: active
[0.00] e820: update [mem 0xc7b50018-0xc7b6ce57] usable ==> usable
[0.00] e820: update [mem 0xc7b50018-0xc7b6ce57] usable ==> usable
[0.00] extended physical RAM map:
[0.00] reserve setup_data: [mem 0x-0x0009cfff] 
usable
[0.00] reserve setup_data: [mem 0x0009d000-0x0009efff] 
reserved
[0.00] reserve setup_data: [mem 0x0009f000-0x0009] 
usable
[0.00] reserve setup_data: [mem 0x0010-0xc7b50017] 
usable
[0.00] reserve setup_data: [mem 0xc7b50018-0xc7b6ce57] 
usable
[0.00] reserve setup_data: [mem 0xc7b6ce58-0xca709fff] 
usable
[0.00] reserve setup_data: [mem 0xca70a000-0xca7f] 
reserved
[0.00] reserve setup_data: [mem 0xca80-0xcaf52fff] 
usable
[0.00] reserve setup_data: [mem 

Re: linux-next 20180320 compile failure - tools/lib/str_error_r.c

[valdis . kletnieks]

On Wed, 21 Mar 2018 10:29:38 -0300, Arnaldo Carvalho de Melo said:
> Em Tue, Mar 20, 2018 at 12:43:32PM -0400, valdis.kletni...@vt.edu escreveu:

> > next-20180320 with "gcc (GCC) 8.0.1 20180317 (Red Hat 8.0.1-0.19)"  dies a 
> > horrid death early
> > during the compile:
> >
> >   CC   /usr/src/linux-next/tools/objtool/str_error_r.o
> > ../lib/str_error_r.c: In function 'str_error_r':
> > ../lib/str_error_r.c:25:3: error: passing argument 1 to restrict-qualified 
> > parameter aliases with argument 5 [-Werror=restrict]
> >snprintf(buf, buflen, "INTERNAL ERROR: strerror_r(%d, %p, %zd)=%d", 
> > errnum, buf, buflen, err);
> >^~~~
> > cc1: all warnings being treated as errors
> > mv: cannot stat '/usr/src/linux-next/tools/objtool/.str_error_r.o.tmp': No 
> > such file or directory
> > make[3]: *** [Build:22: /usr/src/linux-next/tools/objtool/str_error_r.o] 
> > Error 1
> > make[2]: *** [Makefile:46: /usr/src/linux-next/tools/objtool/objtool-in.o] 
> > Error 2
> > make[1]: *** [Makefile:63: objtool] Error 2
> > make: *** [Makefile:1681: tools/objtool] Error 2
> >
>
> https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=854e55ad289e

Confirming that fixes the problem...


pgpW9017GZYH_.pgp
Description: PGP signature

Re: linux-next 20180320 compile failure - tools/lib/str_error_r.c

[valdis . kletnieks]

On Wed, 21 Mar 2018 10:29:38 -0300, Arnaldo Carvalho de Melo said:
> Em Tue, Mar 20, 2018 at 12:43:32PM -0400, valdis.kletni...@vt.edu escreveu:

> > next-20180320 with "gcc (GCC) 8.0.1 20180317 (Red Hat 8.0.1-0.19)"  dies a 
> > horrid death early
> > during the compile:
> >
> >   CC   /usr/src/linux-next/tools/objtool/str_error_r.o
> > ../lib/str_error_r.c: In function 'str_error_r':
> > ../lib/str_error_r.c:25:3: error: passing argument 1 to restrict-qualified 
> > parameter aliases with argument 5 [-Werror=restrict]
> >snprintf(buf, buflen, "INTERNAL ERROR: strerror_r(%d, %p, %zd)=%d", 
> > errnum, buf, buflen, err);
> >^~~~
> > cc1: all warnings being treated as errors
> > mv: cannot stat '/usr/src/linux-next/tools/objtool/.str_error_r.o.tmp': No 
> > such file or directory
> > make[3]: *** [Build:22: /usr/src/linux-next/tools/objtool/str_error_r.o] 
> > Error 1
> > make[2]: *** [Makefile:46: /usr/src/linux-next/tools/objtool/objtool-in.o] 
> > Error 2
> > make[1]: *** [Makefile:63: objtool] Error 2
> > make: *** [Makefile:1681: tools/objtool] Error 2
> >
>
> https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=854e55ad289e

Confirming that fixes the problem...


pgpW9017GZYH_.pgp
Description: PGP signature

Re: [PATCH] net: dev_forward_skb(): Scrub packet's per-netns info only when crossing netns

[valdis . kletnieks]

On Tue, 20 Mar 2018 18:39:47 +0200, Liran Alon said:
> What is your opinion in regards if it's OK to put the flag enabling this
> "fix" in /proc/sys/net/core? Do you think it's sufficient?

Umm.. *which* /proc/sys/net/core?  These could differ for things that
are in different namespaces.  Or are you proposing one systemwide
global value (which also gets "interesting" if it's writable inside a
container and changes the behavior a different container sees...)



pgplcZmg_k6C1.pgp
Description: PGP signature

Re: [PATCH] net: dev_forward_skb(): Scrub packet's per-netns info only when crossing netns

[valdis . kletnieks]

On Tue, 20 Mar 2018 18:39:47 +0200, Liran Alon said:
> What is your opinion in regards if it's OK to put the flag enabling this
> "fix" in /proc/sys/net/core? Do you think it's sufficient?

Umm.. *which* /proc/sys/net/core?  These could differ for things that
are in different namespaces.  Or are you proposing one systemwide
global value (which also gets "interesting" if it's writable inside a
container and changes the behavior a different container sees...)



pgplcZmg_k6C1.pgp
Description: PGP signature

linux-next 20180320 compile failure - tools/lib/str_error_r.c

[valdis . kletnieks]

Not sure who to blame here, or what changed in gcc between 0.16 and 0.19,
or what the proper fix is here

next-20180307 with "gcc version 8.0.1 20180222 (Red Hat 8.0.1-0.16)" built and 
runs fine.

next-20180320 with "gcc (GCC) 8.0.1 20180317 (Red Hat 8.0.1-0.19)"  dies a 
horrid death early
during the compile:

  CC   /usr/src/linux-next/tools/objtool/str_error_r.o
../lib/str_error_r.c: In function 'str_error_r':
../lib/str_error_r.c:25:3: error: passing argument 1 to restrict-qualified 
parameter aliases with argument 5 [-Werror=restrict]
   snprintf(buf, buflen, "INTERNAL ERROR: strerror_r(%d, %p, %zd)=%d", errnum, 
buf, buflen, err);
   ^~~~
cc1: all warnings being treated as errors
mv: cannot stat '/usr/src/linux-next/tools/objtool/.str_error_r.o.tmp': No such 
file or directory
make[3]: *** [Build:22: /usr/src/linux-next/tools/objtool/str_error_r.o] Error 1
make[2]: *** [Makefile:46: /usr/src/linux-next/tools/objtool/objtool-in.o] 
Error 2
make[1]: *** [Makefile:63: objtool] Error 2
make: *** [Makefile:1681: tools/objtool] Error 2




pgpG1B3rxPoGP.pgp
Description: PGP signature

linux-next 20180320 compile failure - tools/lib/str_error_r.c

[valdis . kletnieks]

Not sure who to blame here, or what changed in gcc between 0.16 and 0.19,
or what the proper fix is here

next-20180307 with "gcc version 8.0.1 20180222 (Red Hat 8.0.1-0.16)" built and 
runs fine.

next-20180320 with "gcc (GCC) 8.0.1 20180317 (Red Hat 8.0.1-0.19)"  dies a 
horrid death early
during the compile:

  CC   /usr/src/linux-next/tools/objtool/str_error_r.o
../lib/str_error_r.c: In function 'str_error_r':
../lib/str_error_r.c:25:3: error: passing argument 1 to restrict-qualified 
parameter aliases with argument 5 [-Werror=restrict]
   snprintf(buf, buflen, "INTERNAL ERROR: strerror_r(%d, %p, %zd)=%d", errnum, 
buf, buflen, err);
   ^~~~
cc1: all warnings being treated as errors
mv: cannot stat '/usr/src/linux-next/tools/objtool/.str_error_r.o.tmp': No such 
file or directory
make[3]: *** [Build:22: /usr/src/linux-next/tools/objtool/str_error_r.o] Error 1
make[2]: *** [Makefile:46: /usr/src/linux-next/tools/objtool/objtool-in.o] 
Error 2
make[1]: *** [Makefile:63: objtool] Error 2
make: *** [Makefile:1681: tools/objtool] Error 2




pgpG1B3rxPoGP.pgp
Description: PGP signature

Re: linux-next: ip6tables *broken* - last base chain position %u doesn't match underflow %u (hook %u

[valdis . kletnieks]

On Tue, 20 Mar 2018 16:48:42 +0100, Florian Westphal said:
> valdis.kletni...@vt.edu  wrote:
> > (Resending because I haven't heard anything)
> [ ip6tables broken ]
>
> Sorry, did not see this email before.
>
> I'll investigate asap, thanks for the detailed report.

No problem, it reverts cleanly and looks like it's 4.17 material,
and finding stuff like this is why I build linux-next kernels :)

Just remember to stick a Reported-By: on the fix :)



pgpny1vvlQOAr.pgp
Description: PGP signature

Re: linux-next: ip6tables *broken* - last base chain position %u doesn't match underflow %u (hook %u

[valdis . kletnieks]

On Tue, 20 Mar 2018 16:48:42 +0100, Florian Westphal said:
> valdis.kletni...@vt.edu  wrote:
> > (Resending because I haven't heard anything)
> [ ip6tables broken ]
>
> Sorry, did not see this email before.
>
> I'll investigate asap, thanks for the detailed report.

No problem, it reverts cleanly and looks like it's 4.17 material,
and finding stuff like this is why I build linux-next kernels :)

Just remember to stick a Reported-By: on the fix :)



pgpny1vvlQOAr.pgp
Description: PGP signature

linux-next: ip6tables *broken* - last base chain position %u doesn't match underflow %u (hook %u

[valdis . kletnieks]

(Resending because I haven't heard anything)

Am hitting an issue with this commit:

commit 0d7df906a0e78079a02108b06d32c3ef2238ad25
Author: Florian Westphal 
Date:   Tue Feb 27 19:42:37 2018 +0100

netfilter: x_tables: ensure last rule in base chain matches underflow/policy

This trips on my system:

[   64.402790] ip6_tables: last base chain position 1136 doesn't match 
underflow 1344 (hook 1)

More annoyingly, the return value means that ip6tables aren't initialized
so there's no firewall protection.  (In other words, this:

If a (syzkaller generated) ruleset doesn't have the underflow/policy
stored as the last rule in the base chain, then iptables will abort()
because it doesn't find the chain policy.

ends up meaning iptables aborts anyhow.

My iptables isn't syzkaller generated - it's mostly crufty vi-generated. ;)

Messages generated as I tried to build smaller tables to narrow down the 
problem:
(not sure where it gets the numbers from, as I reduced it from 50 lines down to 
3
and no real correlation to the tables I was trying to load - in particular the 
numbers
went up once and remained unchanged once, even though between each try I was
whacking out another 5-10 lines...)

[   64.402790] ip6_tables: last base chain position 1136 doesn't match 
underflow 1344 (hook 1)
[ 1897.914828] ip6_tables: last base chain position 928 doesn't match underflow 
1136 (hook 1)
[ 1954.032735] ip6_tables: last base chain position 720 doesn't match underflow 
928 (hook 1)
[ 2021.813719] ip6_tables: last base chain position 920 doesn't match underflow 
1128 (hook 1)
[ 2035.044103] ip6_tables: last base chain position 920 doesn't match underflow 
1128 (hook 1)
[ 2060.594412] ip6_tables: last base chain position 616 doesn't match underflow 
824 (hook 1)

I finally got /etc/sysconfig/ip6tables down to this:

# Generated by ip6tables-save v1.6.2 on Thu Mar  8 08:20:04 2018
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [208207395:46346275671]
[120166037:34218429901] -A INPUT -i lo+ -j ACCEPT
[129329499:129691207309] -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j 
ACCEPT
[0:0] -A INPUT -j DROP
COMMIT
# Completed on Thu Mar  8 08:20:04 2018

About as minimal as it can get. :)

Any ideas?


pgpQr3omeGDfu.pgp
Description: PGP signature

linux-next: ip6tables *broken* - last base chain position %u doesn't match underflow %u (hook %u

[valdis . kletnieks]

(Resending because I haven't heard anything)

Am hitting an issue with this commit:

commit 0d7df906a0e78079a02108b06d32c3ef2238ad25
Author: Florian Westphal 
Date:   Tue Feb 27 19:42:37 2018 +0100

netfilter: x_tables: ensure last rule in base chain matches underflow/policy

This trips on my system:

[   64.402790] ip6_tables: last base chain position 1136 doesn't match 
underflow 1344 (hook 1)

More annoyingly, the return value means that ip6tables aren't initialized
so there's no firewall protection.  (In other words, this:

If a (syzkaller generated) ruleset doesn't have the underflow/policy
stored as the last rule in the base chain, then iptables will abort()
because it doesn't find the chain policy.

ends up meaning iptables aborts anyhow.

My iptables isn't syzkaller generated - it's mostly crufty vi-generated. ;)

Messages generated as I tried to build smaller tables to narrow down the 
problem:
(not sure where it gets the numbers from, as I reduced it from 50 lines down to 
3
and no real correlation to the tables I was trying to load - in particular the 
numbers
went up once and remained unchanged once, even though between each try I was
whacking out another 5-10 lines...)

[   64.402790] ip6_tables: last base chain position 1136 doesn't match 
underflow 1344 (hook 1)
[ 1897.914828] ip6_tables: last base chain position 928 doesn't match underflow 
1136 (hook 1)
[ 1954.032735] ip6_tables: last base chain position 720 doesn't match underflow 
928 (hook 1)
[ 2021.813719] ip6_tables: last base chain position 920 doesn't match underflow 
1128 (hook 1)
[ 2035.044103] ip6_tables: last base chain position 920 doesn't match underflow 
1128 (hook 1)
[ 2060.594412] ip6_tables: last base chain position 616 doesn't match underflow 
824 (hook 1)

I finally got /etc/sysconfig/ip6tables down to this:

# Generated by ip6tables-save v1.6.2 on Thu Mar  8 08:20:04 2018
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [208207395:46346275671]
[120166037:34218429901] -A INPUT -i lo+ -j ACCEPT
[129329499:129691207309] -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j 
ACCEPT
[0:0] -A INPUT -j DROP
COMMIT
# Completed on Thu Mar  8 08:20:04 2018

About as minimal as it can get. :)

Any ideas?


pgpQr3omeGDfu.pgp
Description: PGP signature

linux-next 20180307 - UBSAN whine in lib/radix-tree.c

[valdis . kletnieks]

Seen in the dmesg:

[0.00] 

[0.00] UBSAN: Undefined behaviour in lib/radix-tree.c:123:14
[0.00] member access within null pointer of type 'const struct 
radix_tree_node'
[0.00] CPU: 0 PID: 0 Comm: swapper/0 Tainted: GT 
4.16.0-rc4-next-20180307-dirty #559
[0.00] Hardware name: Dell Inc. Latitude E6530/07Y85M, BIOS A20 
05/08/2017
[0.00] Call Trace:
[0.00]  dump_stack+0x83/0xca
[0.00]  ubsan_epilogue+0xd/0x3a
[0.00]  handle_null_ptr_deref+0x85/0x90
[0.00]  __ubsan_handle_type_mismatch_v1+0x5e/0x70
[0.00]  __radix_tree_replace+0x1e4/0x1f0
[0.00]  radix_tree_iter_replace+0x25/0x50
[0.00]  idr_alloc_u32+0x166/0x1f0
[0.00]  idr_alloc+0x7e/0xd0
[0.00]  worker_pool_assign_id+0x61/0xd0
[0.00]  ? mutex_lock_nested+0x1b/0x20
[0.00]  workqueue_init_early+0x58a/0xc3f
[0.00]  start_kernel+0x4f7/0x809
[0.00]  x86_64_start_reservations+0x40/0x61
[0.00]  x86_64_start_kernel+0x7b/0x9e
[0.00]  secondary_startup_64+0xa5/0xb0
[0.00] 


not sure why a null 'parent' value got passed to get_slot_offset() in the first 
place, but it sounds
like something is missing an 'if (NULL)' test...


pgpxQhArNSOci.pgp
Description: PGP signature

linux-next 20180307 - UBSAN whine in lib/radix-tree.c

[valdis . kletnieks]

Seen in the dmesg:

[0.00] 

[0.00] UBSAN: Undefined behaviour in lib/radix-tree.c:123:14
[0.00] member access within null pointer of type 'const struct 
radix_tree_node'
[0.00] CPU: 0 PID: 0 Comm: swapper/0 Tainted: GT 
4.16.0-rc4-next-20180307-dirty #559
[0.00] Hardware name: Dell Inc. Latitude E6530/07Y85M, BIOS A20 
05/08/2017
[0.00] Call Trace:
[0.00]  dump_stack+0x83/0xca
[0.00]  ubsan_epilogue+0xd/0x3a
[0.00]  handle_null_ptr_deref+0x85/0x90
[0.00]  __ubsan_handle_type_mismatch_v1+0x5e/0x70
[0.00]  __radix_tree_replace+0x1e4/0x1f0
[0.00]  radix_tree_iter_replace+0x25/0x50
[0.00]  idr_alloc_u32+0x166/0x1f0
[0.00]  idr_alloc+0x7e/0xd0
[0.00]  worker_pool_assign_id+0x61/0xd0
[0.00]  ? mutex_lock_nested+0x1b/0x20
[0.00]  workqueue_init_early+0x58a/0xc3f
[0.00]  start_kernel+0x4f7/0x809
[0.00]  x86_64_start_reservations+0x40/0x61
[0.00]  x86_64_start_kernel+0x7b/0x9e
[0.00]  secondary_startup_64+0xa5/0xb0
[0.00] 


not sure why a null 'parent' value got passed to get_slot_offset() in the first 
place, but it sounds
like something is missing an 'if (NULL)' test...


pgpxQhArNSOci.pgp
Description: PGP signature

Re: [PATCH] scsi: eata: drop VLA in reorder()

[valdis . kletnieks]

On Mon, 12 Mar 2018 14:08:34 +1100, "Tobin C. Harding" said:

> removal patch that 768 was a lot of stack space.  That comment did,
> however say 'deep in some transfer call chain'.  I don't know what a
> 'transfer call chain' (the transfer bit) is but is there some heuristic
> we can use to know how deep is deep?  Or more to the point, is there some
> heuristic we can use to know what is an acceptable amount of stack space
> to use?

The canonical "why we put kernel stacks on a diet" configuration:

Imagine a bunch of ISCSI targets - with IPSec wrapping the connection.
Arranged into a software RAID5. With LVM. With encryption on the LV.  With XFS
on the encrypted LV.  And then the in-kernel sharing it out over NFS. With
more IPSec wrapping the  NFS TCP connection.

Oh, and I/O interrupts, just for fun.  And most of all of that has to fit their 
*entire*
stack chain into 2 4K pages.  Suddenly, that 768 bytes is taking close to 10% of
*all* of the stack that all of that call chain has to share.

And I see that patch is against scsi/eata.c - which means it can plausibly end 
up
sharing that stack scenario above starting at 'software raid5'.

(For bonus points, the alert reader is invited to figure out which stack each 
of the
above actually ends up on.  No, it isn't split across enough stacks that taking
768 bytes out of any of them is acceptable.. :)


pgpNOPolYrc3M.pgp
Description: PGP signature

Re: [PATCH] scsi: eata: drop VLA in reorder()

[valdis . kletnieks]

On Mon, 12 Mar 2018 14:08:34 +1100, "Tobin C. Harding" said:

> removal patch that 768 was a lot of stack space.  That comment did,
> however say 'deep in some transfer call chain'.  I don't know what a
> 'transfer call chain' (the transfer bit) is but is there some heuristic
> we can use to know how deep is deep?  Or more to the point, is there some
> heuristic we can use to know what is an acceptable amount of stack space
> to use?

The canonical "why we put kernel stacks on a diet" configuration:

Imagine a bunch of ISCSI targets - with IPSec wrapping the connection.
Arranged into a software RAID5. With LVM. With encryption on the LV.  With XFS
on the encrypted LV.  And then the in-kernel sharing it out over NFS. With
more IPSec wrapping the  NFS TCP connection.

Oh, and I/O interrupts, just for fun.  And most of all of that has to fit their 
*entire*
stack chain into 2 4K pages.  Suddenly, that 768 bytes is taking close to 10% of
*all* of the stack that all of that call chain has to share.

And I see that patch is against scsi/eata.c - which means it can plausibly end 
up
sharing that stack scenario above starting at 'software raid5'.

(For bonus points, the alert reader is invited to figure out which stack each 
of the
above actually ends up on.  No, it isn't split across enough stacks that taking
768 bytes out of any of them is acceptable.. :)


pgpNOPolYrc3M.pgp
Description: PGP signature

ip6tables - last base chain position %u doesn't match underflow %u (hook %u

[valdis . kletnieks]

Am hitting an issue with this commit:

commit 0d7df906a0e78079a02108b06d32c3ef2238ad25
Author: Florian Westphal 
Date:   Tue Feb 27 19:42:37 2018 +0100

netfilter: x_tables: ensure last rule in base chain matches underflow/policy

This trips on my system:

[   64.402790] ip6_tables: last base chain position 1136 doesn't match 
underflow 1344 (hook 1)

More annoyingly, the return value means that ip6tables aren't initialized
so there's no firewall protection.

My iptables isn't syzkaller generated - it's mostly crufty vi-generated. ;)

Messages generated as I tried to build smaller tables to narrow down the 
problem:
(not sure where it gets the numbers from, as I reduced it from 50 lines down to 
3
and no real correlation to the tables I was trying to load - in particular the 
numbers
went up once and remained unchanged once, even though between each try I was
whacking out another 5-10 lines...)

[   64.402790] ip6_tables: last base chain position 1136 doesn't match 
underflow 1344 (hook 1)
[ 1897.914828] ip6_tables: last base chain position 928 doesn't match underflow 
1136 (hook 1)
[ 1954.032735] ip6_tables: last base chain position 720 doesn't match underflow 
928 (hook 1)
[ 2021.813719] ip6_tables: last base chain position 920 doesn't match underflow 
1128 (hook 1)
[ 2035.044103] ip6_tables: last base chain position 920 doesn't match underflow 
1128 (hook 1)
[ 2060.594412] ip6_tables: last base chain position 616 doesn't match underflow 
824 (hook 1)

I finally got /etc/sysconfig/ip6tables down to this:

# Generated by ip6tables-save v1.6.2 on Thu Mar  8 08:20:04 2018
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [208207395:46346275671]
[120166037:34218429901] -A INPUT -i lo+ -j ACCEPT
[129329499:129691207309] -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j 
ACCEPT
[0:0] -A INPUT -j DROP
COMMIT
# Completed on Thu Mar  8 08:20:04 2018

About as minimal as it can get. :)

Any ideas?

ip6tables - last base chain position %u doesn't match underflow %u (hook %u

[valdis . kletnieks]

Am hitting an issue with this commit:

commit 0d7df906a0e78079a02108b06d32c3ef2238ad25
Author: Florian Westphal 
Date:   Tue Feb 27 19:42:37 2018 +0100

netfilter: x_tables: ensure last rule in base chain matches underflow/policy

This trips on my system:

[   64.402790] ip6_tables: last base chain position 1136 doesn't match 
underflow 1344 (hook 1)

More annoyingly, the return value means that ip6tables aren't initialized
so there's no firewall protection.

My iptables isn't syzkaller generated - it's mostly crufty vi-generated. ;)

Messages generated as I tried to build smaller tables to narrow down the 
problem:
(not sure where it gets the numbers from, as I reduced it from 50 lines down to 
3
and no real correlation to the tables I was trying to load - in particular the 
numbers
went up once and remained unchanged once, even though between each try I was
whacking out another 5-10 lines...)

[   64.402790] ip6_tables: last base chain position 1136 doesn't match 
underflow 1344 (hook 1)
[ 1897.914828] ip6_tables: last base chain position 928 doesn't match underflow 
1136 (hook 1)
[ 1954.032735] ip6_tables: last base chain position 720 doesn't match underflow 
928 (hook 1)
[ 2021.813719] ip6_tables: last base chain position 920 doesn't match underflow 
1128 (hook 1)
[ 2035.044103] ip6_tables: last base chain position 920 doesn't match underflow 
1128 (hook 1)
[ 2060.594412] ip6_tables: last base chain position 616 doesn't match underflow 
824 (hook 1)

I finally got /etc/sysconfig/ip6tables down to this:

# Generated by ip6tables-save v1.6.2 on Thu Mar  8 08:20:04 2018
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [208207395:46346275671]
[120166037:34218429901] -A INPUT -i lo+ -j ACCEPT
[129329499:129691207309] -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j 
ACCEPT
[0:0] -A INPUT -j DROP
COMMIT
# Completed on Thu Mar  8 08:20:04 2018

About as minimal as it can get. :)

Any ideas?

Re: [PATCH 2/2] x86/speculation: Support "Enhanced IBRS" on future CPUs

[valdis . kletnieks]

On Mon, 19 Feb 2018 23:42:24 +, "Van De Ven, Arjan" said:

> the guest is not the problem; guests obviously will already honor if Enhanced
> IBRS is enumerated. The problem is mixed migration pools where the hypervisor
> may need to decide to not pass this enumeration through to the guest.

For bonus points:  What should happen to a VM that is live migrated from one
hypervisor to another, and the hypervisors have different IBRS support?


pgppHtdxww49G.pgp
Description: PGP signature

Re: [PATCH 2/2] x86/speculation: Support "Enhanced IBRS" on future CPUs

[valdis . kletnieks]

On Mon, 19 Feb 2018 23:42:24 +, "Van De Ven, Arjan" said:

> the guest is not the problem; guests obviously will already honor if Enhanced
> IBRS is enumerated. The problem is mixed migration pools where the hypervisor
> may need to decide to not pass this enumeration through to the guest.

For bonus points:  What should happen to a VM that is live migrated from one
hypervisor to another, and the hypervisors have different IBRS support?


pgppHtdxww49G.pgp
Description: PGP signature

Re: [PATCH v1 2/2] PCI: Allow user to request power management of conventional and hotplug bridges

[valdis . kletnieks]

On Mon, 19 Feb 2018 17:14:06 -0600, Bjorn Helgaas said:

> Change "pcie_port_pm=force" to enable power management of conventional PCI
> bridges and hotplug bridges as well as PCIe ports.  As with the previous
> PCIe port-only behavior, this is not expected to work in all systems.

This part says the behavior changes - which is itself a Bad Idea unless you
have a deprecation cut-over across several releases.  The general rule is that
you're not allowed to break somebody's kernel without a lot of warning.
Remember that there's probably a lot of embedded systems that hardcode their
boot cmdline and changing the behavior can result in a failed boot - which can
be a royal bitch to debug if the embedded system doesn't have a console.

In addition, it doesn't match the actual patch, which documents the boot
parameter as being removed, rather than the behavior changed:

> diff --git a/Documentation/admin-guide/kernel-parameters.txt 
> b/Documentation/admin-guide/kernel-parameters.txt
> index 1d1d53f85ddd..4660105ec851 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt

> @@ -3143,10 +3147,6 @@
>   compat  Treat PCIe ports as PCI-to-PCI bridges, disable the PCIe
>   ports driver.
>
> - pcie_port_pm=   [PCIE] PCIe port power management handling:
> - off Disable power management of all PCIe ports
> - force   Forcibly enable power management of all PCIe ports
> -

And *that* doesn't match the rest of the patch, which never touches the handling
of that parameter, either changing it or removing it.


pgpfHi0SeztCu.pgp
Description: PGP signature

Re: [PATCH v1 2/2] PCI: Allow user to request power management of conventional and hotplug bridges

[valdis . kletnieks]

On Mon, 19 Feb 2018 17:14:06 -0600, Bjorn Helgaas said:

> Change "pcie_port_pm=force" to enable power management of conventional PCI
> bridges and hotplug bridges as well as PCIe ports.  As with the previous
> PCIe port-only behavior, this is not expected to work in all systems.

This part says the behavior changes - which is itself a Bad Idea unless you
have a deprecation cut-over across several releases.  The general rule is that
you're not allowed to break somebody's kernel without a lot of warning.
Remember that there's probably a lot of embedded systems that hardcode their
boot cmdline and changing the behavior can result in a failed boot - which can
be a royal bitch to debug if the embedded system doesn't have a console.

In addition, it doesn't match the actual patch, which documents the boot
parameter as being removed, rather than the behavior changed:

> diff --git a/Documentation/admin-guide/kernel-parameters.txt 
> b/Documentation/admin-guide/kernel-parameters.txt
> index 1d1d53f85ddd..4660105ec851 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt

> @@ -3143,10 +3147,6 @@
>   compat  Treat PCIe ports as PCI-to-PCI bridges, disable the PCIe
>   ports driver.
>
> - pcie_port_pm=   [PCIE] PCIe port power management handling:
> - off Disable power management of all PCIe ports
> - force   Forcibly enable power management of all PCIe ports
> -

And *that* doesn't match the rest of the patch, which never touches the handling
of that parameter, either changing it or removing it.


pgpfHi0SeztCu.pgp
Description: PGP signature

Re: [RFC] Warn the user when they could overflow mapcount

[valdis . kletnieks]

On Thu, 08 Feb 2018 03:56:26 +0100, Jann Horn said:

> I wouldn't be too surprised if there are more 32-bit overflows that
> start being realistic once you put something on the order of terabytes
> of memory into one machine, given that refcount_t is 32 bits wide -
> for example, the i_count. See
> https://bugs.chromium.org/p/project-zero/issues/detail?id=809 for an
> example where, given a sufficiently high RLIMIT_MEMLOCK, it was
> possible to overflow a 32-bit refcounter on a system with just ~32GiB
> of free memory (minimum required to store 2^32 64-bit pointers).
>
> On systems with RAM on the order of terabytes, it's probably a good
> idea to turn on refcount hardening to make issues like that
> non-exploitable for now.

I have at least 10 systems across the hall that have 3T of RAM on them
across our various HPC clusters.  So this is indeed no longer a hypothetical
issue.


pgp6H70ASJFMG.pgp
Description: PGP signature