[PATCH] scsi: 3ware: fix a missing-check bug

[Wenwen Wang]

In twl_chrdev_ioctl(), the ioctl driver command is firstly copied from the
userspace pointer 'argp' and saved to the kernel object 'driver_command'.
Then a security check is performed on the data buffer size indicated by
'driver_command', which is 'driver_command.buffer_length'. If the security
check is passed, the entire ioctl command is copied again from the 'argp'
pointer and saved to the kernel object 'tw_ioctl'. Then, various operations
are performed on 'tw_ioctl' according to the 'cmd'. Given that the 'argp'
pointer resides in userspace, a malicious userspace process can race to
change the buffer size between the two copies. This way, the user can
bypass the security check and inject invalid data buffer size. This can
cause potential security issues in the following execution.

This patch checks the buffer size obtained in the second copy. An error
code -EINVAL will be returned if it is not same as the original one in the
first copy.

Signed-off-by: Wenwen Wang 
---
 drivers/scsi/3w-sas.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/scsi/3w-sas.c b/drivers/scsi/3w-sas.c
index cf9f2a0..ea41969 100644
--- a/drivers/scsi/3w-sas.c
+++ b/drivers/scsi/3w-sas.c
@@ -757,6 +757,11 @@ static long twl_chrdev_ioctl(struct file *file, unsigned 
int cmd, unsigned long
/* Now copy down the entire ioctl */
if (copy_from_user(tw_ioctl, argp, driver_command.buffer_length + 
sizeof(TW_Ioctl_Buf_Apache) - 1))
goto out3;
+   if (tw_ioctl->driver_command.buffer_length !=
+   driver_command.buffer_length) {
+   retval = -EINVAL;
+   goto out3;
+   }
 
/* See which ioctl we are doing */
switch (cmd) {
-- 
2.7.4

Re: [PATCH v3 3/5] kernel hacking: new config NO_AUTO_INLINE to disable compiler auto-inline optimizations

[kbuild test robot]

Hi Changbin,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[also build test WARNING on v4.17-rc3 next-20180504]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/changbin-du-intel-com/kernel-hacking-GCC-optimization-for-better-debug-experience-Og/20180506-110946
config: arm64-allmodconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64 

Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings

All warnings (new ones prefixed by >>):

   drivers/pci/host/pci-xgene.c: In function 'xgene_pcie_setup_ib_reg':
>> drivers/pci/host/pci-xgene.c:532:2: warning: 'pim_reg' may be used 
>> uninitialized in this function [-Wmaybe-uninitialized]
 xgene_pcie_setup_pims(port, pim_reg, pci_addr, ~(size - 1));
 ^~~
--
   drivers/scsi/ufs/ufs-qcom.c: In function 'ufs_qcom_testbus_config':
>> drivers/scsi/ufs/ufs-qcom.c:1527:6: warning: 'offset' may be used 
>> uninitialized in this function [-Wmaybe-uninitialized]
 int offset;
 ^~
>> drivers/scsi/ufs/ufs-qcom.c:1526:6: warning: 'reg' may be used uninitialized 
>> in this function [-Wmaybe-uninitialized]
 int reg;
 ^~~

vim +/pim_reg +532 drivers/pci/host/pci-xgene.c

5f6b6ccd Tanmay Inamdar 2014-10-01  484  
5f6b6ccd Tanmay Inamdar 2014-10-01  485  static void 
xgene_pcie_setup_ib_reg(struct xgene_pcie_port *port,
5f6b6ccd Tanmay Inamdar 2014-10-01  486 
struct of_pci_range *range, u8 *ib_reg_mask)
5f6b6ccd Tanmay Inamdar 2014-10-01  487  {
5f6b6ccd Tanmay Inamdar 2014-10-01  488 void __iomem *cfg_base = 
port->cfg_base;
d963ab22 Bjorn Helgaas  2016-10-06  489 struct device *dev = port->dev;
5f6b6ccd Tanmay Inamdar 2014-10-01  490 void *bar_addr;
4ecf6b0f Bjorn Helgaas  2016-10-06  491 u32 pim_reg;
5f6b6ccd Tanmay Inamdar 2014-10-01  492 u64 cpu_addr = range->cpu_addr;
5f6b6ccd Tanmay Inamdar 2014-10-01  493 u64 pci_addr = range->pci_addr;
5f6b6ccd Tanmay Inamdar 2014-10-01  494 u64 size = range->size;
5f6b6ccd Tanmay Inamdar 2014-10-01  495 u64 mask = ~(size - 1) | EN_REG;
5f6b6ccd Tanmay Inamdar 2014-10-01  496 u32 flags = 
PCI_BASE_ADDRESS_MEM_TYPE_64;
5f6b6ccd Tanmay Inamdar 2014-10-01  497 u32 bar_low;
5f6b6ccd Tanmay Inamdar 2014-10-01  498 int region;
5f6b6ccd Tanmay Inamdar 2014-10-01  499  
5f6b6ccd Tanmay Inamdar 2014-10-01  500 region = 
xgene_pcie_select_ib_reg(ib_reg_mask, range->size);
5f6b6ccd Tanmay Inamdar 2014-10-01  501 if (region < 0) {
d963ab22 Bjorn Helgaas  2016-10-06  502 dev_warn(dev, "invalid 
pcie dma-range config\n");
5f6b6ccd Tanmay Inamdar 2014-10-01  503 return;
5f6b6ccd Tanmay Inamdar 2014-10-01  504 }
5f6b6ccd Tanmay Inamdar 2014-10-01  505  
5f6b6ccd Tanmay Inamdar 2014-10-01  506 if (range->flags & 
IORESOURCE_PREFETCH)
5f6b6ccd Tanmay Inamdar 2014-10-01  507 flags |= 
PCI_BASE_ADDRESS_MEM_PREFETCH;
5f6b6ccd Tanmay Inamdar 2014-10-01  508  
5f6b6ccd Tanmay Inamdar 2014-10-01  509 bar_low = 
pcie_bar_low_val((u32)cpu_addr, flags);
5f6b6ccd Tanmay Inamdar 2014-10-01  510 switch (region) {
5f6b6ccd Tanmay Inamdar 2014-10-01  511 case 0:
4ecf6b0f Bjorn Helgaas  2016-10-06  512 
xgene_pcie_set_ib_mask(port, BRIDGE_CFG_4, flags, size);
5f6b6ccd Tanmay Inamdar 2014-10-01  513 bar_addr = cfg_base + 
PCI_BASE_ADDRESS_0;
5f6b6ccd Tanmay Inamdar 2014-10-01  514 writel(bar_low, 
bar_addr);
5f6b6ccd Tanmay Inamdar 2014-10-01  515 
writel(upper_32_bits(cpu_addr), bar_addr + 0x4);
4ecf6b0f Bjorn Helgaas  2016-10-06  516 pim_reg = PIM1_1L;
5f6b6ccd Tanmay Inamdar 2014-10-01  517 break;
5f6b6ccd Tanmay Inamdar 2014-10-01  518 case 1:
8e93c513 Bjorn Helgaas  2016-10-06  519 xgene_pcie_writel(port, 
IBAR2, bar_low);
8e93c513 Bjorn Helgaas  2016-10-06  520 xgene_pcie_writel(port, 
IR2MSK, lower_32_bits(mask));
4ecf6b0f Bjorn Helgaas  2016-10-06  521 pim_reg = PIM2_1L;
5f6b6ccd Tanmay Inamdar 2014-10-01  522 break;
5f6b6ccd Tanmay Inamdar 2014-10-01  523 case 2:
8e93c513 Bjorn Helgaas  2016-10-06  524 xgene_pcie_writel(port, 
IBAR3L, bar_low);
8e93c513 Bjorn Helgaas  2016-10-06  525 xgene_pcie_writel(port, 
IBAR3L + 0x4, upper_32_bits(cpu_addr));
8e93c513 

[PATCH] scsi: 3ware: fix a missing-check bug

[Wenwen Wang]

In twl_chrdev_ioctl(), the ioctl driver command is firstly copied from the
userspace pointer 'argp' and saved to the kernel object 'driver_command'.
Then a security check is performed on the data buffer size indicated by
'driver_command', which is 'driver_command.buffer_length'. If the security
check is passed, the entire ioctl command is copied again from the 'argp'
pointer and saved to the kernel object 'tw_ioctl'. Then, various operations
are performed on 'tw_ioctl' according to the 'cmd'. Given that the 'argp'
pointer resides in userspace, a malicious userspace process can race to
change the buffer size between the two copies. This way, the user can
bypass the security check and inject invalid data buffer size. This can
cause potential security issues in the following execution.

This patch checks the buffer size obtained in the second copy. An error
code -EINVAL will be returned if it is not same as the original one in the
first copy.

Signed-off-by: Wenwen Wang 
---
 drivers/scsi/3w-sas.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/scsi/3w-sas.c b/drivers/scsi/3w-sas.c
index cf9f2a0..ea41969 100644
--- a/drivers/scsi/3w-sas.c
+++ b/drivers/scsi/3w-sas.c
@@ -757,6 +757,11 @@ static long twl_chrdev_ioctl(struct file *file, unsigned 
int cmd, unsigned long
/* Now copy down the entire ioctl */
if (copy_from_user(tw_ioctl, argp, driver_command.buffer_length + 
sizeof(TW_Ioctl_Buf_Apache) - 1))
goto out3;
+   if (tw_ioctl->driver_command.buffer_length !=
+   driver_command.buffer_length) {
+   retval = -EINVAL;
+   goto out3;
+   }
 
/* See which ioctl we are doing */
switch (cmd) {
-- 
2.7.4

Re: [PATCH v3 3/5] kernel hacking: new config NO_AUTO_INLINE to disable compiler auto-inline optimizations

[kbuild test robot]

Hi Changbin,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[also build test WARNING on v4.17-rc3 next-20180504]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/changbin-du-intel-com/kernel-hacking-GCC-optimization-for-better-debug-experience-Og/20180506-110946
config: arm64-allmodconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64 

Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings

All warnings (new ones prefixed by >>):

   drivers/pci/host/pci-xgene.c: In function 'xgene_pcie_setup_ib_reg':
>> drivers/pci/host/pci-xgene.c:532:2: warning: 'pim_reg' may be used 
>> uninitialized in this function [-Wmaybe-uninitialized]
 xgene_pcie_setup_pims(port, pim_reg, pci_addr, ~(size - 1));
 ^~~
--
   drivers/scsi/ufs/ufs-qcom.c: In function 'ufs_qcom_testbus_config':
>> drivers/scsi/ufs/ufs-qcom.c:1527:6: warning: 'offset' may be used 
>> uninitialized in this function [-Wmaybe-uninitialized]
 int offset;
 ^~
>> drivers/scsi/ufs/ufs-qcom.c:1526:6: warning: 'reg' may be used uninitialized 
>> in this function [-Wmaybe-uninitialized]
 int reg;
 ^~~

vim +/pim_reg +532 drivers/pci/host/pci-xgene.c

5f6b6ccd Tanmay Inamdar 2014-10-01  484  
5f6b6ccd Tanmay Inamdar 2014-10-01  485  static void 
xgene_pcie_setup_ib_reg(struct xgene_pcie_port *port,
5f6b6ccd Tanmay Inamdar 2014-10-01  486 
struct of_pci_range *range, u8 *ib_reg_mask)
5f6b6ccd Tanmay Inamdar 2014-10-01  487  {
5f6b6ccd Tanmay Inamdar 2014-10-01  488 void __iomem *cfg_base = 
port->cfg_base;
d963ab22 Bjorn Helgaas  2016-10-06  489 struct device *dev = port->dev;
5f6b6ccd Tanmay Inamdar 2014-10-01  490 void *bar_addr;
4ecf6b0f Bjorn Helgaas  2016-10-06  491 u32 pim_reg;
5f6b6ccd Tanmay Inamdar 2014-10-01  492 u64 cpu_addr = range->cpu_addr;
5f6b6ccd Tanmay Inamdar 2014-10-01  493 u64 pci_addr = range->pci_addr;
5f6b6ccd Tanmay Inamdar 2014-10-01  494 u64 size = range->size;
5f6b6ccd Tanmay Inamdar 2014-10-01  495 u64 mask = ~(size - 1) | EN_REG;
5f6b6ccd Tanmay Inamdar 2014-10-01  496 u32 flags = 
PCI_BASE_ADDRESS_MEM_TYPE_64;
5f6b6ccd Tanmay Inamdar 2014-10-01  497 u32 bar_low;
5f6b6ccd Tanmay Inamdar 2014-10-01  498 int region;
5f6b6ccd Tanmay Inamdar 2014-10-01  499  
5f6b6ccd Tanmay Inamdar 2014-10-01  500 region = 
xgene_pcie_select_ib_reg(ib_reg_mask, range->size);
5f6b6ccd Tanmay Inamdar 2014-10-01  501 if (region < 0) {
d963ab22 Bjorn Helgaas  2016-10-06  502 dev_warn(dev, "invalid 
pcie dma-range config\n");
5f6b6ccd Tanmay Inamdar 2014-10-01  503 return;
5f6b6ccd Tanmay Inamdar 2014-10-01  504 }
5f6b6ccd Tanmay Inamdar 2014-10-01  505  
5f6b6ccd Tanmay Inamdar 2014-10-01  506 if (range->flags & 
IORESOURCE_PREFETCH)
5f6b6ccd Tanmay Inamdar 2014-10-01  507 flags |= 
PCI_BASE_ADDRESS_MEM_PREFETCH;
5f6b6ccd Tanmay Inamdar 2014-10-01  508  
5f6b6ccd Tanmay Inamdar 2014-10-01  509 bar_low = 
pcie_bar_low_val((u32)cpu_addr, flags);
5f6b6ccd Tanmay Inamdar 2014-10-01  510 switch (region) {
5f6b6ccd Tanmay Inamdar 2014-10-01  511 case 0:
4ecf6b0f Bjorn Helgaas  2016-10-06  512 
xgene_pcie_set_ib_mask(port, BRIDGE_CFG_4, flags, size);
5f6b6ccd Tanmay Inamdar 2014-10-01  513 bar_addr = cfg_base + 
PCI_BASE_ADDRESS_0;
5f6b6ccd Tanmay Inamdar 2014-10-01  514 writel(bar_low, 
bar_addr);
5f6b6ccd Tanmay Inamdar 2014-10-01  515 
writel(upper_32_bits(cpu_addr), bar_addr + 0x4);
4ecf6b0f Bjorn Helgaas  2016-10-06  516 pim_reg = PIM1_1L;
5f6b6ccd Tanmay Inamdar 2014-10-01  517 break;
5f6b6ccd Tanmay Inamdar 2014-10-01  518 case 1:
8e93c513 Bjorn Helgaas  2016-10-06  519 xgene_pcie_writel(port, 
IBAR2, bar_low);
8e93c513 Bjorn Helgaas  2016-10-06  520 xgene_pcie_writel(port, 
IR2MSK, lower_32_bits(mask));
4ecf6b0f Bjorn Helgaas  2016-10-06  521 pim_reg = PIM2_1L;
5f6b6ccd Tanmay Inamdar 2014-10-01  522 break;
5f6b6ccd Tanmay Inamdar 2014-10-01  523 case 2:
8e93c513 Bjorn Helgaas  2016-10-06  524 xgene_pcie_writel(port, 
IBAR3L, bar_low);
8e93c513 Bjorn Helgaas  2016-10-06  525 xgene_pcie_writel(port, 
IBAR3L + 0x4, upper_32_bits(cpu_addr));
8e93c513 

[PATCH] scsi: 3w-xxxx: fix a missing-check bug

[Wenwen Wang]

In tw_chrdev_ioctl(), the length of the data buffer is firstly copied from
the userspace pointer 'argp' and saved to the kernel object
'data_buffer_length'. Then a security check is performed on it to make sure
that the length is not more than 'TW_MAX_IOCTL_SECTORS * 512'. Otherwise,
an error code -EINVAL is returned. If the security check is passed, the
entire ioctl command is copied again from the 'argp' pointer and saved to
the kernel object 'tw_ioctl'. Then, various operations are performed on
'tw_ioctl' according to the 'cmd'. Given that the 'argp' pointer resides in
userspace, a malicious userspace process can race to change the buffer
length between the two copies. This way, the user can bypass the security
check and inject invalid data buffer length. This can cause potential
security issues in the following execution.

This patch checks the buffer length obtained in the second copy. An error
code -EINVAL will be returned if it is not same as the original one in the
first copy.

Signed-off-by: Wenwen Wang 
---
 drivers/scsi/3w-.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/scsi/3w-.c b/drivers/scsi/3w-.c
index 33261b6..ef79194 100644
--- a/drivers/scsi/3w-.c
+++ b/drivers/scsi/3w-.c
@@ -919,6 +919,10 @@ static long tw_chrdev_ioctl(struct file *file, unsigned 
int cmd, unsigned long a
/* Now copy down the entire ioctl */
if (copy_from_user(tw_ioctl, argp, data_buffer_length + 
sizeof(TW_New_Ioctl) - 1))
goto out2;
+   if (tw_ioctl->data_buffer_length != data_buffer_length) {
+   retval = -EINVAL;
+   goto out2;
+   }
 
passthru = (TW_Passthru *)_ioctl->firmware_command;
 
-- 
2.7.4

[PATCH] scsi: 3w-xxxx: fix a missing-check bug

[Wenwen Wang]

In tw_chrdev_ioctl(), the length of the data buffer is firstly copied from
the userspace pointer 'argp' and saved to the kernel object
'data_buffer_length'. Then a security check is performed on it to make sure
that the length is not more than 'TW_MAX_IOCTL_SECTORS * 512'. Otherwise,
an error code -EINVAL is returned. If the security check is passed, the
entire ioctl command is copied again from the 'argp' pointer and saved to
the kernel object 'tw_ioctl'. Then, various operations are performed on
'tw_ioctl' according to the 'cmd'. Given that the 'argp' pointer resides in
userspace, a malicious userspace process can race to change the buffer
length between the two copies. This way, the user can bypass the security
check and inject invalid data buffer length. This can cause potential
security issues in the following execution.

This patch checks the buffer length obtained in the second copy. An error
code -EINVAL will be returned if it is not same as the original one in the
first copy.

Signed-off-by: Wenwen Wang 
---
 drivers/scsi/3w-.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/scsi/3w-.c b/drivers/scsi/3w-.c
index 33261b6..ef79194 100644
--- a/drivers/scsi/3w-.c
+++ b/drivers/scsi/3w-.c
@@ -919,6 +919,10 @@ static long tw_chrdev_ioctl(struct file *file, unsigned 
int cmd, unsigned long a
/* Now copy down the entire ioctl */
if (copy_from_user(tw_ioctl, argp, data_buffer_length + 
sizeof(TW_New_Ioctl) - 1))
goto out2;
+   if (tw_ioctl->data_buffer_length != data_buffer_length) {
+   retval = -EINVAL;
+   goto out2;
+   }
 
passthru = (TW_Passthru *)_ioctl->firmware_command;
 
-- 
2.7.4

[PATCH v3] block: add verifier for cmdline partition

[Wang YanQing]

I meet strange filesystem corruption issue recently, the reason
is there are overlaps partitions in cmdline partition argument.

This patch add verifier for cmdline partition, then if there are
overlaps partitions, cmdline_partition will log a warning.

Signed-off-by: Wang YanQing 
---
 Changes
 v2-v3:
 1:Fix log one pair of overlaps partitions twice in cmdline_parts_verifier.
 2:Fix out of bound access in cmdline_parts_verifier.

 v1-v2:
 1:Don't treat overlaps partition as a error, but log a warning.

 block/partitions/cmdline.c | 66 ++
 1 file changed, 66 insertions(+)

diff --git a/block/partitions/cmdline.c b/block/partitions/cmdline.c
index e333583..fefcc72 100644
--- a/block/partitions/cmdline.c
+++ b/block/partitions/cmdline.c
@@ -58,6 +58,71 @@ static int __init cmdline_parts_setup(char *s)
 }
 __setup("blkdevparts=", cmdline_parts_setup);
 
+static bool has_overlaps(sector_t from, sector_t size,
+sector_t from2, sector_t size2)
+{
+   sector_t end = from + size;
+   sector_t end2 = from2 + size2;
+
+   if (from >= from2 && from < end2)
+   return true;
+
+   if (end > from2 && end <= end2)
+   return true;
+
+   if (from2 >= from && from2 < end)
+   return true;
+
+   if (end2 > from && end2 <= end)
+   return true;
+
+   return false;
+}
+
+static inline void overlaps_warns_header(void)
+{
+   pr_warn("\n");
+   pr_warn("Overlaps partitions being used in command line partition.\n");
+   pr_warn("Don't use filesystems on overlaps partitions:\n");
+}
+
+static inline void overlaps_warns_tailer(void)
+{
+   pr_warn("\n");
+}
+
+static void cmdline_parts_verifier(int slot, struct parsed_partitions *state)
+{
+   int i;
+   bool header = true;
+
+   for (; slot < state->limit && state->parts[slot].has_info; slot++) {
+   for (i = slot+1; i < state->limit && state->parts[i].has_info;
+i++) {
+   if (has_overlaps(state->parts[slot].from,
+state->parts[slot].size,
+state->parts[i].from,
+state->parts[i].size)) {
+   if (header) {
+   header = false;
+   overlaps_warns_header();
+   }
+   pr_warn("%s[%llu,%llu] overlaps with "
+   "%s[%llu,%llu].\n",
+   state->parts[slot].info.volname,
+   (u64)state->parts[slot].from << 9,
+   (u64)state->parts[slot].size << 9,
+   state->parts[i].info.volname,
+   (u64)state->parts[i].from << 9,
+   (u64)state->parts[i].size << 9);
+   }
+   }
+   }
+
+   if (!header)
+   overlaps_warns_tailer();
+}
+
 /*
  * Purpose: allocate cmdline partitions.
  * Returns:
@@ -93,6 +158,7 @@ int cmdline_partition(struct parsed_partitions *state)
disk_size = get_capacity(state->bdev->bd_disk) << 9;
 
cmdline_parts_set(parts, disk_size, 1, add_part, (void *)state);
+   cmdline_parts_verifier(1, (void *)state);
 
strlcat(state->pp_buf, "\n", PAGE_SIZE);
 
-- 
1.8.5.6.2.g3d8a54e.dirty

[PATCH v3] block: add verifier for cmdline partition

[Wang YanQing]

I meet strange filesystem corruption issue recently, the reason
is there are overlaps partitions in cmdline partition argument.

This patch add verifier for cmdline partition, then if there are
overlaps partitions, cmdline_partition will log a warning.

Signed-off-by: Wang YanQing 
---
 Changes
 v2-v3:
 1:Fix log one pair of overlaps partitions twice in cmdline_parts_verifier.
 2:Fix out of bound access in cmdline_parts_verifier.

 v1-v2:
 1:Don't treat overlaps partition as a error, but log a warning.

 block/partitions/cmdline.c | 66 ++
 1 file changed, 66 insertions(+)

diff --git a/block/partitions/cmdline.c b/block/partitions/cmdline.c
index e333583..fefcc72 100644
--- a/block/partitions/cmdline.c
+++ b/block/partitions/cmdline.c
@@ -58,6 +58,71 @@ static int __init cmdline_parts_setup(char *s)
 }
 __setup("blkdevparts=", cmdline_parts_setup);
 
+static bool has_overlaps(sector_t from, sector_t size,
+sector_t from2, sector_t size2)
+{
+   sector_t end = from + size;
+   sector_t end2 = from2 + size2;
+
+   if (from >= from2 && from < end2)
+   return true;
+
+   if (end > from2 && end <= end2)
+   return true;
+
+   if (from2 >= from && from2 < end)
+   return true;
+
+   if (end2 > from && end2 <= end)
+   return true;
+
+   return false;
+}
+
+static inline void overlaps_warns_header(void)
+{
+   pr_warn("\n");
+   pr_warn("Overlaps partitions being used in command line partition.\n");
+   pr_warn("Don't use filesystems on overlaps partitions:\n");
+}
+
+static inline void overlaps_warns_tailer(void)
+{
+   pr_warn("\n");
+}
+
+static void cmdline_parts_verifier(int slot, struct parsed_partitions *state)
+{
+   int i;
+   bool header = true;
+
+   for (; slot < state->limit && state->parts[slot].has_info; slot++) {
+   for (i = slot+1; i < state->limit && state->parts[i].has_info;
+i++) {
+   if (has_overlaps(state->parts[slot].from,
+state->parts[slot].size,
+state->parts[i].from,
+state->parts[i].size)) {
+   if (header) {
+   header = false;
+   overlaps_warns_header();
+   }
+   pr_warn("%s[%llu,%llu] overlaps with "
+   "%s[%llu,%llu].\n",
+   state->parts[slot].info.volname,
+   (u64)state->parts[slot].from << 9,
+   (u64)state->parts[slot].size << 9,
+   state->parts[i].info.volname,
+   (u64)state->parts[i].from << 9,
+   (u64)state->parts[i].size << 9);
+   }
+   }
+   }
+
+   if (!header)
+   overlaps_warns_tailer();
+}
+
 /*
  * Purpose: allocate cmdline partitions.
  * Returns:
@@ -93,6 +158,7 @@ int cmdline_partition(struct parsed_partitions *state)
disk_size = get_capacity(state->bdev->bd_disk) << 9;
 
cmdline_parts_set(parts, disk_size, 1, add_part, (void *)state);
+   cmdline_parts_verifier(1, (void *)state);
 
strlcat(state->pp_buf, "\n", PAGE_SIZE);
 
-- 
1.8.5.6.2.g3d8a54e.dirty

Re: [PATCH 8/8] rhashtable: don't hold lock on first table throughout insertion.

[Herbert Xu]

On Sun, May 06, 2018 at 08:00:49AM +1000, NeilBrown wrote:
>
> The insert function must (and does) take the lock on the bucket before
> testing if there is a "next" table.
> If one inserter finds that it has locked the "last" table (because there
> is no next) and successfully inserts, then the other inserter cannot
> have locked that table yet, else it would have inserted.  When it does,
> it will find what the first inserter inserted. 

If you release the lock to the first table then it may be deleted
by the resize thread.  Hence the other inserter may not have even
started from the same place.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH 8/8] rhashtable: don't hold lock on first table throughout insertion.

[Herbert Xu]

On Sun, May 06, 2018 at 08:00:49AM +1000, NeilBrown wrote:
>
> The insert function must (and does) take the lock on the bucket before
> testing if there is a "next" table.
> If one inserter finds that it has locked the "last" table (because there
> is no next) and successfully inserts, then the other inserter cannot
> have locked that table yet, else it would have inserted.  When it does,
> it will find what the first inserter inserted. 

If you release the lock to the first table then it may be deleted
by the resize thread.  Hence the other inserter may not have even
started from the same place.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH 4/8] rhashtable: fix race in nested_table_alloc()

[Herbert Xu]

On Sun, May 06, 2018 at 07:48:20AM +1000, NeilBrown wrote:
>
> The spinlock protects 2 or more buckets.  The nested table contains at
> least 512 buckets, maybe more.
> It is quite possible for two insertions into 2 different buckets to both
> get their spinlock and both try to instantiate the same nested table.

I think you missed the fact that when we use nested tables the spin
lock table is limited to just a single page and hence corresponds
to the first level in the nested table.  Therefore it's always safe.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH 4/8] rhashtable: fix race in nested_table_alloc()

[Herbert Xu]

On Sun, May 06, 2018 at 07:48:20AM +1000, NeilBrown wrote:
>
> The spinlock protects 2 or more buckets.  The nested table contains at
> least 512 buckets, maybe more.
> It is quite possible for two insertions into 2 different buckets to both
> get their spinlock and both try to instantiate the same nested table.

I think you missed the fact that when we use nested tables the spin
lock table is limited to just a single page and hence corresponds
to the first level in the nested table.  Therefore it's always safe.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: kernel panic: EXT4-fs (device loop0): panic forced after error

[Tetsuo Handa]

On 2018/05/06 11:24, Theodore Y. Ts'o wrote:
> On Sat, May 05, 2018 at 05:57:02PM -0700, syzbot wrote:
>> Hello,
>>
>> syzbot found the following crash on:
>>
>> EXT4-fs error (device loop0): ext4_iget:4756: inode #2: comm
>> syz-executor909: root inode unallocated
>> Kernel panic - not syncing: EXT4-fs (device loop0): panic forced after error
> 
> I don't get why syzbot considers this a bug.  It created a corrupted
> file system, mounted it as root, and said file system had the flag
> which says, "panic if you find a file system corruption".

"panic if file system error occurred (so that we won't continue with
inconsistent state)", doesn't it?

Since syzbot is hitting this error path inside mount() request, calling
panic() when something went wrong inside mount() request might be
overkill. We can recover without shutting down the system, can't we?

> 
> In what world is this a security bug?  There's a *reason* why I've
> always said people who want to containers to be allowed to mount
> arbitrary file systems controlled by potentially malicious container
> users are insane
> 
> I could mark this as a one-off invalid bug, but if syzkaller is going
> to be generating classes of corrupted file systems like this, and are
> going to be complaing about how this causes the kernel to crash, then
> we have a fundamental syzkaller BUG.
> 
>   - Ted

If we won't try to recover this case, this specific report would be
marked as "#syz invalid".

Re: kernel panic: EXT4-fs (device loop0): panic forced after error

[Tetsuo Handa]

On 2018/05/06 11:24, Theodore Y. Ts'o wrote:
> On Sat, May 05, 2018 at 05:57:02PM -0700, syzbot wrote:
>> Hello,
>>
>> syzbot found the following crash on:
>>
>> EXT4-fs error (device loop0): ext4_iget:4756: inode #2: comm
>> syz-executor909: root inode unallocated
>> Kernel panic - not syncing: EXT4-fs (device loop0): panic forced after error
> 
> I don't get why syzbot considers this a bug.  It created a corrupted
> file system, mounted it as root, and said file system had the flag
> which says, "panic if you find a file system corruption".

"panic if file system error occurred (so that we won't continue with
inconsistent state)", doesn't it?

Since syzbot is hitting this error path inside mount() request, calling
panic() when something went wrong inside mount() request might be
overkill. We can recover without shutting down the system, can't we?

> 
> In what world is this a security bug?  There's a *reason* why I've
> always said people who want to containers to be allowed to mount
> arbitrary file systems controlled by potentially malicious container
> users are insane
> 
> I could mark this as a one-off invalid bug, but if syzkaller is going
> to be generating classes of corrupted file systems like this, and are
> going to be complaing about how this causes the kernel to crash, then
> we have a fundamental syzkaller BUG.
> 
>   - Ted

If we won't try to recover this case, this specific report would be
marked as "#syz invalid".

Re: [PATCH] nubus: Unconditionally register bus type

[Greg Kroah-Hartman]

On Sun, May 06, 2018 at 11:47:52AM +1000, Finn Thain wrote:
> Loading a NuBus driver module on a non-NuBus machine triggers the
> BUG_ON(!drv->bus->p) in driver_register() because the bus does not get
> registered unless MACH_IS_MAC(). Avoid this by registering the bus
> unconditionally using postcore_initcall().
> 
> Cc: Greg Kroah-Hartman 
> Reported-by: Michael Schmitz 
> Tested-by: Stan Johnson 
> Fixes: 7f86c765a6a2 ("nubus: Add support for the driver model")
> Signed-off-by: Finn Thain 
> ---
>  drivers/nubus/bus.c   | 3 ++-
>  drivers/nubus/nubus.c | 5 -
>  include/linux/nubus.h | 1 -
>  3 files changed, 2 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/nubus/bus.c b/drivers/nubus/bus.c
> index d306c348c857..27ca9f1a281b 100644
> --- a/drivers/nubus/bus.c
> +++ b/drivers/nubus/bus.c
> @@ -63,7 +63,7 @@ static struct device nubus_parent = {
>   .init_name  = "nubus",
>  };
>  
> -int __init nubus_bus_register(void)
> +static int __init nubus_bus_register(void)
>  {
>   int err;
>  
> @@ -78,6 +78,7 @@ int __init nubus_bus_register(void)
>   device_unregister(_parent);
>   return err;
>  }
> +postcore_initcall(nubus_bus_register);

Why not just have an "bus is registered" flag in your driver register
function that refuses to let drivers register with the driver core if it
isn't set?  And then fix your linking error, the bus should come first
in link order, before your drivers :)

thanks,

greg k-h

Re: [PATCH] nubus: Unconditionally register bus type

[Greg Kroah-Hartman]

On Sun, May 06, 2018 at 11:47:52AM +1000, Finn Thain wrote:
> Loading a NuBus driver module on a non-NuBus machine triggers the
> BUG_ON(!drv->bus->p) in driver_register() because the bus does not get
> registered unless MACH_IS_MAC(). Avoid this by registering the bus
> unconditionally using postcore_initcall().
> 
> Cc: Greg Kroah-Hartman 
> Reported-by: Michael Schmitz 
> Tested-by: Stan Johnson 
> Fixes: 7f86c765a6a2 ("nubus: Add support for the driver model")
> Signed-off-by: Finn Thain 
> ---
>  drivers/nubus/bus.c   | 3 ++-
>  drivers/nubus/nubus.c | 5 -
>  include/linux/nubus.h | 1 -
>  3 files changed, 2 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/nubus/bus.c b/drivers/nubus/bus.c
> index d306c348c857..27ca9f1a281b 100644
> --- a/drivers/nubus/bus.c
> +++ b/drivers/nubus/bus.c
> @@ -63,7 +63,7 @@ static struct device nubus_parent = {
>   .init_name  = "nubus",
>  };
>  
> -int __init nubus_bus_register(void)
> +static int __init nubus_bus_register(void)
>  {
>   int err;
>  
> @@ -78,6 +78,7 @@ int __init nubus_bus_register(void)
>   device_unregister(_parent);
>   return err;
>  }
> +postcore_initcall(nubus_bus_register);

Why not just have an "bus is registered" flag in your driver register
function that refuses to let drivers register with the driver core if it
isn't set?  And then fix your linking error, the bus should come first
in link order, before your drivers :)

thanks,

greg k-h

[PATCH v2] block: add verifier for cmdline partition

[Wang YanQing]

I meet strange filesystem corruption issue recently, the reason
is there are overlaps partitions in cmdline partition argument.

This patch add verifier for cmdline partition, then if there are
overlaps partitions, cmdline_partition will log a warning. We don't
treat overlaps partition as a error:
"
Caizhiyong  said:
Partition overlap was intentionally designed in this cmdline partition.
reference http://lists.infradead.org/pipermail/linux-mtd/2013-August/048092.html
"

Signed-off-by: Wang YanQing 
---
 Changes
 v1-v2:
 1:Don't treat overlaps partition as a error, but log a warning.

 block/partitions/cmdline.c | 68 ++
 1 file changed, 68 insertions(+)

diff --git a/block/partitions/cmdline.c b/block/partitions/cmdline.c
index e333583..7d70046 100644
--- a/block/partitions/cmdline.c
+++ b/block/partitions/cmdline.c
@@ -58,6 +58,73 @@ static int __init cmdline_parts_setup(char *s)
 }
 __setup("blkdevparts=", cmdline_parts_setup);
 
+static bool has_overlaps(sector_t from, sector_t size,
+sector_t from2, sector_t size2)
+{
+   sector_t end = from + size;
+   sector_t end2 = from2 + size2;
+
+   if (from >= from2 && from < end2)
+   return true;
+
+   if (end > from2 && end <= end2)
+   return true;
+
+   if (from2 >= from && from2 < end)
+   return true;
+
+   if (end2 > from && end2 <= end)
+   return true;
+
+   return false;
+}
+
+static inline void overlaps_warns_header(void)
+{
+   pr_warn("\n");
+   pr_warn("Overlaps partitions being used in command line partition.\n");
+   pr_warn("Don't use filesystems on overlaps partitions:\n");
+}
+
+static inline void overlaps_warns_tailer(void)
+{
+   pr_warn("\n");
+}
+
+static void cmdline_parts_verifier(int slot, struct parsed_partitions *state)
+{
+   int i, j = slot;
+   bool header = true;
+
+   for (; state->parts[slot].has_info; slot++) {
+   for (i = j; state->parts[i].has_info; i++) {
+   if (i == slot)
+   continue;
+
+   if (has_overlaps(state->parts[slot].from,
+state->parts[slot].size,
+state->parts[i].from,
+state->parts[i].size)) {
+   if (header) {
+   header = false;
+   overlaps_warns_header();
+   }
+   pr_warn("%s[%llu,%llu] overlaps with "
+   "%s[%llu,%llu].\n",
+   state->parts[slot].info.volname,
+   (u64)state->parts[slot].from << 9,
+   (u64)state->parts[slot].size << 9,
+   state->parts[i].info.volname,
+   (u64)state->parts[i].from << 9,
+   (u64)state->parts[i].size << 9);
+   }
+   }
+   }
+
+   if (!header)
+   overlaps_warns_tailer();
+}
+
 /*
  * Purpose: allocate cmdline partitions.
  * Returns:
@@ -93,6 +160,7 @@ int cmdline_partition(struct parsed_partitions *state)
disk_size = get_capacity(state->bdev->bd_disk) << 9;
 
cmdline_parts_set(parts, disk_size, 1, add_part, (void *)state);
+   cmdline_parts_verifier(1, (void *)state);
 
strlcat(state->pp_buf, "\n", PAGE_SIZE);
 
-- 
1.8.5.6.2.g3d8a54e.dirty

[PATCH v2] block: add verifier for cmdline partition

[Wang YanQing]

I meet strange filesystem corruption issue recently, the reason
is there are overlaps partitions in cmdline partition argument.

This patch add verifier for cmdline partition, then if there are
overlaps partitions, cmdline_partition will log a warning. We don't
treat overlaps partition as a error:
"
Caizhiyong  said:
Partition overlap was intentionally designed in this cmdline partition.
reference http://lists.infradead.org/pipermail/linux-mtd/2013-August/048092.html
"

Signed-off-by: Wang YanQing 
---
 Changes
 v1-v2:
 1:Don't treat overlaps partition as a error, but log a warning.

 block/partitions/cmdline.c | 68 ++
 1 file changed, 68 insertions(+)

diff --git a/block/partitions/cmdline.c b/block/partitions/cmdline.c
index e333583..7d70046 100644
--- a/block/partitions/cmdline.c
+++ b/block/partitions/cmdline.c
@@ -58,6 +58,73 @@ static int __init cmdline_parts_setup(char *s)
 }
 __setup("blkdevparts=", cmdline_parts_setup);
 
+static bool has_overlaps(sector_t from, sector_t size,
+sector_t from2, sector_t size2)
+{
+   sector_t end = from + size;
+   sector_t end2 = from2 + size2;
+
+   if (from >= from2 && from < end2)
+   return true;
+
+   if (end > from2 && end <= end2)
+   return true;
+
+   if (from2 >= from && from2 < end)
+   return true;
+
+   if (end2 > from && end2 <= end)
+   return true;
+
+   return false;
+}
+
+static inline void overlaps_warns_header(void)
+{
+   pr_warn("\n");
+   pr_warn("Overlaps partitions being used in command line partition.\n");
+   pr_warn("Don't use filesystems on overlaps partitions:\n");
+}
+
+static inline void overlaps_warns_tailer(void)
+{
+   pr_warn("\n");
+}
+
+static void cmdline_parts_verifier(int slot, struct parsed_partitions *state)
+{
+   int i, j = slot;
+   bool header = true;
+
+   for (; state->parts[slot].has_info; slot++) {
+   for (i = j; state->parts[i].has_info; i++) {
+   if (i == slot)
+   continue;
+
+   if (has_overlaps(state->parts[slot].from,
+state->parts[slot].size,
+state->parts[i].from,
+state->parts[i].size)) {
+   if (header) {
+   header = false;
+   overlaps_warns_header();
+   }
+   pr_warn("%s[%llu,%llu] overlaps with "
+   "%s[%llu,%llu].\n",
+   state->parts[slot].info.volname,
+   (u64)state->parts[slot].from << 9,
+   (u64)state->parts[slot].size << 9,
+   state->parts[i].info.volname,
+   (u64)state->parts[i].from << 9,
+   (u64)state->parts[i].size << 9);
+   }
+   }
+   }
+
+   if (!header)
+   overlaps_warns_tailer();
+}
+
 /*
  * Purpose: allocate cmdline partitions.
  * Returns:
@@ -93,6 +160,7 @@ int cmdline_partition(struct parsed_partitions *state)
disk_size = get_capacity(state->bdev->bd_disk) << 9;
 
cmdline_parts_set(parts, disk_size, 1, add_part, (void *)state);
+   cmdline_parts_verifier(1, (void *)state);
 
strlcat(state->pp_buf, "\n", PAGE_SIZE);
 
-- 
1.8.5.6.2.g3d8a54e.dirty

Re: [PATCH] x86/kvm: replace TASK_UNINTERRUPTIBLE with TASK_KILLABLE

[Joey Pabalinas]

On Thu, Mar 29, 2018 at 11:41:20PM +0200, Radim Krčmář wrote:
> I remember we had a bug where tasks were getting stuck when running
> nested and maybe there are going to be other cases to excuse the change.
> I'm slightly against changing the behavior as it's pretty hard to test,
> but I can be easily convinced with a well reasoned patch,
> 
> thanks!

Yes, that was quite a thorough explanation, thank you for that :). Took
me a while to read through all of your reply as well as look through the
accompanying code. I can definitely see that, yeah, this is quite a bit
more complicated that it appears at first glance. This will take a lot
more thought before tackling, and I am unsure if honestl it may be a bit
over my head as well, but I suppose I will see, haha.

Regardless, I did learn a lot, so thank you for taking the time to make
such a detailed reply!

If I do end up seeing something I can improve will definitely cook up
a patch and send it in, thanks again!

-- 
Cheers,
Joey Pabalinas


signature.asc
Description: PGP signature

Re: [PATCH] x86/kvm: replace TASK_UNINTERRUPTIBLE with TASK_KILLABLE

[Joey Pabalinas]

On Thu, Mar 29, 2018 at 11:41:20PM +0200, Radim Krčmář wrote:
> I remember we had a bug where tasks were getting stuck when running
> nested and maybe there are going to be other cases to excuse the change.
> I'm slightly against changing the behavior as it's pretty hard to test,
> but I can be easily convinced with a well reasoned patch,
> 
> thanks!

Yes, that was quite a thorough explanation, thank you for that :). Took
me a while to read through all of your reply as well as look through the
accompanying code. I can definitely see that, yeah, this is quite a bit
more complicated that it appears at first glance. This will take a lot
more thought before tackling, and I am unsure if honestl it may be a bit
over my head as well, but I suppose I will see, haha.

Regardless, I did learn a lot, so thank you for taking the time to make
such a detailed reply!

If I do end up seeing something I can improve will definitely cook up
a patch and send it in, thanks again!

-- 
Cheers,
Joey Pabalinas


signature.asc
Description: PGP signature

Re: BUG: corrupted list in rdma_listen

[syzbot]

syzbot has found a reproducer for the following crash on:

HEAD commit:d2d741e5d189 kmsan: add initialization for shmem pages
git tree:   https://github.com/google/kmsan.git/master
console output: https://syzkaller.appspot.com/x/log.txt?x=126df29780
kernel config:  https://syzkaller.appspot.com/x/.config?x=48f9de3384bcd0f
dashboard link: https://syzkaller.appspot.com/bug?extid=8458d13b13562abf6b77
compiler:   clang version 7.0.0 (trunk 329391)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=168a723780
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=176f5e0780

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+8458d13b13562abf6...@syzkaller.appspotmail.com

list_add corruption. prev->next should be next (f634c78e), but  
was   (null). (prev=4ec1b2e1).

[ cut here ]
kernel BUG at lib/list_debug.c:28!
invalid opcode:  [#1] SMP PTI
Dumping ftrace buffer:
   (ftrace buffer empty)
Modules linked in:
CPU: 1 PID: 4686 Comm: syz-executor918 Not tainted 4.16.0+ #87
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

RIP: 0010:__list_add_valid+0x43c/0x450 lib/list_debug.c:26
RSP: 0018:8801af0df9e0 EFLAGS: 00010286
RAX: 0075 RBX:  RCX: 
RDX:  RSI: b000 RDI: ea00
RBP: 8801af0dfa48 R08: 01080020 R09: 0002
R10:  R11:  R12: 8acd0d90
R13:  R14:  R15: 88019d514418
FS:  01259880() GS:88021fd0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 006cc0a0 CR3: 00019d4a4000 CR4: 001406e0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
 __list_add include/linux/list.h:60 [inline]
 list_add_tail include/linux/list.h:93 [inline]
 cma_listen_on_all drivers/infiniband/core/cma.c:2309 [inline]
 rdma_listen+0x65f/0x10f0 drivers/infiniband/core/cma.c:
 ucma_listen+0x4e9/0x630 drivers/infiniband/core/ucma.c:1074
 ucma_write+0x576/0x5e0 drivers/infiniband/core/ucma.c:1656
 __vfs_write+0x1a3/0x9f0 fs/read_write.c:480
 vfs_write+0x463/0x8d0 fs/read_write.c:544
 SYSC_write+0x172/0x360 fs/read_write.c:589
 SyS_write+0x55/0x80 fs/read_write.c:581
 do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
 entry_SYSCALL_64_after_hwframe+0x3d/0xa2
RIP: 0033:0x4417b9
RSP: 002b:7ffd97fcaf88 EFLAGS: 0207 ORIG_RAX: 0001
RAX: ffda RBX:  RCX: 004417b9
RDX: 0010 RSI: 2100 RDI: 0003
RBP:  R08: 0001 R09: 0001
R10: 0001 R11: 0207 R12: aa92
R13: 006cd448 R14:  R15: 
Code: 80 0c 00 00 00 00 00 00 41 c7 87 20 03 00 00 00 00 00 00 48 c7 c7 c8  
f6 82 8a 31 c0 4c 89 e6 4c 89 ea 48 8b 4d c0 e8 34 ab 51 fd <0f> 0b 66 90  
eb fe 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 55

RIP: __list_add_valid+0x43c/0x450 lib/list_debug.c:26 RSP: 8801af0df9e0
---[ end trace 0c643a8ef7cc369f ]---

Re: BUG: corrupted list in rdma_listen

[syzbot]

syzbot has found a reproducer for the following crash on:

HEAD commit:d2d741e5d189 kmsan: add initialization for shmem pages
git tree:   https://github.com/google/kmsan.git/master
console output: https://syzkaller.appspot.com/x/log.txt?x=126df29780
kernel config:  https://syzkaller.appspot.com/x/.config?x=48f9de3384bcd0f
dashboard link: https://syzkaller.appspot.com/bug?extid=8458d13b13562abf6b77
compiler:   clang version 7.0.0 (trunk 329391)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=168a723780
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=176f5e0780

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+8458d13b13562abf6...@syzkaller.appspotmail.com

list_add corruption. prev->next should be next (f634c78e), but  
was   (null). (prev=4ec1b2e1).

[ cut here ]
kernel BUG at lib/list_debug.c:28!
invalid opcode:  [#1] SMP PTI
Dumping ftrace buffer:
   (ftrace buffer empty)
Modules linked in:
CPU: 1 PID: 4686 Comm: syz-executor918 Not tainted 4.16.0+ #87
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

RIP: 0010:__list_add_valid+0x43c/0x450 lib/list_debug.c:26
RSP: 0018:8801af0df9e0 EFLAGS: 00010286
RAX: 0075 RBX:  RCX: 
RDX:  RSI: b000 RDI: ea00
RBP: 8801af0dfa48 R08: 01080020 R09: 0002
R10:  R11:  R12: 8acd0d90
R13:  R14:  R15: 88019d514418
FS:  01259880() GS:88021fd0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 006cc0a0 CR3: 00019d4a4000 CR4: 001406e0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
 __list_add include/linux/list.h:60 [inline]
 list_add_tail include/linux/list.h:93 [inline]
 cma_listen_on_all drivers/infiniband/core/cma.c:2309 [inline]
 rdma_listen+0x65f/0x10f0 drivers/infiniband/core/cma.c:
 ucma_listen+0x4e9/0x630 drivers/infiniband/core/ucma.c:1074
 ucma_write+0x576/0x5e0 drivers/infiniband/core/ucma.c:1656
 __vfs_write+0x1a3/0x9f0 fs/read_write.c:480
 vfs_write+0x463/0x8d0 fs/read_write.c:544
 SYSC_write+0x172/0x360 fs/read_write.c:589
 SyS_write+0x55/0x80 fs/read_write.c:581
 do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
 entry_SYSCALL_64_after_hwframe+0x3d/0xa2
RIP: 0033:0x4417b9
RSP: 002b:7ffd97fcaf88 EFLAGS: 0207 ORIG_RAX: 0001
RAX: ffda RBX:  RCX: 004417b9
RDX: 0010 RSI: 2100 RDI: 0003
RBP:  R08: 0001 R09: 0001
R10: 0001 R11: 0207 R12: aa92
R13: 006cd448 R14:  R15: 
Code: 80 0c 00 00 00 00 00 00 41 c7 87 20 03 00 00 00 00 00 00 48 c7 c7 c8  
f6 82 8a 31 c0 4c 89 e6 4c 89 ea 48 8b 4d c0 e8 34 ab 51 fd <0f> 0b 66 90  
eb fe 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 55

RIP: __list_add_valid+0x43c/0x450 lib/list_debug.c:26 RSP: 8801af0df9e0
---[ end trace 0c643a8ef7cc369f ]---

[PATCH] scsi: 3w-9xxx: fix a missing-check bug

[Wenwen Wang]

In twa_chrdev_ioctl(), the ioctl driver command is firstly copied from the
userspace pointer 'argp' and saved to the kernel object 'driver_command'.
Then a security check is performed on the data buffer size indicated by
'driver_command', which is 'driver_command.buffer_length'. If the security
check is passed, the entire ioctl command is copied again from the 'argp'
pointer and saved to the kernel object 'tw_ioctl'. Then, various operations
are performed on 'tw_ioctl' according to the 'cmd'. Given that the 'argp'
pointer resides in userspace, a malicious userspace process can race to
change the buffer size between the two copies. This way, the user can
bypass the security check and inject invalid data buffer size. This can
cause potential security issues in the following execution.

This patch checks the buffer size obtained in the second copy. An error
code -EINVAL will be returned if it is not same as the original one in the
first copy.

Signed-off-by: Wenwen Wang 
---
 drivers/scsi/3w-9xxx.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/scsi/3w-9xxx.c b/drivers/scsi/3w-9xxx.c
index b42c9c4..8bc43db 100644
--- a/drivers/scsi/3w-9xxx.c
+++ b/drivers/scsi/3w-9xxx.c
@@ -684,6 +684,12 @@ static long twa_chrdev_ioctl(struct file *file, unsigned 
int cmd, unsigned long
if (copy_from_user(tw_ioctl, argp, driver_command.buffer_length + 
sizeof(TW_Ioctl_Buf_Apache) - 1))
goto out3;
 
+   if (tw_ioctl->driver_command.buffer_length
+!= driver_command.buffer_length) {
+   retval = TW_IOCTL_ERROR_OS_EINVAL;
+   goto out3;
+   }
+
/* See which ioctl we are doing */
switch (cmd) {
case TW_IOCTL_FIRMWARE_PASS_THROUGH:
-- 
2.7.4

[PATCH] scsi: 3w-9xxx: fix a missing-check bug

[Wenwen Wang]

In twa_chrdev_ioctl(), the ioctl driver command is firstly copied from the
userspace pointer 'argp' and saved to the kernel object 'driver_command'.
Then a security check is performed on the data buffer size indicated by
'driver_command', which is 'driver_command.buffer_length'. If the security
check is passed, the entire ioctl command is copied again from the 'argp'
pointer and saved to the kernel object 'tw_ioctl'. Then, various operations
are performed on 'tw_ioctl' according to the 'cmd'. Given that the 'argp'
pointer resides in userspace, a malicious userspace process can race to
change the buffer size between the two copies. This way, the user can
bypass the security check and inject invalid data buffer size. This can
cause potential security issues in the following execution.

This patch checks the buffer size obtained in the second copy. An error
code -EINVAL will be returned if it is not same as the original one in the
first copy.

Signed-off-by: Wenwen Wang 
---
 drivers/scsi/3w-9xxx.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/scsi/3w-9xxx.c b/drivers/scsi/3w-9xxx.c
index b42c9c4..8bc43db 100644
--- a/drivers/scsi/3w-9xxx.c
+++ b/drivers/scsi/3w-9xxx.c
@@ -684,6 +684,12 @@ static long twa_chrdev_ioctl(struct file *file, unsigned 
int cmd, unsigned long
if (copy_from_user(tw_ioctl, argp, driver_command.buffer_length + 
sizeof(TW_Ioctl_Buf_Apache) - 1))
goto out3;
 
+   if (tw_ioctl->driver_command.buffer_length
+!= driver_command.buffer_length) {
+   retval = TW_IOCTL_ERROR_OS_EINVAL;
+   goto out3;
+   }
+
/* See which ioctl we are doing */
switch (cmd) {
case TW_IOCTL_FIRMWARE_PASS_THROUGH:
-- 
2.7.4

Re: [PATCH 05/12] perf pmu: Fix pmu events parsing rule

[Andi Kleen]

Jiri Olsa  writes:

Please fix this quickly, PT is currently totally non functional in Linus
mainline.

-Andi

Re: [PATCH 05/12] perf pmu: Fix pmu events parsing rule

[Andi Kleen]

Jiri Olsa  writes:

Please fix this quickly, PT is currently totally non functional in Linus
mainline.

-Andi

[PATCH] virt: vbox: fix a missing-check bug

[Wenwen Wang]

In vbg_misc_device_ioctl(), the header of the ioctl argument is copied from
the userspace pointer 'arg' and saved to the kernel object 'hdr'. Then the
'version', 'size_in', and 'size_out' fields of 'hdr' are verified. For
example, if 'hdr.version' is not VBG_IOCTL_HDR_VERSION, an error code
-EINVAL will be returned. If 'hdr' can pass all verifications, the whole
structure of the ioctl argument is copied once again from 'arg' and saved
to 'buf'. Then the function vbg_core_ioctl() is invoked to execute the
ioctl command. Given that the 'arg' pointer resides in userspace, a
malicious userspace process can race to change the data pointed to by 'arg'
between the two copies. By doing so, the user can bypass the verifications
on the ioctl argument, which can cause vbg_core_ioctl() to work on unsecure
data because it assumes the 'version', 'size_in', and 'size_out' have been
verified by vbg_misc_device_ioctl(), as mentioned in the comment in
vbg_core_ioctl():

/*
 * hdr->version and hdr->size_in / hdr->size_out minimum size are
 * already checked by vbg_misc_device_ioctl().
 */

This patch adds checks after the second copy to ensure the consistency
between the data obtained in the two copies. In case an inconsistency is
detected, an error code -EINVAL will be returned.

Signed-off-by: Wenwen Wang 
---
 drivers/virt/vboxguest/vboxguest_linux.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/virt/vboxguest/vboxguest_linux.c 
b/drivers/virt/vboxguest/vboxguest_linux.c
index 398d226..6b525259 100644
--- a/drivers/virt/vboxguest/vboxguest_linux.c
+++ b/drivers/virt/vboxguest/vboxguest_linux.c
@@ -125,6 +125,12 @@ static long vbg_misc_device_ioctl(struct file *filp, 
unsigned int req,
ret = -EFAULT;
goto out;
}
+   if (((struct vbg_ioctl_hdr *)buf)->version != hdr.version ||
+   ((struct vbg_ioctl_hdr *)buf)->size_in != hdr.size_in ||
+   ((struct vbg_ioctl_hdr *)buf)->size_out != hdr.size_out) {
+   ret = -EINVAL;
+   goto out;
+   }
if (hdr.size_in < size)
memset(buf + hdr.size_in, 0, size -  hdr.size_in);
 
@@ -133,11 +139,6 @@ static long vbg_misc_device_ioctl(struct file *filp, 
unsigned int req,
goto out;
 
returned_size = ((struct vbg_ioctl_hdr *)buf)->size_out;
-   if (returned_size > size) {
-   vbg_debug("%s: too much output data %zu > %zu\n",
- __func__, returned_size, size);
-   returned_size = size;
-   }
if (copy_to_user((void *)arg, buf, returned_size) != 0)
ret = -EFAULT;
 
-- 
2.7.4

[PATCH] virt: vbox: fix a missing-check bug

[Wenwen Wang]

In vbg_misc_device_ioctl(), the header of the ioctl argument is copied from
the userspace pointer 'arg' and saved to the kernel object 'hdr'. Then the
'version', 'size_in', and 'size_out' fields of 'hdr' are verified. For
example, if 'hdr.version' is not VBG_IOCTL_HDR_VERSION, an error code
-EINVAL will be returned. If 'hdr' can pass all verifications, the whole
structure of the ioctl argument is copied once again from 'arg' and saved
to 'buf'. Then the function vbg_core_ioctl() is invoked to execute the
ioctl command. Given that the 'arg' pointer resides in userspace, a
malicious userspace process can race to change the data pointed to by 'arg'
between the two copies. By doing so, the user can bypass the verifications
on the ioctl argument, which can cause vbg_core_ioctl() to work on unsecure
data because it assumes the 'version', 'size_in', and 'size_out' have been
verified by vbg_misc_device_ioctl(), as mentioned in the comment in
vbg_core_ioctl():

/*
 * hdr->version and hdr->size_in / hdr->size_out minimum size are
 * already checked by vbg_misc_device_ioctl().
 */

This patch adds checks after the second copy to ensure the consistency
between the data obtained in the two copies. In case an inconsistency is
detected, an error code -EINVAL will be returned.

Signed-off-by: Wenwen Wang 
---
 drivers/virt/vboxguest/vboxguest_linux.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/virt/vboxguest/vboxguest_linux.c 
b/drivers/virt/vboxguest/vboxguest_linux.c
index 398d226..6b525259 100644
--- a/drivers/virt/vboxguest/vboxguest_linux.c
+++ b/drivers/virt/vboxguest/vboxguest_linux.c
@@ -125,6 +125,12 @@ static long vbg_misc_device_ioctl(struct file *filp, 
unsigned int req,
ret = -EFAULT;
goto out;
}
+   if (((struct vbg_ioctl_hdr *)buf)->version != hdr.version ||
+   ((struct vbg_ioctl_hdr *)buf)->size_in != hdr.size_in ||
+   ((struct vbg_ioctl_hdr *)buf)->size_out != hdr.size_out) {
+   ret = -EINVAL;
+   goto out;
+   }
if (hdr.size_in < size)
memset(buf + hdr.size_in, 0, size -  hdr.size_in);
 
@@ -133,11 +139,6 @@ static long vbg_misc_device_ioctl(struct file *filp, 
unsigned int req,
goto out;
 
returned_size = ((struct vbg_ioctl_hdr *)buf)->size_out;
-   if (returned_size > size) {
-   vbg_debug("%s: too much output data %zu > %zu\n",
- __func__, returned_size, size);
-   returned_size = size;
-   }
if (copy_to_user((void *)arg, buf, returned_size) != 0)
ret = -EFAULT;
 
-- 
2.7.4

[PATCH] scsi: sg: fix a missing-check bug

[Wenwen Wang]

In sg_write(), the opcode of the command is firstly copied from the
userspace pointer 'buf' and saved to the kernel variable 'opcode', using
the __get_user() function. The size of the command, i.e., 'cmd_size' is
then calculated based on the 'opcode'. After that, the whole command,
including the opcode, is copied again from 'buf' using the
__copy_from_user() function and saved to 'cmnd'. Finally, the function
 sg_common_write() is invoked to process 'cmnd'. Given that the 'buf'
pointer resides in userspace, a malicious userspace process can race to
change the opcode of the command between the two copies. That means, the
opcode indicated by the variable 'opcode' could be different from the
opcode in 'cmnd'. This can cause inconsistent data in 'cmnd' and
potential logical errors in the function sg_common_write(), as it needs to
work on 'cmnd'.

This patch reuses the opcode obtained in the first copy and only copies the
remaining part of the command from userspace.

Signed-off-by: Wenwen Wang 
---
 drivers/scsi/sg.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
index c198b963..0ad8106 100644
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -657,7 +657,8 @@ sg_write(struct file *filp, const char __user *buf, size_t 
count, loff_t * ppos)
hp->flags = input_size; /* structure abuse ... */
hp->pack_id = old_hdr.pack_id;
hp->usr_ptr = NULL;
-   if (__copy_from_user(cmnd, buf, cmd_size))
+   cmnd[0] = opcode;
+   if (__copy_from_user(cmnd + 1, buf + 1, cmd_size - 1))
return -EFAULT;
/*
 * SG_DXFER_TO_FROM_DEV is functionally equivalent to SG_DXFER_FROM_DEV,
-- 
2.7.4

[PATCH] scsi: sg: fix a missing-check bug

[Wenwen Wang]

In sg_write(), the opcode of the command is firstly copied from the
userspace pointer 'buf' and saved to the kernel variable 'opcode', using
the __get_user() function. The size of the command, i.e., 'cmd_size' is
then calculated based on the 'opcode'. After that, the whole command,
including the opcode, is copied again from 'buf' using the
__copy_from_user() function and saved to 'cmnd'. Finally, the function
 sg_common_write() is invoked to process 'cmnd'. Given that the 'buf'
pointer resides in userspace, a malicious userspace process can race to
change the opcode of the command between the two copies. That means, the
opcode indicated by the variable 'opcode' could be different from the
opcode in 'cmnd'. This can cause inconsistent data in 'cmnd' and
potential logical errors in the function sg_common_write(), as it needs to
work on 'cmnd'.

This patch reuses the opcode obtained in the first copy and only copies the
remaining part of the command from userspace.

Signed-off-by: Wenwen Wang 
---
 drivers/scsi/sg.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
index c198b963..0ad8106 100644
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -657,7 +657,8 @@ sg_write(struct file *filp, const char __user *buf, size_t 
count, loff_t * ppos)
hp->flags = input_size; /* structure abuse ... */
hp->pack_id = old_hdr.pack_id;
hp->usr_ptr = NULL;
-   if (__copy_from_user(cmnd, buf, cmd_size))
+   cmnd[0] = opcode;
+   if (__copy_from_user(cmnd + 1, buf + 1, cmd_size - 1))
return -EFAULT;
/*
 * SG_DXFER_TO_FROM_DEV is functionally equivalent to SG_DXFER_FROM_DEV,
-- 
2.7.4

Re: [PATCH v2 2/2] MIPS: Convert update_persistent_clock() to update_persistent_clock64()

[Arnd Bergmann]

On Fri, May 4, 2018 at 3:07 AM, Baolin Wang  wrote:
> Since struct timespec is not y2038 safe on 32bit machines, this patch
> converts update_persistent_clock() to update_persistent_clock64() using
> struct timespec64.
>
> The rtc_mips_set_time() and rtc_mips_set_mmss() interfaces were using
> 'unsigned long' type that is not y2038 safe on 32bit machines, moreover
> there is only one platform implementing rtc_mips_set_time() and two
> platforms implementing rtc_mips_set_mmss(), so we can just make them each
> implement update_persistent_clock64() directly, to get that helper out
> of the common mips code by removing rtc_mips_set_time() and
> rtc_mips_set_mmss() interfaces.
>
> Signed-off-by: Baolin Wang 

Looks good overall, but I still found a bug and one minor issue. With
those fixed,

Acked-by: Arnd Bergmann 

> diff --git a/arch/mips/dec/time.c b/arch/mips/dec/time.c
> index 9e992cf..934db6f 100644
> --- a/arch/mips/dec/time.c
> +++ b/arch/mips/dec/time.c
> @@ -59,14 +59,15 @@ void read_persistent_clock64(struct timespec64 *ts)
>  }
>
>  /*
> - * In order to set the CMOS clock precisely, rtc_mips_set_mmss has to
> + * In order to set the CMOS clock precisely, update_persistent_clock64 has to
>   * be called 500 ms after the second nowtime has started, because when
>   * nowtime is written into the registers of the CMOS clock, it will
>   * jump to the next second precisely 500 ms later.  Check the Dallas
>   * DS1287 data sheet for details.
>   */
> -int rtc_mips_set_mmss(unsigned long nowtime)
> +int update_persistent_clock64(struct timespec64 now)
>  {
> +   time64_t nowtime = now.tv_sec;
> int retval = 0;
> int real_seconds, real_minutes, cmos_minutes;
> unsigned char save_control, save_freq_select;


It looks like you now get an invalid 64-bit division in here,
you have to change it to either use div_u64_rem() or possibly
time64_to_tm() or rtc_time64_to_tm() (the latter requires
CONFIG_RTC_LIB).

> diff --git a/arch/mips/lasat/ds1603.c b/arch/mips/lasat/ds1603.c
> index d75c887..061815e 100644
> --- a/arch/mips/lasat/ds1603.c
> +++ b/arch/mips/lasat/ds1603.c
> @@ -98,7 +98,7 @@ static void rtc_write_byte(unsigned int byte)
> }
>  }
>
> -static void rtc_write_word(unsigned long word)
> +static void rtc_write_word(time64_t word)
>  {
> int i;
>

I would say this function should take a 'u32' argument (or keep the
unsigned long) to match the name and implementation, but then have a
type cast in the caller with a comment about the loss of range and overflow
in y2106.

> diff --git a/arch/mips/lasat/sysctl.c b/arch/mips/lasat/sysctl.c
> index 6f74224..76f7b62 100644
> --- a/arch/mips/lasat/sysctl.c
> +++ b/arch/mips/lasat/sysctl.c
> @@ -73,8 +73,12 @@ int proc_dolasatrtc(struct ctl_table *table, int write,
> if (r)
> return r;
>
> -   if (write)
> -   rtc_mips_set_mmss(rtctmp);
> +   if (write) {
> +   ts.tv_sec = rtctmp;
> +   ts.tv_nsec = 0;
> +
> +   update_persistent_clock64(ts);
> +   }
>
... and probably also a comment here to explain that we can't actually use
the full 64-bit range because of HW limits.

 Arnd

Re: [PATCH v2 2/2] MIPS: Convert update_persistent_clock() to update_persistent_clock64()

[Arnd Bergmann]

On Fri, May 4, 2018 at 3:07 AM, Baolin Wang  wrote:
> Since struct timespec is not y2038 safe on 32bit machines, this patch
> converts update_persistent_clock() to update_persistent_clock64() using
> struct timespec64.
>
> The rtc_mips_set_time() and rtc_mips_set_mmss() interfaces were using
> 'unsigned long' type that is not y2038 safe on 32bit machines, moreover
> there is only one platform implementing rtc_mips_set_time() and two
> platforms implementing rtc_mips_set_mmss(), so we can just make them each
> implement update_persistent_clock64() directly, to get that helper out
> of the common mips code by removing rtc_mips_set_time() and
> rtc_mips_set_mmss() interfaces.
>
> Signed-off-by: Baolin Wang 

Looks good overall, but I still found a bug and one minor issue. With
those fixed,

Acked-by: Arnd Bergmann 

> diff --git a/arch/mips/dec/time.c b/arch/mips/dec/time.c
> index 9e992cf..934db6f 100644
> --- a/arch/mips/dec/time.c
> +++ b/arch/mips/dec/time.c
> @@ -59,14 +59,15 @@ void read_persistent_clock64(struct timespec64 *ts)
>  }
>
>  /*
> - * In order to set the CMOS clock precisely, rtc_mips_set_mmss has to
> + * In order to set the CMOS clock precisely, update_persistent_clock64 has to
>   * be called 500 ms after the second nowtime has started, because when
>   * nowtime is written into the registers of the CMOS clock, it will
>   * jump to the next second precisely 500 ms later.  Check the Dallas
>   * DS1287 data sheet for details.
>   */
> -int rtc_mips_set_mmss(unsigned long nowtime)
> +int update_persistent_clock64(struct timespec64 now)
>  {
> +   time64_t nowtime = now.tv_sec;
> int retval = 0;
> int real_seconds, real_minutes, cmos_minutes;
> unsigned char save_control, save_freq_select;


It looks like you now get an invalid 64-bit division in here,
you have to change it to either use div_u64_rem() or possibly
time64_to_tm() or rtc_time64_to_tm() (the latter requires
CONFIG_RTC_LIB).

> diff --git a/arch/mips/lasat/ds1603.c b/arch/mips/lasat/ds1603.c
> index d75c887..061815e 100644
> --- a/arch/mips/lasat/ds1603.c
> +++ b/arch/mips/lasat/ds1603.c
> @@ -98,7 +98,7 @@ static void rtc_write_byte(unsigned int byte)
> }
>  }
>
> -static void rtc_write_word(unsigned long word)
> +static void rtc_write_word(time64_t word)
>  {
> int i;
>

I would say this function should take a 'u32' argument (or keep the
unsigned long) to match the name and implementation, but then have a
type cast in the caller with a comment about the loss of range and overflow
in y2106.

> diff --git a/arch/mips/lasat/sysctl.c b/arch/mips/lasat/sysctl.c
> index 6f74224..76f7b62 100644
> --- a/arch/mips/lasat/sysctl.c
> +++ b/arch/mips/lasat/sysctl.c
> @@ -73,8 +73,12 @@ int proc_dolasatrtc(struct ctl_table *table, int write,
> if (r)
> return r;
>
> -   if (write)
> -   rtc_mips_set_mmss(rtctmp);
> +   if (write) {
> +   ts.tv_sec = rtctmp;
> +   ts.tv_nsec = 0;
> +
> +   update_persistent_clock64(ts);
> +   }
>
... and probably also a comment here to explain that we can't actually use
the full 64-bit range because of HW limits.

 Arnd

Re: [RFC PATCH] locking/atomics/powerpc: Introduce optimized cmpxchg_release() family of APIs for PowerPC

[Benjamin Herrenschmidt]

On Sat, 2018-05-05 at 12:00 +0200, Ingo Molnar wrote:
> This clearly suggests that PPC_RELEASE_BARRIER is in active use and 'lwsync' 
> is 
> the 'release barrier' instruction, if I interpreted that right.

The closest to one we got.

The semantics are that it orders all load/store pairs to cachable
storage except store+load.

Cheers,
Ben.

Re: [RFC PATCH] locking/atomics/powerpc: Introduce optimized cmpxchg_release() family of APIs for PowerPC

[Benjamin Herrenschmidt]

On Sat, 2018-05-05 at 12:00 +0200, Ingo Molnar wrote:
> This clearly suggests that PPC_RELEASE_BARRIER is in active use and 'lwsync' 
> is 
> the 'release barrier' instruction, if I interpreted that right.

The closest to one we got.

The semantics are that it orders all load/store pairs to cachable
storage except store+load.

Cheers,
Ben.

Re: crosstool requirements?

[Arnd Bergmann]

On Sat, May 5, 2018 at 2:20 PM, Randy Dunlap  wrote:
> Hi Arnd,
>
> I was trying to use the x86_64 hosted openrisc/or1k gcc compiler 
> (7.3.0-nolibc)
> but I mostly what I get are errors like the following:
>
> crosstool/gcc-7.3.0-nolibc/or1k-linux/bin/../libexec/gcc/or1k-linux/7.3.0/cc1:
>  error while loading shared libraries: libisl.so.15: cannot open shared 
> object file: No such file or directory
>
>
> I do have /usr/lib64/libisl.so.10 (not .15) installed on my system.
> Am I just outofluck for doing this?

This has been pointed out by some others before, sorry for not having addressed
it yet. I'll be back from travelling on May 22 and should be able to build a set
of gcc-8.1 binaries without this problem, and also rebuild some of the older
compilers to fix it (gcc-4.8 is already fixed, but IIRC doesn't
support openrisc)

What happened here is that I built against the libraries that came
with Ubuntu 16.04,
intentionally picking a somewhat older distro in the hope that this
would produce
binaries that work on a wider range of systems, but I had it use the
system libisl,
libgmp, libmpfc, and libmpc rather than using the one provided by the
gcc project
for static linking.

You should be able to just install the binaries from
https://launchpad.net/ubuntu/xenial/amd64/libisl15/0.16.1-1
as well as any others you might need along with the toolchain (either
using dpkg on Debian or Ubuntu, or extracting the .so file into an
appropriate directory for others) until then.

Arnd

Re: crosstool requirements?

[Arnd Bergmann]

On Sat, May 5, 2018 at 2:20 PM, Randy Dunlap  wrote:
> Hi Arnd,
>
> I was trying to use the x86_64 hosted openrisc/or1k gcc compiler 
> (7.3.0-nolibc)
> but I mostly what I get are errors like the following:
>
> crosstool/gcc-7.3.0-nolibc/or1k-linux/bin/../libexec/gcc/or1k-linux/7.3.0/cc1:
>  error while loading shared libraries: libisl.so.15: cannot open shared 
> object file: No such file or directory
>
>
> I do have /usr/lib64/libisl.so.10 (not .15) installed on my system.
> Am I just outofluck for doing this?

This has been pointed out by some others before, sorry for not having addressed
it yet. I'll be back from travelling on May 22 and should be able to build a set
of gcc-8.1 binaries without this problem, and also rebuild some of the older
compilers to fix it (gcc-4.8 is already fixed, but IIRC doesn't
support openrisc)

What happened here is that I built against the libraries that came
with Ubuntu 16.04,
intentionally picking a somewhat older distro in the hope that this
would produce
binaries that work on a wider range of systems, but I had it use the
system libisl,
libgmp, libmpfc, and libmpc rather than using the one provided by the
gcc project
for static linking.

You should be able to just install the binaries from
https://launchpad.net/ubuntu/xenial/amd64/libisl15/0.16.1-1
as well as any others you might need along with the toolchain (either
using dpkg on Debian or Ubuntu, or extracting the .so file into an
appropriate directory for others) until then.

Arnd

Re: kernel panic: EXT4-fs (device loop0): panic forced after error

[Theodore Y. Ts'o]

On Sat, May 05, 2018 at 05:57:02PM -0700, syzbot wrote:
> Hello,
> 
> syzbot found the following crash on:
> 
> EXT4-fs error (device loop0): ext4_iget:4756: inode #2: comm
> syz-executor909: root inode unallocated
> Kernel panic - not syncing: EXT4-fs (device loop0): panic forced after error

I don't get why syzbot considers this a bug.  It created a corrupted
file system, mounted it as root, and said file system had the flag
which says, "panic if you find a file system corruption".

In what world is this a security bug?  There's a *reason* why I've
always said people who want to containers to be allowed to mount
arbitrary file systems controlled by potentially malicious container
users are insane

I could mark this as a one-off invalid bug, but if syzkaller is going
to be generating classes of corrupted file systems like this, and are
going to be complaing about how this causes the kernel to crash, then
we have a fundamental syzkaller BUG.

- Ted

Re: kernel panic: EXT4-fs (device loop0): panic forced after error

[Theodore Y. Ts'o]

On Sat, May 05, 2018 at 05:57:02PM -0700, syzbot wrote:
> Hello,
> 
> syzbot found the following crash on:
> 
> EXT4-fs error (device loop0): ext4_iget:4756: inode #2: comm
> syz-executor909: root inode unallocated
> Kernel panic - not syncing: EXT4-fs (device loop0): panic forced after error

I don't get why syzbot considers this a bug.  It created a corrupted
file system, mounted it as root, and said file system had the flag
which says, "panic if you find a file system corruption".

In what world is this a security bug?  There's a *reason* why I've
always said people who want to containers to be allowed to mount
arbitrary file systems controlled by potentially malicious container
users are insane

I could mark this as a one-off invalid bug, but if syzkaller is going
to be generating classes of corrupted file systems like this, and are
going to be complaing about how this causes the kernel to crash, then
we have a fundamental syzkaller BUG.

- Ted

[GIT PULL] platform-drivers-x86 for 4.17-2

[Darren Hart]

Hi Linus,

I was trying to keep DELL_LAPTOP visible in the menu, but the "select"
behavior makes that impossible. I'm planning on refactoring the Kconfig
by vendor for those with many options in 4.18 which should clean things
up. This fix from Mario corrects the potential for misconfiguration for
4.17 and 4.16 via stable.

Thanks,

Darren Hart
VMware Open Source Technology Center

The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:

  Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)

are available in the git repository at:

  git://git.infradead.org/linux-platform-drivers-x86.git 
tags/platform-drivers-x86-v4.17-2

for you to fetch changes up to 7fe3fa3b5ec8e75389cce4bf5d052a52e6198d59:

  platform/x86: Kconfig: Fix dell-laptop dependency chain. (2018-05-04 22:20:14 
+0200)


platform-drivers-x86 for v4.17-2

We missed a case in the Dell config dependencies resulting in a possible bad
configuration, resolve it by giving up on trying to keep DELL_LAPTOP visible in
the menu and make it depend on DELL_SMBIOS.

Fix a null pointer dereference at module unload for the asus-wireless driver.

The following is an automated git shortlog grouped by driver:

Kconfig:
 -  Fix dell-laptop dependency chain.

asus-wireless:
 -  Fix NULL pointer dereference


João Paulo Rechi Vita (1):
  platform/x86: asus-wireless: Fix NULL pointer dereference

Mario Limonciello (1):
  platform/x86: Kconfig: Fix dell-laptop dependency chain.

 drivers/platform/x86/Kconfig | 2 +-
 drivers/platform/x86/asus-wireless.c | 4 +++-
 2 files changed, 4 insertions(+), 2 deletions(-)

-- 
Darren Hart
VMware Open Source Technology Center

[GIT PULL] platform-drivers-x86 for 4.17-2

[Darren Hart]

Hi Linus,

I was trying to keep DELL_LAPTOP visible in the menu, but the "select"
behavior makes that impossible. I'm planning on refactoring the Kconfig
by vendor for those with many options in 4.18 which should clean things
up. This fix from Mario corrects the potential for misconfiguration for
4.17 and 4.16 via stable.

Thanks,

Darren Hart
VMware Open Source Technology Center

The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:

  Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)

are available in the git repository at:

  git://git.infradead.org/linux-platform-drivers-x86.git 
tags/platform-drivers-x86-v4.17-2

for you to fetch changes up to 7fe3fa3b5ec8e75389cce4bf5d052a52e6198d59:

  platform/x86: Kconfig: Fix dell-laptop dependency chain. (2018-05-04 22:20:14 
+0200)


platform-drivers-x86 for v4.17-2

We missed a case in the Dell config dependencies resulting in a possible bad
configuration, resolve it by giving up on trying to keep DELL_LAPTOP visible in
the menu and make it depend on DELL_SMBIOS.

Fix a null pointer dereference at module unload for the asus-wireless driver.

The following is an automated git shortlog grouped by driver:

Kconfig:
 -  Fix dell-laptop dependency chain.

asus-wireless:
 -  Fix NULL pointer dereference


João Paulo Rechi Vita (1):
  platform/x86: asus-wireless: Fix NULL pointer dereference

Mario Limonciello (1):
  platform/x86: Kconfig: Fix dell-laptop dependency chain.

 drivers/platform/x86/Kconfig | 2 +-
 drivers/platform/x86/asus-wireless.c | 4 +++-
 2 files changed, 4 insertions(+), 2 deletions(-)

-- 
Darren Hart
VMware Open Source Technology Center

Re: [Intel-wired-lan] [PATCH v2 1/1] drivers core: multi-threading device shutdown

[kbuild test robot]

Hi Pavel,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on driver-core/driver-core-testing]
[also build test WARNING on v4.17-rc3 next-20180504]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Pavel-Tatashin/multi-threading-device-shutdown/20180506-035150
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

>> drivers/base/core.c:2877:25: sparse: symbol 'device_root_tasks_done' was not 
>> declared. Should it be static?
   drivers/base/core.c:62:5: sparse: context imbalance in 
'device_links_read_lock' - wrong count at exit
   drivers/base/core.c:67:6: sparse: context imbalance in 
'device_links_read_unlock' - unexpected unlock

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation

Re: [Intel-wired-lan] [PATCH v2 1/1] drivers core: multi-threading device shutdown

[kbuild test robot]

Hi Pavel,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on driver-core/driver-core-testing]
[also build test WARNING on v4.17-rc3 next-20180504]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Pavel-Tatashin/multi-threading-device-shutdown/20180506-035150
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

>> drivers/base/core.c:2877:25: sparse: symbol 'device_root_tasks_done' was not 
>> declared. Should it be static?
   drivers/base/core.c:62:5: sparse: context imbalance in 
'device_links_read_lock' - wrong count at exit
   drivers/base/core.c:67:6: sparse: context imbalance in 
'device_links_read_unlock' - unexpected unlock

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation

[RFC PATCH] drivers core: device_root_tasks_done can be static

[kbuild test robot]

Fixes: 6d54ba128905 ("drivers core: multi-threading device shutdown")
Signed-off-by: Fengguang Wu 
---
 core.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/base/core.c b/drivers/base/core.c
index 110d797..666c163 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -2874,7 +2874,7 @@ static int device_shutdown_child_task(void *data);
  */
 static atomic_tdevice_root_tasks_finished;
 static atomic_tdevice_root_tasks_started;
-struct completion  device_root_tasks_done;
+static struct completion   device_root_tasks_done;
 
 /**
  * Shutdown device tree with root started in dev. If dev has no children

[RFC PATCH] drivers core: device_root_tasks_done can be static

[kbuild test robot]

Fixes: 6d54ba128905 ("drivers core: multi-threading device shutdown")
Signed-off-by: Fengguang Wu 
---
 core.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/base/core.c b/drivers/base/core.c
index 110d797..666c163 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -2874,7 +2874,7 @@ static int device_shutdown_child_task(void *data);
  */
 static atomic_tdevice_root_tasks_finished;
 static atomic_tdevice_root_tasks_started;
-struct completion  device_root_tasks_done;
+static struct completion   device_root_tasks_done;
 
 /**
  * Shutdown device tree with root started in dev. If dev has no children

[PATCH] nubus: Unconditionally register bus type

[Finn Thain]

Loading a NuBus driver module on a non-NuBus machine triggers the
BUG_ON(!drv->bus->p) in driver_register() because the bus does not get
registered unless MACH_IS_MAC(). Avoid this by registering the bus
unconditionally using postcore_initcall().

Cc: Greg Kroah-Hartman 
Reported-by: Michael Schmitz 
Tested-by: Stan Johnson 
Fixes: 7f86c765a6a2 ("nubus: Add support for the driver model")
Signed-off-by: Finn Thain 
---
 drivers/nubus/bus.c   | 3 ++-
 drivers/nubus/nubus.c | 5 -
 include/linux/nubus.h | 1 -
 3 files changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/nubus/bus.c b/drivers/nubus/bus.c
index d306c348c857..27ca9f1a281b 100644
--- a/drivers/nubus/bus.c
+++ b/drivers/nubus/bus.c
@@ -63,7 +63,7 @@ static struct device nubus_parent = {
.init_name  = "nubus",
 };
 
-int __init nubus_bus_register(void)
+static int __init nubus_bus_register(void)
 {
int err;
 
@@ -78,6 +78,7 @@ int __init nubus_bus_register(void)
device_unregister(_parent);
return err;
 }
+postcore_initcall(nubus_bus_register);
 
 static void nubus_device_release(struct device *dev)
 {
diff --git a/drivers/nubus/nubus.c b/drivers/nubus/nubus.c
index 4621ff98138c..f6bab483f4cb 100644
--- a/drivers/nubus/nubus.c
+++ b/drivers/nubus/nubus.c
@@ -869,15 +869,10 @@ static void __init nubus_scan_bus(void)
 
 static int __init nubus_init(void)
 {
-   int err;
-
if (!MACH_IS_MAC)
return 0;
 
nubus_proc_init();
-   err = nubus_bus_register();
-   if (err)
-   return err;
nubus_scan_bus();
return 0;
 }
diff --git a/include/linux/nubus.h b/include/linux/nubus.h
index 6e8200215321..f01e7f4bcff8 100644
--- a/include/linux/nubus.h
+++ b/include/linux/nubus.h
@@ -163,7 +163,6 @@ void nubus_seq_write_rsrc_mem(struct seq_file *m,
 unsigned char *nubus_dirptr(const struct nubus_dirent *nd);
 
 /* Declarations relating to driver model objects */
-int nubus_bus_register(void);
 int nubus_device_register(struct nubus_board *board);
 int nubus_driver_register(struct nubus_driver *ndrv);
 void nubus_driver_unregister(struct nubus_driver *ndrv);
-- 
2.16.1

[PATCH] nubus: Unconditionally register bus type

[Finn Thain]

Loading a NuBus driver module on a non-NuBus machine triggers the
BUG_ON(!drv->bus->p) in driver_register() because the bus does not get
registered unless MACH_IS_MAC(). Avoid this by registering the bus
unconditionally using postcore_initcall().

Cc: Greg Kroah-Hartman 
Reported-by: Michael Schmitz 
Tested-by: Stan Johnson 
Fixes: 7f86c765a6a2 ("nubus: Add support for the driver model")
Signed-off-by: Finn Thain 
---
 drivers/nubus/bus.c   | 3 ++-
 drivers/nubus/nubus.c | 5 -
 include/linux/nubus.h | 1 -
 3 files changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/nubus/bus.c b/drivers/nubus/bus.c
index d306c348c857..27ca9f1a281b 100644
--- a/drivers/nubus/bus.c
+++ b/drivers/nubus/bus.c
@@ -63,7 +63,7 @@ static struct device nubus_parent = {
.init_name  = "nubus",
 };
 
-int __init nubus_bus_register(void)
+static int __init nubus_bus_register(void)
 {
int err;
 
@@ -78,6 +78,7 @@ int __init nubus_bus_register(void)
device_unregister(_parent);
return err;
 }
+postcore_initcall(nubus_bus_register);
 
 static void nubus_device_release(struct device *dev)
 {
diff --git a/drivers/nubus/nubus.c b/drivers/nubus/nubus.c
index 4621ff98138c..f6bab483f4cb 100644
--- a/drivers/nubus/nubus.c
+++ b/drivers/nubus/nubus.c
@@ -869,15 +869,10 @@ static void __init nubus_scan_bus(void)
 
 static int __init nubus_init(void)
 {
-   int err;
-
if (!MACH_IS_MAC)
return 0;
 
nubus_proc_init();
-   err = nubus_bus_register();
-   if (err)
-   return err;
nubus_scan_bus();
return 0;
 }
diff --git a/include/linux/nubus.h b/include/linux/nubus.h
index 6e8200215321..f01e7f4bcff8 100644
--- a/include/linux/nubus.h
+++ b/include/linux/nubus.h
@@ -163,7 +163,6 @@ void nubus_seq_write_rsrc_mem(struct seq_file *m,
 unsigned char *nubus_dirptr(const struct nubus_dirent *nd);
 
 /* Declarations relating to driver model objects */
-int nubus_bus_register(void);
 int nubus_device_register(struct nubus_board *board);
 int nubus_driver_register(struct nubus_driver *ndrv);
 void nubus_driver_unregister(struct nubus_driver *ndrv);
-- 
2.16.1

Re: moving affs + RDB partition support to staging?

[Al Viro]

On Thu, Apr 26, 2018 at 12:45:41PM +0200, John Paul Adrian Glaubitz wrote:

> Exactly. It works fine as is:
> 
> root@elgar:~> uname -a
> Linux elgar 4.16.0-rc2-amiga-16784-ga8917fc #650 Mon Mar 5 15:32:52 NZDT 2018 
> m68k GNU/Linux
> root@elgar:~> mount /dev/sda1 /mnt -taffs
> root@elgar:~> ls -l /mnt | head
> total 0
> drwx-- 1 root root  0 Mar 30  2001 Alt
> -rw--- 1 root root   1352 Mar 27  1997 Alt.info
> drwx-- 1 root root  0 Nov 16 14:39 C
> drwx-- 1 root root  0 Mar 27  1997 CS_Fonts
> drwx-- 1 root root  0 Mar 27  1997 Classes
> -rwx-- 1 root root   1132 Aug 14  1996 Classes.info
> drwx-- 1 root root  0 Feb 10  2004 Commodities
> -rw--- 1 root root628 Jan 14  2002 Commodities.info
> drwx-- 1 root root  0 Apr 10  1999 CyberTools
> root@elgar:~> mount |grep affs
> /dev/sda1 on /mnt type affs (rw,relatime,bs=512,volume=:)
> root@elgar:~>
> 
> There is nothing at the moment that needs fixing.

Funny, that...  I'd been going through the damn thing for the
last week or so; open-by-fhandle/nfs export support is completely
buggered.  And as for the rest... the least said about the error
handling, the better - something like rename() hitting an IO
error (read one) can not only screw the on-disk data into the
ground, it can do seriously bad things to kernel data structures.

Is there anything resembling fsck for that thing, BTW?  Nevermind
the repairs, just the validity checks would be nice...

Re: moving affs + RDB partition support to staging?

[Al Viro]

On Thu, Apr 26, 2018 at 12:45:41PM +0200, John Paul Adrian Glaubitz wrote:

> Exactly. It works fine as is:
> 
> root@elgar:~> uname -a
> Linux elgar 4.16.0-rc2-amiga-16784-ga8917fc #650 Mon Mar 5 15:32:52 NZDT 2018 
> m68k GNU/Linux
> root@elgar:~> mount /dev/sda1 /mnt -taffs
> root@elgar:~> ls -l /mnt | head
> total 0
> drwx-- 1 root root  0 Mar 30  2001 Alt
> -rw--- 1 root root   1352 Mar 27  1997 Alt.info
> drwx-- 1 root root  0 Nov 16 14:39 C
> drwx-- 1 root root  0 Mar 27  1997 CS_Fonts
> drwx-- 1 root root  0 Mar 27  1997 Classes
> -rwx-- 1 root root   1132 Aug 14  1996 Classes.info
> drwx-- 1 root root  0 Feb 10  2004 Commodities
> -rw--- 1 root root628 Jan 14  2002 Commodities.info
> drwx-- 1 root root  0 Apr 10  1999 CyberTools
> root@elgar:~> mount |grep affs
> /dev/sda1 on /mnt type affs (rw,relatime,bs=512,volume=:)
> root@elgar:~>
> 
> There is nothing at the moment that needs fixing.

Funny, that...  I'd been going through the damn thing for the
last week or so; open-by-fhandle/nfs export support is completely
buggered.  And as for the rest... the least said about the error
handling, the better - something like rename() hitting an IO
error (read one) can not only screw the on-disk data into the
ground, it can do seriously bad things to kernel data structures.

Is there anything resembling fsck for that thing, BTW?  Nevermind
the repairs, just the validity checks would be nice...

BUG: please report to d...@vger.kernel.org => prev = 0, last = 0 at net/dccp/ccids/lib/packet_history.c:LINE/tfrc_rx_his

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit:c1c07416cdd4 Merge tag 'kbuild-fixes-v4.17' of git://git.k..
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=13d5de4780
kernel config:  https://syzkaller.appspot.com/x/.config?x=5a1dc06635c10d27
dashboard link: https://syzkaller.appspot.com/bug?extid=99858724c0ba555a12ea
compiler:   gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=170afde780
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=141b4be780

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+99858724c0ba555a1...@syzkaller.appspotmail.com

random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
BUG: please report to d...@vger.kernel.org => prev = 0, last = 0 at  
net/dccp/ccids/lib/packet_history.c:425/tfrc_rx_hist_sample_rtt()

CPU: 0 PID: 4495 Comm: syz-executor551 Not tainted 4.17.0-rc3+ #34
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

Call Trace:
 
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x1b9/0x294 lib/dump_stack.c:113
 tfrc_rx_hist_sample_rtt.cold.3+0x54/0x5c  
net/dccp/ccids/lib/packet_history.c:422

 ccid3_hc_rx_packet_recv+0x5c8/0xed0 net/dccp/ccids/ccid3.c:765
 ccid_hc_rx_packet_recv net/dccp/ccid.h:185 [inline]
 dccp_deliver_input_to_ccids+0xf0/0x280 net/dccp/input.c:180
 dccp_rcv_established+0x87/0xb0 net/dccp/input.c:378
 dccp_v4_do_rcv+0x153/0x180 net/dccp/ipv4.c:654
 sk_backlog_rcv include/net/sock.h:909 [inline]
 __sk_receive_skb+0x3a2/0xd60 net/core/sock.c:513
 dccp_v4_rcv+0x10e5/0x1f3f net/dccp/ipv4.c:875
 ip_local_deliver_finish+0x2e3/0xd80 net/ipv4/ip_input.c:215
 NF_HOOK include/linux/netfilter.h:288 [inline]
 ip_local_deliver+0x1e1/0x720 net/ipv4/ip_input.c:256
 dst_input include/net/dst.h:450 [inline]
 ip_rcv_finish+0x81b/0x2200 net/ipv4/ip_input.c:396
 NF_HOOK include/linux/netfilter.h:288 [inline]
 ip_rcv+0xb70/0x143d net/ipv4/ip_input.c:492
 __netif_receive_skb_core+0x26f5/0x3630 net/core/dev.c:4592
 __netif_receive_skb+0x2c/0x1e0 net/core/dev.c:4657
 process_backlog+0x219/0x760 net/core/dev.c:5337
 napi_poll net/core/dev.c:5735 [inline]
 net_rx_action+0x7b7/0x1930 net/core/dev.c:5801
 __do_softirq+0x2e0/0xaf5 kernel/softirq.c:285
 do_softirq_own_stack+0x2a/0x40 arch/x86/entry/entry_64.S:1046
 
 do_softirq.part.17+0x14d/0x190 kernel/softirq.c:329
 do_softirq arch/x86/include/asm/preempt.h:23 [inline]
 __local_bh_enable_ip+0x1ec/0x230 kernel/softirq.c:182
 local_bh_enable include/linux/bottom_half.h:32 [inline]
 rcu_read_unlock_bh include/linux/rcupdate.h:728 [inline]
 ip_finish_output2+0xab2/0x1840 net/ipv4/ip_output.c:231
 ip_finish_output+0x828/0xf80 net/ipv4/ip_output.c:317
 NF_HOOK_COND include/linux/netfilter.h:277 [inline]
 ip_output+0x21b/0x850 net/ipv4/ip_output.c:405
 dst_output include/net/dst.h:444 [inline]
 ip_local_out+0xc5/0x1b0 net/ipv4/ip_output.c:124
 ip_queue_xmit+0x9d7/0x1f70 net/ipv4/ip_output.c:504
 dccp_transmit_skb+0x999/0x12e0 net/dccp/output.c:142
 dccp_xmit_packet+0x250/0x790 net/dccp/output.c:281
 dccp_write_xmit+0x190/0x1f0 net/dccp/output.c:363
 dccp_sendmsg+0x8c7/0x1020 net/dccp/proto.c:818
 inet_sendmsg+0x19f/0x690 net/ipv4/af_inet.c:798
 sock_sendmsg_nosec net/socket.c:629 [inline]
 sock_sendmsg+0xd5/0x120 net/socket.c:639
 ___sys_sendmsg+0x525/0x940 net/socket.c:2117
 __sys_sendmmsg+0x240/0x6f0 net/socket.c:2212
 __do_sys_sendmmsg net/socket.c:2241 [inline]
 __se_sys_sendmmsg net/socket.c:2238 [inline]
 __x64_sys_sendmmsg+0x9d/0x100 net/socket.c:2238
 do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x445d09
RSP: 002b:7f3c7eff5d88 EFLAGS: 0293 ORIG_RAX: 0133
RAX: ffda RBX: 006dac40 RCX: 00445d09
RDX: 0001 RSI: 00


---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.

syzbot will keep track of this bug report.
If you forgot to add the Reported-by tag, once the fix for this bug is  
merged

into any tree, please reply to this email with:
#syz fix: exact-commit-title
If you want to test a patch for this bug, please reply with:
#syz test: git://repo/address.git branch
and provide the patch inline or as an attachment.
To mark this as a duplicate of another syzbot report, please reply with:
#syz dup: exact-subject-of-another-report
If it's a one-off invalid bug report, please reply with:
#syz invalid
Note: if the crash happens again, it will cause creation of a new bug  
report.

Note: all commands must start from beginning of the line in the email body.

kernel panic: EXT4-fs (device loop0): panic forced after error

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit:c1c07416cdd4 Merge tag 'kbuild-fixes-v4.17' of git://git.k..
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=11a8a07b80
kernel config:  https://syzkaller.appspot.com/x/.config?x=5a1dc06635c10d27
dashboard link: https://syzkaller.appspot.com/bug?extid=a9a45987b8b2daabdc88
compiler:   gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=164fa29780
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=13635c3780

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+a9a45987b8b2daabd...@syzkaller.appspotmail.com

random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
EXT4-fs error (device loop0): ext4_iget:4756: inode #2: comm  
syz-executor909: root inode unallocated

Kernel panic - not syncing: EXT4-fs (device loop0): panic forced after error

CPU: 1 PID: 4451 Comm: syz-executor909 Not tainted 4.17.0-rc3+ #34
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x1b9/0x294 lib/dump_stack.c:113
 panic+0x22f/0x4de kernel/panic.c:184
 ext4_handle_error.part.120.cold.128+0x1d/0x1d fs/ext4/super.c:431
 ext4_handle_error fs/ext4/super.c:408 [inline]
 __ext4_error_inode+0x351/0x730 fs/ext4/super.c:494
 ext4_iget+0xe82/0x3dd0 fs/ext4/inode.c:4756
 ext4_fill_super+0x733c/0xd810 fs/ext4/super.c:4208
 mount_bdev+0x30c/0x3e0 fs/super.c:1164
 ext4_mount+0x34/0x40 fs/ext4/super.c:5740
 mount_fs+0xae/0x328 fs/super.c:1267
 vfs_kern_mount.part.34+0xd4/0x4d0 fs/namespace.c:1037
 vfs_kern_mount fs/namespace.c:1027 [inline]
 do_new_mount fs/namespace.c:2518 [inline]
 do_mount+0x564/0x3070 fs/namespace.c:2848
 ksys_mount+0x12d/0x140 fs/namespace.c:3064
 __do_sys_mount fs/namespace.c:3078 [inline]
 __se_sys_mount fs/namespace.c:3075 [inline]
 __x64_sys_mount+0xbe/0x150 fs/namespace.c:3075
 do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x442dda
RSP: 002b:7ffdadaf1e38 EFLAGS: 0297 ORIG_RAX: 00a5
RAX: ffda RBX: 0003 RCX: 00442dda
RDX: 2480 RSI: 2100 RDI: 7ffdadaf1e40
RBP: 0004 R08: 2440 R09: 000a
R10:  R11: 0297 R12: 00401c40
R13: 00401cd0 R14:  R15: 
Dumping ftrace buffer:
   (ftrace buffer empty)
Kernel Offset: disabled
Rebooting in 86400 seconds..


---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.

syzbot will keep track of this bug report.
If you forgot to add the Reported-by tag, once the fix for this bug is  
merged

into any tree, please reply to this email with:
#syz fix: exact-commit-title
If you want to test a patch for this bug, please reply with:
#syz test: git://repo/address.git branch
and provide the patch inline or as an attachment.
To mark this as a duplicate of another syzbot report, please reply with:
#syz dup: exact-subject-of-another-report
If it's a one-off invalid bug report, please reply with:
#syz invalid
Note: if the crash happens again, it will cause creation of a new bug  
report.

Note: all commands must start from beginning of the line in the email body.

BUG: please report to d...@vger.kernel.org => prev = 0, last = 0 at net/dccp/ccids/lib/packet_history.c:LINE/tfrc_rx_his

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit:c1c07416cdd4 Merge tag 'kbuild-fixes-v4.17' of git://git.k..
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=13d5de4780
kernel config:  https://syzkaller.appspot.com/x/.config?x=5a1dc06635c10d27
dashboard link: https://syzkaller.appspot.com/bug?extid=99858724c0ba555a12ea
compiler:   gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=170afde780
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=141b4be780

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+99858724c0ba555a1...@syzkaller.appspotmail.com

random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
BUG: please report to d...@vger.kernel.org => prev = 0, last = 0 at  
net/dccp/ccids/lib/packet_history.c:425/tfrc_rx_hist_sample_rtt()

CPU: 0 PID: 4495 Comm: syz-executor551 Not tainted 4.17.0-rc3+ #34
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

Call Trace:
 
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x1b9/0x294 lib/dump_stack.c:113
 tfrc_rx_hist_sample_rtt.cold.3+0x54/0x5c  
net/dccp/ccids/lib/packet_history.c:422

 ccid3_hc_rx_packet_recv+0x5c8/0xed0 net/dccp/ccids/ccid3.c:765
 ccid_hc_rx_packet_recv net/dccp/ccid.h:185 [inline]
 dccp_deliver_input_to_ccids+0xf0/0x280 net/dccp/input.c:180
 dccp_rcv_established+0x87/0xb0 net/dccp/input.c:378
 dccp_v4_do_rcv+0x153/0x180 net/dccp/ipv4.c:654
 sk_backlog_rcv include/net/sock.h:909 [inline]
 __sk_receive_skb+0x3a2/0xd60 net/core/sock.c:513
 dccp_v4_rcv+0x10e5/0x1f3f net/dccp/ipv4.c:875
 ip_local_deliver_finish+0x2e3/0xd80 net/ipv4/ip_input.c:215
 NF_HOOK include/linux/netfilter.h:288 [inline]
 ip_local_deliver+0x1e1/0x720 net/ipv4/ip_input.c:256
 dst_input include/net/dst.h:450 [inline]
 ip_rcv_finish+0x81b/0x2200 net/ipv4/ip_input.c:396
 NF_HOOK include/linux/netfilter.h:288 [inline]
 ip_rcv+0xb70/0x143d net/ipv4/ip_input.c:492
 __netif_receive_skb_core+0x26f5/0x3630 net/core/dev.c:4592
 __netif_receive_skb+0x2c/0x1e0 net/core/dev.c:4657
 process_backlog+0x219/0x760 net/core/dev.c:5337
 napi_poll net/core/dev.c:5735 [inline]
 net_rx_action+0x7b7/0x1930 net/core/dev.c:5801
 __do_softirq+0x2e0/0xaf5 kernel/softirq.c:285
 do_softirq_own_stack+0x2a/0x40 arch/x86/entry/entry_64.S:1046
 
 do_softirq.part.17+0x14d/0x190 kernel/softirq.c:329
 do_softirq arch/x86/include/asm/preempt.h:23 [inline]
 __local_bh_enable_ip+0x1ec/0x230 kernel/softirq.c:182
 local_bh_enable include/linux/bottom_half.h:32 [inline]
 rcu_read_unlock_bh include/linux/rcupdate.h:728 [inline]
 ip_finish_output2+0xab2/0x1840 net/ipv4/ip_output.c:231
 ip_finish_output+0x828/0xf80 net/ipv4/ip_output.c:317
 NF_HOOK_COND include/linux/netfilter.h:277 [inline]
 ip_output+0x21b/0x850 net/ipv4/ip_output.c:405
 dst_output include/net/dst.h:444 [inline]
 ip_local_out+0xc5/0x1b0 net/ipv4/ip_output.c:124
 ip_queue_xmit+0x9d7/0x1f70 net/ipv4/ip_output.c:504
 dccp_transmit_skb+0x999/0x12e0 net/dccp/output.c:142
 dccp_xmit_packet+0x250/0x790 net/dccp/output.c:281
 dccp_write_xmit+0x190/0x1f0 net/dccp/output.c:363
 dccp_sendmsg+0x8c7/0x1020 net/dccp/proto.c:818
 inet_sendmsg+0x19f/0x690 net/ipv4/af_inet.c:798
 sock_sendmsg_nosec net/socket.c:629 [inline]
 sock_sendmsg+0xd5/0x120 net/socket.c:639
 ___sys_sendmsg+0x525/0x940 net/socket.c:2117
 __sys_sendmmsg+0x240/0x6f0 net/socket.c:2212
 __do_sys_sendmmsg net/socket.c:2241 [inline]
 __se_sys_sendmmsg net/socket.c:2238 [inline]
 __x64_sys_sendmmsg+0x9d/0x100 net/socket.c:2238
 do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x445d09
RSP: 002b:7f3c7eff5d88 EFLAGS: 0293 ORIG_RAX: 0133
RAX: ffda RBX: 006dac40 RCX: 00445d09
RDX: 0001 RSI: 00


---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.

syzbot will keep track of this bug report.
If you forgot to add the Reported-by tag, once the fix for this bug is  
merged

into any tree, please reply to this email with:
#syz fix: exact-commit-title
If you want to test a patch for this bug, please reply with:
#syz test: git://repo/address.git branch
and provide the patch inline or as an attachment.
To mark this as a duplicate of another syzbot report, please reply with:
#syz dup: exact-subject-of-another-report
If it's a one-off invalid bug report, please reply with:
#syz invalid
Note: if the crash happens again, it will cause creation of a new bug  
report.

Note: all commands must start from beginning of the line in the email body.

kernel panic: EXT4-fs (device loop0): panic forced after error

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit:c1c07416cdd4 Merge tag 'kbuild-fixes-v4.17' of git://git.k..
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=11a8a07b80
kernel config:  https://syzkaller.appspot.com/x/.config?x=5a1dc06635c10d27
dashboard link: https://syzkaller.appspot.com/bug?extid=a9a45987b8b2daabdc88
compiler:   gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=164fa29780
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=13635c3780

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+a9a45987b8b2daabd...@syzkaller.appspotmail.com

random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
EXT4-fs error (device loop0): ext4_iget:4756: inode #2: comm  
syz-executor909: root inode unallocated

Kernel panic - not syncing: EXT4-fs (device loop0): panic forced after error

CPU: 1 PID: 4451 Comm: syz-executor909 Not tainted 4.17.0-rc3+ #34
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x1b9/0x294 lib/dump_stack.c:113
 panic+0x22f/0x4de kernel/panic.c:184
 ext4_handle_error.part.120.cold.128+0x1d/0x1d fs/ext4/super.c:431
 ext4_handle_error fs/ext4/super.c:408 [inline]
 __ext4_error_inode+0x351/0x730 fs/ext4/super.c:494
 ext4_iget+0xe82/0x3dd0 fs/ext4/inode.c:4756
 ext4_fill_super+0x733c/0xd810 fs/ext4/super.c:4208
 mount_bdev+0x30c/0x3e0 fs/super.c:1164
 ext4_mount+0x34/0x40 fs/ext4/super.c:5740
 mount_fs+0xae/0x328 fs/super.c:1267
 vfs_kern_mount.part.34+0xd4/0x4d0 fs/namespace.c:1037
 vfs_kern_mount fs/namespace.c:1027 [inline]
 do_new_mount fs/namespace.c:2518 [inline]
 do_mount+0x564/0x3070 fs/namespace.c:2848
 ksys_mount+0x12d/0x140 fs/namespace.c:3064
 __do_sys_mount fs/namespace.c:3078 [inline]
 __se_sys_mount fs/namespace.c:3075 [inline]
 __x64_sys_mount+0xbe/0x150 fs/namespace.c:3075
 do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x442dda
RSP: 002b:7ffdadaf1e38 EFLAGS: 0297 ORIG_RAX: 00a5
RAX: ffda RBX: 0003 RCX: 00442dda
RDX: 2480 RSI: 2100 RDI: 7ffdadaf1e40
RBP: 0004 R08: 2440 R09: 000a
R10:  R11: 0297 R12: 00401c40
R13: 00401cd0 R14:  R15: 
Dumping ftrace buffer:
   (ftrace buffer empty)
Kernel Offset: disabled
Rebooting in 86400 seconds..


---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.

syzbot will keep track of this bug report.
If you forgot to add the Reported-by tag, once the fix for this bug is  
merged

into any tree, please reply to this email with:
#syz fix: exact-commit-title
If you want to test a patch for this bug, please reply with:
#syz test: git://repo/address.git branch
and provide the patch inline or as an attachment.
To mark this as a duplicate of another syzbot report, please reply with:
#syz dup: exact-subject-of-another-report
If it's a one-off invalid bug report, please reply with:
#syz invalid
Note: if the crash happens again, it will cause creation of a new bug  
report.

Note: all commands must start from beginning of the line in the email body.

Re: drivers/gpu/drm/bridge/sil-sii8620.c:2229: undefined reference to `extcon_find_edev_by_node'

[Randy Dunlap]

On 05/05/2018 04:22 PM, kbuild test robot wrote:
> Hi Maciej,
> 
> FYI, the error/warning still remains.

Hi M. Robot,

I am cc-ing dri-de...@lists.freedesktop.org so that they are aware of the
multiple times that you have posted this kbuild error (I have 3 different
posts in my Inbox with the same errors; I may have missed some).

I hope that someone there will have some insights into this problem.

I have looked at the issues and concluded that the correct fix for this IMO is:

config DRM_SIL_SII8620
...
depends on EXTCON || !EXTCON

However, that causes some unhappy errors from scripts/kconfig/ concerning
Kconfig recursive dependencies detected.  Alternatively, using
select EXTCON
does not cause any kconfig recursive dependency issues and solves the build
errors.


thanks!

> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
> master
> head:   c1c07416cdd47161a359286021d483f449ad8c4f
> commit: 688838442147d9dd94c2ef7c2c31a35cf150c5fa drm/bridge/sii8620: use 
> micro-USB cable detection logic to detect MHL
> date:   8 weeks ago
> config: i386-randconfig-c0-05060527 (attached as .config)
> compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
> reproduce:
> git checkout 688838442147d9dd94c2ef7c2c31a35cf150c5fa
> # save the attached .config to linux build tree
> make ARCH=i386 
> 
> All errors (new ones prefixed by >>):
> 
>drivers/gpu/drm/bridge/sil-sii8620.o: In function `sii8620_remove':
>drivers/gpu/drm/bridge/sil-sii8620.c:2405: undefined reference to 
> `extcon_unregister_notifier'
>drivers/gpu/drm/bridge/sil-sii8620.o: In function `sii8620_extcon_init':
>>> drivers/gpu/drm/bridge/sil-sii8620.c:2229: undefined reference to 
>>> `extcon_find_edev_by_node'
>>> drivers/gpu/drm/bridge/sil-sii8620.c:2241: undefined reference to 
>>> `extcon_register_notifier'
>drivers/gpu/drm/bridge/sil-sii8620.o: In function `sii8620_extcon_work':
>drivers/gpu/drm/bridge/sil-sii8620.c:2189: undefined reference to 
> `extcon_get_state'
> 
> vim +2229 drivers/gpu/drm/bridge/sil-sii8620.c
> 
>   2212
>   2213static int sii8620_extcon_init(struct sii8620 *ctx)
>   2214{
>   2215struct extcon_dev *edev;
>   2216struct device_node *musb, *muic;
>   2217int ret;
>   2218
>   2219/* get micro-USB connector node */
>   2220musb = of_graph_get_remote_node(ctx->dev->of_node, 1, 
> -1);
>   2221/* next get micro-USB Interface Controller node */
>   muic = of_get_next_parent(musb);
>   2223
>   2224if (!muic) {
>   2225dev_info(ctx->dev, "no extcon found, switching 
> to 'always on' mode\n");
>   2226return 0;
>   2227}
>   2228
>> 2229 edev = extcon_find_edev_by_node(muic);
>   2230of_node_put(muic);
>   2231if (IS_ERR(edev)) {
>   2232if (PTR_ERR(edev) == -EPROBE_DEFER)
>   2233return -EPROBE_DEFER;
>   2234dev_err(ctx->dev, "Invalid or missing 
> extcon\n");
>   2235return PTR_ERR(edev);
>   2236}
>   2237
>   2238ctx->extcon = edev;
>   2239ctx->extcon_nb.notifier_call = sii8620_extcon_notifier;
>   2240INIT_WORK(>extcon_wq, sii8620_extcon_work);
>> 2241 ret = extcon_register_notifier(edev, EXTCON_DISP_MHL, 
>> >extcon_nb);
>   2242if (ret) {
>   2243dev_err(ctx->dev, "failed to register notifier 
> for MHL\n");
>   2244return ret;
>   2245}
>   2246
>   2247return 0;
>   2248}
>   2249
>   2250static inline struct sii8620 *bridge_to_sii8620(struct 
> drm_bridge *bridge)
>   2251{
>   2252return container_of(bridge, struct sii8620, bridge);
>   2253}
>   2254
>   2255static int sii8620_attach(struct drm_bridge *bridge)
>   2256{
>   2257struct sii8620 *ctx = bridge_to_sii8620(bridge);
>   2258
>   2259sii8620_init_rcp_input_dev(ctx);
>   2260
>   2261return sii8620_clear_error(ctx);
>   2262}
>   2263
>   2264static void sii8620_detach(struct drm_bridge *bridge)
>   2265{
>   2266struct sii8620 *ctx = bridge_to_sii8620(bridge);
>   2267
>   2268rc_unregister_device(ctx->rc_dev);
>   2269}
>   2270
>   2271static enum drm_mode_status sii8620_mode_valid(struct 
> drm_bridge *bridge,
>   2272 const struct 
> drm_display_mode *mode)
>   2273{
>   2274struct sii8620 *ctx = 

Re: drivers/gpu/drm/bridge/sil-sii8620.c:2229: undefined reference to `extcon_find_edev_by_node'

[Randy Dunlap]

On 05/05/2018 04:22 PM, kbuild test robot wrote:
> Hi Maciej,
> 
> FYI, the error/warning still remains.

Hi M. Robot,

I am cc-ing dri-de...@lists.freedesktop.org so that they are aware of the
multiple times that you have posted this kbuild error (I have 3 different
posts in my Inbox with the same errors; I may have missed some).

I hope that someone there will have some insights into this problem.

I have looked at the issues and concluded that the correct fix for this IMO is:

config DRM_SIL_SII8620
...
depends on EXTCON || !EXTCON

However, that causes some unhappy errors from scripts/kconfig/ concerning
Kconfig recursive dependencies detected.  Alternatively, using
select EXTCON
does not cause any kconfig recursive dependency issues and solves the build
errors.


thanks!

> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
> master
> head:   c1c07416cdd47161a359286021d483f449ad8c4f
> commit: 688838442147d9dd94c2ef7c2c31a35cf150c5fa drm/bridge/sii8620: use 
> micro-USB cable detection logic to detect MHL
> date:   8 weeks ago
> config: i386-randconfig-c0-05060527 (attached as .config)
> compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
> reproduce:
> git checkout 688838442147d9dd94c2ef7c2c31a35cf150c5fa
> # save the attached .config to linux build tree
> make ARCH=i386 
> 
> All errors (new ones prefixed by >>):
> 
>drivers/gpu/drm/bridge/sil-sii8620.o: In function `sii8620_remove':
>drivers/gpu/drm/bridge/sil-sii8620.c:2405: undefined reference to 
> `extcon_unregister_notifier'
>drivers/gpu/drm/bridge/sil-sii8620.o: In function `sii8620_extcon_init':
>>> drivers/gpu/drm/bridge/sil-sii8620.c:2229: undefined reference to 
>>> `extcon_find_edev_by_node'
>>> drivers/gpu/drm/bridge/sil-sii8620.c:2241: undefined reference to 
>>> `extcon_register_notifier'
>drivers/gpu/drm/bridge/sil-sii8620.o: In function `sii8620_extcon_work':
>drivers/gpu/drm/bridge/sil-sii8620.c:2189: undefined reference to 
> `extcon_get_state'
> 
> vim +2229 drivers/gpu/drm/bridge/sil-sii8620.c
> 
>   2212
>   2213static int sii8620_extcon_init(struct sii8620 *ctx)
>   2214{
>   2215struct extcon_dev *edev;
>   2216struct device_node *musb, *muic;
>   2217int ret;
>   2218
>   2219/* get micro-USB connector node */
>   2220musb = of_graph_get_remote_node(ctx->dev->of_node, 1, 
> -1);
>   2221/* next get micro-USB Interface Controller node */
>   muic = of_get_next_parent(musb);
>   2223
>   2224if (!muic) {
>   2225dev_info(ctx->dev, "no extcon found, switching 
> to 'always on' mode\n");
>   2226return 0;
>   2227}
>   2228
>> 2229 edev = extcon_find_edev_by_node(muic);
>   2230of_node_put(muic);
>   2231if (IS_ERR(edev)) {
>   2232if (PTR_ERR(edev) == -EPROBE_DEFER)
>   2233return -EPROBE_DEFER;
>   2234dev_err(ctx->dev, "Invalid or missing 
> extcon\n");
>   2235return PTR_ERR(edev);
>   2236}
>   2237
>   2238ctx->extcon = edev;
>   2239ctx->extcon_nb.notifier_call = sii8620_extcon_notifier;
>   2240INIT_WORK(>extcon_wq, sii8620_extcon_work);
>> 2241 ret = extcon_register_notifier(edev, EXTCON_DISP_MHL, 
>> >extcon_nb);
>   2242if (ret) {
>   2243dev_err(ctx->dev, "failed to register notifier 
> for MHL\n");
>   2244return ret;
>   2245}
>   2246
>   2247return 0;
>   2248}
>   2249
>   2250static inline struct sii8620 *bridge_to_sii8620(struct 
> drm_bridge *bridge)
>   2251{
>   2252return container_of(bridge, struct sii8620, bridge);
>   2253}
>   2254
>   2255static int sii8620_attach(struct drm_bridge *bridge)
>   2256{
>   2257struct sii8620 *ctx = bridge_to_sii8620(bridge);
>   2258
>   2259sii8620_init_rcp_input_dev(ctx);
>   2260
>   2261return sii8620_clear_error(ctx);
>   2262}
>   2263
>   2264static void sii8620_detach(struct drm_bridge *bridge)
>   2265{
>   2266struct sii8620 *ctx = bridge_to_sii8620(bridge);
>   2267
>   2268rc_unregister_device(ctx->rc_dev);
>   2269}
>   2270
>   2271static enum drm_mode_status sii8620_mode_valid(struct 
> drm_bridge *bridge,
>   2272 const struct 
> drm_display_mode *mode)
>   2273{
>   2274struct sii8620 *ctx = 

[PATCH v3 4/5] kernel hacking: new config CC_OPTIMIZE_FOR_DEBUGGING to apply GCC -Og optimization

[changbin . du]

From: Changbin Du 

This will apply GCC '-Og' optimization level which is supported
since GCC 4.8. This optimization level offers a reasonable level
of optimization while maintaining fast compilation and a good
debugging experience. It is similar to '-O1' while perferring
to keep debug ability over runtime speed.

If enabling this option breaks your kernel, you should either
disable this or find a fix (mostly in the arch code). Currently
this option has only been tested on x86_64 and arm platform.

This option can satisfy people who was searching for a method
to disable compiler optimizations so to achieve better kernel
debugging experience with kgdb or qemu.

The main problem of '-Og' is we must not use __attribute__((error(msg))).
The compiler will report error though the call to error function
still can be optimize out. So we must fallback to array tricky.

Comparison of vmlinux size: a bit smaller.

w/o CONFIG_CC_OPTIMIZE_FOR_DEBUGGING
$ size vmlinux
   textdata bss dec hex filename
22665554   9709674  2920908 3529613621a9388 vmlinux

w/ CONFIG_CC_OPTIMIZE_FOR_DEBUGGING
$ size vmlinux
   textdata bss dec hex filename
21499032   10102758 2920908 3452269820ec64a vmlinux

Comparison of system performance: a bit drop (~6%).
This benchmark of kernel compilation is suggested by Ingo Molnar.
https://lkml.org/lkml/2018/5/2/74

Preparation: Set cpufreq to 'performance'.
for ((cpu=0; cpu<120; cpu++)); do
  G=/sys/devices/system/cpu/cpu$cpu/cpufreq/scaling_governor
  [ -f $G ] && echo performance > $G
done

w/o CONFIG_CC_OPTIMIZE_FOR_DEBUGGING
$ perf stat --repeat 5 --null --pre '\
cp -a kernel ../kernel.copy.$(date +%s); \
rm -rf *;\
git checkout .;  \
echo 1 > /proc/sys/vm/drop_caches;   \
find ../kernel* -type f | xargs cat >/dev/null;  \
make -j kernel >/dev/null;   \
make clean >/dev/null 2>&1;  \
sync'\
 \
make -j8 >/dev/null

Performance counter stats for 'make -j8' (5 runs):

219.764246652 seconds time elapsed   ( +-  0.78% )

w/ CONFIG_CC_OPTIMIZE_FOR_DEBUGGING
$ perf stat --repeat 5 --null --pre '\
cp -a kernel ../kernel.copy.$(date +%s); \
rm -rf *;\
git checkout .;  \
echo 1 > /proc/sys/vm/drop_caches;   \
find ../kernel* -type f | xargs cat >/dev/null;  \
make -j kernel >/dev/null;   \
make clean >/dev/null 2>&1;  \
sync'\
 \
make -j8 >/dev/null

Performance counter stats for 'make -j8' (5 runs):

 233.574187771 seconds time elapsed  ( +-  0.19% )

Signed-off-by: Changbin Du 

---
v3:
  o Rename DEBUG_EXPERIENCE to CC_OPTIMIZE_FOR_DEBUGGING
  o Move new configuration item to "General setup->Compiler optimization level"
v2:
  o Improve performance benchmark as suggested by Ingo.
  o Grammar updates in description. (Randy Dunlap)
---
 Makefile |  4 
 include/linux/compiler-gcc.h |  2 +-
 include/linux/compiler.h |  2 +-
 init/Kconfig | 19 +++
 4 files changed, 25 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index eb694f6..ae1dea7 100644
--- a/Makefile
+++ b/Makefile
@@ -639,6 +639,9 @@ KBUILD_CFLAGS   += $(call cc-disable-warning, 
format-truncation)
 KBUILD_CFLAGS  += $(call cc-disable-warning, format-overflow)
 KBUILD_CFLAGS  += $(call cc-disable-warning, int-in-bool-context)
 
+ifdef CONFIG_CC_OPTIMIZE_FOR_DEBUGGING
+KBUILD_CFLAGS  += $(call cc-option, -Og)
+else
 ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
 KBUILD_CFLAGS  += $(call cc-option,-Oz,-Os)
 KBUILD_CFLAGS  += $(call cc-disable-warning,maybe-uninitialized,)
@@ -649,6 +652,7 @@ else
 KBUILD_CFLAGS   += -O2
 endif
 endif
+endif
 
 KBUILD_CFLAGS += $(call cc-ifversion, -lt, 0409, \
$(call cc-disable-warning,maybe-uninitialized,))
diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
index b4bf73f..586ed11 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -192,7 +192,7 @@
 
 #define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__)
 
-#ifndef __CHECKER__
+#if !defined(__CHECKER__) && !defined(CONFIG_CC_OPTIMIZE_FOR_DEBUGGING)
 # define __compiletime_warning(message) __attribute__((warning(message)))
 # define 

[PATCH v3 4/5] kernel hacking: new config CC_OPTIMIZE_FOR_DEBUGGING to apply GCC -Og optimization

[changbin . du]

From: Changbin Du 

This will apply GCC '-Og' optimization level which is supported
since GCC 4.8. This optimization level offers a reasonable level
of optimization while maintaining fast compilation and a good
debugging experience. It is similar to '-O1' while perferring
to keep debug ability over runtime speed.

If enabling this option breaks your kernel, you should either
disable this or find a fix (mostly in the arch code). Currently
this option has only been tested on x86_64 and arm platform.

This option can satisfy people who was searching for a method
to disable compiler optimizations so to achieve better kernel
debugging experience with kgdb or qemu.

The main problem of '-Og' is we must not use __attribute__((error(msg))).
The compiler will report error though the call to error function
still can be optimize out. So we must fallback to array tricky.

Comparison of vmlinux size: a bit smaller.

w/o CONFIG_CC_OPTIMIZE_FOR_DEBUGGING
$ size vmlinux
   textdata bss dec hex filename
22665554   9709674  2920908 3529613621a9388 vmlinux

w/ CONFIG_CC_OPTIMIZE_FOR_DEBUGGING
$ size vmlinux
   textdata bss dec hex filename
21499032   10102758 2920908 3452269820ec64a vmlinux

Comparison of system performance: a bit drop (~6%).
This benchmark of kernel compilation is suggested by Ingo Molnar.
https://lkml.org/lkml/2018/5/2/74

Preparation: Set cpufreq to 'performance'.
for ((cpu=0; cpu<120; cpu++)); do
  G=/sys/devices/system/cpu/cpu$cpu/cpufreq/scaling_governor
  [ -f $G ] && echo performance > $G
done

w/o CONFIG_CC_OPTIMIZE_FOR_DEBUGGING
$ perf stat --repeat 5 --null --pre '\
cp -a kernel ../kernel.copy.$(date +%s); \
rm -rf *;\
git checkout .;  \
echo 1 > /proc/sys/vm/drop_caches;   \
find ../kernel* -type f | xargs cat >/dev/null;  \
make -j kernel >/dev/null;   \
make clean >/dev/null 2>&1;  \
sync'\
 \
make -j8 >/dev/null

Performance counter stats for 'make -j8' (5 runs):

219.764246652 seconds time elapsed   ( +-  0.78% )

w/ CONFIG_CC_OPTIMIZE_FOR_DEBUGGING
$ perf stat --repeat 5 --null --pre '\
cp -a kernel ../kernel.copy.$(date +%s); \
rm -rf *;\
git checkout .;  \
echo 1 > /proc/sys/vm/drop_caches;   \
find ../kernel* -type f | xargs cat >/dev/null;  \
make -j kernel >/dev/null;   \
make clean >/dev/null 2>&1;  \
sync'\
 \
make -j8 >/dev/null

Performance counter stats for 'make -j8' (5 runs):

 233.574187771 seconds time elapsed  ( +-  0.19% )

Signed-off-by: Changbin Du 

---
v3:
  o Rename DEBUG_EXPERIENCE to CC_OPTIMIZE_FOR_DEBUGGING
  o Move new configuration item to "General setup->Compiler optimization level"
v2:
  o Improve performance benchmark as suggested by Ingo.
  o Grammar updates in description. (Randy Dunlap)
---
 Makefile |  4 
 include/linux/compiler-gcc.h |  2 +-
 include/linux/compiler.h |  2 +-
 init/Kconfig | 19 +++
 4 files changed, 25 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index eb694f6..ae1dea7 100644
--- a/Makefile
+++ b/Makefile
@@ -639,6 +639,9 @@ KBUILD_CFLAGS   += $(call cc-disable-warning, 
format-truncation)
 KBUILD_CFLAGS  += $(call cc-disable-warning, format-overflow)
 KBUILD_CFLAGS  += $(call cc-disable-warning, int-in-bool-context)
 
+ifdef CONFIG_CC_OPTIMIZE_FOR_DEBUGGING
+KBUILD_CFLAGS  += $(call cc-option, -Og)
+else
 ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
 KBUILD_CFLAGS  += $(call cc-option,-Oz,-Os)
 KBUILD_CFLAGS  += $(call cc-disable-warning,maybe-uninitialized,)
@@ -649,6 +652,7 @@ else
 KBUILD_CFLAGS   += -O2
 endif
 endif
+endif
 
 KBUILD_CFLAGS += $(call cc-ifversion, -lt, 0409, \
$(call cc-disable-warning,maybe-uninitialized,))
diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
index b4bf73f..586ed11 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -192,7 +192,7 @@
 
 #define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__)
 
-#ifndef __CHECKER__
+#if !defined(__CHECKER__) && !defined(CONFIG_CC_OPTIMIZE_FOR_DEBUGGING)
 # define __compiletime_warning(message) __attribute__((warning(message)))
 # define __compiletime_error(message) __attribute__((error(message)))
 

[PATCH v3 2/5] regulator: add dummy function of_find_regulator_by_node

[changbin . du]

From: Changbin Du 

If device tree is not enabled, of_find_regulator_by_node() should have
a dummy function since the function call is still there.

This is to fix build error after CONFIG_NO_AUTO_INLINE is introduced.
If this option is enabled, GCC will not auto-inline functions that are
not explicitly marked as inline.

In this case (no CONFIG_OF), the copmiler will report error in function
regulator_dev_lookup().

W/O NO_AUTO_INLINE, function of_get_regulator() is auto-inlined and then
the call to of_find_regulator_by_node() is optimized out since
of_get_regulator() always return NULL.

W/ NO_AUTO_INLINE, the return value of of_get_regulator() is a variable
so the call to of_find_regulator_by_node() cannot be optimized out. So
we need a stub of_find_regulator_by_node().

static struct regulator_dev *regulator_dev_lookup(struct device *dev,
  const char *supply)
{
struct regulator_dev *r = NULL;
struct device_node *node;
struct regulator_map *map;
const char *devname = NULL;

regulator_supply_alias(, );

/* first do a dt based lookup */
if (dev && dev->of_node) {
node = of_get_regulator(dev, supply);
if (node) {
r = of_find_regulator_by_node(node);
if (r)
return r;
...

Signed-off-by: Changbin Du 
---
 drivers/regulator/internal.h | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/regulator/internal.h b/drivers/regulator/internal.h
index abfd56e..24fde1e 100644
--- a/drivers/regulator/internal.h
+++ b/drivers/regulator/internal.h
@@ -56,14 +56,19 @@ static inline struct regulator_dev *dev_to_rdev(struct 
device *dev)
return container_of(dev, struct regulator_dev, dev);
 }
 
-struct regulator_dev *of_find_regulator_by_node(struct device_node *np);
-
 #ifdef CONFIG_OF
+struct regulator_dev *of_find_regulator_by_node(struct device_node *np);
 struct regulator_init_data *regulator_of_get_init_data(struct device *dev,
 const struct regulator_desc *desc,
 struct regulator_config *config,
 struct device_node **node);
 #else
+static inline struct regulator_dev *
+of_find_regulator_by_node(struct device_node *np)
+{
+   return NULL;
+}
+
 static inline struct regulator_init_data *
 regulator_of_get_init_data(struct device *dev,
   const struct regulator_desc *desc,
-- 
2.7.4

[PATCH v3 3/5] kernel hacking: new config NO_AUTO_INLINE to disable compiler auto-inline optimizations

[changbin . du]

From: Changbin Du 

This patch add a new kernel hacking option NO_AUTO_INLINE. Selecting
this option will prevent the compiler from optimizing the kernel by
auto-inlining functions not marked with the inline keyword.

With this option, only functions explicitly marked with "inline" will
be inlined. This will allow the function tracer to trace more functions
because it only traces functions that the compiler has not inlined.

Signed-off-by: Changbin Du 
Cc: Steven Rostedt 

---
v2: Some grammar updates from Steven.
---
 Makefile  |  6 ++
 lib/Kconfig.debug | 17 +
 2 files changed, 23 insertions(+)

diff --git a/Makefile b/Makefile
index 619a85a..eb694f6 100644
--- a/Makefile
+++ b/Makefile
@@ -775,6 +775,12 @@ KBUILD_CFLAGS  += $(call cc-option, 
-femit-struct-debug-baseonly) \
   $(call cc-option,-fno-var-tracking)
 endif
 
+ifdef CONFIG_NO_AUTO_INLINE
+KBUILD_CFLAGS   += $(call cc-option, -fno-inline-functions) \
+  $(call cc-option, -fno-inline-small-functions) \
+  $(call cc-option, -fno-inline-functions-called-once)
+endif
+
 ifdef CONFIG_FUNCTION_TRACER
 ifndef CC_FLAGS_FTRACE
 CC_FLAGS_FTRACE := -pg
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index c40c7b7..da52243 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -198,6 +198,23 @@ config GDB_SCRIPTS
  instance. See Documentation/dev-tools/gdb-kernel-debugging.rst
  for further details.
 
+config NO_AUTO_INLINE
+   bool "Disable compiler auto-inline optimizations"
+   help
+ This will prevent the compiler from optimizing the kernel by
+ auto-inlining functions not marked with the inline keyword.
+ With this option, only functions explicitly marked with
+ "inline" will be inlined. This will allow the function tracer
+ to trace more functions because it only traces functions that
+ the compiler has not inlined.
+
+ Enabling this function can help debugging a kernel if using
+ the function tracer. But it can also change how the kernel
+ works, because inlining functions may change the timing,
+ which could make it difficult while debugging race conditions.
+
+ If unsure, select N.
+
 config ENABLE_WARN_DEPRECATED
bool "Enable __deprecated logic"
default y
-- 
2.7.4

[PATCH v3 2/5] regulator: add dummy function of_find_regulator_by_node

[changbin . du]

From: Changbin Du 

If device tree is not enabled, of_find_regulator_by_node() should have
a dummy function since the function call is still there.

This is to fix build error after CONFIG_NO_AUTO_INLINE is introduced.
If this option is enabled, GCC will not auto-inline functions that are
not explicitly marked as inline.

In this case (no CONFIG_OF), the copmiler will report error in function
regulator_dev_lookup().

W/O NO_AUTO_INLINE, function of_get_regulator() is auto-inlined and then
the call to of_find_regulator_by_node() is optimized out since
of_get_regulator() always return NULL.

W/ NO_AUTO_INLINE, the return value of of_get_regulator() is a variable
so the call to of_find_regulator_by_node() cannot be optimized out. So
we need a stub of_find_regulator_by_node().

static struct regulator_dev *regulator_dev_lookup(struct device *dev,
  const char *supply)
{
struct regulator_dev *r = NULL;
struct device_node *node;
struct regulator_map *map;
const char *devname = NULL;

regulator_supply_alias(, );

/* first do a dt based lookup */
if (dev && dev->of_node) {
node = of_get_regulator(dev, supply);
if (node) {
r = of_find_regulator_by_node(node);
if (r)
return r;
...

Signed-off-by: Changbin Du 
---
 drivers/regulator/internal.h | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/regulator/internal.h b/drivers/regulator/internal.h
index abfd56e..24fde1e 100644
--- a/drivers/regulator/internal.h
+++ b/drivers/regulator/internal.h
@@ -56,14 +56,19 @@ static inline struct regulator_dev *dev_to_rdev(struct 
device *dev)
return container_of(dev, struct regulator_dev, dev);
 }
 
-struct regulator_dev *of_find_regulator_by_node(struct device_node *np);
-
 #ifdef CONFIG_OF
+struct regulator_dev *of_find_regulator_by_node(struct device_node *np);
 struct regulator_init_data *regulator_of_get_init_data(struct device *dev,
 const struct regulator_desc *desc,
 struct regulator_config *config,
 struct device_node **node);
 #else
+static inline struct regulator_dev *
+of_find_regulator_by_node(struct device_node *np)
+{
+   return NULL;
+}
+
 static inline struct regulator_init_data *
 regulator_of_get_init_data(struct device *dev,
   const struct regulator_desc *desc,
-- 
2.7.4

[PATCH v3 3/5] kernel hacking: new config NO_AUTO_INLINE to disable compiler auto-inline optimizations

[changbin . du]

From: Changbin Du 

This patch add a new kernel hacking option NO_AUTO_INLINE. Selecting
this option will prevent the compiler from optimizing the kernel by
auto-inlining functions not marked with the inline keyword.

With this option, only functions explicitly marked with "inline" will
be inlined. This will allow the function tracer to trace more functions
because it only traces functions that the compiler has not inlined.

Signed-off-by: Changbin Du 
Cc: Steven Rostedt 

---
v2: Some grammar updates from Steven.
---
 Makefile  |  6 ++
 lib/Kconfig.debug | 17 +
 2 files changed, 23 insertions(+)

diff --git a/Makefile b/Makefile
index 619a85a..eb694f6 100644
--- a/Makefile
+++ b/Makefile
@@ -775,6 +775,12 @@ KBUILD_CFLAGS  += $(call cc-option, 
-femit-struct-debug-baseonly) \
   $(call cc-option,-fno-var-tracking)
 endif
 
+ifdef CONFIG_NO_AUTO_INLINE
+KBUILD_CFLAGS   += $(call cc-option, -fno-inline-functions) \
+  $(call cc-option, -fno-inline-small-functions) \
+  $(call cc-option, -fno-inline-functions-called-once)
+endif
+
 ifdef CONFIG_FUNCTION_TRACER
 ifndef CC_FLAGS_FTRACE
 CC_FLAGS_FTRACE := -pg
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index c40c7b7..da52243 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -198,6 +198,23 @@ config GDB_SCRIPTS
  instance. See Documentation/dev-tools/gdb-kernel-debugging.rst
  for further details.
 
+config NO_AUTO_INLINE
+   bool "Disable compiler auto-inline optimizations"
+   help
+ This will prevent the compiler from optimizing the kernel by
+ auto-inlining functions not marked with the inline keyword.
+ With this option, only functions explicitly marked with
+ "inline" will be inlined. This will allow the function tracer
+ to trace more functions because it only traces functions that
+ the compiler has not inlined.
+
+ Enabling this function can help debugging a kernel if using
+ the function tracer. But it can also change how the kernel
+ works, because inlining functions may change the timing,
+ which could make it difficult while debugging race conditions.
+
+ If unsure, select N.
+
 config ENABLE_WARN_DEPRECATED
bool "Enable __deprecated logic"
default y
-- 
2.7.4

[PATCH v3 5/5] asm-generic: fix build error in fix_to_virt with CONFIG_CC_OPTIMIZE_FOR_DEBUGGING

[changbin . du]

From: Changbin Du 

With '-Og' optimization level, GCC would not optimize a count for a loop
as a constant value. But BUILD_BUG_ON() only accept compile-time constant
values. Let's use __fix_to_virt() to avoid the error.

arch/arm/mm/mmu.o: In function `fix_to_virt':
/home/changbin/work/linux/./include/asm-generic/fixmap.h:31: undefined 
reference to `__compiletime_assert_31'
Makefile:1051: recipe for target 'vmlinux' failed
make: *** [vmlinux] Error 1

Signed-off-by: Changbin Du 

---
v2: use __fix_to_virt() to fix the issue.
---
 arch/arm/mm/mmu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index e46a6a4..c08d74e 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -1599,7 +1599,7 @@ static void __init early_fixmap_shutdown(void)
pte_t *pte;
struct map_desc map;
 
-   map.virtual = fix_to_virt(i);
+   map.virtual = __fix_to_virt(i);
pte = pte_offset_early_fixmap(pmd_off_k(map.virtual), 
map.virtual);
 
/* Only i/o device mappings are supported ATM */
-- 
2.7.4

[PATCH v3 0/5] kernel hacking: GCC optimization for better debug experience (-Og)

[changbin . du]

From: Changbin Du 

Hi all,
I know some kernel developers was searching for a method to dissable GCC
optimizations, probably they want to apply GCC '-O0' option. But since Linux
kernel replys on GCC optimization to remove some dead code, so '-O0' just
breaks the build. They do need this because they want to debug kernel with
qemu, simics, kgtp or kgdb.

Thanks for the GCC '-Og' optimization level introduced in GCC 4.8, which
offers a reasonable level of optimization while maintaining fast compilation
and a good debugging experience. It is similar to '-O1' while perferring to
keep debug ability over runtime speed. With '-Og', we can build a kernel with
better debug ability and little performance drop after some simple change.

In this series, firstly introduce a new config CONFIG_NO_AUTO_INLINE after two
fixes for this new option. With this option, only functions explicitly marked
with "inline" will  be inlined. This will allow the function tracer to trace
more functions because it only traces functions that the compiler has not
inlined.

Then introduce new config CC_OPTIMIZE_FOR_DEBUGGING which apply '-Og'
optimization level for whole kernel, with a simple fix in fix_to_virt().
Currently I have only tested this option on x86 and ARM platform. Other
platforms should also work but probably need some compiling fixes as what
having done in this series. I leave that to who want to try this debug
option.

Comparison of vmlinux size: a bit smaller.

w/o CONFIG_DEBUG_EXPERIENCE
$ size vmlinux
   textdata bss dec hex filename
22665554   9709674  2920908 3529613621a9388 vmlinux

w/ CONFIG_DEBUG_EXPERIENCE
$ size vmlinux
   textdata bss dec hex filename
21499032   10102758 2920908 3452269820ec64a vmlinux


Comparison of system performance: a bit drop (~6%).
This benchmark of kernel compilation is suggested by Ingo Molnar.
https://lkml.org/lkml/2018/5/2/74

Preparation: Set cpufreq to 'performance'.
for ((cpu=0; cpu<120; cpu++)); do
  G=/sys/devices/system/cpu/cpu$cpu/cpufreq/scaling_governor
  [ -f $G ] && echo performance > $G
done

w/o CONFIG_DEBUG_EXPERIENCE
$ perf stat --repeat 5 --null --pre '\
cp -a kernel ../kernel.copy.$(date +%s); \
rm -rf *;\
git checkout .;  \
echo 1 > /proc/sys/vm/drop_caches;   \
find ../kernel* -type f | xargs cat >/dev/null;  \
make -j kernel >/dev/null;   \
make clean >/dev/null 2>&1;  \
sync'\
 \
make -j8 >/dev/null

 Performance counter stats for 'make -j8' (5 runs):

219.764246652 seconds time elapsed   ( +-  0.78% )

w/ CONFIG_DEBUG_EXPERIENCE
$ perf stat --repeat 5 --null --pre '\
cp -a kernel ../kernel.copy.$(date +%s); \
rm -rf *;\
git checkout .;  \
echo 1 > /proc/sys/vm/drop_caches;   \
find ../kernel* -type f | xargs cat >/dev/null;  \
make -j kernel >/dev/null;   \
make clean >/dev/null 2>&1;  \
sync'\
 \
make -j8 >/dev/null

Performance counter stats for 'make -j8' (5 runs):

 233.574187771 seconds time elapsed  ( +-  0.19% )

Changbin Du (5):
  x86/mm: surround level4_kernel_pgt with #ifdef
CONFIG_X86_5LEVEL...#endif
  regulator: add dummy function of_find_regulator_by_node
  kernel hacking: new config NO_AUTO_INLINE to disable compiler
auto-inline optimizations
  kernel hacking: new config CC_OPTIMIZE_FOR_DEBUGGING to apply GCC -Og
optimization
  asm-generic: fix build error in fix_to_virt with
CONFIG_CC_OPTIMIZE_FOR_DEBUGGING

 Makefile  | 10 ++
 arch/arm/mm/mmu.c |  2 +-
 arch/x86/include/asm/pgtable_64.h |  2 ++
 arch/x86/kernel/head64.c  | 13 ++---
 drivers/regulator/internal.h  |  9 +++--
 include/linux/compiler-gcc.h  |  2 +-
 include/linux/compiler.h  |  2 +-
 init/Kconfig  | 19 +++
 lib/Kconfig.debug | 17 +
 9 files changed, 64 insertions(+), 12 deletions(-)

-- 
2.7.4

[PATCH v3 1/5] x86/mm: surround level4_kernel_pgt with #ifdef CONFIG_X86_5LEVEL...#endif

[changbin . du]

From: Changbin Du 

The level4_kernel_pgt is only defined when X86_5LEVEL is enabled. So
surround level4_kernel_pgt with #ifdef CONFIG_X86_5LEVEL...#endif to
make code correct.

Signed-off-by: Changbin Du 
---
 arch/x86/include/asm/pgtable_64.h |  2 ++
 arch/x86/kernel/head64.c  | 13 ++---
 2 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/arch/x86/include/asm/pgtable_64.h 
b/arch/x86/include/asm/pgtable_64.h
index 877bc27..9e7f667 100644
--- a/arch/x86/include/asm/pgtable_64.h
+++ b/arch/x86/include/asm/pgtable_64.h
@@ -15,7 +15,9 @@
 #include 
 #include 
 
+#ifdef CONFIG_X86_5LEVEL
 extern p4d_t level4_kernel_pgt[512];
+#endif
 extern p4d_t level4_ident_pgt[512];
 extern pud_t level3_kernel_pgt[512];
 extern pud_t level3_ident_pgt[512];
diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index 0c408f8..775d7a6 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -143,16 +143,15 @@ unsigned long __head __startup_64(unsigned long physaddr,
 
pgd = fixup_pointer(_top_pgt, physaddr);
p = pgd + pgd_index(__START_KERNEL_map);
-   if (la57)
-   *p = (unsigned long)level4_kernel_pgt;
-   else
-   *p = (unsigned long)level3_kernel_pgt;
-   *p += _PAGE_TABLE_NOENC - __START_KERNEL_map + load_delta;
-
+#ifdef CONFIG_X86_5LEVEL
if (la57) {
+   *p = (unsigned long)level4_kernel_pgt;
p4d = fixup_pointer(_kernel_pgt, physaddr);
p4d[511] += load_delta;
-   }
+   } else
+#endif
+   *p = (unsigned long)level3_kernel_pgt;
+   *p += _PAGE_TABLE_NOENC - __START_KERNEL_map + load_delta;
 
pud = fixup_pointer(_kernel_pgt, physaddr);
pud[510] += load_delta;
-- 
2.7.4

[PATCH v3 5/5] asm-generic: fix build error in fix_to_virt with CONFIG_CC_OPTIMIZE_FOR_DEBUGGING

[changbin . du]

From: Changbin Du 

With '-Og' optimization level, GCC would not optimize a count for a loop
as a constant value. But BUILD_BUG_ON() only accept compile-time constant
values. Let's use __fix_to_virt() to avoid the error.

arch/arm/mm/mmu.o: In function `fix_to_virt':
/home/changbin/work/linux/./include/asm-generic/fixmap.h:31: undefined 
reference to `__compiletime_assert_31'
Makefile:1051: recipe for target 'vmlinux' failed
make: *** [vmlinux] Error 1

Signed-off-by: Changbin Du 

---
v2: use __fix_to_virt() to fix the issue.
---
 arch/arm/mm/mmu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index e46a6a4..c08d74e 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -1599,7 +1599,7 @@ static void __init early_fixmap_shutdown(void)
pte_t *pte;
struct map_desc map;
 
-   map.virtual = fix_to_virt(i);
+   map.virtual = __fix_to_virt(i);
pte = pte_offset_early_fixmap(pmd_off_k(map.virtual), 
map.virtual);
 
/* Only i/o device mappings are supported ATM */
-- 
2.7.4

[PATCH v3 0/5] kernel hacking: GCC optimization for better debug experience (-Og)

[changbin . du]

From: Changbin Du 

Hi all,
I know some kernel developers was searching for a method to dissable GCC
optimizations, probably they want to apply GCC '-O0' option. But since Linux
kernel replys on GCC optimization to remove some dead code, so '-O0' just
breaks the build. They do need this because they want to debug kernel with
qemu, simics, kgtp or kgdb.

Thanks for the GCC '-Og' optimization level introduced in GCC 4.8, which
offers a reasonable level of optimization while maintaining fast compilation
and a good debugging experience. It is similar to '-O1' while perferring to
keep debug ability over runtime speed. With '-Og', we can build a kernel with
better debug ability and little performance drop after some simple change.

In this series, firstly introduce a new config CONFIG_NO_AUTO_INLINE after two
fixes for this new option. With this option, only functions explicitly marked
with "inline" will  be inlined. This will allow the function tracer to trace
more functions because it only traces functions that the compiler has not
inlined.

Then introduce new config CC_OPTIMIZE_FOR_DEBUGGING which apply '-Og'
optimization level for whole kernel, with a simple fix in fix_to_virt().
Currently I have only tested this option on x86 and ARM platform. Other
platforms should also work but probably need some compiling fixes as what
having done in this series. I leave that to who want to try this debug
option.

Comparison of vmlinux size: a bit smaller.

w/o CONFIG_DEBUG_EXPERIENCE
$ size vmlinux
   textdata bss dec hex filename
22665554   9709674  2920908 3529613621a9388 vmlinux

w/ CONFIG_DEBUG_EXPERIENCE
$ size vmlinux
   textdata bss dec hex filename
21499032   10102758 2920908 3452269820ec64a vmlinux


Comparison of system performance: a bit drop (~6%).
This benchmark of kernel compilation is suggested by Ingo Molnar.
https://lkml.org/lkml/2018/5/2/74

Preparation: Set cpufreq to 'performance'.
for ((cpu=0; cpu<120; cpu++)); do
  G=/sys/devices/system/cpu/cpu$cpu/cpufreq/scaling_governor
  [ -f $G ] && echo performance > $G
done

w/o CONFIG_DEBUG_EXPERIENCE
$ perf stat --repeat 5 --null --pre '\
cp -a kernel ../kernel.copy.$(date +%s); \
rm -rf *;\
git checkout .;  \
echo 1 > /proc/sys/vm/drop_caches;   \
find ../kernel* -type f | xargs cat >/dev/null;  \
make -j kernel >/dev/null;   \
make clean >/dev/null 2>&1;  \
sync'\
 \
make -j8 >/dev/null

 Performance counter stats for 'make -j8' (5 runs):

219.764246652 seconds time elapsed   ( +-  0.78% )

w/ CONFIG_DEBUG_EXPERIENCE
$ perf stat --repeat 5 --null --pre '\
cp -a kernel ../kernel.copy.$(date +%s); \
rm -rf *;\
git checkout .;  \
echo 1 > /proc/sys/vm/drop_caches;   \
find ../kernel* -type f | xargs cat >/dev/null;  \
make -j kernel >/dev/null;   \
make clean >/dev/null 2>&1;  \
sync'\
 \
make -j8 >/dev/null

Performance counter stats for 'make -j8' (5 runs):

 233.574187771 seconds time elapsed  ( +-  0.19% )

Changbin Du (5):
  x86/mm: surround level4_kernel_pgt with #ifdef
CONFIG_X86_5LEVEL...#endif
  regulator: add dummy function of_find_regulator_by_node
  kernel hacking: new config NO_AUTO_INLINE to disable compiler
auto-inline optimizations
  kernel hacking: new config CC_OPTIMIZE_FOR_DEBUGGING to apply GCC -Og
optimization
  asm-generic: fix build error in fix_to_virt with
CONFIG_CC_OPTIMIZE_FOR_DEBUGGING

 Makefile  | 10 ++
 arch/arm/mm/mmu.c |  2 +-
 arch/x86/include/asm/pgtable_64.h |  2 ++
 arch/x86/kernel/head64.c  | 13 ++---
 drivers/regulator/internal.h  |  9 +++--
 include/linux/compiler-gcc.h  |  2 +-
 include/linux/compiler.h  |  2 +-
 init/Kconfig  | 19 +++
 lib/Kconfig.debug | 17 +
 9 files changed, 64 insertions(+), 12 deletions(-)

-- 
2.7.4

[PATCH v3 1/5] x86/mm: surround level4_kernel_pgt with #ifdef CONFIG_X86_5LEVEL...#endif

[changbin . du]

From: Changbin Du 

The level4_kernel_pgt is only defined when X86_5LEVEL is enabled. So
surround level4_kernel_pgt with #ifdef CONFIG_X86_5LEVEL...#endif to
make code correct.

Signed-off-by: Changbin Du 
---
 arch/x86/include/asm/pgtable_64.h |  2 ++
 arch/x86/kernel/head64.c  | 13 ++---
 2 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/arch/x86/include/asm/pgtable_64.h 
b/arch/x86/include/asm/pgtable_64.h
index 877bc27..9e7f667 100644
--- a/arch/x86/include/asm/pgtable_64.h
+++ b/arch/x86/include/asm/pgtable_64.h
@@ -15,7 +15,9 @@
 #include 
 #include 
 
+#ifdef CONFIG_X86_5LEVEL
 extern p4d_t level4_kernel_pgt[512];
+#endif
 extern p4d_t level4_ident_pgt[512];
 extern pud_t level3_kernel_pgt[512];
 extern pud_t level3_ident_pgt[512];
diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index 0c408f8..775d7a6 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -143,16 +143,15 @@ unsigned long __head __startup_64(unsigned long physaddr,
 
pgd = fixup_pointer(_top_pgt, physaddr);
p = pgd + pgd_index(__START_KERNEL_map);
-   if (la57)
-   *p = (unsigned long)level4_kernel_pgt;
-   else
-   *p = (unsigned long)level3_kernel_pgt;
-   *p += _PAGE_TABLE_NOENC - __START_KERNEL_map + load_delta;
-
+#ifdef CONFIG_X86_5LEVEL
if (la57) {
+   *p = (unsigned long)level4_kernel_pgt;
p4d = fixup_pointer(_kernel_pgt, physaddr);
p4d[511] += load_delta;
-   }
+   } else
+#endif
+   *p = (unsigned long)level3_kernel_pgt;
+   *p += _PAGE_TABLE_NOENC - __START_KERNEL_map + load_delta;
 
pud = fixup_pointer(_kernel_pgt, physaddr);
pud[510] += load_delta;
-- 
2.7.4

Re: [PATCH v2 4/5] kernel hacking: new config DEBUG_EXPERIENCE to apply GCC -Og optimization

[Randy Dunlap]

On 05/05/2018 04:57 PM, Du, Changbin wrote:
> On Thu, May 03, 2018 at 10:28:23AM -0400, Steven Rostedt wrote:
>> On Thu, 3 May 2018 21:45:46 +0800
>> "Du, Changbin"  wrote:
>>
 With that gcc comment, I still think CONFIG_OPTIMIZE_DEBUG is more
 inline with what it is and understandable than
 CONFIG_DEBUG_EXPERIENCE. The "OPTIMIZE" is the key word there.

 -- Steve  
>>> What about CONFIG_CC_OPTIMIZE_FOR_DEBUGGING? We alreay have
>>> CONFIG_CC_OPTIMIZE_FOR_SIZE and CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE.
>>
>> Yes I like that much better.
>>
>>>
>>> And do we need to move it to existing configuration menu "General setup->
>>> Compiler optimization level"? But I also want it appear in "kernel hacking"
>>> since this is a debug option.
>>
>> I understand why you would want it by debugging, but I think it does
>> make more sense to be included with the above two other options, as
>> they are all mutually exclusive.

mm, sounds good.

>> This brings up the topic of creating config paradigms. That is, a way
>> of saying "I want a debug kernel" and select one option that selects
>> everything you would expect. Or perhaps we should have a:
>>
>>  make debug_config

Sometimes I want to build allmodconfig-minus-debug options ... but not
all debug options.  I still want debugfs but most options that end with
_DEBUG are disabled.  I.e., I don't want the options that cause big
run-time slowdowns. (unless I cause that by printing some debugfs
contents)

Can merge_config.sh (or one of its cousins) help with that?

> Agree, I accomplish this by running script scripts/kconfig/merge_config.sh.
> 
>> that does it.
>>
>> But that's a different topic. For now, I would just included it in
>> init/Kconfig, and not worry about it not showing up in kernel hacking.

Ack.


thanks.
-- 
~Randy

Re: [PATCH v2 4/5] kernel hacking: new config DEBUG_EXPERIENCE to apply GCC -Og optimization

[Randy Dunlap]

On 05/05/2018 04:57 PM, Du, Changbin wrote:
> On Thu, May 03, 2018 at 10:28:23AM -0400, Steven Rostedt wrote:
>> On Thu, 3 May 2018 21:45:46 +0800
>> "Du, Changbin"  wrote:
>>
 With that gcc comment, I still think CONFIG_OPTIMIZE_DEBUG is more
 inline with what it is and understandable than
 CONFIG_DEBUG_EXPERIENCE. The "OPTIMIZE" is the key word there.

 -- Steve  
>>> What about CONFIG_CC_OPTIMIZE_FOR_DEBUGGING? We alreay have
>>> CONFIG_CC_OPTIMIZE_FOR_SIZE and CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE.
>>
>> Yes I like that much better.
>>
>>>
>>> And do we need to move it to existing configuration menu "General setup->
>>> Compiler optimization level"? But I also want it appear in "kernel hacking"
>>> since this is a debug option.
>>
>> I understand why you would want it by debugging, but I think it does
>> make more sense to be included with the above two other options, as
>> they are all mutually exclusive.

mm, sounds good.

>> This brings up the topic of creating config paradigms. That is, a way
>> of saying "I want a debug kernel" and select one option that selects
>> everything you would expect. Or perhaps we should have a:
>>
>>  make debug_config

Sometimes I want to build allmodconfig-minus-debug options ... but not
all debug options.  I still want debugfs but most options that end with
_DEBUG are disabled.  I.e., I don't want the options that cause big
run-time slowdowns. (unless I cause that by printing some debugfs
contents)

Can merge_config.sh (or one of its cousins) help with that?

> Agree, I accomplish this by running script scripts/kconfig/merge_config.sh.
> 
>> that does it.
>>
>> But that's a different topic. For now, I would just included it in
>> init/Kconfig, and not worry about it not showing up in kernel hacking.

Ack.


thanks.
-- 
~Randy

Re: [PATCH v2 4/5] kernel hacking: new config DEBUG_EXPERIENCE to apply GCC -Og optimization

[Du, Changbin]

On Thu, May 03, 2018 at 10:28:23AM -0400, Steven Rostedt wrote:
> On Thu, 3 May 2018 21:45:46 +0800
> "Du, Changbin"  wrote:
> 
> > > With that gcc comment, I still think CONFIG_OPTIMIZE_DEBUG is more
> > > inline with what it is and understandable than
> > > CONFIG_DEBUG_EXPERIENCE. The "OPTIMIZE" is the key word there.
> > > 
> > > -- Steve  
> > What about CONFIG_CC_OPTIMIZE_FOR_DEBUGGING? We alreay have
> > CONFIG_CC_OPTIMIZE_FOR_SIZE and CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE.
> 
> Yes I like that much better.
> 
> > 
> > And do we need to move it to existing configuration menu "General setup->
> > Compiler optimization level"? But I also want it appear in "kernel hacking"
> > since this is a debug option.
> 
> I understand why you would want it by debugging, but I think it does
> make more sense to be included with the above two other options, as
> they are all mutually exclusive.
> 
> This brings up the topic of creating config paradigms. That is, a way
> of saying "I want a debug kernel" and select one option that selects
> everything you would expect. Or perhaps we should have a:
> 
>  make debug_config
> 
Agree, I accomplish this by running script scripts/kconfig/merge_config.sh.

> that does it.
> 
> But that's a different topic. For now, I would just included it in
> init/Kconfig, and not worry about it not showing up in kernel hacking.
> 
> 
> -- Steve

-- 
Thanks,
Changbin Du

Re: [PATCH v2 4/5] kernel hacking: new config DEBUG_EXPERIENCE to apply GCC -Og optimization

[Du, Changbin]

On Thu, May 03, 2018 at 10:28:23AM -0400, Steven Rostedt wrote:
> On Thu, 3 May 2018 21:45:46 +0800
> "Du, Changbin"  wrote:
> 
> > > With that gcc comment, I still think CONFIG_OPTIMIZE_DEBUG is more
> > > inline with what it is and understandable than
> > > CONFIG_DEBUG_EXPERIENCE. The "OPTIMIZE" is the key word there.
> > > 
> > > -- Steve  
> > What about CONFIG_CC_OPTIMIZE_FOR_DEBUGGING? We alreay have
> > CONFIG_CC_OPTIMIZE_FOR_SIZE and CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE.
> 
> Yes I like that much better.
> 
> > 
> > And do we need to move it to existing configuration menu "General setup->
> > Compiler optimization level"? But I also want it appear in "kernel hacking"
> > since this is a debug option.
> 
> I understand why you would want it by debugging, but I think it does
> make more sense to be included with the above two other options, as
> they are all mutually exclusive.
> 
> This brings up the topic of creating config paradigms. That is, a way
> of saying "I want a debug kernel" and select one option that selects
> everything you would expect. Or perhaps we should have a:
> 
>  make debug_config
> 
Agree, I accomplish this by running script scripts/kconfig/merge_config.sh.

> that does it.
> 
> But that's a different topic. For now, I would just included it in
> init/Kconfig, and not worry about it not showing up in kernel hacking.
> 
> 
> -- Steve

-- 
Thanks,
Changbin Du

[GIT PULL] USB driver fixes for 4.17-rc4

[Greg KH]

The following changes since commit 6da6c0db5316275015e8cc2959f12a17584aeb64:

  Linux v4.17-rc3 (2018-04-29 14:17:42 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ 
tags/usb-4.17-rc4

for you to fetch changes up to 6844dc42722cac37762a45e742ab4b2cc5348023:

  Merge tag 'usb-serial-4.17-rc4' of 
https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus 
(2018-05-04 14:38:32 -0700)


USB fixes for 4.17-rc4

Here are some USB driver fixes for 4.17-rc4.

The majority of them are some USB gadget fixes that missed my last pull
request.  The "largest" patch in here is a fix for the old visor driver
that syzbot found 6 months or so ago and I finally remembered to fix it.

All of these have been in linux-next with no reported issues.

Signed-off-by: Greg Kroah-Hartman 


Alan Stern (1):
  USB: Accept bulk endpoints with 1024-byte maxpacket

Artur Petrosyan (1):
  usb: dwc2: WA for Full speed ISOC IN in DDMA mode.

Bin Liu (2):
  usb: musb: host: fix potential NULL pointer dereference
  usb: musb: trace: fix NULL pointer dereference in musb_g_tx()

Greg Kroah-Hartman (4):
  Merge tag 'fixes-for-v4.17-rc3' of git://git.kernel.org/.../balbi/usb 
into usb-linus
  USB: serial: visor: handle potential invalid device configuration
  Revert "usb: host: ehci: Use dma_pool_zalloc()"
  Merge tag 'usb-serial-4.17-rc4' of 
https://git.kernel.org/.../johan/usb-serial into usb-linus

Heikki Krogerus (2):
  usb: typec: tcpm: Release the role mux when exiting
  usb: typec: tps6598x: handle block reads separately with plain-I2C 
adapters

Joel Pepper (1):
  usb: gadget: composite Allow for larger configuration descriptors

Luc Van Oostenryck (1):
  usb: gadget: f_phonet: fix pn_net_xmit()'s return type

Mathias Nyman (1):
  xhci: Fix use-after-free in xhci_free_virt_device

Mayank Rana (1):
  usb: dwc3: gadget: Fix list_del corruption in dwc3_ep_dequeue

SZ Lin (林上智) (1):
  USB: serial: option: adding support for ublox R410M

Tomeu Vizoso (1):
  usb: dwc2: dwc2_vbus_supply_init: fix error check

Wei Yongjun (2):
  usb: dwc2: pci: Fix error return code in dwc2_pci_probe()
  usb: dwc3: gadget: dwc3_gadget_del_and_unmap_request() can be static

 drivers/usb/core/config.c  |  4 +-
 drivers/usb/dwc2/core.h|  2 +
 drivers/usb/dwc2/gadget.c  | 21 +++
 drivers/usb/dwc2/hcd.c | 13 ---
 drivers/usb/dwc2/pci.c |  4 +-
 drivers/usb/dwc3/gadget.c  |  4 +-
 drivers/usb/gadget/function/f_phonet.c |  2 +-
 drivers/usb/host/ehci-mem.c|  3 +-
 drivers/usb/host/ehci-sched.c  |  6 ++-
 drivers/usb/host/xhci.c|  1 +
 drivers/usb/musb/musb_gadget.c |  3 +-
 drivers/usb/musb/musb_host.c   |  4 +-
 drivers/usb/serial/option.c|  5 +++
 drivers/usb/serial/visor.c | 69 +-
 drivers/usb/typec/tcpm.c   |  1 +
 drivers/usb/typec/tps6598x.c   | 47 +++
 include/linux/usb/composite.h  |  2 +-
 17 files changed, 133 insertions(+), 58 deletions(-)

[GIT PULL] USB driver fixes for 4.17-rc4

[Greg KH]

The following changes since commit 6da6c0db5316275015e8cc2959f12a17584aeb64:

  Linux v4.17-rc3 (2018-04-29 14:17:42 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ 
tags/usb-4.17-rc4

for you to fetch changes up to 6844dc42722cac37762a45e742ab4b2cc5348023:

  Merge tag 'usb-serial-4.17-rc4' of 
https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus 
(2018-05-04 14:38:32 -0700)


USB fixes for 4.17-rc4

Here are some USB driver fixes for 4.17-rc4.

The majority of them are some USB gadget fixes that missed my last pull
request.  The "largest" patch in here is a fix for the old visor driver
that syzbot found 6 months or so ago and I finally remembered to fix it.

All of these have been in linux-next with no reported issues.

Signed-off-by: Greg Kroah-Hartman 


Alan Stern (1):
  USB: Accept bulk endpoints with 1024-byte maxpacket

Artur Petrosyan (1):
  usb: dwc2: WA for Full speed ISOC IN in DDMA mode.

Bin Liu (2):
  usb: musb: host: fix potential NULL pointer dereference
  usb: musb: trace: fix NULL pointer dereference in musb_g_tx()

Greg Kroah-Hartman (4):
  Merge tag 'fixes-for-v4.17-rc3' of git://git.kernel.org/.../balbi/usb 
into usb-linus
  USB: serial: visor: handle potential invalid device configuration
  Revert "usb: host: ehci: Use dma_pool_zalloc()"
  Merge tag 'usb-serial-4.17-rc4' of 
https://git.kernel.org/.../johan/usb-serial into usb-linus

Heikki Krogerus (2):
  usb: typec: tcpm: Release the role mux when exiting
  usb: typec: tps6598x: handle block reads separately with plain-I2C 
adapters

Joel Pepper (1):
  usb: gadget: composite Allow for larger configuration descriptors

Luc Van Oostenryck (1):
  usb: gadget: f_phonet: fix pn_net_xmit()'s return type

Mathias Nyman (1):
  xhci: Fix use-after-free in xhci_free_virt_device

Mayank Rana (1):
  usb: dwc3: gadget: Fix list_del corruption in dwc3_ep_dequeue

SZ Lin (林上智) (1):
  USB: serial: option: adding support for ublox R410M

Tomeu Vizoso (1):
  usb: dwc2: dwc2_vbus_supply_init: fix error check

Wei Yongjun (2):
  usb: dwc2: pci: Fix error return code in dwc2_pci_probe()
  usb: dwc3: gadget: dwc3_gadget_del_and_unmap_request() can be static

 drivers/usb/core/config.c  |  4 +-
 drivers/usb/dwc2/core.h|  2 +
 drivers/usb/dwc2/gadget.c  | 21 +++
 drivers/usb/dwc2/hcd.c | 13 ---
 drivers/usb/dwc2/pci.c |  4 +-
 drivers/usb/dwc3/gadget.c  |  4 +-
 drivers/usb/gadget/function/f_phonet.c |  2 +-
 drivers/usb/host/ehci-mem.c|  3 +-
 drivers/usb/host/ehci-sched.c  |  6 ++-
 drivers/usb/host/xhci.c|  1 +
 drivers/usb/musb/musb_gadget.c |  3 +-
 drivers/usb/musb/musb_host.c   |  4 +-
 drivers/usb/serial/option.c|  5 +++
 drivers/usb/serial/visor.c | 69 +-
 drivers/usb/typec/tcpm.c   |  1 +
 drivers/usb/typec/tps6598x.c   | 47 +++
 include/linux/usb/composite.h  |  2 +-
 17 files changed, 133 insertions(+), 58 deletions(-)

drivers/gpu/drm/bridge/sil-sii8620.c:2229: undefined reference to `extcon_find_edev_by_node'

[kbuild test robot]

Hi Maciej,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   c1c07416cdd47161a359286021d483f449ad8c4f
commit: 688838442147d9dd94c2ef7c2c31a35cf150c5fa drm/bridge/sii8620: use 
micro-USB cable detection logic to detect MHL
date:   8 weeks ago
config: i386-randconfig-c0-05060527 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
git checkout 688838442147d9dd94c2ef7c2c31a35cf150c5fa
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/bridge/sil-sii8620.o: In function `sii8620_remove':
   drivers/gpu/drm/bridge/sil-sii8620.c:2405: undefined reference to 
`extcon_unregister_notifier'
   drivers/gpu/drm/bridge/sil-sii8620.o: In function `sii8620_extcon_init':
>> drivers/gpu/drm/bridge/sil-sii8620.c:2229: undefined reference to 
>> `extcon_find_edev_by_node'
>> drivers/gpu/drm/bridge/sil-sii8620.c:2241: undefined reference to 
>> `extcon_register_notifier'
   drivers/gpu/drm/bridge/sil-sii8620.o: In function `sii8620_extcon_work':
   drivers/gpu/drm/bridge/sil-sii8620.c:2189: undefined reference to 
`extcon_get_state'

vim +2229 drivers/gpu/drm/bridge/sil-sii8620.c

  2212  
  2213  static int sii8620_extcon_init(struct sii8620 *ctx)
  2214  {
  2215  struct extcon_dev *edev;
  2216  struct device_node *musb, *muic;
  2217  int ret;
  2218  
  2219  /* get micro-USB connector node */
  2220  musb = of_graph_get_remote_node(ctx->dev->of_node, 1, -1);
  2221  /* next get micro-USB Interface Controller node */
    muic = of_get_next_parent(musb);
  2223  
  2224  if (!muic) {
  2225  dev_info(ctx->dev, "no extcon found, switching to 
'always on' mode\n");
  2226  return 0;
  2227  }
  2228  
> 2229  edev = extcon_find_edev_by_node(muic);
  2230  of_node_put(muic);
  2231  if (IS_ERR(edev)) {
  2232  if (PTR_ERR(edev) == -EPROBE_DEFER)
  2233  return -EPROBE_DEFER;
  2234  dev_err(ctx->dev, "Invalid or missing extcon\n");
  2235  return PTR_ERR(edev);
  2236  }
  2237  
  2238  ctx->extcon = edev;
  2239  ctx->extcon_nb.notifier_call = sii8620_extcon_notifier;
  2240  INIT_WORK(>extcon_wq, sii8620_extcon_work);
> 2241  ret = extcon_register_notifier(edev, EXTCON_DISP_MHL, 
> >extcon_nb);
  2242  if (ret) {
  2243  dev_err(ctx->dev, "failed to register notifier for 
MHL\n");
  2244  return ret;
  2245  }
  2246  
  2247  return 0;
  2248  }
  2249  
  2250  static inline struct sii8620 *bridge_to_sii8620(struct drm_bridge 
*bridge)
  2251  {
  2252  return container_of(bridge, struct sii8620, bridge);
  2253  }
  2254  
  2255  static int sii8620_attach(struct drm_bridge *bridge)
  2256  {
  2257  struct sii8620 *ctx = bridge_to_sii8620(bridge);
  2258  
  2259  sii8620_init_rcp_input_dev(ctx);
  2260  
  2261  return sii8620_clear_error(ctx);
  2262  }
  2263  
  2264  static void sii8620_detach(struct drm_bridge *bridge)
  2265  {
  2266  struct sii8620 *ctx = bridge_to_sii8620(bridge);
  2267  
  2268  rc_unregister_device(ctx->rc_dev);
  2269  }
  2270  
  2271  static enum drm_mode_status sii8620_mode_valid(struct drm_bridge 
*bridge,
  2272   const struct drm_display_mode 
*mode)
  2273  {
  2274  struct sii8620 *ctx = bridge_to_sii8620(bridge);
  2275  bool can_pack = ctx->devcap[MHL_DCAP_VID_LINK_MODE] &
  2276  MHL_DCAP_VID_LINK_PPIXEL;
  2277  unsigned int max_pclk = sii8620_is_mhl3(ctx) ? MHL3_MAX_LCLK :
  2278 MHL1_MAX_LCLK;
  2279  max_pclk /= can_pack ? 2 : 3;
  2280  
  2281  return (mode->clock > max_pclk) ? MODE_CLOCK_HIGH : MODE_OK;
  2282  }
  2283  
  2284  static bool sii8620_mode_fixup(struct drm_bridge *bridge,
  2285 const struct drm_display_mode *mode,
  2286 struct drm_display_mode *adjusted_mode)
  2287  {
  2288  struct sii8620 *ctx = bridge_to_sii8620(bridge);
  2289  int max_lclk;
  2290  bool ret = true;
  2291  
  2292  mutex_lock(>lock);
  2293  
  2294  max_lclk = sii8620_is_mhl3(ctx) ? MHL3_MAX_LCLK : MHL1_MAX_LCLK;
  2295  if (max_lclk > 3 * adjusted_mode->clock) {
  2296  ctx->use_packed_pixel = 0;
  2297  goto end;
  2298  }
  2299  if ((ctx->devcap[MHL_DCAP_VID_LINK_MODE] & 
MHL_DCAP_VID_LINK_PPIXEL) &&
  2300  max_lclk > 2 * adjusted_mode->clock) {
  2301  ctx->use_packed_pixel = 1;
  2302 

drivers/gpu/drm/bridge/sil-sii8620.c:2229: undefined reference to `extcon_find_edev_by_node'

[kbuild test robot]

Hi Maciej,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   c1c07416cdd47161a359286021d483f449ad8c4f
commit: 688838442147d9dd94c2ef7c2c31a35cf150c5fa drm/bridge/sii8620: use 
micro-USB cable detection logic to detect MHL
date:   8 weeks ago
config: i386-randconfig-c0-05060527 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
git checkout 688838442147d9dd94c2ef7c2c31a35cf150c5fa
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/bridge/sil-sii8620.o: In function `sii8620_remove':
   drivers/gpu/drm/bridge/sil-sii8620.c:2405: undefined reference to 
`extcon_unregister_notifier'
   drivers/gpu/drm/bridge/sil-sii8620.o: In function `sii8620_extcon_init':
>> drivers/gpu/drm/bridge/sil-sii8620.c:2229: undefined reference to 
>> `extcon_find_edev_by_node'
>> drivers/gpu/drm/bridge/sil-sii8620.c:2241: undefined reference to 
>> `extcon_register_notifier'
   drivers/gpu/drm/bridge/sil-sii8620.o: In function `sii8620_extcon_work':
   drivers/gpu/drm/bridge/sil-sii8620.c:2189: undefined reference to 
`extcon_get_state'

vim +2229 drivers/gpu/drm/bridge/sil-sii8620.c

  2212  
  2213  static int sii8620_extcon_init(struct sii8620 *ctx)
  2214  {
  2215  struct extcon_dev *edev;
  2216  struct device_node *musb, *muic;
  2217  int ret;
  2218  
  2219  /* get micro-USB connector node */
  2220  musb = of_graph_get_remote_node(ctx->dev->of_node, 1, -1);
  2221  /* next get micro-USB Interface Controller node */
    muic = of_get_next_parent(musb);
  2223  
  2224  if (!muic) {
  2225  dev_info(ctx->dev, "no extcon found, switching to 
'always on' mode\n");
  2226  return 0;
  2227  }
  2228  
> 2229  edev = extcon_find_edev_by_node(muic);
  2230  of_node_put(muic);
  2231  if (IS_ERR(edev)) {
  2232  if (PTR_ERR(edev) == -EPROBE_DEFER)
  2233  return -EPROBE_DEFER;
  2234  dev_err(ctx->dev, "Invalid or missing extcon\n");
  2235  return PTR_ERR(edev);
  2236  }
  2237  
  2238  ctx->extcon = edev;
  2239  ctx->extcon_nb.notifier_call = sii8620_extcon_notifier;
  2240  INIT_WORK(>extcon_wq, sii8620_extcon_work);
> 2241  ret = extcon_register_notifier(edev, EXTCON_DISP_MHL, 
> >extcon_nb);
  2242  if (ret) {
  2243  dev_err(ctx->dev, "failed to register notifier for 
MHL\n");
  2244  return ret;
  2245  }
  2246  
  2247  return 0;
  2248  }
  2249  
  2250  static inline struct sii8620 *bridge_to_sii8620(struct drm_bridge 
*bridge)
  2251  {
  2252  return container_of(bridge, struct sii8620, bridge);
  2253  }
  2254  
  2255  static int sii8620_attach(struct drm_bridge *bridge)
  2256  {
  2257  struct sii8620 *ctx = bridge_to_sii8620(bridge);
  2258  
  2259  sii8620_init_rcp_input_dev(ctx);
  2260  
  2261  return sii8620_clear_error(ctx);
  2262  }
  2263  
  2264  static void sii8620_detach(struct drm_bridge *bridge)
  2265  {
  2266  struct sii8620 *ctx = bridge_to_sii8620(bridge);
  2267  
  2268  rc_unregister_device(ctx->rc_dev);
  2269  }
  2270  
  2271  static enum drm_mode_status sii8620_mode_valid(struct drm_bridge 
*bridge,
  2272   const struct drm_display_mode 
*mode)
  2273  {
  2274  struct sii8620 *ctx = bridge_to_sii8620(bridge);
  2275  bool can_pack = ctx->devcap[MHL_DCAP_VID_LINK_MODE] &
  2276  MHL_DCAP_VID_LINK_PPIXEL;
  2277  unsigned int max_pclk = sii8620_is_mhl3(ctx) ? MHL3_MAX_LCLK :
  2278 MHL1_MAX_LCLK;
  2279  max_pclk /= can_pack ? 2 : 3;
  2280  
  2281  return (mode->clock > max_pclk) ? MODE_CLOCK_HIGH : MODE_OK;
  2282  }
  2283  
  2284  static bool sii8620_mode_fixup(struct drm_bridge *bridge,
  2285 const struct drm_display_mode *mode,
  2286 struct drm_display_mode *adjusted_mode)
  2287  {
  2288  struct sii8620 *ctx = bridge_to_sii8620(bridge);
  2289  int max_lclk;
  2290  bool ret = true;
  2291  
  2292  mutex_lock(>lock);
  2293  
  2294  max_lclk = sii8620_is_mhl3(ctx) ? MHL3_MAX_LCLK : MHL1_MAX_LCLK;
  2295  if (max_lclk > 3 * adjusted_mode->clock) {
  2296  ctx->use_packed_pixel = 0;
  2297  goto end;
  2298  }
  2299  if ((ctx->devcap[MHL_DCAP_VID_LINK_MODE] & 
MHL_DCAP_VID_LINK_PPIXEL) &&
  2300  max_lclk > 2 * adjusted_mode->clock) {
  2301  ctx->use_packed_pixel = 1;
  2302 

Re: [PATCH v4 05/22] iommu: introduce iommu invalidate API function

[Jerry Snitselaar]

On Mon Apr 16 18, Jacob Pan wrote:

From: "Liu, Yi L" 

When an SVM capable device is assigned to a guest, the first level page
tables are owned by the guest and the guest PASID table pointer is
linked to the device context entry of the physical IOMMU.

Host IOMMU driver has no knowledge of caching structure updates unless
the guest invalidation activities are passed down to the host. The
primary usage is derived from emulated IOMMU in the guest, where QEMU
can trap invalidation activities before passing them down to the
host/physical IOMMU.
Since the invalidation data are obtained from user space and will be
written into physical IOMMU, we must allow security check at various
layers. Therefore, generic invalidation data format are proposed here,
model specific IOMMU drivers need to convert them into their own format.

Signed-off-by: Liu, Yi L 
Signed-off-by: Jean-Philippe Brucker 
Signed-off-by: Jacob Pan 
Signed-off-by: Ashok Raj 
---
drivers/iommu/iommu.c  | 14 
include/linux/iommu.h  | 12 +++
include/uapi/linux/iommu.h | 79 ++
3 files changed, 105 insertions(+)

diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 3a69620..784e019 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -1344,6 +1344,20 @@ void iommu_unbind_pasid_table(struct iommu_domain 
*domain, struct device *dev)
}
EXPORT_SYMBOL_GPL(iommu_unbind_pasid_table);

+int iommu_sva_invalidate(struct iommu_domain *domain,
+   struct device *dev, struct tlb_invalidate_info *inv_info)
+{
+   int ret = 0;
+
+   if (unlikely(!domain->ops->sva_invalidate))
+   return -ENODEV;
+
+   ret = domain->ops->sva_invalidate(domain, dev, inv_info);
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(iommu_sva_invalidate);
+
static void __iommu_detach_device(struct iommu_domain *domain,
  struct device *dev)
{
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 8ad111f..e963dbd 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -190,6 +190,7 @@ struct iommu_resv_region {
 * @pgsize_bitmap: bitmap of all possible supported page sizes
 * @bind_pasid_table: bind pasid table pointer for guest SVM
 * @unbind_pasid_table: unbind pasid table pointer and restore defaults
+ * @sva_invalidate: invalidate translation caches of shared virtual address
 */
struct iommu_ops {
bool (*capable)(enum iommu_cap);
@@ -243,6 +244,8 @@ struct iommu_ops {
struct pasid_table_config *pasidt_binfo);
void (*unbind_pasid_table)(struct iommu_domain *domain,
struct device *dev);
+   int (*sva_invalidate)(struct iommu_domain *domain,
+   struct device *dev, struct tlb_invalidate_info *inv_info);

unsigned long pgsize_bitmap;
};
@@ -309,6 +312,9 @@ extern int iommu_bind_pasid_table(struct iommu_domain 
*domain,
struct device *dev, struct pasid_table_config *pasidt_binfo);
extern void iommu_unbind_pasid_table(struct iommu_domain *domain,
struct device *dev);
+extern int iommu_sva_invalidate(struct iommu_domain *domain,
+   struct device *dev, struct tlb_invalidate_info *inv_info);
+
extern struct iommu_domain *iommu_get_domain_for_dev(struct device *dev);
extern int iommu_map(struct iommu_domain *domain, unsigned long iova,
 phys_addr_t paddr, size_t size, int prot);
@@ -720,6 +726,12 @@ void iommu_unbind_pasid_table(struct iommu_domain *domain, 
struct device *dev)
{
}

+static inline int iommu_sva_invalidate(struct iommu_domain *domain,
+   struct device *dev, struct tlb_invalidate_info *inv_info)
+{
+   return -EINVAL;
+}
+


Would -ENODEV make more sense here?


#endif /* CONFIG_IOMMU_API */

#endif /* __LINUX_IOMMU_H */
diff --git a/include/uapi/linux/iommu.h b/include/uapi/linux/iommu.h
index 9f7a6bf..4447943 100644
--- a/include/uapi/linux/iommu.h
+++ b/include/uapi/linux/iommu.h
@@ -29,4 +29,83 @@ struct pasid_table_config {
__u8 pasid_bits;
};

+/**
+ * enum iommu_inv_granularity - Generic invalidation granularity
+ *
+ * When an invalidation request is sent to IOMMU to flush translation caches,
+ * it may carry different granularity. These granularity levels are not 
specific
+ * to a type of translation cache. For an example, PASID selective granularity
+ * is only applicable to PASID cache invalidation.
+ * This enum is a collection of granularities for all types of translation
+ * caches. The idea is to make it easy for IOMMU model specific driver do
+ * conversion from generic to model specific value.
+ */
+enum iommu_inv_granularity {
+   IOMMU_INV_GRANU_DOMAIN = 1, /* all TLBs associated with a domain */
+   IOMMU_INV_GRANU_DEVICE, /* caching 

Re: [PATCH v4 05/22] iommu: introduce iommu invalidate API function

[Jerry Snitselaar]

On Mon Apr 16 18, Jacob Pan wrote:

From: "Liu, Yi L" 

When an SVM capable device is assigned to a guest, the first level page
tables are owned by the guest and the guest PASID table pointer is
linked to the device context entry of the physical IOMMU.

Host IOMMU driver has no knowledge of caching structure updates unless
the guest invalidation activities are passed down to the host. The
primary usage is derived from emulated IOMMU in the guest, where QEMU
can trap invalidation activities before passing them down to the
host/physical IOMMU.
Since the invalidation data are obtained from user space and will be
written into physical IOMMU, we must allow security check at various
layers. Therefore, generic invalidation data format are proposed here,
model specific IOMMU drivers need to convert them into their own format.

Signed-off-by: Liu, Yi L 
Signed-off-by: Jean-Philippe Brucker 
Signed-off-by: Jacob Pan 
Signed-off-by: Ashok Raj 
---
drivers/iommu/iommu.c  | 14 
include/linux/iommu.h  | 12 +++
include/uapi/linux/iommu.h | 79 ++
3 files changed, 105 insertions(+)

diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 3a69620..784e019 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -1344,6 +1344,20 @@ void iommu_unbind_pasid_table(struct iommu_domain 
*domain, struct device *dev)
}
EXPORT_SYMBOL_GPL(iommu_unbind_pasid_table);

+int iommu_sva_invalidate(struct iommu_domain *domain,
+   struct device *dev, struct tlb_invalidate_info *inv_info)
+{
+   int ret = 0;
+
+   if (unlikely(!domain->ops->sva_invalidate))
+   return -ENODEV;
+
+   ret = domain->ops->sva_invalidate(domain, dev, inv_info);
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(iommu_sva_invalidate);
+
static void __iommu_detach_device(struct iommu_domain *domain,
  struct device *dev)
{
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 8ad111f..e963dbd 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -190,6 +190,7 @@ struct iommu_resv_region {
 * @pgsize_bitmap: bitmap of all possible supported page sizes
 * @bind_pasid_table: bind pasid table pointer for guest SVM
 * @unbind_pasid_table: unbind pasid table pointer and restore defaults
+ * @sva_invalidate: invalidate translation caches of shared virtual address
 */
struct iommu_ops {
bool (*capable)(enum iommu_cap);
@@ -243,6 +244,8 @@ struct iommu_ops {
struct pasid_table_config *pasidt_binfo);
void (*unbind_pasid_table)(struct iommu_domain *domain,
struct device *dev);
+   int (*sva_invalidate)(struct iommu_domain *domain,
+   struct device *dev, struct tlb_invalidate_info *inv_info);

unsigned long pgsize_bitmap;
};
@@ -309,6 +312,9 @@ extern int iommu_bind_pasid_table(struct iommu_domain 
*domain,
struct device *dev, struct pasid_table_config *pasidt_binfo);
extern void iommu_unbind_pasid_table(struct iommu_domain *domain,
struct device *dev);
+extern int iommu_sva_invalidate(struct iommu_domain *domain,
+   struct device *dev, struct tlb_invalidate_info *inv_info);
+
extern struct iommu_domain *iommu_get_domain_for_dev(struct device *dev);
extern int iommu_map(struct iommu_domain *domain, unsigned long iova,
 phys_addr_t paddr, size_t size, int prot);
@@ -720,6 +726,12 @@ void iommu_unbind_pasid_table(struct iommu_domain *domain, 
struct device *dev)
{
}

+static inline int iommu_sva_invalidate(struct iommu_domain *domain,
+   struct device *dev, struct tlb_invalidate_info *inv_info)
+{
+   return -EINVAL;
+}
+


Would -ENODEV make more sense here?


#endif /* CONFIG_IOMMU_API */

#endif /* __LINUX_IOMMU_H */
diff --git a/include/uapi/linux/iommu.h b/include/uapi/linux/iommu.h
index 9f7a6bf..4447943 100644
--- a/include/uapi/linux/iommu.h
+++ b/include/uapi/linux/iommu.h
@@ -29,4 +29,83 @@ struct pasid_table_config {
__u8 pasid_bits;
};

+/**
+ * enum iommu_inv_granularity - Generic invalidation granularity
+ *
+ * When an invalidation request is sent to IOMMU to flush translation caches,
+ * it may carry different granularity. These granularity levels are not 
specific
+ * to a type of translation cache. For an example, PASID selective granularity
+ * is only applicable to PASID cache invalidation.
+ * This enum is a collection of granularities for all types of translation
+ * caches. The idea is to make it easy for IOMMU model specific driver do
+ * conversion from generic to model specific value.
+ */
+enum iommu_inv_granularity {
+   IOMMU_INV_GRANU_DOMAIN = 1, /* all TLBs associated with a domain */
+   IOMMU_INV_GRANU_DEVICE, /* caching structure associated with a
+* device ID
+*/
+   

Re: WARNING in kernfs_add_one

[Greg KH]

On Sat, May 05, 2018 at 10:43:45AM -0700, Eric Dumazet wrote:
> 
> 
> On 05/05/2018 09:40 AM, Greg KH wrote:
> > On Sat, May 05, 2018 at 08:47:02AM -0700, syzbot wrote:
> >> Hello,
> >>
> >> syzbot found the following crash on:
> >>
> >> HEAD commit:8fb11a9a8d51 net/ipv6: rename rt6_next to fib6_next
> >> git tree:   net-next
> >> console output: https://syzkaller.appspot.com/x/log.txt?x=14b2723780
> >> kernel config:  https://syzkaller.appspot.com/x/.config?x=c416c61f3cd96be
> >> dashboard link: 
> >> https://syzkaller.appspot.com/bug?extid=df47f81c226b31d89fb1
> >> compiler:   gcc (GCC) 8.0.1 20180413 (experimental)
> >> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=172fb3e780
> >> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=16552e5780
> >>
> >> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> >> Reported-by: syzbot+df47f81c226b31d89...@syzkaller.appspotmail.com
> >>
> >> RBP: 7fff808f3e10 R08: 0002 R09: 7fff80003534
> >> R10:  R11: 0246 R12: 
> >> R13: 0006 R14:  R15: 
> >> [ cut here ]
> >> kernfs: ns required in 'ieee80211' for 'phy3'
> > 
> > That's interesting, this looks like a netfilter bug (adding netdev to
> > the report here.)
> 
> 
> I do not see anything netfilter related here.
> 
> More likely wireless territory

Ugh, that's what I get for writing emails before coffee in the
morning...

Yes, you are right, this looks like a wireless issue.

Now cc: linux-wireless.

> > Yes, we can "tone down" the kernfs warning to just be an error message
> > in the log, but there might be something worse going on here.
> > 
> > Network developers, any idea?  Rest of the callback chain is here:
> > 
> > 
> >> WARNING: CPU: 0 PID: 4538 at fs/kernfs/dir.c:759 kernfs_add_one+0x406/0x4d0
> >> fs/kernfs/dir.c:758
> >> Kernel panic - not syncing: panic_on_warn set ...
> >>
> >> CPU: 0 PID: 4538 Comm: syz-executor486 Not tainted 4.17.0-rc3+ #33
> >> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> >> Google 01/01/2011
> >> Call Trace:
> >>  __dump_stack lib/dump_stack.c:77 [inline]
> >>  dump_stack+0x1b9/0x294 lib/dump_stack.c:113
> >>  panic+0x22f/0x4de kernel/panic.c:184
> >>  __warn.cold.8+0x163/0x1b3 kernel/panic.c:536
> >>  report_bug+0x252/0x2d0 lib/bug.c:186
> >>  fixup_bug arch/x86/kernel/traps.c:178 [inline]
> >>  do_error_trap+0x1de/0x490 arch/x86/kernel/traps.c:296
> >>  do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315
> >>  invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:992
> >> RIP: 0010:kernfs_add_one+0x406/0x4d0 fs/kernfs/dir.c:758
> >> RSP: 0018:8801ca9eece0 EFLAGS: 00010286
> >> RAX: 002d RBX: 87d5cee0 RCX: 8160ba7d
> >> RDX:  RSI: 81610731 RDI: 8801ca9ee840
> >> RBP: 8801ca9eed20 R08: 8801d9538500 R09: 0006
> >> R10: 8801d9538500 R11:  R12: 8801ad1cb6c0
> >> R13: 885da640 R14: 0020 R15: 
> >>  kernfs_create_link+0x112/0x180 fs/kernfs/symlink.c:41
> >>  sysfs_do_create_link_sd.isra.2+0x90/0x130 fs/sysfs/symlink.c:43
> >>  sysfs_do_create_link fs/sysfs/symlink.c:79 [inline]
> >>  sysfs_create_link+0x65/0xc0 fs/sysfs/symlink.c:91
> >>  device_add_class_symlinks drivers/base/core.c:1612 [inline]
> >>  device_add+0x7a0/0x16d0 drivers/base/core.c:1810
> >>  wiphy_register+0x178a/0x2430 net/wireless/core.c:806
> >>  ieee80211_register_hw+0x13cd/0x35d0 net/mac80211/main.c:1047
> >>  mac80211_hwsim_new_radio+0x1d9b/0x3410
> >> drivers/net/wireless/mac80211_hwsim.c:2772
> >>  hwsim_new_radio_nl+0x7a7/0xa60 drivers/net/wireless/mac80211_hwsim.c:3246
> >>  genl_family_rcv_msg+0x889/0x1120 net/netlink/genetlink.c:599
> >>  genl_rcv_msg+0xc6/0x170 net/netlink/genetlink.c:624
> >>  netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2448
> >>  genl_rcv+0x28/0x40 net/netlink/genetlink.c:635
> >>  netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline]
> >>  netlink_unicast+0x58b/0x740 net/netlink/af_netlink.c:1336
> >>  netlink_sendmsg+0x9f0/0xfa0 net/netlink/af_netlink.c:1901
> >>  sock_sendmsg_nosec net/socket.c:629 [inline]
> >>  sock_sendmsg+0xd5/0x120 net/socket.c:639
> >>  ___sys_sendmsg+0x805/0x940 net/socket.c:2117
> >>  __sys_sendmsg+0x115/0x270 net/socket.c:2155
> >>  __do_sys_sendmsg net/socket.c:2164 [inline]
> >>  __se_sys_sendmsg net/socket.c:2162 [inline]
> >>  __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2162
> >>  do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
> >>  entry_SYSCALL_64_after_hwframe+0x49/0xbe
> >> RIP: 0033:0x4404c9
> >> RSP: 002b:7fff808f3e08 EFLAGS: 0246 ORIG_RAX: 002e
> >> RAX: ffda RBX:  RCX: 004404c9
> >> RDX:  RSI: 20b3dfc8 RDI: 0005
> >> RBP: 7fff808f3e10 R08: 0002 R09: 7fff80003534

Re: WARNING in kernfs_add_one

[Greg KH]

On Sat, May 05, 2018 at 10:43:45AM -0700, Eric Dumazet wrote:
> 
> 
> On 05/05/2018 09:40 AM, Greg KH wrote:
> > On Sat, May 05, 2018 at 08:47:02AM -0700, syzbot wrote:
> >> Hello,
> >>
> >> syzbot found the following crash on:
> >>
> >> HEAD commit:8fb11a9a8d51 net/ipv6: rename rt6_next to fib6_next
> >> git tree:   net-next
> >> console output: https://syzkaller.appspot.com/x/log.txt?x=14b2723780
> >> kernel config:  https://syzkaller.appspot.com/x/.config?x=c416c61f3cd96be
> >> dashboard link: 
> >> https://syzkaller.appspot.com/bug?extid=df47f81c226b31d89fb1
> >> compiler:   gcc (GCC) 8.0.1 20180413 (experimental)
> >> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=172fb3e780
> >> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=16552e5780
> >>
> >> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> >> Reported-by: syzbot+df47f81c226b31d89...@syzkaller.appspotmail.com
> >>
> >> RBP: 7fff808f3e10 R08: 0002 R09: 7fff80003534
> >> R10:  R11: 0246 R12: 
> >> R13: 0006 R14:  R15: 
> >> [ cut here ]
> >> kernfs: ns required in 'ieee80211' for 'phy3'
> > 
> > That's interesting, this looks like a netfilter bug (adding netdev to
> > the report here.)
> 
> 
> I do not see anything netfilter related here.
> 
> More likely wireless territory

Ugh, that's what I get for writing emails before coffee in the
morning...

Yes, you are right, this looks like a wireless issue.

Now cc: linux-wireless.

> > Yes, we can "tone down" the kernfs warning to just be an error message
> > in the log, but there might be something worse going on here.
> > 
> > Network developers, any idea?  Rest of the callback chain is here:
> > 
> > 
> >> WARNING: CPU: 0 PID: 4538 at fs/kernfs/dir.c:759 kernfs_add_one+0x406/0x4d0
> >> fs/kernfs/dir.c:758
> >> Kernel panic - not syncing: panic_on_warn set ...
> >>
> >> CPU: 0 PID: 4538 Comm: syz-executor486 Not tainted 4.17.0-rc3+ #33
> >> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> >> Google 01/01/2011
> >> Call Trace:
> >>  __dump_stack lib/dump_stack.c:77 [inline]
> >>  dump_stack+0x1b9/0x294 lib/dump_stack.c:113
> >>  panic+0x22f/0x4de kernel/panic.c:184
> >>  __warn.cold.8+0x163/0x1b3 kernel/panic.c:536
> >>  report_bug+0x252/0x2d0 lib/bug.c:186
> >>  fixup_bug arch/x86/kernel/traps.c:178 [inline]
> >>  do_error_trap+0x1de/0x490 arch/x86/kernel/traps.c:296
> >>  do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315
> >>  invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:992
> >> RIP: 0010:kernfs_add_one+0x406/0x4d0 fs/kernfs/dir.c:758
> >> RSP: 0018:8801ca9eece0 EFLAGS: 00010286
> >> RAX: 002d RBX: 87d5cee0 RCX: 8160ba7d
> >> RDX:  RSI: 81610731 RDI: 8801ca9ee840
> >> RBP: 8801ca9eed20 R08: 8801d9538500 R09: 0006
> >> R10: 8801d9538500 R11:  R12: 8801ad1cb6c0
> >> R13: 885da640 R14: 0020 R15: 
> >>  kernfs_create_link+0x112/0x180 fs/kernfs/symlink.c:41
> >>  sysfs_do_create_link_sd.isra.2+0x90/0x130 fs/sysfs/symlink.c:43
> >>  sysfs_do_create_link fs/sysfs/symlink.c:79 [inline]
> >>  sysfs_create_link+0x65/0xc0 fs/sysfs/symlink.c:91
> >>  device_add_class_symlinks drivers/base/core.c:1612 [inline]
> >>  device_add+0x7a0/0x16d0 drivers/base/core.c:1810
> >>  wiphy_register+0x178a/0x2430 net/wireless/core.c:806
> >>  ieee80211_register_hw+0x13cd/0x35d0 net/mac80211/main.c:1047
> >>  mac80211_hwsim_new_radio+0x1d9b/0x3410
> >> drivers/net/wireless/mac80211_hwsim.c:2772
> >>  hwsim_new_radio_nl+0x7a7/0xa60 drivers/net/wireless/mac80211_hwsim.c:3246
> >>  genl_family_rcv_msg+0x889/0x1120 net/netlink/genetlink.c:599
> >>  genl_rcv_msg+0xc6/0x170 net/netlink/genetlink.c:624
> >>  netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2448
> >>  genl_rcv+0x28/0x40 net/netlink/genetlink.c:635
> >>  netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline]
> >>  netlink_unicast+0x58b/0x740 net/netlink/af_netlink.c:1336
> >>  netlink_sendmsg+0x9f0/0xfa0 net/netlink/af_netlink.c:1901
> >>  sock_sendmsg_nosec net/socket.c:629 [inline]
> >>  sock_sendmsg+0xd5/0x120 net/socket.c:639
> >>  ___sys_sendmsg+0x805/0x940 net/socket.c:2117
> >>  __sys_sendmsg+0x115/0x270 net/socket.c:2155
> >>  __do_sys_sendmsg net/socket.c:2164 [inline]
> >>  __se_sys_sendmsg net/socket.c:2162 [inline]
> >>  __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2162
> >>  do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
> >>  entry_SYSCALL_64_after_hwframe+0x49/0xbe
> >> RIP: 0033:0x4404c9
> >> RSP: 002b:7fff808f3e08 EFLAGS: 0246 ORIG_RAX: 002e
> >> RAX: ffda RBX:  RCX: 004404c9
> >> RDX:  RSI: 20b3dfc8 RDI: 0005
> >> RBP: 7fff808f3e10 R08: 0002 R09: 7fff80003534

Re: [PATCH 8/8] rhashtable: don't hold lock on first table throughout insertion.

[NeilBrown]

On Sat, May 05 2018, Herbert Xu wrote:

> On Fri, May 04, 2018 at 01:54:14PM +1000, NeilBrown wrote:
>> rhashtable_try_insert() currently hold a lock on the bucket in
>> the first table, while also locking buckets in subsequent tables.
>> This is unnecessary and looks like a hold-over from some earlier
>> version of the implementation.
>> 
>> As insert and remove always lock a bucket in each table in turn, and
>> as insert only inserts in the final table, there cannot be any races
>> that are not covered by simply locking a bucket in each table in turn.
>> 
>> When an insert call reaches that last table it can be sure that there
>> is no match entry in any other table as it has searched them all, and
>> insertion never happens anywhere but in the last table.  The fact that
>> code tests for the existence of future_tbl while holding a lock on
>> the relevant bucket ensures that two threads inserting the same key
>> will make compatible decisions about which is the "last" table.
>> 
>> This simplifies the code and allows the ->rehash field to be
>> discarded.
>> We still need a way to ensure that a dead bucket_table is never
>> re-linked by rhashtable_walk_stop().  This can be achieved by
>> setting the ->size to 1.  This still allows lookup code to work (and
>> correctly not find anything) but can never happen on an active bucket
>> table (as the minimum size is 4).
>> 
>> Signed-off-by: NeilBrown 
>
> I'm not convinced this is safe.  There can be multiple tables
> in existence.  Unless you hold the lock on the first table, what
> is to stop two parallel inserters each from inserting into their
> "last" tables which may not be the same table?

The insert function must (and does) take the lock on the bucket before
testing if there is a "next" table.
If one inserter finds that it has locked the "last" table (because there
is no next) and successfully inserts, then the other inserter cannot
have locked that table yet, else it would have inserted.  When it does,
it will find what the first inserter inserted. 

Thanks,
NeilBrown

>
> Cheers,
> -- 
> Email: Herbert Xu 
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


signature.asc
Description: PGP signature

Re: [PATCH 8/8] rhashtable: don't hold lock on first table throughout insertion.

[NeilBrown]

On Sat, May 05 2018, Herbert Xu wrote:

> On Fri, May 04, 2018 at 01:54:14PM +1000, NeilBrown wrote:
>> rhashtable_try_insert() currently hold a lock on the bucket in
>> the first table, while also locking buckets in subsequent tables.
>> This is unnecessary and looks like a hold-over from some earlier
>> version of the implementation.
>> 
>> As insert and remove always lock a bucket in each table in turn, and
>> as insert only inserts in the final table, there cannot be any races
>> that are not covered by simply locking a bucket in each table in turn.
>> 
>> When an insert call reaches that last table it can be sure that there
>> is no match entry in any other table as it has searched them all, and
>> insertion never happens anywhere but in the last table.  The fact that
>> code tests for the existence of future_tbl while holding a lock on
>> the relevant bucket ensures that two threads inserting the same key
>> will make compatible decisions about which is the "last" table.
>> 
>> This simplifies the code and allows the ->rehash field to be
>> discarded.
>> We still need a way to ensure that a dead bucket_table is never
>> re-linked by rhashtable_walk_stop().  This can be achieved by
>> setting the ->size to 1.  This still allows lookup code to work (and
>> correctly not find anything) but can never happen on an active bucket
>> table (as the minimum size is 4).
>> 
>> Signed-off-by: NeilBrown 
>
> I'm not convinced this is safe.  There can be multiple tables
> in existence.  Unless you hold the lock on the first table, what
> is to stop two parallel inserters each from inserting into their
> "last" tables which may not be the same table?

The insert function must (and does) take the lock on the bucket before
testing if there is a "next" table.
If one inserter finds that it has locked the "last" table (because there
is no next) and successfully inserts, then the other inserter cannot
have locked that table yet, else it would have inserted.  When it does,
it will find what the first inserter inserted. 

Thanks,
NeilBrown

>
> Cheers,
> -- 
> Email: Herbert Xu 
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


signature.asc
Description: PGP signature

Re: [PATCH 6/8] rhashtable: further improve stability of rhashtable_walk

[NeilBrown]

On Sat, May 05 2018, Herbert Xu wrote:

> On Fri, May 04, 2018 at 01:54:14PM +1000, NeilBrown wrote:
>> If the sequence:
>>obj = rhashtable_walk_next(iter);
>>rhashtable_walk_stop(iter);
>>rhashtable_remove_fast(ht, >head, params);
>>rhashtable_walk_start(iter);
>> 
>>  races with another thread inserting or removing
>>  an object on the same hash chain, a subsequent
>>  rhashtable_walk_next() is not guaranteed to get the "next"
>>  object. It is possible that an object could be
>>  repeated, or missed.
>> 
>>  This can be made more reliable by keeping the objects in a hash chain
>>  sorted by memory address.  A subsequent rhashtable_walk_next()
>>  call can reliably find the correct position in the list, and thus
>>  find the 'next' object.
>> 
>>  It is not possible (certainly not so easy) to achieve this with an
>>  rhltable as keeping the hash chain in order is not so easy.  When the
>>  first object with a given key is removed, it is replaced in the chain
>>  with the next object with the same key, and the address of that
>>  object may not be correctly ordered.
>>  No current user of rhltable_walk_enter() calls
>>  rhashtable_walk_start() more than once, so no current code
>>  could benefit from a more reliable walk of rhltables.
>> 
>>  This patch only attempts to improve walks for rhashtables.
>>  - a new object is always inserted after the last object with a
>>smaller address, or at the start
>>  - when rhashtable_walk_start() is called, it records that 'p' is not
>>'safe', meaning that it cannot be dereferenced.  The revalidation
>>that was previously done here is moved to rhashtable_walk_next()
>>  - when rhashtable_walk_next() is called while p is not NULL and not
>>safe, it walks the chain looking for the first object with an
>>address greater than p and returns that.  If there is none, it moves
>>to the next hash chain.
>> 
>> Signed-off-by: NeilBrown 
>
> I'm a bit torn on this.  On the hand this is definitely an improvement
> over the status quo.  On the other this does not work on rhltable and
> we do have a way of fixing it for both rhashtable and rhltable.

Do we?  How could we fix it for both rhashtable and rhltable?

Thanks,
NeilBrown



signature.asc
Description: PGP signature

Re: [PATCH 6/8] rhashtable: further improve stability of rhashtable_walk

[NeilBrown]

On Sat, May 05 2018, Herbert Xu wrote:

> On Fri, May 04, 2018 at 01:54:14PM +1000, NeilBrown wrote:
>> If the sequence:
>>obj = rhashtable_walk_next(iter);
>>rhashtable_walk_stop(iter);
>>rhashtable_remove_fast(ht, >head, params);
>>rhashtable_walk_start(iter);
>> 
>>  races with another thread inserting or removing
>>  an object on the same hash chain, a subsequent
>>  rhashtable_walk_next() is not guaranteed to get the "next"
>>  object. It is possible that an object could be
>>  repeated, or missed.
>> 
>>  This can be made more reliable by keeping the objects in a hash chain
>>  sorted by memory address.  A subsequent rhashtable_walk_next()
>>  call can reliably find the correct position in the list, and thus
>>  find the 'next' object.
>> 
>>  It is not possible (certainly not so easy) to achieve this with an
>>  rhltable as keeping the hash chain in order is not so easy.  When the
>>  first object with a given key is removed, it is replaced in the chain
>>  with the next object with the same key, and the address of that
>>  object may not be correctly ordered.
>>  No current user of rhltable_walk_enter() calls
>>  rhashtable_walk_start() more than once, so no current code
>>  could benefit from a more reliable walk of rhltables.
>> 
>>  This patch only attempts to improve walks for rhashtables.
>>  - a new object is always inserted after the last object with a
>>smaller address, or at the start
>>  - when rhashtable_walk_start() is called, it records that 'p' is not
>>'safe', meaning that it cannot be dereferenced.  The revalidation
>>that was previously done here is moved to rhashtable_walk_next()
>>  - when rhashtable_walk_next() is called while p is not NULL and not
>>safe, it walks the chain looking for the first object with an
>>address greater than p and returns that.  If there is none, it moves
>>to the next hash chain.
>> 
>> Signed-off-by: NeilBrown 
>
> I'm a bit torn on this.  On the hand this is definitely an improvement
> over the status quo.  On the other this does not work on rhltable and
> we do have a way of fixing it for both rhashtable and rhltable.

Do we?  How could we fix it for both rhashtable and rhltable?

Thanks,
NeilBrown



signature.asc
Description: PGP signature

Re: [PATCH 1/8] rhashtable: silence RCU warning in rhashtable_test.

[NeilBrown]

On Sat, May 05 2018, Herbert Xu wrote:

> On Fri, May 04, 2018 at 01:54:14PM +1000, NeilBrown wrote:
>> print_ht in rhashtable_test calls rht_dereference() with neither
>> RCU protection or the mutex.  This triggers an RCU warning.
>> So take the mutex to silence the warning.
>> 
>> Signed-off-by: NeilBrown 
>
> I don't think the mutex is actually needed but since we don't
> have rht_dereference_raw and this is just test code:

I agrees there is no functional need for the mutex.  It just needed to
silence the warning, so that other warnings are easier to see.

>
> Acked-by: Herbert Xu 

thanks,
NeilBrown

> -- 
> Email: Herbert Xu 
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


signature.asc
Description: PGP signature

Re: [PATCH 1/8] rhashtable: silence RCU warning in rhashtable_test.

[NeilBrown]

On Sat, May 05 2018, Herbert Xu wrote:

> On Fri, May 04, 2018 at 01:54:14PM +1000, NeilBrown wrote:
>> print_ht in rhashtable_test calls rht_dereference() with neither
>> RCU protection or the mutex.  This triggers an RCU warning.
>> So take the mutex to silence the warning.
>> 
>> Signed-off-by: NeilBrown 
>
> I don't think the mutex is actually needed but since we don't
> have rht_dereference_raw and this is just test code:

I agrees there is no functional need for the mutex.  It just needed to
silence the warning, so that other warnings are easier to see.

>
> Acked-by: Herbert Xu 

thanks,
NeilBrown

> -- 
> Email: Herbert Xu 
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


signature.asc
Description: PGP signature

Re: [PATCH 4/8] rhashtable: fix race in nested_table_alloc()

[NeilBrown]

On Sat, May 05 2018, Herbert Xu wrote:

> On Fri, May 04, 2018 at 01:54:14PM +1000, NeilBrown wrote:
>> If two threads run nested_table_alloc() at the same time
>> they could both allocate a new table.
>> Best case is that one of them will never be freed, leaking memory.
>> Worst case is hat entry get stored there before it leaks,
>> and the are lost from the table.
>> 
>> So use cmpxchg to detect the race and free the unused table.
>> 
>> Fixes: da20420f83ea ("rhashtable: Add nested tables")
>> Cc: sta...@vger.kernel.org # 4.11+
>> Signed-off-by: NeilBrown 
>
> What about the spinlock that's meant to be held around this
> operation?

The spinlock protects 2 or more buckets.  The nested table contains at
least 512 buckets, maybe more.
It is quite possible for two insertions into 2 different buckets to both
get their spinlock and both try to instantiate the same nested table.

Thanks,
NeilBrown


signature.asc
Description: PGP signature

Re: [PATCH 4/8] rhashtable: fix race in nested_table_alloc()

[NeilBrown]

On Sat, May 05 2018, Herbert Xu wrote:

> On Fri, May 04, 2018 at 01:54:14PM +1000, NeilBrown wrote:
>> If two threads run nested_table_alloc() at the same time
>> they could both allocate a new table.
>> Best case is that one of them will never be freed, leaking memory.
>> Worst case is hat entry get stored there before it leaks,
>> and the are lost from the table.
>> 
>> So use cmpxchg to detect the race and free the unused table.
>> 
>> Fixes: da20420f83ea ("rhashtable: Add nested tables")
>> Cc: sta...@vger.kernel.org # 4.11+
>> Signed-off-by: NeilBrown 
>
> What about the spinlock that's meant to be held around this
> operation?

The spinlock protects 2 or more buckets.  The nested table contains at
least 512 buckets, maybe more.
It is quite possible for two insertions into 2 different buckets to both
get their spinlock and both try to instantiate the same nested table.

Thanks,
NeilBrown


signature.asc
Description: PGP signature

Re: [PATCH 3/8] rhashtable: use cmpxchg() to protect ->future_tbl.

[NeilBrown]

On Sat, May 05 2018, Herbert Xu wrote:

> On Fri, May 04, 2018 at 01:54:14PM +1000, NeilBrown wrote:
>> Rather than borrowing one of the bucket locks to
>> protect ->future_tbl updates, use cmpxchg().
>> This gives more freedom to change how bucket locking
>> is implemented.
>> 
>> Signed-off-by: NeilBrown 
>
> This looks nice.
>
>> -spin_unlock_bh(old_tbl->locks);
>> +rcu_assign_pointer(tmp, new_tbl);
>
> Do we need this barrier since cmpxchg is supposed to provide memory
> barrier semantics?

It's hard to find documentation even for what cmpxchg() is meant do, let
alone what barriers is provides, but there does seem to be something
hidden in Documentation/core-api/atomic_ops.rst which suggests full
barrier semantics if the comparison succeeds.  I'll replace the
rcu_assign_pointer with a comment saying why it isn't needed.

Thanks,
NeilBrown

>
>> +if (cmpxchg(_tbl->future_tbl, NULL, tmp) != NULL)
>> +return -EEXIST;
>
> Thanks,
> -- 
> Email: Herbert Xu 
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


signature.asc
Description: PGP signature

Re: [PATCH 3/8] rhashtable: use cmpxchg() to protect ->future_tbl.

[NeilBrown]

On Sat, May 05 2018, Herbert Xu wrote:

> On Fri, May 04, 2018 at 01:54:14PM +1000, NeilBrown wrote:
>> Rather than borrowing one of the bucket locks to
>> protect ->future_tbl updates, use cmpxchg().
>> This gives more freedom to change how bucket locking
>> is implemented.
>> 
>> Signed-off-by: NeilBrown 
>
> This looks nice.
>
>> -spin_unlock_bh(old_tbl->locks);
>> +rcu_assign_pointer(tmp, new_tbl);
>
> Do we need this barrier since cmpxchg is supposed to provide memory
> barrier semantics?

It's hard to find documentation even for what cmpxchg() is meant do, let
alone what barriers is provides, but there does seem to be something
hidden in Documentation/core-api/atomic_ops.rst which suggests full
barrier semantics if the comparison succeeds.  I'll replace the
rcu_assign_pointer with a comment saying why it isn't needed.

Thanks,
NeilBrown

>
>> +if (cmpxchg(_tbl->future_tbl, NULL, tmp) != NULL)
>> +return -EEXIST;
>
> Thanks,
> -- 
> Email: Herbert Xu 
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


signature.asc
Description: PGP signature

Handling lm3559 flash on Motorola Droid 4 and others

[Pavel Machek]

Hi!

It seems lm3559 flash driver is available on github (
https://github.com/ZenfoneArea/android_kernel_asus_zenfone5/tree/master/linux/modules/camera/drivers/media/i2c
) but there'll be some fun getting it cleaned up and merged.

Did anyone start doing anything in that area? Is there possibly better
source to start from?

Best regards,

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Handling lm3559 flash on Motorola Droid 4 and others

[Pavel Machek]

Hi!

It seems lm3559 flash driver is available on github (
https://github.com/ZenfoneArea/android_kernel_asus_zenfone5/tree/master/linux/modules/camera/drivers/media/i2c
) but there'll be some fun getting it cleaned up and merged.

Did anyone start doing anything in that area? Is there possibly better
source to start from?

Best regards,

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

[RFC PATCH 2/3] arcnet: com20020: Fixup missing SLOWARB bit

[Andrea Greco]

From: Andrea Greco 

If com20020 clock is major of 40Mhz SLOWARB bit is requested.

Signed-off-by: Andrea Greco 
---
 drivers/net/arcnet/com20020.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/arcnet/com20020.c b/drivers/net/arcnet/com20020.c
index f09ea77dd6a8..abd32ed8ec9b 100644
--- a/drivers/net/arcnet/com20020.c
+++ b/drivers/net/arcnet/com20020.c
@@ -102,6 +102,10 @@ int com20020_check(struct net_device *dev)
lp->setup = lp->clockm ? 0 : (lp->clockp << 1);
lp->setup2 = (lp->clockm << 4) | 8;
 
+   // If clock is major of 40Mhz, SLOWARB bit must be set
+   if (lp->clockm > 1)
+   lp->setup2 |= SLOWARB;
+
/* CHECK: should we do this for SOHARD cards ? */
/* Enable P1Mode for backplane mode */
lp->setup = lp->setup | P1MODE;
-- 
2.14.3

[RFC PATCH 2/3] arcnet: com20020: Fixup missing SLOWARB bit

[Andrea Greco]

From: Andrea Greco 

If com20020 clock is major of 40Mhz SLOWARB bit is requested.

Signed-off-by: Andrea Greco 
---
 drivers/net/arcnet/com20020.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/arcnet/com20020.c b/drivers/net/arcnet/com20020.c
index f09ea77dd6a8..abd32ed8ec9b 100644
--- a/drivers/net/arcnet/com20020.c
+++ b/drivers/net/arcnet/com20020.c
@@ -102,6 +102,10 @@ int com20020_check(struct net_device *dev)
lp->setup = lp->clockm ? 0 : (lp->clockp << 1);
lp->setup2 = (lp->clockm << 4) | 8;
 
+   // If clock is major of 40Mhz, SLOWARB bit must be set
+   if (lp->clockm > 1)
+   lp->setup2 |= SLOWARB;
+
/* CHECK: should we do this for SOHARD cards ? */
/* Enable P1Mode for backplane mode */
lp->setup = lp->setup | P1MODE;
-- 
2.14.3

Re: [PATCH 2/8] rhashtable: remove nulls_base and related code.

[NeilBrown]

On Sat, May 05 2018, Herbert Xu wrote:

> On Fri, May 04, 2018 at 01:54:14PM +1000, NeilBrown wrote:
>> This "feature" is unused, undocumented, and untested and so
>> doesn't really belong.  If a use for the nulls marker
>> is found, all this code would need to be reviewed to
>> ensure it works as required.  It would be just as easy to
>> just add the code if/when it is needed instead.
>> 
>> This patch actually fixes a bug too.  The table resizing allows a
>> table to grow to 2^31 buckets, but the hash is truncated to 27 bits -
>> any growth beyond 2^27 is wasteful an ineffective.
>> 
>> This patch result in NULLS_MARKER(0) being used for all chains,
>> and leave the use of rht_is_a_null() to test for it.
>> 
>> Signed-off-by: NeilBrown 
>
> I disagree.  This is a fundamental requirement for the use of
> rhashtable in certain networking systems such as TCP/UDP.  So
> we know that there will be a use for this.

I can see no evidence that this is required for anything, as it isn't
use and I'm fairly sure that in it's current form - it cannot be used.

Based on my best guess about how you might intend to use it, I suspect
it would be simpler to store the address of the bucket head in the nuls
rather than the hash and a magic number.  This would make it just as
easy to detect when a search reaches the end of the wrong chain, which I
presume is the purpose.
I would find that useful myself - if the search would repeat when that
happened - as I could then use SLAB_TYPESAFE_BY_RCU.

Were we to take this approach, all the code I've removed here would
still need to be removed.

>
> As to the bug fix, please separate it out of the patch and resubmit.

I don't know how to do that.  I don't know what is safe to change
without "breaking" the nulls_base code because that code is undocumented and
unused, so unmaintainable.
In general the kernel has, I believe, a policy against keeping unused
interfaces.  While that isn't firm and universal, is seems to apply
particularly well to unusable interfaces.

Thanks,
NeilBrown


>
> Thanks,
> -- 
> Email: Herbert Xu 
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


signature.asc
Description: PGP signature

Re: [PATCH 2/8] rhashtable: remove nulls_base and related code.

[NeilBrown]

On Sat, May 05 2018, Herbert Xu wrote:

> On Fri, May 04, 2018 at 01:54:14PM +1000, NeilBrown wrote:
>> This "feature" is unused, undocumented, and untested and so
>> doesn't really belong.  If a use for the nulls marker
>> is found, all this code would need to be reviewed to
>> ensure it works as required.  It would be just as easy to
>> just add the code if/when it is needed instead.
>> 
>> This patch actually fixes a bug too.  The table resizing allows a
>> table to grow to 2^31 buckets, but the hash is truncated to 27 bits -
>> any growth beyond 2^27 is wasteful an ineffective.
>> 
>> This patch result in NULLS_MARKER(0) being used for all chains,
>> and leave the use of rht_is_a_null() to test for it.
>> 
>> Signed-off-by: NeilBrown 
>
> I disagree.  This is a fundamental requirement for the use of
> rhashtable in certain networking systems such as TCP/UDP.  So
> we know that there will be a use for this.

I can see no evidence that this is required for anything, as it isn't
use and I'm fairly sure that in it's current form - it cannot be used.

Based on my best guess about how you might intend to use it, I suspect
it would be simpler to store the address of the bucket head in the nuls
rather than the hash and a magic number.  This would make it just as
easy to detect when a search reaches the end of the wrong chain, which I
presume is the purpose.
I would find that useful myself - if the search would repeat when that
happened - as I could then use SLAB_TYPESAFE_BY_RCU.

Were we to take this approach, all the code I've removed here would
still need to be removed.

>
> As to the bug fix, please separate it out of the patch and resubmit.

I don't know how to do that.  I don't know what is safe to change
without "breaking" the nulls_base code because that code is undocumented and
unused, so unmaintainable.
In general the kernel has, I believe, a policy against keeping unused
interfaces.  While that isn't firm and universal, is seems to apply
particularly well to unusable interfaces.

Thanks,
NeilBrown


>
> Thanks,
> -- 
> Email: Herbert Xu 
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


signature.asc
Description: PGP signature

[RFC PATCH 3/3] arcnet: com20020: Add ethtool support

[Andrea Greco]

From: Andrea Greco 

Setup ethtols for export com20020 diag register

Signed-off-by: Andrea Greco 
---
 drivers/net/arcnet/com20020-isa.c|  1 +
 drivers/net/arcnet/com20020-membus.c |  1 +
 drivers/net/arcnet/com20020.c| 29 +
 drivers/net/arcnet/com20020.h|  1 +
 drivers/net/arcnet/com20020_cs.c |  1 +
 include/uapi/linux/if_arcnet.h   |  6 ++
 6 files changed, 39 insertions(+)

diff --git a/drivers/net/arcnet/com20020-isa.c 
b/drivers/net/arcnet/com20020-isa.c
index 38fa60ddaf2e..44ab6dcccb58 100644
--- a/drivers/net/arcnet/com20020-isa.c
+++ b/drivers/net/arcnet/com20020-isa.c
@@ -154,6 +154,7 @@ static int __init com20020_init(void)
dev->dev_addr[0] = node;
 
dev->netdev_ops = _netdev_ops;
+   dev->ethtool_ops = _ethtool_ops;
 
lp = netdev_priv(dev);
lp->backplane = backplane;
diff --git a/drivers/net/arcnet/com20020-membus.c 
b/drivers/net/arcnet/com20020-membus.c
index 6e4a2f3a84f7..9eead734a3cf 100644
--- a/drivers/net/arcnet/com20020-membus.c
+++ b/drivers/net/arcnet/com20020-membus.c
@@ -91,6 +91,7 @@ static int com20020_probe(struct platform_device *pdev)
 
dev = alloc_arcdev(NULL);// Let autoassign name arc%d
dev->netdev_ops = _netdev_ops;
+   dev->ethtool_ops = _ethtool_ops;
lp = netdev_priv(dev);
 
lp->card_flags = ARC_CAN_10MBIT;/* pretend all of them can 10Mbit */
diff --git a/drivers/net/arcnet/com20020.c b/drivers/net/arcnet/com20020.c
index abd32ed8ec9b..2089b45e81c8 100644
--- a/drivers/net/arcnet/com20020.c
+++ b/drivers/net/arcnet/com20020.c
@@ -201,6 +201,34 @@ const struct net_device_ops com20020_netdev_ops = {
.ndo_set_rx_mode = com20020_set_mc_list,
 };
 
+static int com20020_ethtool_regs_len(struct net_device *netdev)
+{
+   return sizeof(struct com20020_ethtool_regs);
+}
+
+static void com20020_ethtool_regs_read(struct net_device *dev,
+  struct ethtool_regs *regs, void *p)
+{
+   struct arcnet_local *lp;
+   struct com20020_ethtool_regs *com_reg;
+
+   lp = netdev_priv(dev);
+   memset(p, 0, sizeof(struct com20020_ethtool_regs));
+
+   regs->version = 1;
+
+   com_reg = p;
+
+   com_reg->status = lp->hw.status(dev) & 0xFF;
+   com_reg->diag_register = (lp->hw.status(dev) >> 8) & 0xFF;
+   com_reg->reconf_count = lp->num_recons;
+}
+
+const struct ethtool_ops com20020_ethtool_ops = {
+   .get_regs = com20020_ethtool_regs_read,
+   .get_regs_len  = com20020_ethtool_regs_len,
+};
+
 /* Set up the struct net_device associated with this card.  Called after
  * probing succeeds.
  */
@@ -402,6 +430,7 @@ static void com20020_set_mc_list(struct net_device *dev)
 EXPORT_SYMBOL(com20020_check);
 EXPORT_SYMBOL(com20020_found);
 EXPORT_SYMBOL(com20020_netdev_ops);
+EXPORT_SYMBOL(com20020_ethtool_ops);
 #endif
 
 MODULE_LICENSE("GPL");
diff --git a/drivers/net/arcnet/com20020.h b/drivers/net/arcnet/com20020.h
index 0bcc5d0a6903..a1024c8f8a1f 100644
--- a/drivers/net/arcnet/com20020.h
+++ b/drivers/net/arcnet/com20020.h
@@ -31,6 +31,7 @@
 int com20020_check(struct net_device *dev);
 int com20020_found(struct net_device *dev, int shared);
 extern const struct net_device_ops com20020_netdev_ops;
+extern const struct ethtool_ops com20020_ethtool_ops;
 
 /* The number of low I/O ports used by the card. */
 #define ARCNET_TOTAL_SIZE 8
diff --git a/drivers/net/arcnet/com20020_cs.c b/drivers/net/arcnet/com20020_cs.c
index cf607ffcf358..ae64f436fd54 100644
--- a/drivers/net/arcnet/com20020_cs.c
+++ b/drivers/net/arcnet/com20020_cs.c
@@ -233,6 +233,7 @@ static int com20020_config(struct pcmcia_device *link)
}
 
dev->irq = link->irq;
+   dev->ethtool_ops = _ethtool_ops;
 
ret = pcmcia_enable_device(link);
if (ret)
diff --git a/include/uapi/linux/if_arcnet.h b/include/uapi/linux/if_arcnet.h
index 683878036d76..790c0fa7386d 100644
--- a/include/uapi/linux/if_arcnet.h
+++ b/include/uapi/linux/if_arcnet.h
@@ -127,4 +127,10 @@ struct archdr {
} soft;
 };
 
+struct com20020_ethtool_regs {
+   __u8 status;
+   __u8 diag_register;
+   __u32 reconf_count;
+};
+
 #endif /* _LINUX_IF_ARCNET_H */
-- 
2.14.3

[RFC PATCH 1/3] arcnet: com20020: Add memory map of com20020

[Andrea Greco]

From: Andrea Greco 

Add support for com20022I/com20020, memory mapped chip version.
Support bus: Intel 80xx and Motorola 68xx.
Bus size: Only 8 bit bus size is supported.
Added related device tree bindings

Signed-off-by: Andrea Greco 
---
 .../devicetree/bindings/net/smsc-com20020.txt  |  23 +++
 drivers/net/arcnet/Kconfig |  12 +-
 drivers/net/arcnet/Makefile|   1 +
 drivers/net/arcnet/arcdevice.h |  27 ++-
 drivers/net/arcnet/com20020-membus.c   | 191 +
 drivers/net/arcnet/com20020.c  |   9 +-
 6 files changed, 253 insertions(+), 10 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/net/smsc-com20020.txt
 create mode 100644 drivers/net/arcnet/com20020-membus.c

diff --git a/Documentation/devicetree/bindings/net/smsc-com20020.txt 
b/Documentation/devicetree/bindings/net/smsc-com20020.txt
new file mode 100644
index ..39c5b19c55af
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/smsc-com20020.txt
@@ -0,0 +1,23 @@
+SMSC com20020, com20022I
+
+timeout: Arcnet timeout, checkout datashet
+clockp: Clock Prescaler, checkout datashet
+clockm: Clock multiplier, checkout datasheet
+
+phy-reset-gpios: Chip reset ppin
+phy-irq-gpios: Chip irq pin
+
+com20020_A@0 {
+compatible = "smsc,com20020";
+
+   timeout = <0x3>;
+   backplane = <0x0>;
+
+   clockp = <0x0>;
+   clockm = <0x3>;
+
+   phy-reset-gpios = < 21 GPIO_ACTIVE_LOW>;
+   phy-irq-gpios = < 10 GPIO_ACTIVE_LOW>;
+
+   status = "okay";
+};
diff --git a/drivers/net/arcnet/Kconfig b/drivers/net/arcnet/Kconfig
index 39bd16f3f86d..d39faf45be1e 100644
--- a/drivers/net/arcnet/Kconfig
+++ b/drivers/net/arcnet/Kconfig
@@ -3,7 +3,7 @@
 #
 
 menuconfig ARCNET
-   depends on NETDEVICES && (ISA || PCI || PCMCIA)
+   depends on NETDEVICES
tristate "ARCnet support"
---help---
  If you have a network card of this type, say Y and check out the
@@ -129,5 +129,15 @@ config ARCNET_COM20020_CS
 
  To compile this driver as a module, choose M here: the module will be
  called com20020_cs.  If unsure, say N.
+config ARCNET_COM20020_MEMORY_BUS
+   bool "Support for COM20020 on external memory"
+   depends on ARCNET_COM20020 && !(ARCNET_COM20020_PCI || 
ARCNET_COM20020_ISA || ARCNET_COM20020_CS)
+   help
+ Say Y here if on your custom board mount com20020 or friends.
+
+ Com20022I support arcnet bus 10Mbitps.
+ This driver support only 8bit, and DMA is not supported is attached 
on your board at external interface bus.
+ Supported bus Intel80xx / Motorola 68xx.
+ This driver not work with other com20020 module: PCI or PCMCIA 
compiled as [M].
 
 endif # ARCNET
diff --git a/drivers/net/arcnet/Makefile b/drivers/net/arcnet/Makefile
index 53525e8ea130..19425c1e06f4 100644
--- a/drivers/net/arcnet/Makefile
+++ b/drivers/net/arcnet/Makefile
@@ -14,3 +14,4 @@ obj-$(CONFIG_ARCNET_COM20020) += com20020.o
 obj-$(CONFIG_ARCNET_COM20020_ISA) += com20020-isa.o
 obj-$(CONFIG_ARCNET_COM20020_PCI) += com20020-pci.o
 obj-$(CONFIG_ARCNET_COM20020_CS) += com20020_cs.o
+obj-$(CONFIG_ARCNET_COM20020_MEMORY_BUS) += com20020-membus.o
diff --git a/drivers/net/arcnet/arcdevice.h b/drivers/net/arcnet/arcdevice.h
index d09b2b46ab63..16c608269cca 100644
--- a/drivers/net/arcnet/arcdevice.h
+++ b/drivers/net/arcnet/arcdevice.h
@@ -201,7 +201,7 @@ struct ArcProto {
void (*rx)(struct net_device *dev, int bufnum,
   struct archdr *pkthdr, int length);
int (*build_header)(struct sk_buff *skb, struct net_device *dev,
-   unsigned short ethproto, uint8_t daddr);
+   unsigned short ethproto, uint8_t daddr);
 
/* these functions return '1' if the skb can now be freed */
int (*prepare_tx)(struct net_device *dev, struct archdr *pkt,
@@ -326,9 +326,9 @@ struct arcnet_local {
void (*recontrigger) (struct net_device * dev, int enable);
 
void (*copy_to_card)(struct net_device *dev, int bufnum,
-int offset, void *buf, int count);
+int offset, void *buf, int count);
void (*copy_from_card)(struct net_device *dev, int bufnum,
-  int offset, void *buf, int count);
+  int offset, void *buf, int count);
} hw;
 
void __iomem *mem_start;/* pointer to ioremap'ed MMIO */
@@ -360,7 +360,7 @@ struct net_device *alloc_arcdev(const char *name);
 int arcnet_open(struct net_device *dev);
 int arcnet_close(struct net_device *dev);
 netdev_tx_t arcnet_send_packet(struct sk_buff *skb,
-  struct net_device *dev);
+  struct net_device *dev);
 

[RFC PATCH 1/3] arcnet: com20020: Add memory map of com20020

[Andrea Greco]

From: Andrea Greco 

Add support for com20022I/com20020, memory mapped chip version.
Support bus: Intel 80xx and Motorola 68xx.
Bus size: Only 8 bit bus size is supported.
Added related device tree bindings

Signed-off-by: Andrea Greco 
---
 .../devicetree/bindings/net/smsc-com20020.txt  |  23 +++
 drivers/net/arcnet/Kconfig |  12 +-
 drivers/net/arcnet/Makefile|   1 +
 drivers/net/arcnet/arcdevice.h |  27 ++-
 drivers/net/arcnet/com20020-membus.c   | 191 +
 drivers/net/arcnet/com20020.c  |   9 +-
 6 files changed, 253 insertions(+), 10 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/net/smsc-com20020.txt
 create mode 100644 drivers/net/arcnet/com20020-membus.c

diff --git a/Documentation/devicetree/bindings/net/smsc-com20020.txt 
b/Documentation/devicetree/bindings/net/smsc-com20020.txt
new file mode 100644
index ..39c5b19c55af
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/smsc-com20020.txt
@@ -0,0 +1,23 @@
+SMSC com20020, com20022I
+
+timeout: Arcnet timeout, checkout datashet
+clockp: Clock Prescaler, checkout datashet
+clockm: Clock multiplier, checkout datasheet
+
+phy-reset-gpios: Chip reset ppin
+phy-irq-gpios: Chip irq pin
+
+com20020_A@0 {
+compatible = "smsc,com20020";
+
+   timeout = <0x3>;
+   backplane = <0x0>;
+
+   clockp = <0x0>;
+   clockm = <0x3>;
+
+   phy-reset-gpios = < 21 GPIO_ACTIVE_LOW>;
+   phy-irq-gpios = < 10 GPIO_ACTIVE_LOW>;
+
+   status = "okay";
+};
diff --git a/drivers/net/arcnet/Kconfig b/drivers/net/arcnet/Kconfig
index 39bd16f3f86d..d39faf45be1e 100644
--- a/drivers/net/arcnet/Kconfig
+++ b/drivers/net/arcnet/Kconfig
@@ -3,7 +3,7 @@
 #
 
 menuconfig ARCNET
-   depends on NETDEVICES && (ISA || PCI || PCMCIA)
+   depends on NETDEVICES
tristate "ARCnet support"
---help---
  If you have a network card of this type, say Y and check out the
@@ -129,5 +129,15 @@ config ARCNET_COM20020_CS
 
  To compile this driver as a module, choose M here: the module will be
  called com20020_cs.  If unsure, say N.
+config ARCNET_COM20020_MEMORY_BUS
+   bool "Support for COM20020 on external memory"
+   depends on ARCNET_COM20020 && !(ARCNET_COM20020_PCI || 
ARCNET_COM20020_ISA || ARCNET_COM20020_CS)
+   help
+ Say Y here if on your custom board mount com20020 or friends.
+
+ Com20022I support arcnet bus 10Mbitps.
+ This driver support only 8bit, and DMA is not supported is attached 
on your board at external interface bus.
+ Supported bus Intel80xx / Motorola 68xx.
+ This driver not work with other com20020 module: PCI or PCMCIA 
compiled as [M].
 
 endif # ARCNET
diff --git a/drivers/net/arcnet/Makefile b/drivers/net/arcnet/Makefile
index 53525e8ea130..19425c1e06f4 100644
--- a/drivers/net/arcnet/Makefile
+++ b/drivers/net/arcnet/Makefile
@@ -14,3 +14,4 @@ obj-$(CONFIG_ARCNET_COM20020) += com20020.o
 obj-$(CONFIG_ARCNET_COM20020_ISA) += com20020-isa.o
 obj-$(CONFIG_ARCNET_COM20020_PCI) += com20020-pci.o
 obj-$(CONFIG_ARCNET_COM20020_CS) += com20020_cs.o
+obj-$(CONFIG_ARCNET_COM20020_MEMORY_BUS) += com20020-membus.o
diff --git a/drivers/net/arcnet/arcdevice.h b/drivers/net/arcnet/arcdevice.h
index d09b2b46ab63..16c608269cca 100644
--- a/drivers/net/arcnet/arcdevice.h
+++ b/drivers/net/arcnet/arcdevice.h
@@ -201,7 +201,7 @@ struct ArcProto {
void (*rx)(struct net_device *dev, int bufnum,
   struct archdr *pkthdr, int length);
int (*build_header)(struct sk_buff *skb, struct net_device *dev,
-   unsigned short ethproto, uint8_t daddr);
+   unsigned short ethproto, uint8_t daddr);
 
/* these functions return '1' if the skb can now be freed */
int (*prepare_tx)(struct net_device *dev, struct archdr *pkt,
@@ -326,9 +326,9 @@ struct arcnet_local {
void (*recontrigger) (struct net_device * dev, int enable);
 
void (*copy_to_card)(struct net_device *dev, int bufnum,
-int offset, void *buf, int count);
+int offset, void *buf, int count);
void (*copy_from_card)(struct net_device *dev, int bufnum,
-  int offset, void *buf, int count);
+  int offset, void *buf, int count);
} hw;
 
void __iomem *mem_start;/* pointer to ioremap'ed MMIO */
@@ -360,7 +360,7 @@ struct net_device *alloc_arcdev(const char *name);
 int arcnet_open(struct net_device *dev);
 int arcnet_close(struct net_device *dev);
 netdev_tx_t arcnet_send_packet(struct sk_buff *skb,
-  struct net_device *dev);
+  struct net_device *dev);
 void arcnet_timeout(struct net_device 

[RFC PATCH 3/3] arcnet: com20020: Add ethtool support

[Andrea Greco]

From: Andrea Greco 

Setup ethtols for export com20020 diag register

Signed-off-by: Andrea Greco 
---
 drivers/net/arcnet/com20020-isa.c|  1 +
 drivers/net/arcnet/com20020-membus.c |  1 +
 drivers/net/arcnet/com20020.c| 29 +
 drivers/net/arcnet/com20020.h|  1 +
 drivers/net/arcnet/com20020_cs.c |  1 +
 include/uapi/linux/if_arcnet.h   |  6 ++
 6 files changed, 39 insertions(+)

diff --git a/drivers/net/arcnet/com20020-isa.c 
b/drivers/net/arcnet/com20020-isa.c
index 38fa60ddaf2e..44ab6dcccb58 100644
--- a/drivers/net/arcnet/com20020-isa.c
+++ b/drivers/net/arcnet/com20020-isa.c
@@ -154,6 +154,7 @@ static int __init com20020_init(void)
dev->dev_addr[0] = node;
 
dev->netdev_ops = _netdev_ops;
+   dev->ethtool_ops = _ethtool_ops;
 
lp = netdev_priv(dev);
lp->backplane = backplane;
diff --git a/drivers/net/arcnet/com20020-membus.c 
b/drivers/net/arcnet/com20020-membus.c
index 6e4a2f3a84f7..9eead734a3cf 100644
--- a/drivers/net/arcnet/com20020-membus.c
+++ b/drivers/net/arcnet/com20020-membus.c
@@ -91,6 +91,7 @@ static int com20020_probe(struct platform_device *pdev)
 
dev = alloc_arcdev(NULL);// Let autoassign name arc%d
dev->netdev_ops = _netdev_ops;
+   dev->ethtool_ops = _ethtool_ops;
lp = netdev_priv(dev);
 
lp->card_flags = ARC_CAN_10MBIT;/* pretend all of them can 10Mbit */
diff --git a/drivers/net/arcnet/com20020.c b/drivers/net/arcnet/com20020.c
index abd32ed8ec9b..2089b45e81c8 100644
--- a/drivers/net/arcnet/com20020.c
+++ b/drivers/net/arcnet/com20020.c
@@ -201,6 +201,34 @@ const struct net_device_ops com20020_netdev_ops = {
.ndo_set_rx_mode = com20020_set_mc_list,
 };
 
+static int com20020_ethtool_regs_len(struct net_device *netdev)
+{
+   return sizeof(struct com20020_ethtool_regs);
+}
+
+static void com20020_ethtool_regs_read(struct net_device *dev,
+  struct ethtool_regs *regs, void *p)
+{
+   struct arcnet_local *lp;
+   struct com20020_ethtool_regs *com_reg;
+
+   lp = netdev_priv(dev);
+   memset(p, 0, sizeof(struct com20020_ethtool_regs));
+
+   regs->version = 1;
+
+   com_reg = p;
+
+   com_reg->status = lp->hw.status(dev) & 0xFF;
+   com_reg->diag_register = (lp->hw.status(dev) >> 8) & 0xFF;
+   com_reg->reconf_count = lp->num_recons;
+}
+
+const struct ethtool_ops com20020_ethtool_ops = {
+   .get_regs = com20020_ethtool_regs_read,
+   .get_regs_len  = com20020_ethtool_regs_len,
+};
+
 /* Set up the struct net_device associated with this card.  Called after
  * probing succeeds.
  */
@@ -402,6 +430,7 @@ static void com20020_set_mc_list(struct net_device *dev)
 EXPORT_SYMBOL(com20020_check);
 EXPORT_SYMBOL(com20020_found);
 EXPORT_SYMBOL(com20020_netdev_ops);
+EXPORT_SYMBOL(com20020_ethtool_ops);
 #endif
 
 MODULE_LICENSE("GPL");
diff --git a/drivers/net/arcnet/com20020.h b/drivers/net/arcnet/com20020.h
index 0bcc5d0a6903..a1024c8f8a1f 100644
--- a/drivers/net/arcnet/com20020.h
+++ b/drivers/net/arcnet/com20020.h
@@ -31,6 +31,7 @@
 int com20020_check(struct net_device *dev);
 int com20020_found(struct net_device *dev, int shared);
 extern const struct net_device_ops com20020_netdev_ops;
+extern const struct ethtool_ops com20020_ethtool_ops;
 
 /* The number of low I/O ports used by the card. */
 #define ARCNET_TOTAL_SIZE 8
diff --git a/drivers/net/arcnet/com20020_cs.c b/drivers/net/arcnet/com20020_cs.c
index cf607ffcf358..ae64f436fd54 100644
--- a/drivers/net/arcnet/com20020_cs.c
+++ b/drivers/net/arcnet/com20020_cs.c
@@ -233,6 +233,7 @@ static int com20020_config(struct pcmcia_device *link)
}
 
dev->irq = link->irq;
+   dev->ethtool_ops = _ethtool_ops;
 
ret = pcmcia_enable_device(link);
if (ret)
diff --git a/include/uapi/linux/if_arcnet.h b/include/uapi/linux/if_arcnet.h
index 683878036d76..790c0fa7386d 100644
--- a/include/uapi/linux/if_arcnet.h
+++ b/include/uapi/linux/if_arcnet.h
@@ -127,4 +127,10 @@ struct archdr {
} soft;
 };
 
+struct com20020_ethtool_regs {
+   __u8 status;
+   __u8 diag_register;
+   __u32 reconf_count;
+};
+
 #endif /* _LINUX_IF_ARCNET_H */
-- 
2.14.3

Re: [PATCH] ANDROID: binder: remove 32-bit binder interface.

[kbuild test robot]

Hi Martijn,

I love your patch! Yet something to improve:

[auto build test ERROR on staging/staging-testing]
[also build test ERROR on v4.17-rc3 next-20180504]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Martijn-Coenen/ANDROID-binder-remove-32-bit-binder-interface/20180505-130632
config: m68k-allmodconfig (attached as .config)
compiler: m68k-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=m68k 

All errors (new ones prefixed by >>):

   drivers/android/binder.o: In function `binder_thread_write':
>> binder.c:(.text+0x6a16): undefined reference to `__get_user_bad'
   binder.c:(.text+0x6c9a): undefined reference to `__get_user_bad'
   binder.c:(.text+0x701e): undefined reference to `__get_user_bad'
   binder.c:(.text+0x7414): undefined reference to `__get_user_bad'

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH] ANDROID: binder: remove 32-bit binder interface.

[kbuild test robot]

Hi Martijn,

I love your patch! Yet something to improve:

[auto build test ERROR on staging/staging-testing]
[also build test ERROR on v4.17-rc3 next-20180504]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Martijn-Coenen/ANDROID-binder-remove-32-bit-binder-interface/20180505-130632
config: m68k-allmodconfig (attached as .config)
compiler: m68k-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=m68k 

All errors (new ones prefixed by >>):

   drivers/android/binder.o: In function `binder_thread_write':
>> binder.c:(.text+0x6a16): undefined reference to `__get_user_bad'
   binder.c:(.text+0x6c9a): undefined reference to `__get_user_bad'
   binder.c:(.text+0x701e): undefined reference to `__get_user_bad'
   binder.c:(.text+0x7414): undefined reference to `__get_user_bad'

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip