Re: [PATCH v2] ACPI: NFIT: limit string attribute write
On 11/07/2023 16:28, Dave Jiang wrote:
On 7/11/23 02:37, Ben Dooks wrote:
If we're writing what could be an arbitrary sized string into an
attribute
we should probably use sysfs_emit() just to be safe. Most of the other
attriubtes are some sort of integer so unlikely to be an issue so not
altered at this time.
Signed-off-by: Ben Dooks
---
v2:
- use sysfs_emit() instead of snprintf.
---
drivers/acpi/nfit/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
index 9213b426b125..d7e9d9cd16d2 100644
--- a/drivers/acpi/nfit/core.c
+++ b/drivers/acpi/nfit/core.c
@@ -1579,7 +1579,7 @@ static ssize_t id_show(struct device *dev,
{
struct nfit_mem *nfit_mem = to_nfit_mem(dev);
- return sprintf(buf, "%s\n", nfit_mem->id);
+ return snprintf(buf, PAGE_SIZE, "%s\n", nfit_mem->id);
Doesn't look like you updated your patch with your new changes
Ooops, sorry about that. Will sort that for v2++
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
https://www.codethink.co.uk/privacy.html
Re: [PATCH] ACPI: NFIT: limit string attribute write
On 11/07/2023 10:22, Ben Dooks wrote:
If we're writing what could be an arbitrary sized string into an attribute
we should probably use sysfs_emit() just to be safe. Most of the other
attriubtes are some sort of integer so unlikely to be an issue so not
altered at this time.
Signed-off-by: Ben Dooks
---
v2:
- use sysfs_emit() instead of snprintf.
---
drivers/acpi/nfit/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
index 9213b426b125..d7e9d9cd16d2 100644
--- a/drivers/acpi/nfit/core.c
+++ b/drivers/acpi/nfit/core.c
@@ -1579,7 +1579,7 @@ static ssize_t id_show(struct device *dev,
{
struct nfit_mem *nfit_mem = to_nfit_mem(dev);
- return sprintf(buf, "%s\n", nfit_mem->id);
+ return snprintf(buf, PAGE_SIZE, "%s\n", nfit_mem->id);
}
static DEVICE_ATTR_RO(id);
whoops, forgot to add before hitting ammend...
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
https://www.codethink.co.uk/privacy.html
[PATCH v2] ACPI: NFIT: limit string attribute write
If we're writing what could be an arbitrary sized string into an attribute
we should probably use sysfs_emit() just to be safe. Most of the other
attriubtes are some sort of integer so unlikely to be an issue so not
altered at this time.
Signed-off-by: Ben Dooks
---
v2:
- use sysfs_emit() instead of snprintf.
---
drivers/acpi/nfit/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
index 9213b426b125..d7e9d9cd16d2 100644
--- a/drivers/acpi/nfit/core.c
+++ b/drivers/acpi/nfit/core.c
@@ -1579,7 +1579,7 @@ static ssize_t id_show(struct device *dev,
{
struct nfit_mem *nfit_mem = to_nfit_mem(dev);
- return sprintf(buf, "%s\n", nfit_mem->id);
+ return snprintf(buf, PAGE_SIZE, "%s\n", nfit_mem->id);
}
static DEVICE_ATTR_RO(id);
--
2.40.1
[PATCH] ACPI: NFIT: limit string attribute write
If we're writing what could be an arbitrary sized string into an attribute
we should probably use sysfs_emit() just to be safe. Most of the other
attriubtes are some sort of integer so unlikely to be an issue so not
altered at this time.
Signed-off-by: Ben Dooks
---
v2:
- use sysfs_emit() instead of snprintf.
---
drivers/acpi/nfit/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
index 9213b426b125..d7e9d9cd16d2 100644
--- a/drivers/acpi/nfit/core.c
+++ b/drivers/acpi/nfit/core.c
@@ -1579,7 +1579,7 @@ static ssize_t id_show(struct device *dev,
{
struct nfit_mem *nfit_mem = to_nfit_mem(dev);
- return sprintf(buf, "%s\n", nfit_mem->id);
+ return snprintf(buf, PAGE_SIZE, "%s\n", nfit_mem->id);
}
static DEVICE_ATTR_RO(id);
--
2.40.1
Re: [PATCH] ACPI: NFIT: limit string attribute write
On 05/07/2023 19:34, Dave Jiang wrote:
On 7/4/23 01:17, Ben Dooks wrote:
If we're writing what could be an arbitrary sized string into an
attribute
we should probably use snprintf() just to be safe. Most of the other
attriubtes are some sort of integer so unlikely to be an issue so not
altered at this time.
Signed-off-by: Ben Dooks
---
drivers/acpi/nfit/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
index 9213b426b125..d7e9d9cd16d2 100644
--- a/drivers/acpi/nfit/core.c
+++ b/drivers/acpi/nfit/core.c
@@ -1579,7 +1579,7 @@ static ssize_t id_show(struct device *dev,
{
struct nfit_mem *nfit_mem = to_nfit_mem(dev);
- return sprintf(buf, "%s\n", nfit_mem->id);
+ return snprintf(buf, PAGE_SIZE, "%s\n", nfit_mem->id);
Why not just convert it to sysfs_emit()?
I'll look into that.
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
https://www.codethink.co.uk/privacy.html
[PATCH] ACPI: NFIT: limit string attribute write
If we're writing what could be an arbitrary sized string into an attribute
we should probably use snprintf() just to be safe. Most of the other
attriubtes are some sort of integer so unlikely to be an issue so not
altered at this time.
Signed-off-by: Ben Dooks
---
drivers/acpi/nfit/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
index 9213b426b125..d7e9d9cd16d2 100644
--- a/drivers/acpi/nfit/core.c
+++ b/drivers/acpi/nfit/core.c
@@ -1579,7 +1579,7 @@ static ssize_t id_show(struct device *dev,
{
struct nfit_mem *nfit_mem = to_nfit_mem(dev);
- return sprintf(buf, "%s\n", nfit_mem->id);
+ return snprintf(buf, PAGE_SIZE, "%s\n", nfit_mem->id);
}
static DEVICE_ATTR_RO(id);
--
2.40.1
[PATCH] ACPICA: actbl2: change to be16/be32 types for big endian data
Some of the fields in struct acpi_nfit_control_region are used in big
endian format, and thus are generatng warnings from spare where the
member is passed to one of the conversion functions.
Fix the following sparse warnings by changing the data types:
drivers/acpi/nfit/core.c:1403:41: warning: cast to restricted __be16
drivers/acpi/nfit/core.c:1403:41: warning: cast to restricted __be16
drivers/acpi/nfit/core.c:1403:41: warning: cast to restricted __be16
drivers/acpi/nfit/core.c:1403:41: warning: cast to restricted __be16
drivers/acpi/nfit/core.c:1412:41: warning: cast to restricted __be16
drivers/acpi/nfit/core.c:1412:41: warning: cast to restricted __be16
drivers/acpi/nfit/core.c:1412:41: warning: cast to restricted __be16
drivers/acpi/nfit/core.c:1412:41: warning: cast to restricted __be16
drivers/acpi/nfit/core.c:1421:41: warning: cast to restricted __be16
drivers/acpi/nfit/core.c:1421:41: warning: cast to restricted __be16
drivers/acpi/nfit/core.c:1421:41: warning: cast to restricted __be16
drivers/acpi/nfit/core.c:1421:41: warning: cast to restricted __be16
drivers/acpi/nfit/core.c:1430:41: warning: cast to restricted __be16
drivers/acpi/nfit/core.c:1430:41: warning: cast to restricted __be16
drivers/acpi/nfit/core.c:1430:41: warning: cast to restricted __be16
drivers/acpi/nfit/core.c:1430:41: warning: cast to restricted __be16
drivers/acpi/nfit/core.c:1440:25: warning: cast to restricted __be16
drivers/acpi/nfit/core.c:1440:25: warning: cast to restricted __be16
drivers/acpi/nfit/core.c:1440:25: warning: cast to restricted __be16
drivers/acpi/nfit/core.c:1440:25: warning: cast to restricted __be16
drivers/acpi/nfit/core.c:1449:41: warning: cast to restricted __be16
drivers/acpi/nfit/core.c:1449:41: warning: cast to restricted __be16
drivers/acpi/nfit/core.c:1449:41: warning: cast to restricted __be16
drivers/acpi/nfit/core.c:1449:41: warning: cast to restricted __be16
drivers/acpi/nfit/core.c:1468:41: warning: cast to restricted __le16
drivers/acpi/nfit/core.c:1502:41: warning: cast to restricted __le16
drivers/acpi/nfit/core.c:1527:41: warning: cast to restricted __be32
drivers/acpi/nfit/core.c:1527:41: warning: cast to restricted __be32
drivers/acpi/nfit/core.c:1527:41: warning: cast to restricted __be32
drivers/acpi/nfit/core.c:1527:41: warning: cast to restricted __be32
drivers/acpi/nfit/core.c:1527:41: warning: cast to restricted __be32
drivers/acpi/nfit/core.c:1527:41: warning: cast to restricted __be32
drivers/acpi/nfit/core.c:1792:33: warning: cast to restricted __be16
drivers/acpi/nfit/core.c:1792:33: warning: cast to restricted __be16
drivers/acpi/nfit/core.c:1792:33: warning: cast to restricted __be16
drivers/acpi/nfit/core.c:1792:33: warning: cast to restricted __be16
drivers/acpi/nfit/core.c:1794:33: warning: cast to restricted __be16
drivers/acpi/nfit/core.c:1794:33: warning: cast to restricted __be16
drivers/acpi/nfit/core.c:1794:33: warning: cast to restricted __be16
drivers/acpi/nfit/core.c:1794:33: warning: cast to restricted __be16
drivers/acpi/nfit/core.c:1795:33: warning: cast to restricted __be32
drivers/acpi/nfit/core.c:1795:33: warning: cast to restricted __be32
drivers/acpi/nfit/core.c:1795:33: warning: cast to restricted __be32
drivers/acpi/nfit/core.c:1795:33: warning: cast to restricted __be32
drivers/acpi/nfit/core.c:1795:33: warning: cast to restricted __be32
drivers/acpi/nfit/core.c:1795:33: warning: cast to restricted __be32
drivers/acpi/nfit/core.c:1798:33: warning: cast to restricted __be16
drivers/acpi/nfit/core.c:1798:33: warning: cast to restricted __be16
drivers/acpi/nfit/core.c:1798:33: warning: cast to restricted __be16
drivers/acpi/nfit/core.c:1798:33: warning: cast to restricted __be16
drivers/acpi/nfit/core.c:1799:33: warning: cast to restricted __be32
drivers/acpi/nfit/core.c:1799:33: warning: cast to restricted __be32
drivers/acpi/nfit/core.c:1799:33: warning: cast to restricted __be32
drivers/acpi/nfit/core.c:1799:33: warning: cast to restricted __be32
drivers/acpi/nfit/core.c:1799:33: warning: cast to restricted __be32
drivers/acpi/nfit/core.c:1799:33: warning: cast to restricted __be32
Signed-off-by: Ben Dooks
---
drivers/acpi/nfit/core.c | 8
include/acpi/actbl2.h| 18 +-
2 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
index 07204d482968..0fcc247fdfac 100644
--- a/drivers/acpi/nfit/core.c
+++ b/drivers/acpi/nfit/core.c
@@ -2194,15 +2194,15 @@ static const struct attribute_group
*acpi_nfit_region_attribute_groups[] = {
/* enough info to uniquely specify an interleave set */
struct nfit_set_info {
u64 region_offset;
- u32 serial_number;
+ __be32 serial_number;
u32 pad;
};
struct nfit_set_info2 {
u64 region_offset;
- u32 serial_number;
- u16 vendor_id;
- u16 manufacturing_date;
+ __be32 serial_number;
+ __be16 vendor_id;
+ __be16 manufacturing_date;
u8
[PATCH] ACPI: NFIT: add helper to_nfit_mem() to take device to nfit_mem
Add a quick helper to just do struct device to the struct nfit_mem
field it should be referencing. This reduces the number of code
lines in some of the followgn code as it removes the intermediate
struct nvdimm.
Signed-off-by: Ben Dooks
---
drivers/acpi/nfit/core.c | 27 +--
1 file changed, 13 insertions(+), 14 deletions(-)
diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
index 0fcc247fdfac..9213b426b125 100644
--- a/drivers/acpi/nfit/core.c
+++ b/drivers/acpi/nfit/core.c
@@ -1361,18 +1361,22 @@ static const struct attribute_group
*acpi_nfit_attribute_groups[] = {
NULL,
};
-static struct acpi_nfit_memory_map *to_nfit_memdev(struct device *dev)
+static struct nfit_mem *to_nfit_mem(struct device *dev)
{
struct nvdimm *nvdimm = to_nvdimm(dev);
- struct nfit_mem *nfit_mem = nvdimm_provider_data(nvdimm);
+ return nvdimm_provider_data(nvdimm);
+}
+
+static struct acpi_nfit_memory_map *to_nfit_memdev(struct device *dev)
+{
+ struct nfit_mem *nfit_mem = to_nfit_mem(dev);
return __to_nfit_memdev(nfit_mem);
}
static struct acpi_nfit_control_region *to_nfit_dcr(struct device *dev)
{
- struct nvdimm *nvdimm = to_nvdimm(dev);
- struct nfit_mem *nfit_mem = nvdimm_provider_data(nvdimm);
+ struct nfit_mem *nfit_mem = to_nfit_mem(dev);
return nfit_mem->dcr;
}
@@ -1531,8 +1535,7 @@ static DEVICE_ATTR_RO(serial);
static ssize_t family_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
- struct nvdimm *nvdimm = to_nvdimm(dev);
- struct nfit_mem *nfit_mem = nvdimm_provider_data(nvdimm);
+ struct nfit_mem *nfit_mem = to_nfit_mem(dev);
if (nfit_mem->family < 0)
return -ENXIO;
@@ -1543,8 +1546,7 @@ static DEVICE_ATTR_RO(family);
static ssize_t dsm_mask_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
- struct nvdimm *nvdimm = to_nvdimm(dev);
- struct nfit_mem *nfit_mem = nvdimm_provider_data(nvdimm);
+ struct nfit_mem *nfit_mem = to_nfit_mem(dev);
if (nfit_mem->family < 0)
return -ENXIO;
@@ -1555,8 +1557,7 @@ static DEVICE_ATTR_RO(dsm_mask);
static ssize_t flags_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
- struct nvdimm *nvdimm = to_nvdimm(dev);
- struct nfit_mem *nfit_mem = nvdimm_provider_data(nvdimm);
+ struct nfit_mem *nfit_mem = to_nfit_mem(dev);
u16 flags = __to_nfit_memdev(nfit_mem)->flags;
if (test_bit(NFIT_MEM_DIRTY, _mem->flags))
@@ -1576,8 +1577,7 @@ static DEVICE_ATTR_RO(flags);
static ssize_t id_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
- struct nvdimm *nvdimm = to_nvdimm(dev);
- struct nfit_mem *nfit_mem = nvdimm_provider_data(nvdimm);
+ struct nfit_mem *nfit_mem = to_nfit_mem(dev);
return sprintf(buf, "%s\n", nfit_mem->id);
}
@@ -1586,8 +1586,7 @@ static DEVICE_ATTR_RO(id);
static ssize_t dirty_shutdown_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
- struct nvdimm *nvdimm = to_nvdimm(dev);
- struct nfit_mem *nfit_mem = nvdimm_provider_data(nvdimm);
+ struct nfit_mem *nfit_mem = to_nfit_mem(dev);
return sprintf(buf, "%d\n", nfit_mem->dirty_shutdown);
}
--
2.40.1
[PATCH] nvdimm: make nd_class variable static
The nd_class is not used outside of drivers/nvdimm/bus.c and thus sparse is generating the following warning. Remove this by making it static: drivers/nvdimm/bus.c:28:14: warning: symbol 'nd_class' was not declared. Should it be static? Signed-off-by: Ben Dooks --- drivers/nvdimm/bus.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/nvdimm/bus.c b/drivers/nvdimm/bus.c index 954dbc105fc8..5852fe290523 100644 --- a/drivers/nvdimm/bus.c +++ b/drivers/nvdimm/bus.c @@ -25,7 +25,7 @@ int nvdimm_major; static int nvdimm_bus_major; -struct class *nd_class; +static struct class *nd_class; static DEFINE_IDA(nd_ida); static int to_nd_device_type(const struct device *dev) -- 2.39.2
[PATCH] nvdimm: make security_show static
The security_show function is not used outsid of drivers/nvdimm/dimm_devs.c
and the attribute it is for is also already static. Silence the sparse
warning for this not being declared by making it static. Fixes:
drivers/nvdimm/dimm_devs.c:352:9: warning: symbol 'security_show' was not
declared. Should it be static?
Signed-off-by: Ben Dooks
---
drivers/nvdimm/dimm_devs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/nvdimm/dimm_devs.c b/drivers/nvdimm/dimm_devs.c
index 957f7c3d17ba..1273873582be 100644
--- a/drivers/nvdimm/dimm_devs.c
+++ b/drivers/nvdimm/dimm_devs.c
@@ -349,8 +349,8 @@ static ssize_t available_slots_show(struct device *dev,
}
static DEVICE_ATTR_RO(available_slots);
-ssize_t security_show(struct device *dev,
- struct device_attribute *attr, char *buf)
+static ssize_t security_show(struct device *dev,
+struct device_attribute *attr, char *buf)
{
struct nvdimm *nvdimm = to_nvdimm(dev);
--
2.39.2
[PATCH] dax: include bus.h for definition of run_dax()
The run_dax() prototype is defined in "bus.h" but drivers/dax/super.c does not include this. Include bus.h to silece the following sparse warning: drivers/dax/super.c:337:6: warning: symbol 'run_dax' was not declared. Should it be static? Signed-off-by: Ben Dooks --- drivers/dax/super.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/dax/super.c b/drivers/dax/super.c index c4c4728a36e4..8c05dae19bfe 100644 --- a/drivers/dax/super.c +++ b/drivers/dax/super.c @@ -14,6 +14,7 @@ #include #include #include "dax-private.h" +#include "bus.h" /** * struct dax_device - anchor object for dax services -- 2.39.2
Re: [syzbot] BUG: unable to handle kernel access to user memory in sock_ioctl
On 18/03/2021 15:18, Dmitry Vyukov wrote: On Mon, Mar 15, 2021 at 3:41 PM Ben Dooks wrote: On 15/03/2021 11:52, Dmitry Vyukov wrote: On Mon, Mar 15, 2021 at 12:30 PM Ben Dooks wrote: On 14/03/2021 11:03, Dmitry Vyukov wrote: On Sun, Mar 14, 2021 at 11:01 AM Dmitry Vyukov wrote: On Wed, Mar 10, 2021 at 7:28 PM syzbot wrote: Hello, syzbot found the following issue on: HEAD commit:0d7588ab riscv: process: Fix no prototype for arch_dup_tas.. git tree: git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git fixes console output: https://syzkaller.appspot.com/x/log.txt?x=122c343ad0 kernel config: https://syzkaller.appspot.com/x/.config?x=e3c595255fb2d136 dashboard link: https://syzkaller.appspot.com/bug?extid=c23c5421600e9b454849 userspace arch: riscv64 Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+c23c5421600e9b454...@syzkaller.appspotmail.com +riscv maintainers Another case of put_user crashing. There are 58 crashes in sock_ioctl already. Somehow there is a very significant skew towards crashing with this "user memory without uaccess routines" in schedule_tail and sock_ioctl of all places in the kernel that use put_user... This looks very strange... Any ideas what's special about these 2 locations? I could imagine if such a crash happens after a previous stack overflow and now task data structures are corrupted. But f_getown does not look like a function that consumes way more than other kernel syscalls... The last crash I looked at suggested somehow put_user got re-entered with the user protection turned back on. Either there is a path through one of the kernel handlers where this happens or there's something weird going on with qemu. Is there any kind of tracking/reporting that would help to localize it? I could re-reproduce with that code. I'm not sure. I will have a go at debugging on qemu today just to make sure I can reproduce here before I have to go into the office and fix my Icicle board for real hardware tests. I think my first plan post reproduction is to stuff some trace points into the fault handlers to see if we can get a idea of faults being processed, etc. Maybe also add a check in the fault handler to see if the fault was in a fixable region and post an error if that happens / maybe retry the instruction with the relevant SR_SUM flag set. Hopefully tomorrow I can get a run on real hardware to confirm. Would have been better if the Unmatched board I ordered last year would turn up. In retrospect it's obvious what's common between these 2 locations: they both call a function inside of put_user. #syz dup: BUG: unable to handle kernel access to user memory in schedule_tail I think so. I've posted a patch that you can test, which should force the flags to be saved over switch_to(). I think the sanitisers are just making it easier to see. There is a seperate issue of passing complicated things to put_user() as for security, the function may be executed with the user-space protections turned off. I plan to raise this on the kernel list later once I've done some more testing. -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius https://www.codethink.co.uk/privacy.html
Re: [syzbot] BUG: unable to handle kernel access to user memory in schedule_tail
On 18/03/2021 10:05, Dmitry Vyukov wrote:
On Thu, Mar 18, 2021 at 10:41 AM Ben Dooks wrote:
On 12/03/2021 17:38, Dmitry Vyukov wrote:
On Fri, Mar 12, 2021 at 6:34 PM Dmitry Vyukov wrote:
On Fri, Mar 12, 2021 at 5:36 PM Ben Dooks wrote:
On 12/03/2021 16:34, Ben Dooks wrote:
On 12/03/2021 16:30, Ben Dooks wrote:
On 12/03/2021 15:12, Dmitry Vyukov wrote:
On Fri, Mar 12, 2021 at 2:50 PM Ben Dooks
wrote:
On 10/03/2021 17:16, Dmitry Vyukov wrote:
On Wed, Mar 10, 2021 at 5:46 PM syzbot
wrote:
Hello,
syzbot found the following issue on:
HEAD commit:0d7588ab riscv: process: Fix no prototype for
arch_dup_tas..
git tree:
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git fixes
console output:
https://syzkaller.appspot.com/x/log.txt?x=1212c6e6d0
kernel config:
https://syzkaller.appspot.com/x/.config?x=e3c595255fb2d136
dashboard link:
https://syzkaller.appspot.com/bug?extid=e74b94fe601ab9552d69
userspace arch: riscv64
Unfortunately, I don't have any reproducer for this issue yet.
IMPORTANT: if you fix the issue, please add the following tag to
the commit:
Reported-by: syzbot+e74b94fe601ab9552...@syzkaller.appspotmail.com
+riscv maintainers
This is riscv64-specific.
I've seen similar crashes in put_user in other places. It looks like
put_user crashes in the user address is not mapped/protected (?).
I've been having a look, and this seems to be down to access of the
tsk->set_child_tid variable. I assume the fuzzing here is to pass a
bad address to clone?
From looking at the code, the put_user() code should have set the
relevant SR_SUM bit (the value for this, which is 1<<18 is in the
s2 register in the crash report) and from looking at the compiler
output from my gcc-10, the code looks to be dong the relevant csrs
and then csrc around the put_user
So currently I do not understand how the above could have happened
over than something re-tried the code seqeunce and ended up retrying
the faulting instruction without the SR_SUM bit set.
I would maybe blame qemu for randomly resetting SR_SUM, but it's
strange that 99% of these crashes are in schedule_tail. If it would be
qemu, then they would be more evenly distributed...
Another observation: looking at a dozen of crash logs, in none of
these cases fuzzer was actually trying to fuzz clone with some insane
arguments. So it looks like completely normal clone's (e..g coming
from pthread_create) result in this crash.
I also wonder why there is ret_from_exception, is it normal? I see
handle_exception disables SR_SUM:
https://elixir.bootlin.com/linux/v5.12-rc2/source/arch/riscv/kernel/entry.S#L73
So I think if SR_SUM is set, then it faults the access to user memory
which the _user() routines clear to allow them access.
I'm thinking there is at least one issue here:
- the test in fault is the wrong way around for die kernel
- the handler only catches this if the page has yet to be mapped.
So I think the test should be:
if (!user_mode(regs) && addr < TASK_SIZE &&
unlikely(regs->status & SR_SUM)
This then should continue on and allow the rest of the handler to
complete mapping the page if it is not there.
I have been trying to create a very simple clone test, but so far it
has yet to actually trigger anything.
I should have added there doesn't seem to be a good way to use mmap()
to allocate memory but not insert a vm-mapping post the mmap().
How difficult is it to try building a branch with the above test
modified?
I don't have access to hardware, I don't have other qemu versions ready to use.
But I can teach you how to run syzkaller locally :)
I am not sure anybody run it on real riscv hardware at all. When
Tobias ported syzkaller, Tobias also used qemu I think.
I am now building with an inverted check to test locally.
I don't fully understand but this code, but does handle_exception
reset SR_SUM around do_page_fault? If so, then looking at SR_SUM in
do_page_fault won't work with positive nor negative check.
The inverted check crashes during boot:
--- a/arch/riscv/mm/fault.c
+++ b/arch/riscv/mm/fault.c
@@ -249,7 +249,7 @@ asmlinkage void do_page_fault(struct pt_regs *regs)
flags |= FAULT_FLAG_USER;
if (!user_mode(regs) && addr < TASK_SIZE &&
- unlikely(!(regs->status & SR_SUM)))
+ unlikely(regs->status & SR_SUM))
die_kernel_fault("access to user memory without
uaccess routines",
addr, regs);
[ 77.349329][T1] Run /sbin/init as init process
[ 77.868371][T1] Unable to handle kernel access to user memory
without uaccess routines at virtual address 000e8e39
[ 77.870355][T1] Oops [#1]
[ 77.870766][T1] Modules linked in:
[ 77.871326][T1] CPU: 0 PID: 1 Comm: init Not tainted
5.12.0-rc2-00010-g0d7588ab9ef9-dirty #42
[ 77.87
Re: [syzbot] BUG: unable to handle kernel access to user memory in schedule_tail
On 12/03/2021 17:38, Dmitry Vyukov wrote:
On Fri, Mar 12, 2021 at 6:34 PM Dmitry Vyukov wrote:
On Fri, Mar 12, 2021 at 5:36 PM Ben Dooks wrote:
On 12/03/2021 16:34, Ben Dooks wrote:
On 12/03/2021 16:30, Ben Dooks wrote:
On 12/03/2021 15:12, Dmitry Vyukov wrote:
On Fri, Mar 12, 2021 at 2:50 PM Ben Dooks
wrote:
On 10/03/2021 17:16, Dmitry Vyukov wrote:
On Wed, Mar 10, 2021 at 5:46 PM syzbot
wrote:
Hello,
syzbot found the following issue on:
HEAD commit:0d7588ab riscv: process: Fix no prototype for
arch_dup_tas..
git tree:
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git fixes
console output:
https://syzkaller.appspot.com/x/log.txt?x=1212c6e6d0
kernel config:
https://syzkaller.appspot.com/x/.config?x=e3c595255fb2d136
dashboard link:
https://syzkaller.appspot.com/bug?extid=e74b94fe601ab9552d69
userspace arch: riscv64
Unfortunately, I don't have any reproducer for this issue yet.
IMPORTANT: if you fix the issue, please add the following tag to
the commit:
Reported-by: syzbot+e74b94fe601ab9552...@syzkaller.appspotmail.com
+riscv maintainers
This is riscv64-specific.
I've seen similar crashes in put_user in other places. It looks like
put_user crashes in the user address is not mapped/protected (?).
I've been having a look, and this seems to be down to access of the
tsk->set_child_tid variable. I assume the fuzzing here is to pass a
bad address to clone?
From looking at the code, the put_user() code should have set the
relevant SR_SUM bit (the value for this, which is 1<<18 is in the
s2 register in the crash report) and from looking at the compiler
output from my gcc-10, the code looks to be dong the relevant csrs
and then csrc around the put_user
So currently I do not understand how the above could have happened
over than something re-tried the code seqeunce and ended up retrying
the faulting instruction without the SR_SUM bit set.
I would maybe blame qemu for randomly resetting SR_SUM, but it's
strange that 99% of these crashes are in schedule_tail. If it would be
qemu, then they would be more evenly distributed...
Another observation: looking at a dozen of crash logs, in none of
these cases fuzzer was actually trying to fuzz clone with some insane
arguments. So it looks like completely normal clone's (e..g coming
from pthread_create) result in this crash.
I also wonder why there is ret_from_exception, is it normal? I see
handle_exception disables SR_SUM:
https://elixir.bootlin.com/linux/v5.12-rc2/source/arch/riscv/kernel/entry.S#L73
So I think if SR_SUM is set, then it faults the access to user memory
which the _user() routines clear to allow them access.
I'm thinking there is at least one issue here:
- the test in fault is the wrong way around for die kernel
- the handler only catches this if the page has yet to be mapped.
So I think the test should be:
if (!user_mode(regs) && addr < TASK_SIZE &&
unlikely(regs->status & SR_SUM)
This then should continue on and allow the rest of the handler to
complete mapping the page if it is not there.
I have been trying to create a very simple clone test, but so far it
has yet to actually trigger anything.
I should have added there doesn't seem to be a good way to use mmap()
to allocate memory but not insert a vm-mapping post the mmap().
How difficult is it to try building a branch with the above test
modified?
I don't have access to hardware, I don't have other qemu versions ready to use.
But I can teach you how to run syzkaller locally :)
I am not sure anybody run it on real riscv hardware at all. When
Tobias ported syzkaller, Tobias also used qemu I think.
I am now building with an inverted check to test locally.
I don't fully understand but this code, but does handle_exception
reset SR_SUM around do_page_fault? If so, then looking at SR_SUM in
do_page_fault won't work with positive nor negative check.
The inverted check crashes during boot:
--- a/arch/riscv/mm/fault.c
+++ b/arch/riscv/mm/fault.c
@@ -249,7 +249,7 @@ asmlinkage void do_page_fault(struct pt_regs *regs)
flags |= FAULT_FLAG_USER;
if (!user_mode(regs) && addr < TASK_SIZE &&
- unlikely(!(regs->status & SR_SUM)))
+ unlikely(regs->status & SR_SUM))
die_kernel_fault("access to user memory without
uaccess routines",
addr, regs);
[ 77.349329][T1] Run /sbin/init as init process
[ 77.868371][T1] Unable to handle kernel access to user memory
without uaccess routines at virtual address 000e8e39
[ 77.870355][T1] Oops [#1]
[ 77.870766][T1] Modules linked in:
[ 77.871326][T1] CPU: 0 PID: 1 Comm: init Not tainted
5.12.0-rc2-00010-g0d7588ab9ef9-dirty #42
[ 77.872057][T1] Hardware name: riscv-virtio,qemu (DT)
[ 77.872620][T1] epc : __clear_user+0x36/
Re: [syzbot] BUG: unable to handle kernel access to user memory in schedule_tail
On 16/03/2021 08:52, Dmitry Vyukov wrote:
On Mon, Mar 15, 2021 at 10:38 PM Ben Dooks wrote:
On 13/03/2021 07:20, Dmitry Vyukov wrote:
On Fri, Mar 12, 2021 at 9:12 PM Ben Dooks wrote:
On 12/03/2021 16:25, Alex Ghiti wrote:
Le 3/12/21 à 10:12 AM, Dmitry Vyukov a écrit :
On Fri, Mar 12, 2021 at 2:50 PM Ben Dooks
wrote:
On 10/03/2021 17:16, Dmitry Vyukov wrote:
On Wed, Mar 10, 2021 at 5:46 PM syzbot
wrote:
Hello,
syzbot found the following issue on:
HEAD commit:0d7588ab riscv: process: Fix no prototype for
arch_dup_tas..
git tree:
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git fixes
console output:
https://syzkaller.appspot.com/x/log.txt?x=1212c6e6d0
kernel config:
https://syzkaller.appspot.com/x/.config?x=e3c595255fb2d136
dashboard link:
https://syzkaller.appspot.com/bug?extid=e74b94fe601ab9552d69
userspace arch: riscv64
Unfortunately, I don't have any reproducer for this issue yet.
IMPORTANT: if you fix the issue, please add the following tag to
the commit:
Reported-by: syzbot+e74b94fe601ab9552...@syzkaller.appspotmail.com
+riscv maintainers
This is riscv64-specific.
I've seen similar crashes in put_user in other places. It looks like
put_user crashes in the user address is not mapped/protected (?).
I've been having a look, and this seems to be down to access of the
tsk->set_child_tid variable. I assume the fuzzing here is to pass a
bad address to clone?
From looking at the code, the put_user() code should have set the
relevant SR_SUM bit (the value for this, which is 1<<18 is in the
s2 register in the crash report) and from looking at the compiler
output from my gcc-10, the code looks to be dong the relevant csrs
and then csrc around the put_user
So currently I do not understand how the above could have happened
over than something re-tried the code seqeunce and ended up retrying
the faulting instruction without the SR_SUM bit set.
I would maybe blame qemu for randomly resetting SR_SUM, but it's
strange that 99% of these crashes are in schedule_tail. If it would be
qemu, then they would be more evenly distributed...
Another observation: looking at a dozen of crash logs, in none of
these cases fuzzer was actually trying to fuzz clone with some insane
arguments. So it looks like completely normal clone's (e..g coming
from pthread_create) result in this crash.
I also wonder why there is ret_from_exception, is it normal? I see
handle_exception disables SR_SUM:
csrrc does the right thing: it cleans SR_SUM bit in status but saves the
previous value that will get correctly restored.
("The CSRRC (Atomic Read and Clear Bits in CSR) instruction reads the
value of the CSR, zero-extends the value to XLEN bits, and writes it to
integer registerrd. The initial value in integerregisterrs1is treated
as a bit mask that specifies bit positions to be cleared in the CSR. Any
bitthat is high inrs1will cause the corresponding bit to be cleared in
the CSR, if that CSR bit iswritable. Other bits in the CSR are
unaffected.")
I think there may also be an understanding issue on what the SR_SUM
bit does. I thought if it is set, M->U accesses would fault, which is
why it gets set early on. But from reading the uaccess code it looks
like the uaccess code sets it on entry and then clears on exit.
I am very confused. Is there a master reference for rv64?
https://people.eecs.berkeley.edu/~krste/papers/riscv-privileged-v1.9.pdf
seems to state PUM is the SR_SUM bit, and that (if set) disabled
Quote:
The PUM (Protect User Memory) bit modifies the privilege with which
S-mode loads, stores, and instruction fetches access virtual memory.
When PUM=0, translation and protection behave as normal. When PUM=1,
S-mode memory accesses to pages that are accessible by U-mode (U=1 in
Figure 4.19) will fault. PUM has no effect when executing in U-mode
https://elixir.bootlin.com/linux/v5.12-rc2/source/arch/riscv/kernel/entry.S#L73
Still no luck for the moment, can't reproduce it locally, my test is
maybe not that good (I created threads all day long in order to trigger
the put_user of schedule_tail).
It may of course depend on memory and other stuff. I did try to see if
it was possible to clone() with the child_tid address being a valid but
not mapped page...
Given that the path you mention works most of the time, and that the
status register in the stack trace shows the SUM bit is not set whereas
it is set in put_user, I'm leaning toward some race condition (maybe an
interrupt that arrives at the "wrong" time) or a qemu issue as you
mentioned.
I suppose this is possible. From what I read it should get to the
point of being there with the SUM flag cleared, so either something
went wrong in trying to fix the instruction up or there's some other
error we're missing.
To eliminate qemu issues, do you have access to some HW ? Or to
different qemu versions ?
I do have access to a Microchip Polarfire board. I just need the
instructions on ho
Re: [syzbot] BUG: unable to handle kernel access to user memory in schedule_tail
On 13/03/2021 07:20, Dmitry Vyukov wrote:
On Fri, Mar 12, 2021 at 9:12 PM Ben Dooks wrote:
On 12/03/2021 16:25, Alex Ghiti wrote:
Le 3/12/21 à 10:12 AM, Dmitry Vyukov a écrit :
On Fri, Mar 12, 2021 at 2:50 PM Ben Dooks
wrote:
On 10/03/2021 17:16, Dmitry Vyukov wrote:
On Wed, Mar 10, 2021 at 5:46 PM syzbot
wrote:
Hello,
syzbot found the following issue on:
HEAD commit:0d7588ab riscv: process: Fix no prototype for
arch_dup_tas..
git tree:
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git fixes
console output:
https://syzkaller.appspot.com/x/log.txt?x=1212c6e6d0
kernel config:
https://syzkaller.appspot.com/x/.config?x=e3c595255fb2d136
dashboard link:
https://syzkaller.appspot.com/bug?extid=e74b94fe601ab9552d69
userspace arch: riscv64
Unfortunately, I don't have any reproducer for this issue yet.
IMPORTANT: if you fix the issue, please add the following tag to
the commit:
Reported-by: syzbot+e74b94fe601ab9552...@syzkaller.appspotmail.com
+riscv maintainers
This is riscv64-specific.
I've seen similar crashes in put_user in other places. It looks like
put_user crashes in the user address is not mapped/protected (?).
I've been having a look, and this seems to be down to access of the
tsk->set_child_tid variable. I assume the fuzzing here is to pass a
bad address to clone?
From looking at the code, the put_user() code should have set the
relevant SR_SUM bit (the value for this, which is 1<<18 is in the
s2 register in the crash report) and from looking at the compiler
output from my gcc-10, the code looks to be dong the relevant csrs
and then csrc around the put_user
So currently I do not understand how the above could have happened
over than something re-tried the code seqeunce and ended up retrying
the faulting instruction without the SR_SUM bit set.
I would maybe blame qemu for randomly resetting SR_SUM, but it's
strange that 99% of these crashes are in schedule_tail. If it would be
qemu, then they would be more evenly distributed...
Another observation: looking at a dozen of crash logs, in none of
these cases fuzzer was actually trying to fuzz clone with some insane
arguments. So it looks like completely normal clone's (e..g coming
from pthread_create) result in this crash.
I also wonder why there is ret_from_exception, is it normal? I see
handle_exception disables SR_SUM:
csrrc does the right thing: it cleans SR_SUM bit in status but saves the
previous value that will get correctly restored.
("The CSRRC (Atomic Read and Clear Bits in CSR) instruction reads the
value of the CSR, zero-extends the value to XLEN bits, and writes it to
integer registerrd. The initial value in integerregisterrs1is treated
as a bit mask that specifies bit positions to be cleared in the CSR. Any
bitthat is high inrs1will cause the corresponding bit to be cleared in
the CSR, if that CSR bit iswritable. Other bits in the CSR are
unaffected.")
I think there may also be an understanding issue on what the SR_SUM
bit does. I thought if it is set, M->U accesses would fault, which is
why it gets set early on. But from reading the uaccess code it looks
like the uaccess code sets it on entry and then clears on exit.
I am very confused. Is there a master reference for rv64?
https://people.eecs.berkeley.edu/~krste/papers/riscv-privileged-v1.9.pdf
seems to state PUM is the SR_SUM bit, and that (if set) disabled
Quote:
The PUM (Protect User Memory) bit modifies the privilege with which
S-mode loads, stores, and instruction fetches access virtual memory.
When PUM=0, translation and protection behave as normal. When PUM=1,
S-mode memory accesses to pages that are accessible by U-mode (U=1 in
Figure 4.19) will fault. PUM has no effect when executing in U-mode
https://elixir.bootlin.com/linux/v5.12-rc2/source/arch/riscv/kernel/entry.S#L73
Still no luck for the moment, can't reproduce it locally, my test is
maybe not that good (I created threads all day long in order to trigger
the put_user of schedule_tail).
It may of course depend on memory and other stuff. I did try to see if
it was possible to clone() with the child_tid address being a valid but
not mapped page...
Given that the path you mention works most of the time, and that the
status register in the stack trace shows the SUM bit is not set whereas
it is set in put_user, I'm leaning toward some race condition (maybe an
interrupt that arrives at the "wrong" time) or a qemu issue as you
mentioned.
I suppose this is possible. From what I read it should get to the
point of being there with the SUM flag cleared, so either something
went wrong in trying to fix the instruction up or there's some other
error we're missing.
To eliminate qemu issues, do you have access to some HW ? Or to
different qemu versions ?
I do have access to a Microchip Polarfire board. I just need the
instructions on how to setup the test-code to make it work on the
hardware.
For full syzkaller support, it
Re: [syzbot] BUG: unable to handle kernel access to user memory in schedule_tail
On 13/03/2021 07:20, Dmitry Vyukov wrote: On Fri, Mar 12, 2021 at 9:12 PM Ben Dooks wrote: Still no luck for the moment, can't reproduce it locally, my test is maybe not that good (I created threads all day long in order to trigger the put_user of schedule_tail). It may of course depend on memory and other stuff. I did try to see if it was possible to clone() with the child_tid address being a valid but not mapped page... Given that the path you mention works most of the time, and that the status register in the stack trace shows the SUM bit is not set whereas it is set in put_user, I'm leaning toward some race condition (maybe an interrupt that arrives at the "wrong" time) or a qemu issue as you mentioned. I suppose this is possible. From what I read it should get to the point of being there with the SUM flag cleared, so either something went wrong in trying to fix the instruction up or there's some other error we're missing. To eliminate qemu issues, do you have access to some HW ? Or to different qemu versions ? I do have access to a Microchip Polarfire board. I just need the instructions on how to setup the test-code to make it work on the hardware. For full syzkaller support, it would need to know how to reboot these boards and get access to the console. syzkaller has a stop-gap VM backend which just uses ssh to a physical machine and expects the kernel to reboot on its own after any crashes. But I actually managed to reproduce it in an even simpler setup. Assuming you have Go 1.15 and riscv64 cross-compiler gcc installed $ go get -u -d github.com/google/syzkaller/... $ cd $GOPATH/src/github.com/google/syzkaller $ make stress executor TARGETARCH=riscv64 $ scp bin/linux_riscv64/syz-execprog bin/linux_riscv64/syz-executor your_machine:/ Then run ./syz-stress on the machine. On the first run it crashed it with some other bug, on the second run I got the crash in schedule_tail. With qemu tcg I also added -slowdown=10 flag to syz-stress to scale all timeouts, if native execution is faster, then you don't need it. I have built the tools and got it to start. It would be helpful for the dashboard to give the qemu version and how it was launched (memory, cpus etc) -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius https://www.codethink.co.uk/privacy.html
Re: [syzbot] BUG: unable to handle kernel access to user memory in sock_ioctl
On 15/03/2021 11:52, Dmitry Vyukov wrote: On Mon, Mar 15, 2021 at 12:30 PM Ben Dooks wrote: On 14/03/2021 11:03, Dmitry Vyukov wrote: On Sun, Mar 14, 2021 at 11:01 AM Dmitry Vyukov wrote: On Wed, Mar 10, 2021 at 7:28 PM syzbot wrote: Hello, syzbot found the following issue on: HEAD commit:0d7588ab riscv: process: Fix no prototype for arch_dup_tas.. git tree: git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git fixes console output: https://syzkaller.appspot.com/x/log.txt?x=122c343ad0 kernel config: https://syzkaller.appspot.com/x/.config?x=e3c595255fb2d136 dashboard link: https://syzkaller.appspot.com/bug?extid=c23c5421600e9b454849 userspace arch: riscv64 Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+c23c5421600e9b454...@syzkaller.appspotmail.com +riscv maintainers Another case of put_user crashing. There are 58 crashes in sock_ioctl already. Somehow there is a very significant skew towards crashing with this "user memory without uaccess routines" in schedule_tail and sock_ioctl of all places in the kernel that use put_user... This looks very strange... Any ideas what's special about these 2 locations? I could imagine if such a crash happens after a previous stack overflow and now task data structures are corrupted. But f_getown does not look like a function that consumes way more than other kernel syscalls... The last crash I looked at suggested somehow put_user got re-entered with the user protection turned back on. Either there is a path through one of the kernel handlers where this happens or there's something weird going on with qemu. Is there any kind of tracking/reporting that would help to localize it? I could re-reproduce with that code. I'm not sure. I will have a go at debugging on qemu today just to make sure I can reproduce here before I have to go into the office and fix my Icicle board for real hardware tests. I think my first plan post reproduction is to stuff some trace points into the fault handlers to see if we can get a idea of faults being processed, etc. Maybe also add a check in the fault handler to see if the fault was in a fixable region and post an error if that happens / maybe retry the instruction with the relevant SR_SUM flag set. Hopefully tomorrow I can get a run on real hardware to confirm. Would have been better if the Unmatched board I ordered last year would turn up. -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius https://www.codethink.co.uk/privacy.html
Re: [syzbot] BUG: unable to handle kernel access to user memory in sock_ioctl
On 14/03/2021 11:03, Dmitry Vyukov wrote: On Sun, Mar 14, 2021 at 11:01 AM Dmitry Vyukov wrote: On Wed, Mar 10, 2021 at 7:28 PM syzbot wrote: Hello, syzbot found the following issue on: HEAD commit:0d7588ab riscv: process: Fix no prototype for arch_dup_tas.. git tree: git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git fixes console output: https://syzkaller.appspot.com/x/log.txt?x=122c343ad0 kernel config: https://syzkaller.appspot.com/x/.config?x=e3c595255fb2d136 dashboard link: https://syzkaller.appspot.com/bug?extid=c23c5421600e9b454849 userspace arch: riscv64 Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+c23c5421600e9b454...@syzkaller.appspotmail.com +riscv maintainers Another case of put_user crashing. There are 58 crashes in sock_ioctl already. Somehow there is a very significant skew towards crashing with this "user memory without uaccess routines" in schedule_tail and sock_ioctl of all places in the kernel that use put_user... This looks very strange... Any ideas what's special about these 2 locations? I could imagine if such a crash happens after a previous stack overflow and now task data structures are corrupted. But f_getown does not look like a function that consumes way more than other kernel syscalls... The last crash I looked at suggested somehow put_user got re-entered with the user protection turned back on. Either there is a path through one of the kernel handlers where this happens or there's something weird going on with qemu. I'll be trying to get this run up on real hardware this week, the nvme with my debian install died last week so I have to go and re-install the machine to get development work done on it. -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius https://www.codethink.co.uk/privacy.html
Re: [syzbot] BUG: unable to handle kernel access to user memory in schedule_tail
On 12/03/2021 16:25, Alex Ghiti wrote:
Le 3/12/21 à 10:12 AM, Dmitry Vyukov a écrit :
On Fri, Mar 12, 2021 at 2:50 PM Ben Dooks
wrote:
On 10/03/2021 17:16, Dmitry Vyukov wrote:
On Wed, Mar 10, 2021 at 5:46 PM syzbot
wrote:
Hello,
syzbot found the following issue on:
HEAD commit: 0d7588ab riscv: process: Fix no prototype for
arch_dup_tas..
git tree:
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git fixes
console output:
https://syzkaller.appspot.com/x/log.txt?x=1212c6e6d0
kernel config:
https://syzkaller.appspot.com/x/.config?x=e3c595255fb2d136
dashboard link:
https://syzkaller.appspot.com/bug?extid=e74b94fe601ab9552d69
userspace arch: riscv64
Unfortunately, I don't have any reproducer for this issue yet.
IMPORTANT: if you fix the issue, please add the following tag to
the commit:
Reported-by: syzbot+e74b94fe601ab9552...@syzkaller.appspotmail.com
+riscv maintainers
This is riscv64-specific.
I've seen similar crashes in put_user in other places. It looks like
put_user crashes in the user address is not mapped/protected (?).
I've been having a look, and this seems to be down to access of the
tsk->set_child_tid variable. I assume the fuzzing here is to pass a
bad address to clone?
From looking at the code, the put_user() code should have set the
relevant SR_SUM bit (the value for this, which is 1<<18 is in the
s2 register in the crash report) and from looking at the compiler
output from my gcc-10, the code looks to be dong the relevant csrs
and then csrc around the put_user
So currently I do not understand how the above could have happened
over than something re-tried the code seqeunce and ended up retrying
the faulting instruction without the SR_SUM bit set.
I would maybe blame qemu for randomly resetting SR_SUM, but it's
strange that 99% of these crashes are in schedule_tail. If it would be
qemu, then they would be more evenly distributed...
Another observation: looking at a dozen of crash logs, in none of
these cases fuzzer was actually trying to fuzz clone with some insane
arguments. So it looks like completely normal clone's (e..g coming
from pthread_create) result in this crash.
I also wonder why there is ret_from_exception, is it normal? I see
handle_exception disables SR_SUM:
csrrc does the right thing: it cleans SR_SUM bit in status but saves the
previous value that will get correctly restored.
("The CSRRC (Atomic Read and Clear Bits in CSR) instruction reads the
value of the CSR, zero-extends the value to XLEN bits, and writes it to
integer registerrd. The initial value in integerregisterrs1is treated
as a bit mask that specifies bit positions to be cleared in the CSR. Any
bitthat is high inrs1will cause the corresponding bit to be cleared in
the CSR, if that CSR bit iswritable. Other bits in the CSR are
unaffected.")
I think there may also be an understanding issue on what the SR_SUM
bit does. I thought if it is set, M->U accesses would fault, which is
why it gets set early on. But from reading the uaccess code it looks
like the uaccess code sets it on entry and then clears on exit.
I am very confused. Is there a master reference for rv64?
https://people.eecs.berkeley.edu/~krste/papers/riscv-privileged-v1.9.pdf
seems to state PUM is the SR_SUM bit, and that (if set) disabled
Quote:
The PUM (Protect User Memory) bit modifies the privilege with which
S-mode loads, stores, and instruction fetches access virtual memory.
When PUM=0, translation and protection behave as normal. When PUM=1,
S-mode memory accesses to pages that are accessible by U-mode (U=1 in
Figure 4.19) will fault. PUM has no effect when executing in U-mode
https://elixir.bootlin.com/linux/v5.12-rc2/source/arch/riscv/kernel/entry.S#L73
Still no luck for the moment, can't reproduce it locally, my test is
maybe not that good (I created threads all day long in order to trigger
the put_user of schedule_tail).
It may of course depend on memory and other stuff. I did try to see if
it was possible to clone() with the child_tid address being a valid but
not mapped page...
Given that the path you mention works most of the time, and that the
status register in the stack trace shows the SUM bit is not set whereas
it is set in put_user, I'm leaning toward some race condition (maybe an
interrupt that arrives at the "wrong" time) or a qemu issue as you
mentioned.
I suppose this is possible. From what I read it should get to the
point of being there with the SUM flag cleared, so either something
went wrong in trying to fix the instruction up or there's some other
error we're missing.
To eliminate qemu issues, do you have access to some HW ? Or to
different qemu versions ?
I do have access to a Microchip Polarfire board. I just need the
instructions on how to setup the test-code to make it work on the
hardware.
The config supplied takes /ages/ to boot on qemu even on my ryzen9.
--
Ben Dooks
Re: [syzbot] BUG: unable to handle kernel access to user memory in schedule_tail
On 12/03/2021 16:34, Ben Dooks wrote: On 12/03/2021 16:30, Ben Dooks wrote: On 12/03/2021 15:12, Dmitry Vyukov wrote: On Fri, Mar 12, 2021 at 2:50 PM Ben Dooks wrote: On 10/03/2021 17:16, Dmitry Vyukov wrote: On Wed, Mar 10, 2021 at 5:46 PM syzbot wrote: Hello, syzbot found the following issue on: HEAD commit: 0d7588ab riscv: process: Fix no prototype for arch_dup_tas.. git tree: git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git fixes console output: https://syzkaller.appspot.com/x/log.txt?x=1212c6e6d0 kernel config: https://syzkaller.appspot.com/x/.config?x=e3c595255fb2d136 dashboard link: https://syzkaller.appspot.com/bug?extid=e74b94fe601ab9552d69 userspace arch: riscv64 Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+e74b94fe601ab9552...@syzkaller.appspotmail.com +riscv maintainers This is riscv64-specific. I've seen similar crashes in put_user in other places. It looks like put_user crashes in the user address is not mapped/protected (?). I've been having a look, and this seems to be down to access of the tsk->set_child_tid variable. I assume the fuzzing here is to pass a bad address to clone? From looking at the code, the put_user() code should have set the relevant SR_SUM bit (the value for this, which is 1<<18 is in the s2 register in the crash report) and from looking at the compiler output from my gcc-10, the code looks to be dong the relevant csrs and then csrc around the put_user So currently I do not understand how the above could have happened over than something re-tried the code seqeunce and ended up retrying the faulting instruction without the SR_SUM bit set. I would maybe blame qemu for randomly resetting SR_SUM, but it's strange that 99% of these crashes are in schedule_tail. If it would be qemu, then they would be more evenly distributed... Another observation: looking at a dozen of crash logs, in none of these cases fuzzer was actually trying to fuzz clone with some insane arguments. So it looks like completely normal clone's (e..g coming from pthread_create) result in this crash. I also wonder why there is ret_from_exception, is it normal? I see handle_exception disables SR_SUM: https://elixir.bootlin.com/linux/v5.12-rc2/source/arch/riscv/kernel/entry.S#L73 So I think if SR_SUM is set, then it faults the access to user memory which the _user() routines clear to allow them access. I'm thinking there is at least one issue here: - the test in fault is the wrong way around for die kernel - the handler only catches this if the page has yet to be mapped. So I think the test should be: if (!user_mode(regs) && addr < TASK_SIZE && unlikely(regs->status & SR_SUM) This then should continue on and allow the rest of the handler to complete mapping the page if it is not there. I have been trying to create a very simple clone test, but so far it has yet to actually trigger anything. I should have added there doesn't seem to be a good way to use mmap() to allocate memory but not insert a vm-mapping post the mmap(). How difficult is it to try building a branch with the above test modified? -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius https://www.codethink.co.uk/privacy.html
Re: [syzbot] BUG: unable to handle kernel access to user memory in schedule_tail
On 12/03/2021 16:30, Ben Dooks wrote: On 12/03/2021 15:12, Dmitry Vyukov wrote: On Fri, Mar 12, 2021 at 2:50 PM Ben Dooks wrote: On 10/03/2021 17:16, Dmitry Vyukov wrote: On Wed, Mar 10, 2021 at 5:46 PM syzbot wrote: Hello, syzbot found the following issue on: HEAD commit: 0d7588ab riscv: process: Fix no prototype for arch_dup_tas.. git tree: git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git fixes console output: https://syzkaller.appspot.com/x/log.txt?x=1212c6e6d0 kernel config: https://syzkaller.appspot.com/x/.config?x=e3c595255fb2d136 dashboard link: https://syzkaller.appspot.com/bug?extid=e74b94fe601ab9552d69 userspace arch: riscv64 Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+e74b94fe601ab9552...@syzkaller.appspotmail.com +riscv maintainers This is riscv64-specific. I've seen similar crashes in put_user in other places. It looks like put_user crashes in the user address is not mapped/protected (?). I've been having a look, and this seems to be down to access of the tsk->set_child_tid variable. I assume the fuzzing here is to pass a bad address to clone? From looking at the code, the put_user() code should have set the relevant SR_SUM bit (the value for this, which is 1<<18 is in the s2 register in the crash report) and from looking at the compiler output from my gcc-10, the code looks to be dong the relevant csrs and then csrc around the put_user So currently I do not understand how the above could have happened over than something re-tried the code seqeunce and ended up retrying the faulting instruction without the SR_SUM bit set. I would maybe blame qemu for randomly resetting SR_SUM, but it's strange that 99% of these crashes are in schedule_tail. If it would be qemu, then they would be more evenly distributed... Another observation: looking at a dozen of crash logs, in none of these cases fuzzer was actually trying to fuzz clone with some insane arguments. So it looks like completely normal clone's (e..g coming from pthread_create) result in this crash. I also wonder why there is ret_from_exception, is it normal? I see handle_exception disables SR_SUM: https://elixir.bootlin.com/linux/v5.12-rc2/source/arch/riscv/kernel/entry.S#L73 So I think if SR_SUM is set, then it faults the access to user memory which the _user() routines clear to allow them access. I'm thinking there is at least one issue here: - the test in fault is the wrong way around for die kernel - the handler only catches this if the page has yet to be mapped. So I think the test should be: if (!user_mode(regs) && addr < TASK_SIZE && unlikely(regs->status & SR_SUM) This then should continue on and allow the rest of the handler to complete mapping the page if it is not there. I have been trying to create a very simple clone test, but so far it has yet to actually trigger anything. I should have added there doesn't seem to be a good way to use mmap() to allocate memory but not insert a vm-mapping post the mmap(). -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius https://www.codethink.co.uk/privacy.html
Re: [syzbot] BUG: unable to handle kernel access to user memory in schedule_tail
On 12/03/2021 15:12, Dmitry Vyukov wrote: On Fri, Mar 12, 2021 at 2:50 PM Ben Dooks wrote: On 10/03/2021 17:16, Dmitry Vyukov wrote: On Wed, Mar 10, 2021 at 5:46 PM syzbot wrote: Hello, syzbot found the following issue on: HEAD commit:0d7588ab riscv: process: Fix no prototype for arch_dup_tas.. git tree: git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git fixes console output: https://syzkaller.appspot.com/x/log.txt?x=1212c6e6d0 kernel config: https://syzkaller.appspot.com/x/.config?x=e3c595255fb2d136 dashboard link: https://syzkaller.appspot.com/bug?extid=e74b94fe601ab9552d69 userspace arch: riscv64 Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+e74b94fe601ab9552...@syzkaller.appspotmail.com +riscv maintainers This is riscv64-specific. I've seen similar crashes in put_user in other places. It looks like put_user crashes in the user address is not mapped/protected (?). I've been having a look, and this seems to be down to access of the tsk->set_child_tid variable. I assume the fuzzing here is to pass a bad address to clone? From looking at the code, the put_user() code should have set the relevant SR_SUM bit (the value for this, which is 1<<18 is in the s2 register in the crash report) and from looking at the compiler output from my gcc-10, the code looks to be dong the relevant csrs and then csrc around the put_user So currently I do not understand how the above could have happened over than something re-tried the code seqeunce and ended up retrying the faulting instruction without the SR_SUM bit set. I would maybe blame qemu for randomly resetting SR_SUM, but it's strange that 99% of these crashes are in schedule_tail. If it would be qemu, then they would be more evenly distributed... Another observation: looking at a dozen of crash logs, in none of these cases fuzzer was actually trying to fuzz clone with some insane arguments. So it looks like completely normal clone's (e..g coming from pthread_create) result in this crash. I also wonder why there is ret_from_exception, is it normal? I see handle_exception disables SR_SUM: https://elixir.bootlin.com/linux/v5.12-rc2/source/arch/riscv/kernel/entry.S#L73 So I think if SR_SUM is set, then it faults the access to user memory which the _user() routines clear to allow them access. I'm thinking there is at least one issue here: - the test in fault is the wrong way around for die kernel - the handler only catches this if the page has yet to be mapped. So I think the test should be: if (!user_mode(regs) && addr < TASK_SIZE && unlikely(regs->status & SR_SUM) This then should continue on and allow the rest of the handler to complete mapping the page if it is not there. I have been trying to create a very simple clone test, but so far it has yet to actually trigger anything. -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius https://www.codethink.co.uk/privacy.html
Re: [syzbot] BUG: unable to handle kernel access to user memory in schedule_tail
On 10/03/2021 17:16, Dmitry Vyukov wrote: On Wed, Mar 10, 2021 at 5:46 PM syzbot wrote: Hello, syzbot found the following issue on: HEAD commit:0d7588ab riscv: process: Fix no prototype for arch_dup_tas.. git tree: git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git fixes console output: https://syzkaller.appspot.com/x/log.txt?x=1212c6e6d0 kernel config: https://syzkaller.appspot.com/x/.config?x=e3c595255fb2d136 dashboard link: https://syzkaller.appspot.com/bug?extid=e74b94fe601ab9552d69 userspace arch: riscv64 Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+e74b94fe601ab9552...@syzkaller.appspotmail.com +riscv maintainers This is riscv64-specific. I've seen similar crashes in put_user in other places. It looks like put_user crashes in the user address is not mapped/protected (?). I've been having a look, and this seems to be down to access of the tsk->set_child_tid variable. I assume the fuzzing here is to pass a bad address to clone? From looking at the code, the put_user() code should have set the relevant SR_SUM bit (the value for this, which is 1<<18 is in the s2 register in the crash report) and from looking at the compiler output from my gcc-10, the code looks to be dong the relevant csrs and then csrc around the put_user So currently I do not understand how the above could have happened over than something re-tried the code seqeunce and ended up retrying the faulting instruction without the SR_SUM bit set. -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius https://www.codethink.co.uk/privacy.html
Re: [syzbot] BUG: unable to handle kernel access to user memory in schedule_tail
On 11/03/2021 06:52, Dmitry Vyukov wrote:
On Thu, Mar 11, 2021 at 7:50 AM Dmitry Vyukov wrote:
On Thu, Mar 11, 2021 at 7:40 AM Alex Ghiti wrote:
Hi Ben,
Le 3/10/21 à 5:24 PM, Ben Dooks a écrit :
On 10/03/2021 17:16, Dmitry Vyukov wrote:
On Wed, Mar 10, 2021 at 5:46 PM syzbot
wrote:
Hello,
syzbot found the following issue on:
HEAD commit:0d7588ab riscv: process: Fix no prototype for
arch_dup_tas..
git tree:
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git fixes
console output: https://syzkaller.appspot.com/x/log.txt?x=1212c6e6d0
kernel config:
https://syzkaller.appspot.com/x/.config?x=e3c595255fb2d136
dashboard link:
https://syzkaller.appspot.com/bug?extid=e74b94fe601ab9552d69
userspace arch: riscv64
Unfortunately, I don't have any reproducer for this issue yet.
IMPORTANT: if you fix the issue, please add the following tag to the
commit:
Reported-by: syzbot+e74b94fe601ab9552...@syzkaller.appspotmail.com
+riscv maintainers
This is riscv64-specific.
I've seen similar crashes in put_user in other places. It looks like
put_user crashes in the user address is not mapped/protected (?).
The unmapped case should have been handled.
I think this issue is that the check for user-mode access added. From
what I read the code may be wrong in
+if (!user_mode(regs) && addr < TASK_SIZE &&
+unlikely(!(regs->status & SR_SUM)))
+die_kernel_fault("access to user memory without uaccess routines",
+addr, regs);
I think the SR_SUM check might be wrong, as I read the standard the
SR_SUM should be set to disable user-space access. So the check
should be unlikely(regs->status & SR_SUM) to say access without
having disabled the protection.
The check that is done seems correct to me: "The SUM (permit Supervisor
User Memory access) bit modifies the privilege with which S-mode loads
and stores access virtual memory. *When SUM=0, S-mode memory accesses
to pages that are accessible by U-mode (U=1 in Figure 4.15) will fault*.
When SUM=1, these accesses are permitted.SUM has no effect when
page-based virtual memory is not in effect".
I will try to reproduce the problem locally.
Weird. It crashes with this all the time:
https://syzkaller.appspot.com/bug?extid=e74b94fe601ab9552d69
Even on trivial programs that almost don't do anything.
Maybe it's qemu bug? Do registers look sane in the dump? That SR_SUM, etc.
00:13:27 executing program 1:
openat$drirender128(0xff9c,
&(0x7f40)='/dev/dri/renderD128\x00', 0x0, 0x0)
[ 812.318182][ T4833] Unable to handle kernel access to user memory
without uaccess routines at virtual address 250b60d0
[ 812.322304][ T4833] Oops [#1]
[ 812.323196][ T4833] Modules linked in:
[ 812.324110][ T4833] CPU: 1 PID: 4833 Comm: syz-executor.1 Not
tainted 5.12.0-rc2-syzkaller-00467-g0d7588ab9ef9 #0
[ 812.325862][ T4833] Hardware name: riscv-virtio,qemu (DT)
[ 812.327561][ T4833] epc : schedule_tail+0x72/0xb2
[ 812.328640][ T4833] ra : schedule_tail+0x70/0xb2
[ 812.330088][ T4833] epc : ffe8c8b0 ra : ffe8c8ae sp
: ffe0238bbec0
[ 812.331312][ T4833] gp : ffe005d25378 tp : ffe00a275b00 t0
:
[ 812.333014][ T4833] t1 : 0001 t2 : 000f4240 s0
: ffe0238bbee0
[ 812.334137][ T4833] s1 : 250b60d0 a0 : 0036 a1
: 0003
[ 812.336063][ T4833] a2 : 1ffc0cfa8b00 a3 : ffec80cc a4
: 7f467e72c6adf800
[ 812.337398][ T4833] a5 : a6 : 00f0 a7
: ffef8c84
[ 812.339287][ T4833] s2 : 0004 s3 : ffe0077a96c0 s4
: ffe020e67fe0
[ 812.340658][ T4833] s5 : 4020 s6 : ffe0077a9b58 s7
: ffe067d74850
[ 812.342492][ T4833] s8 : ffe067d73e18 s9 :
s10: ffe00bd72280
[ 812.343668][ T4833] s11: 00bd067bf638 t3 : 7f467e72c6adf800 t4
: ffc403ee7fb2
[ 812.345510][ T4833] t5 : ffc403ee7fba t6 : 0004
[ 812.347004][ T4833] status: 0120 badaddr:
250b60d0 cause: 000f
[ 812.348091][ T4833] Call Trace:
[ 812.349291][ T4833] [] schedule_tail+0x72/0xb2
[ 812.350796][ T4833] [] ret_from_exception+0x0/0x14
[ 812.352799][ T4833] Dumping ftrace buffer:
[ 812.354328][ T4833](ftrace buffer empty)
[ 812.428145][ T4833] ---[ end trace 94b077e4d677ee73 ]---
00:10:42 executing program 1:
bpf$ENABLE_STATS(0x20, 0x0, 0x0)
bpf$ENABLE_STATS(0x20, 0x0, 0x0)
[ 646.536862][ T5163] loop0: detected capacity change from 0 to 1
[ 646.566730][ T5165] Unable to handle kernel access to user memory
without uaccess routines at virtual address 032f80d0
[ 646.586024][ T5165] Oops [#1]
[ 646.586640][ T5165] Modules linked in:
[ 646.587350][ T5165] CPU: 1 PID: 5165 Comm: syz-executor.1 Not
tainted 5.12.0-rc2-syzkaller-00467-g0d7588ab9ef9 #0
[ 646.588209][ T5165] Hardware name: riscv-virtio,qemu
Re: [syzbot] BUG: unable to handle kernel access to user memory in schedule_tail
On 10/03/2021 17:16, Dmitry Vyukov wrote:
On Wed, Mar 10, 2021 at 5:46 PM syzbot
wrote:
Hello,
syzbot found the following issue on:
HEAD commit:0d7588ab riscv: process: Fix no prototype for arch_dup_tas..
git tree: git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git
fixes
console output: https://syzkaller.appspot.com/x/log.txt?x=1212c6e6d0
kernel config: https://syzkaller.appspot.com/x/.config?x=e3c595255fb2d136
dashboard link: https://syzkaller.appspot.com/bug?extid=e74b94fe601ab9552d69
userspace arch: riscv64
Unfortunately, I don't have any reproducer for this issue yet.
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+e74b94fe601ab9552...@syzkaller.appspotmail.com
+riscv maintainers
This is riscv64-specific.
I've seen similar crashes in put_user in other places. It looks like
put_user crashes in the user address is not mapped/protected (?).
The unmapped case should have been handled.
I think this issue is that the check for user-mode access added. From
what I read the code may be wrong in
+ if (!user_mode(regs) && addr < TASK_SIZE &&
+ unlikely(!(regs->status & SR_SUM)))
+ die_kernel_fault("access to user memory without uaccess
routines",
+ addr, regs);
I think the SR_SUM check might be wrong, as I read the standard the
SR_SUM should be set to disable user-space access. So the check
should be unlikely(regs->status & SR_SUM) to say access without
having disabled the protection.
Without this, you can end up with an infinite loop in the fault handler.
Unable to handle kernel access to user memory without uaccess routines at
virtual address 2749f0d0
Oops [#1]
Modules linked in:
CPU: 1 PID: 4875 Comm: syz-executor.0 Not tainted
5.12.0-rc2-syzkaller-00467-g0d7588ab9ef9 #0
Hardware name: riscv-virtio,qemu (DT)
epc : schedule_tail+0x72/0xb2 kernel/sched/core.c:4264
ra : task_pid_vnr include/linux/sched.h:1421 [inline]
ra : schedule_tail+0x70/0xb2 kernel/sched/core.c:4264
epc : ffe8c8b0 ra : ffe8c8ae sp : ffe025d17ec0
gp : ffe005d25378 tp : ffe00f0d t0 :
t1 : 0001 t2 : 000f4240 s0 : ffe025d17ee0
s1 : 2749f0d0 a0 : 002a a1 : 0003
a2 : 1ffc0cfac500 a3 : ffec80cc a4 : 5ae9db91c19bbe00
a5 : a6 : 00f0 a7 : ffe82eba
s2 : 0004 s3 : ffe00eef96c0 s4 : ffe022c77fe0
s5 : 4000 s6 : ffe067d74e00 s7 : ffe067d74850
s8 : ffe067d73e18 s9 : ffe067d74e00 s10: ffe00eef96e8
s11: 00ae6cdf8368 t3 : 5ae9db91c19bbe00 t4 : ffc4043cafb2
t5 : ffc4043cafba t6 : 0004
status: 0120 badaddr: 2749f0d0 cause: 000f
Call Trace:
[] schedule_tail+0x72/0xb2 kernel/sched/core.c:4264
[] ret_from_exception+0x0/0x14
Dumping ftrace buffer:
(ftrace buffer empty)
---[ end trace b5f8f9231dc87dda ]---
---
This report 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 issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
--
You received this message because you are subscribed to the Google Groups
"syzkaller-bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to syzkaller-bugs+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/syzkaller-bugs/b74f1b05bd316729%40google.com.
___
linux-riscv mailing list
linux-ri...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
https://www.codethink.co.uk/privacy.html
Re: [PATCH v4 3/5] RISC-V: Initial DTS for Microchip ICICLE board
On 03/03/2021 20:02, Atish Patra wrote:
Add initial DTS for Microchip ICICLE board having only
essential devices (clocks, sdhci, ethernet, serial, etc).
The device tree is based on the U-Boot patch.
https://patchwork.ozlabs.org/project/uboot/patch/20201110103414.10142-6-padmarao.beg...@microchip.com/
Signed-off-by: Atish Patra
---
arch/riscv/boot/dts/Makefile | 1 +
arch/riscv/boot/dts/microchip/Makefile| 2 +
.../microchip/microchip-mpfs-icicle-kit.dts | 72
.../boot/dts/microchip/microchip-mpfs.dtsi| 329 ++
4 files changed, 404 insertions(+)
create mode 100644 arch/riscv/boot/dts/microchip/Makefile
create mode 100644 arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts
create mode 100644 arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi
diff --git a/arch/riscv/boot/dts/Makefile b/arch/riscv/boot/dts/Makefile
index 7ffd502e3e7b..fe996b88319e 100644
--- a/arch/riscv/boot/dts/Makefile
+++ b/arch/riscv/boot/dts/Makefile
@@ -1,5 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
subdir-y += sifive
subdir-$(CONFIG_SOC_CANAAN_K210_DTB_BUILTIN) += canaan
+subdir-y += microchip
obj-$(CONFIG_BUILTIN_DTB) := $(addsuffix /, $(subdir-y))
diff --git a/arch/riscv/boot/dts/microchip/Makefile
b/arch/riscv/boot/dts/microchip/Makefile
new file mode 100644
index ..622b12771fd3
--- /dev/null
+++ b/arch/riscv/boot/dts/microchip/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0
+dtb-$(CONFIG_SOC_MICROCHIP_POLARFIRE) += microchip-mpfs-icicle-kit.dtb
diff --git a/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts
b/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts
new file mode 100644
index ..ec79944065c9
--- /dev/null
+++ b/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts
@@ -0,0 +1,72 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/* Copyright (c) 2020 Microchip Technology Inc */
+
+/dts-v1/;
+
+#include "microchip-mpfs.dtsi"
+
+/* Clock frequency (in Hz) of the rtcclk */
+#define RTCCLK_FREQ100
+
+/ {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ model = "Microchip PolarFire-SoC Icicle Kit";
+ compatible = "microchip,mpfs-icicle-kit";
+
+ chosen {
+ stdout-path =
+ };
+
+ cpus {
+ timebase-frequency = ;
+ };
+
+ memory@8000 {
+ device_type = "memory";
+ reg = <0x0 0x8000 0x0 0x4000>;
+ clocks = < 26>;
+ };
+
The latest Microchip releases have two memory nodes to provide the
full 2GiB of memory space.
+ soc {
+ };
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ phy-mode = "sgmii";
+ phy-handle = <>;
+ phy0: ethernet-phy@8 {
+ reg = <8>;
+ ti,fifo-depth = <0x01>;
+ };
+};
+
+ {
+ status = "okay";
+ phy-mode = "sgmii";
+ phy-handle = <>;
+ phy1: ethernet-phy@9 {
+ reg = <9>;
+ ti,fifo-depth = <0x01>;
+ };
+};
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
https://www.codethink.co.uk/privacy.html
Re: [PATCH] riscv: Return -EFAULT if copy_to_user() failed in signal.c
On 02/03/2021 07:28, Tiezhu Yang wrote:
copy_to_user() returns the amount left to copy, it should return -EFAULT
if copy to user failed.
This looks technically correct, but the caller (only one)
will check for non-zero and will covert that to -EFAULT
in setup_rt_frame().
I expect if this change is done, it also needs to be done
for the callers too and there's a few others than assume
!=0 is an error.
I think it would be easier to define save_fp_state() to
return non-zero on error and note it does not return an
error code. It may be worth exiting the functio nif
the first __copy_to_user fails?
Note: setup_rt_frame -> setup_sigcontext -> save_fp_frame
Signed-off-by: Tiezhu Yang
---
arch/riscv/kernel/signal.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/riscv/kernel/signal.c b/arch/riscv/kernel/signal.c
index 65942b3..2238fc5 100644
--- a/arch/riscv/kernel/signal.c
+++ b/arch/riscv/kernel/signal.c
@@ -67,7 +67,7 @@ static long save_fp_state(struct pt_regs *regs,
fstate_save(current, regs);
err = __copy_to_user(state, >thread.fstate, sizeof(*state));
if (unlikely(err))
- return err;
+ return -EFAULT;
/* We support no other extension state at this time. */
for (i = 0; i < ARRAY_SIZE(sc_fpregs->q.reserved); i++) {
@@ -140,8 +140,12 @@ static long setup_sigcontext(struct rt_sigframe __user
*frame,
{
struct sigcontext __user *sc = >uc.uc_mcontext;
long err;
+
/* sc_regs is structured the same as the start of pt_regs */
err = __copy_to_user(>sc_regs, regs, sizeof(sc->sc_regs));
+ if (unlikely(err))
+ return -EFAULT;
+
/* Save the floating-point state. */
if (has_fpu)
err |= save_fp_state(regs, >sc_fpregs);
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
https://www.codethink.co.uk/privacy.html
Re: [PATCH v3 0/2] Let illegal access to user-space memory die
On 22/12/2020 02:35, Palmer Dabbelt wrote: On Thu, 03 Dec 2020 21:42:57 PST (-0800), tesh...@andestech.com wrote: Accesses to user-space memory without calling uaccess routine leads to hanging in page fault handler. Like arm64, we let it die earlier in page fault handler. Changes in v3: -Let no_context() use die_kernel_fault() helper Changes in v2: -Add a die_kernel_fault() helper -Split one long line code into two Eric Lin (2): riscv/mm: Introduce a die_kernel_fault() helper function riscv/mm: Prevent kernel module to access user memory without uaccess routines arch/riscv/mm/fault.c | 28 ++-- 1 file changed, 22 insertions(+), 6 deletions(-) Thanks, these will be on for-next when the merge window ends. Just tested this and it seems to be working. -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius https://www.codethink.co.uk/privacy.html
Re: [PATCH v1 0/5] Clock and reset improvements for Tegra ALSA drivers
On 12/01/2021 12:58, Dmitry Osipenko wrote: This series improves the handling of clock and reset controls of NVIDA Tegra ALSA drivers. Tegra HDA and AHUB drivers aren't handling resets properly, which needs to be fixed in order to unblock other patches related to fixes on the reset controller driver since HDA/AHUB are bound to fail once reset controller driver will be corrected. In particular ALSA drivers are relying on implicit de-assertion of resets which is done by the tegra-clk driver. It's not the business of the clk driver to touch resets and we need to fix this because it breaks reset/clk programming sequences of other Tegra drivers. Dmitry Osipenko (5): ALSA: hda/tegra: Use clk_bulk helpers ALSA: hda/tegra: Reset hardware ASoC: tegra: ahub: Use of_reset_control_array_get_exclusive() ASoC: tegra: ahub: Use clk_bulk helpers ASoC: tegra: ahub: Reset hardware properly sound/pci/hda/hda_tegra.c | 86 +-- sound/soc/tegra/tegra30_ahub.c | 103 ++--- sound/soc/tegra/tegra30_ahub.h | 6 +- 3 files changed, 49 insertions(+), 146 deletions(-) I wonder if this will help with the issues we saw when the tegra is the i2s clock slave. -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius https://www.codethink.co.uk/privacy.html
Re: [PATCH] i2c: tegra-bpmp: ignore DMA safe buffer flag
On 11/01/2021 14:27, Mikko Perttunen wrote: From: Muhammed Fazal Ignore I2C_M_DMA_SAFE flag as it does not make a difference for bpmp-i2c, but causes -EINVAL to be returned for valid transactions. Signed-off-by: Muhammed Fazal Cc: sta...@vger.kernel.org # v4.19+ Signed-off-by: Mikko Perttunen --- This fixes failures seen with PMIC probing tools on Tegra186+ boards. drivers/i2c/busses/i2c-tegra-bpmp.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/i2c/busses/i2c-tegra-bpmp.c b/drivers/i2c/busses/i2c-tegra-bpmp.c index ec7a7e917edd..998d4b21fb59 100644 --- a/drivers/i2c/busses/i2c-tegra-bpmp.c +++ b/drivers/i2c/busses/i2c-tegra-bpmp.c @@ -80,6 +80,9 @@ static int tegra_bpmp_xlate_flags(u16 flags, u16 *out) flags &= ~I2C_M_RECV_LEN; } + if (flags & I2C_M_DMA_SAFE) + flags &= ~I2C_M_DMA_SAFE; + Just a comment, you can do without the test here. Just doing this would have been fine: flags &= ~I2C_M_DMA_SAFE; -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius https://www.codethink.co.uk/privacy.html
Re: [RFC PATCH 2/3] RISC-V: Initial DTS for Microchip ICICLE board
On 03/11/2020 18:40, cyril.j...@microchip.com wrote: On 11/3/20 6:28 PM, Ben Dooks wrote: EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe On 03/11/2020 18:10, cyril.j...@microchip.com wrote: On 11/3/20 3:07 PM, Atish Patra wrote: EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe On Fri, Oct 30, 2020 at 2:20 PM Ben Dooks wrote: ,snip[ @Cyril : Can we enable both eMMC & sdcard at the same time ? I would put /both/ in but only enable the one in use for the moment. Our boards are booting of eMMC as supplied, so this isn't going to work as well. The eMMC is 8bit wide, and thus is only delivering 11MB/sec instead of 22MB/sec. This performance is still not great, but losing half the data-rate is just not good. I am not sure what should be enabled by default. Updating sdcard is much easier than eMMC card and we use that approach. @Cyril: Is there a way that we can enable both ? Yes, we can enable both but this requires a modification to the FPGA design. One of the guys prototyped this while I was away. We will move this along. This will require reprogramming the FPGA with a new design and HSS version. Regards, Cyril. I either missed or couldn't find a way of forcing the boot mode to be from the SD slot. Have I missed something? At the moment we'd like to have more storage available as the ~7G free on the eMMC is not enough. Currently, you need to program a different FPGA bitstream on the board to boot from SD-card. The different bitstream configures muxes on the board to connect the SD slot to the FPGA and the HSS included in the bit stream configures the FPGA IOs correctly. Links to the programming files are found in this document: https://github.com/polarfire-soc/polarfire-soc-documentation/blob/master/boards/mpfs-icicle-kit-es/updating-icicle-kit/updating-icicle-kit-design-and-linux.md Thanks, but i've no way of remotely re-writing the bitstream of the FPGA since the tools are x86 only and we're using a Pi3 to connect the boards we have to the network. -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius https://www.codethink.co.uk/privacy.html
Re: [RFC PATCH 2/3] RISC-V: Initial DTS for Microchip ICICLE board
On 03/11/2020 18:36, Atish Patra wrote: On Tue, Nov 3, 2020 at 10:28 AM Ben Dooks wrote: On 03/11/2020 18:10, cyril.j...@microchip.com wrote: On 11/3/20 3:07 PM, Atish Patra wrote: EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe On Fri, Oct 30, 2020 at 2:20 PM Ben Dooks wrote: ,snip[ @Cyril : Can we enable both eMMC & sdcard at the same time ? I would put /both/ in but only enable the one in use for the moment. Our boards are booting of eMMC as supplied, so this isn't going to work as well. The eMMC is 8bit wide, and thus is only delivering 11MB/sec instead of 22MB/sec. This performance is still not great, but losing half the data-rate is just not good. I am not sure what should be enabled by default. Updating sdcard is much easier than eMMC card and we use that approach. @Cyril: Is there a way that we can enable both ? Yes, we can enable both but this requires a modification to the FPGA design. One of the guys prototyped this while I was away. We will move this along. This will require reprogramming the FPGA with a new design and HSS version. Regards, Cyril. I either missed or couldn't find a way of forcing the boot mode to be from the SD slot. Have I missed something? At the moment we'd like to have more storage available as the ~7G free on the eMMC is not enough. I use tftpboot to load the kernel & DT from the network. SD card is enabled in this DT and Linux kernel uses SD slot instead of eMMC. To summarize, eMMC is used for HSS & U-Boot while SD card is used for Linux which makes more storage available to Linux. IMO, we should enable the sdcard for Linux DT until updated FPGA design & HSS is available. Interesting as for me the default is for Linux to use the eMMC as well. I can't see any way for forcing the selection lines in the DT to say eMMC vs SD. If there is a way of controlling the selection lines then it might be possible to have both cards enabled with a bus selection MUX in software. -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius https://www.codethink.co.uk/privacy.html
Re: [RFC PATCH 2/3] RISC-V: Initial DTS for Microchip ICICLE board
On 03/11/2020 18:10, cyril.j...@microchip.com wrote: On 11/3/20 3:07 PM, Atish Patra wrote: EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe On Fri, Oct 30, 2020 at 2:20 PM Ben Dooks wrote: ,snip[ @Cyril : Can we enable both eMMC & sdcard at the same time ? I would put /both/ in but only enable the one in use for the moment. Our boards are booting of eMMC as supplied, so this isn't going to work as well. The eMMC is 8bit wide, and thus is only delivering 11MB/sec instead of 22MB/sec. This performance is still not great, but losing half the data-rate is just not good. I am not sure what should be enabled by default. Updating sdcard is much easier than eMMC card and we use that approach. @Cyril: Is there a way that we can enable both ? Yes, we can enable both but this requires a modification to the FPGA design. One of the guys prototyped this while I was away. We will move this along. This will require reprogramming the FPGA with a new design and HSS version. Regards, Cyril. I either missed or couldn't find a way of forcing the boot mode to be from the SD slot. Have I missed something? At the moment we'd like to have more storage available as the ~7G free on the eMMC is not enough. -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius https://www.codethink.co.uk/privacy.html
Re: [RFC PATCH 2/3] RISC-V: Initial DTS for Microchip ICICLE board
On 03/11/2020 15:07, Atish Patra wrote: We could just modify the reg size but to allow more memory. I tried that for Linux but it didn't boot. Probably, DDR init code in HSS only initialized 1GB of memory. Yes, it is only looking at the low window which is 1GiB max. If it used the upper window it would get the 16GiB. I don't know how no-one noticed this issue before shipping a board out with this. I have updated the firmware on my second board but this only seems to currently fix a reboot issue with the eMMC. We can't update the DT for Linux until there is a public release of the updated firmware with 2GB enabled. Yeah, it is really annoying the boards turned up with a number of issues including the half memory. I assume there will be a new release of HSS and U-boot which at worse can insert new memory nodes into the device tree. -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius https://www.codethink.co.uk/privacy.html
Re: [RFC PATCH 2/3] RISC-V: Initial DTS for Microchip ICICLE board
compatible = "sifive,plic-1.0.0";
+ reg = <0x0 0xc00 0x0 0x400>;
+ riscv,ndev = <53>;
+ interrupt-controller;
+ interrupts-extended = <_intc 11
+ _intc 11 _intc 9
+ _intc 11 _intc 9
+ _intc 11 _intc 9
+ _intc 11 _intc 9>;
+ };
+
+ dma@300 {
+ compatible = "sifive,fu540-c000-pdma";
+ reg = <0x0 0x300 0x0 0x8000>;
+ interrupt-parent = <>;
+ interrupts = <23 24 25 26 27 28 29 30>;
+ #dma-cells = <1>;
+ };
+
+ refclk: refclk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <6>;
+ clock-output-names = "msspllclk";
+ };
+
+ clkcfg: clkcfg@20002000 {
+ compatible = "microchip,pfsoc-clkcfg";
+ reg = <0x0 0x20002000 0x0 0x1000>;
+ reg-names = "mss_sysreg";
+ clocks = <>;
+ #clock-cells = <1>;
+ clock-output-names = "cpuclk", "axiclk", "ahbclk", "ENVMclk", "MAC0clk", "MAC1clk", "MMCclk", "TIMERclk", "MMUART0clk", "MMUART1clk", "MMUART2clk", "MMUART3clk", "MMUART4clk", "SPI0clk", "SPI1clk", "I2C0clk",
"I2C1clk", "CAN0clk", "CAN1clk", "USBclk", "RESERVED", "RTCclk", "QSPIclk", "GPIO0clk", "GPIO1clk", "GPIO2clk", "DDRCclk", "FIC0clk", "FIC1clk", "FIC2clk", "FIC3clk", "ATHENAclk", "CFMclk";
+ };
+
H ow about doing something like
clock-output-names = "cpuclk", "axiclk", "ahbclk", "ENVMclk",
"MAC0clk", /* 0 -4 */
"MAC1clk", "MMCclk", "TIMERclk", "MMUART0clk",
"MMUART1clk", /* 5-9 */
this means we can easily work out what clocks are in which index
As per the previos email, I'd leave these all populated as coming back
and adding ones later is just going to be a pain with merge conflicts.
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
https://www.codethink.co.uk/privacy.html
Re: [RFC PATCH 2/3] RISC-V: Initial DTS for Microchip ICICLE board
On 30/10/2020 07:11, Atish Patra wrote:
On Thu, Oct 29, 2020 at 3:24 AM Ben Dooks wrote:
On 28/10/2020 23:27, Atish Patra wrote:
Add initial DTS for Microchip ICICLE board having only
essential devcies (clocks, sdhci, ethernet, serial, etc).
Signed-off-by: Atish Patra
---
arch/riscv/boot/dts/Makefile | 1 +
arch/riscv/boot/dts/microchip/Makefile| 2 +
.../microchip/microchip-icicle-kit-a000.dts | 313 ++
3 files changed, 316 insertions(+)
create mode 100644 arch/riscv/boot/dts/microchip/Makefile
create mode 100644
arch/riscv/boot/dts/microchip/microchip-icicle-kit-a000.dts
diff --git a/arch/riscv/boot/dts/Makefile b/arch/riscv/boot/dts/Makefile
index ca1f8cbd78c0..3ea94ea0a18a 100644
--- a/arch/riscv/boot/dts/Makefile
+++ b/arch/riscv/boot/dts/Makefile
@@ -1,5 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
subdir-y += sifive
subdir-y += kendryte
+subdir-y += microchip
obj-$(CONFIG_BUILTIN_DTB) := $(addsuffix /, $(subdir-y))
diff --git a/arch/riscv/boot/dts/microchip/Makefile
b/arch/riscv/boot/dts/microchip/Makefile
new file mode 100644
index ..55ad77521304
--- /dev/null
+++ b/arch/riscv/boot/dts/microchip/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0
+dtb-$(CONFIG_SOC_MICROCHIP_POLARFIRE) += microchip-icicle-kit-a000.dtb
diff --git a/arch/riscv/boot/dts/microchip/microchip-icicle-kit-a000.dts
b/arch/riscv/boot/dts/microchip/microchip-icicle-kit-a000.dts
new file mode 100644
index ..5848920af55c
--- /dev/null
+++ b/arch/riscv/boot/dts/microchip/microchip-icicle-kit-a000.dts
@@ -0,0 +1,313 @@
+// SPDX-License-Identifier: GPL-2.0+
+/* Copyright (c) 2020 Microchip Technology Inc */
+
+/dts-v1/;
+
+/* Clock frequency (in Hz) of the rtcclk */
+#define RTCCLK_FREQ 100
+
+/ {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ model = "Microchip PolarFire-SoC";
+ compatible = "microchip,polarfire-soc";
+
+ chosen {
+ stdout-path =
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ timebase-frequency = ;
+
+ cpu@0 {
+ clock-frequency = <0>;
+ compatible = "sifive,rocket0", "riscv";
+ device_type = "cpu";
+ i-cache-block-size = <64>;
+ i-cache-sets = <128>;
+ i-cache-size = <16384>;
+ reg = <0>;
+ riscv,isa = "rv64imac";
+ status = "disabled";
+
+ cpu0_intc: interrupt-controller {
+ #interrupt-cells = <1>;
+ compatible = "riscv,cpu-intc";
+ interrupt-controller;
+ };
+ };
+
+ cpu@1 {
+ clock-frequency = <0>;
+ compatible = "sifive,rocket0", "riscv";
+ d-cache-block-size = <64>;
+ d-cache-sets = <64>;
+ d-cache-size = <32768>;
+ d-tlb-sets = <1>;
+ d-tlb-size = <32>;
+ device_type = "cpu";
+ i-cache-block-size = <64>;
+ i-cache-sets = <64>;
+ i-cache-size = <32768>;
+ i-tlb-sets = <1>;
+ i-tlb-size = <32>;
+ mmu-type = "riscv,sv39";
+ reg = <1>;
+ riscv,isa = "rv64imafdc";
+ tlb-split;
+ status = "okay";
+
+ cpu1_intc: interrupt-controller {
+ #interrupt-cells = <1>;
+ compatible = "riscv,cpu-intc";
+ interrupt-controller;
+ };
+ };
+
+ cpu@2 {
+ clock-frequency = <0>;
+ compatible = "sifive,rocket0", "riscv";
+ d-cache-block-size = <64>;
+ d-cache-sets = <64>;
+ d-cache-size = <32768>;
+ d-tlb-sets = <1>;
+ d-tlb-size = <32>;
+ device_type = "cpu";
+ i-cache-block-size = <64>;
+ i-cache-sets = <64>;
+ i-cache-size = <32768>;
+ i-tlb-sets = <1>;
+ i-tlb-size = <32>;
+ mmu-type = "
Re: [RFC PATCH 2/3] RISC-V: Initial DTS for Microchip ICICLE board
On 30/10/2020 09:05, Anup Patel wrote: On Thu, Oct 29, 2020 at 4:58 AM Atish Patra wrote: Add initial DTS for Microchip ICICLE board having only essential devcies (clocks, sdhci, ethernet, serial, etc). Signed-off-by: Atish Patra --- arch/riscv/boot/dts/Makefile | 1 + arch/riscv/boot/dts/microchip/Makefile| 2 + .../microchip/microchip-icicle-kit-a000.dts | 313 ++ I suggest we split this DTS into two parts: 1. SOC (microchip-polarfire.dtsi) 2. Board (microchip-icicle-kit-a000.dts) I was just going to suggest that. -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius https://www.codethink.co.uk/privacy.html
Re: [RFC PATCH 3/3] RISC-V: Enable Microchip PolarFire ICICLE SoC
On 30/10/2020 09:09, Anup Patel wrote: On Thu, Oct 29, 2020 at 4:58 AM Atish Patra wrote: Enable Microchip PolarFire ICICLE soc config in defconfig. It allows the default upstream kernel to boot on PolarFire ICICLE board. Signed-off-by: Atish Patra --- Is there going to be a git tree with all the necessary support for the polarfire/icicle boards? I so far have updated yocto patches, a rebase to v5.9 and the v17 PCIe patches (which still don't work for us) -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius https://www.codethink.co.uk/privacy.html
Re: [RFC PATCH 2/3] RISC-V: Initial DTS for Microchip ICICLE board
cap-mmc-highspeed;
+ cap-sd-highspeed;
+ card-detect-delay = <200>;
+ sd-uhs-sdr12;
+ sd-uhs-sdr25;
+ sd-uhs-sdr50;
+ sd-uhs-sdr104;
+ max-frequency = <2>;
+ status = "okay";
+ };
Given eMMC is the default device, shouldn't that be default for the
device tree too? Even if not, having the emmc node here would be a
good thing as it is different to the SD node.
+
+ emac1: ethernet@20112000 {
+ compatible = "cdns,macb";
+ reg = <0x0 0x20112000 0x0 0x2000>;
+ interrupt-parent = <>;
+ interrupts = <70 71 72 73>;
+ mac-address = [56 34 12 00 FC 00];
+ phy-mode = "sgmii";
+ clocks = < 5>, < 2>;
+ clock-names = "pclk", "hclk";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ phy1: ethernet-phy@9 {
+ reg = <9>;
+ ti,fifo-depth = <0x01>;
+ };
+ };
Aren't there two ethernet ports on the board?
Also, at the moment u-boot is not filling the MAC address parameter
in so we've got at two boards on the network with the same MAC until
we override it in the device tree for the second.
+
+ uio_axi_lsram@203000 {
+ compatible = "generic-uio";
+ reg = <0x20 0x3000 0 0x8000 >;
+ status = "okay";
+ };
+ };
+};
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
https://www.codethink.co.uk/privacy.html
Re: [PATCH v7 10/10] Drivers: hv: Enable Hyper-V code to be built on ARM64
On 24/08/2020 18:24, Ard Biesheuvel wrote: On Mon, 24 Aug 2020 at 18:48, Michael Kelley wrote: Update drivers/hv/Kconfig so CONFIG_HYPERV can be selected on ARM64, causing the Hyper-V specific code to be built. Signed-off-by: Michael Kelley --- drivers/hv/Kconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig index 79e5356..1113e49 100644 --- a/drivers/hv/Kconfig +++ b/drivers/hv/Kconfig @@ -4,7 +4,8 @@ menu "Microsoft Hyper-V guest support" config HYPERV tristate "Microsoft Hyper-V client drivers" - depends on X86 && ACPI && X86_LOCAL_APIC && HYPERVISOR_GUEST + depends on ACPI && \ + ((X86 && X86_LOCAL_APIC && HYPERVISOR_GUEST) || ARM64) select PARAVIRT select X86_HV_CALLBACK_VECTOR help Given the comment in a previous patch +/* + * All data structures defined in the TLFS that are shared between Hyper-V + * and a guest VM use Little Endian byte ordering. This matches the default + * byte ordering of Linux running on ARM64, so no special handling is required. + */ shouldn't this depend on !CONFIG_CPU_BIG_ENDIAN ? or mark the data __le and have the appropriate accessor functions do the swapping. -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius https://www.codethink.co.uk/privacy.html
[tip: timers/urgent] timers/sched_clock: Include local timekeeping.h for missing declarations
The following commit has been merged into the timers/urgent branch of tip:
Commit-ID: 086ee46b08634a999bcd1707eabe3b0dc1806674
Gitweb:
https://git.kernel.org/tip/086ee46b08634a999bcd1707eabe3b0dc1806674
Author:Ben Dooks (Codethink)
AuthorDate:Tue, 22 Oct 2019 14:12:26 +01:00
Committer: Thomas Gleixner
CommitterDate: Wed, 23 Oct 2019 14:48:23 +02:00
timers/sched_clock: Include local timekeeping.h for missing declarations
Include the timekeeping.h header to get the declaration of the
sched_clock_{suspend,resume} functions. Fixes the following sparse
warnings:
kernel/time/sched_clock.c:275:5: warning: symbol 'sched_clock_suspend' was not
declared. Should it be static?
kernel/time/sched_clock.c:286:6: warning: symbol 'sched_clock_resume' was not
declared. Should it be static?
Signed-off-by: Ben Dooks (Codethink)
Signed-off-by: Thomas Gleixner
Link: https://lkml.kernel.org/r/20191022131226.11465-1-ben.do...@codethink.co.uk
---
kernel/time/sched_clock.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/time/sched_clock.c b/kernel/time/sched_clock.c
index 142b076..dbd6905 100644
--- a/kernel/time/sched_clock.c
+++ b/kernel/time/sched_clock.c
@@ -17,6 +17,8 @@
#include
#include
+#include "timekeeping.h"
+
/**
* struct clock_read_data - data required to read from sched_clock()
*
[PATCH] [V3] net: hwbm: if CONFIG_NET_HWBM unset, make stub functions static
If CONFIG_NET_HWBM is not set, then these stub functions in
should be declared static to avoid trying to
export them from any driver that includes this.
Fixes the following sparse warnings:
./include/net/hwbm.h:24:6: warning: symbol 'hwbm_buf_free' was not declared.
Should it be static?
./include/net/hwbm.h:25:5: warning: symbol 'hwbm_pool_refill' was not declared.
Should it be static?
./include/net/hwbm.h:26:5: warning: symbol 'hwbm_pool_add' was not declared.
Should it be static?
Signed-off-by: Ben Dooks (Codethink)
---
Cc: "David S. Miller"
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
v2:
- fix inline instead of __maybe_unused
v3:
- fix formatting issues
---
include/net/hwbm.h | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/include/net/hwbm.h b/include/net/hwbm.h
index 81643cf8a1c4..c81444611a22 100644
--- a/include/net/hwbm.h
+++ b/include/net/hwbm.h
@@ -21,9 +21,13 @@ void hwbm_buf_free(struct hwbm_pool *bm_pool, void *buf);
int hwbm_pool_refill(struct hwbm_pool *bm_pool, gfp_t gfp);
int hwbm_pool_add(struct hwbm_pool *bm_pool, unsigned int buf_num);
#else
-void hwbm_buf_free(struct hwbm_pool *bm_pool, void *buf) {}
-int hwbm_pool_refill(struct hwbm_pool *bm_pool, gfp_t gfp) { return 0; }
-int hwbm_pool_add(struct hwbm_pool *bm_pool, unsigned int buf_num)
+static inline void hwbm_buf_free(struct hwbm_pool *bm_pool, void *buf) {}
+
+static inline int hwbm_pool_refill(struct hwbm_pool *bm_pool, gfp_t gfp)
+{ return 0; }
+
+static inline int hwbm_pool_add(struct hwbm_pool *bm_pool,
+ unsigned int buf_num)
{ return 0; }
#endif /* CONFIG_HWBM */
#endif /* _HWBM_H */
--
2.23.0
[PATCH] [V2] net: mvneta: make stub functions static inline
If the CONFIG_MVNET_BA is not set, then make the stub functions
static inline to avoid trying to export them, and remove hte
following sparse warnings:
drivers/net/ethernet/marvell/mvneta_bm.h:163:6: warning: symbol
'mvneta_bm_pool_destroy' was not declared. Should it be static?
drivers/net/ethernet/marvell/mvneta_bm.h:165:6: warning: symbol
'mvneta_bm_bufs_free' was not declared. Should it be static?
drivers/net/ethernet/marvell/mvneta_bm.h:167:5: warning: symbol
'mvneta_bm_construct' was not declared. Should it be static?
drivers/net/ethernet/marvell/mvneta_bm.h:168:5: warning: symbol
'mvneta_bm_pool_refill' was not declared. Should it be static?
drivers/net/ethernet/marvell/mvneta_bm.h:170:23: warning: symbol
'mvneta_bm_pool_use' was not declared. Should it be static?
drivers/net/ethernet/marvell/mvneta_bm.h:181:18: warning: symbol
'mvneta_bm_get' was not declared. Should it be static?
drivers/net/ethernet/marvell/mvneta_bm.h:182:6: warning: symbol 'mvneta_bm_put'
was not declared. Should it be static?
Signed-off-by: Ben Dooks (Codethink)
---
Cc: "David S. Miller"
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
v2:
- fixup formatting of changes
fixup mvneta
---
drivers/net/ethernet/marvell/mvneta_bm.h | 32 +++-
1 file changed, 20 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvneta_bm.h
b/drivers/net/ethernet/marvell/mvneta_bm.h
index c8425d35c049..e47783ce77e0 100644
--- a/drivers/net/ethernet/marvell/mvneta_bm.h
+++ b/drivers/net/ethernet/marvell/mvneta_bm.h
@@ -160,16 +160,23 @@ static inline u32 mvneta_bm_pool_get_bp(struct mvneta_bm
*priv,
(bm_pool->id << MVNETA_BM_POOL_ACCESS_OFFS));
}
#else
-void mvneta_bm_pool_destroy(struct mvneta_bm *priv,
- struct mvneta_bm_pool *bm_pool, u8 port_map) {}
-void mvneta_bm_bufs_free(struct mvneta_bm *priv, struct mvneta_bm_pool
*bm_pool,
-u8 port_map) {}
-int mvneta_bm_construct(struct hwbm_pool *hwbm_pool, void *buf) { return 0; }
-int mvneta_bm_pool_refill(struct mvneta_bm *priv,
- struct mvneta_bm_pool *bm_pool) {return 0; }
-struct mvneta_bm_pool *mvneta_bm_pool_use(struct mvneta_bm *priv, u8 pool_id,
- enum mvneta_bm_type type, u8 port_id,
- int pkt_size) { return NULL; }
+static inline void mvneta_bm_pool_destroy(struct mvneta_bm *priv,
+ struct mvneta_bm_pool *bm_pool,
+ u8 port_map) {}
+static inline void mvneta_bm_bufs_free(struct mvneta_bm *priv,
+ struct mvneta_bm_pool *bm_pool,
+ u8 port_map) {}
+static inline int mvneta_bm_construct(struct hwbm_pool *hwbm_pool, void *buf)
+{ return 0; }
+static inline int mvneta_bm_pool_refill(struct mvneta_bm *priv,
+ struct mvneta_bm_pool *bm_pool)
+{ return 0; }
+static inline struct mvneta_bm_pool *mvneta_bm_pool_use(struct mvneta_bm *priv,
+ u8 pool_id,
+ enum mvneta_bm_type
type,
+ u8 port_id,
+ int pkt_size)
+{ return NULL; }
static inline void mvneta_bm_pool_put_bp(struct mvneta_bm *priv,
struct mvneta_bm_pool *bm_pool,
@@ -178,7 +185,8 @@ static inline void mvneta_bm_pool_put_bp(struct mvneta_bm
*priv,
static inline u32 mvneta_bm_pool_get_bp(struct mvneta_bm *priv,
struct mvneta_bm_pool *bm_pool)
{ return 0; }
-struct mvneta_bm *mvneta_bm_get(struct device_node *node) { return NULL; }
-void mvneta_bm_put(struct mvneta_bm *priv) {}
+static inline struct mvneta_bm *mvneta_bm_get(struct device_node *node)
+{ return NULL; }
+static inline void mvneta_bm_put(struct mvneta_bm *priv) {}
#endif /* CONFIG_MVNETA_BM */
#endif
--
2.23.0
[PATCH] xfs: add mising include of xfs_pnfs.h for missing declarations
The xfs_pnfs.c file is missing an include of xfs_pnfs.h to add the prototypes of the functions it exports. Include this file to fix the following sparse warnings: fs/xfs/xfs_pnfs.c:27:1: warning: symbol 'xfs_break_leased_layouts' was not declared. Should it be static? fs/xfs/xfs_pnfs.c:52:1: warning: symbol 'xfs_fs_get_uuid' was not declared. Should it be static? fs/xfs/xfs_pnfs.c:77:1: warning: symbol 'xfs_fs_map_blocks' was not declared. Should it be static? fs/xfs/xfs_pnfs.c:226:1: warning: symbol 'xfs_fs_commit_blocks' was not declared. Should it be static? Signed-off-by: Ben Dooks (Codethink) --- Cc: "Darrick J. Wong" Cc: linux-...@vger.kernel.org Cc: linux-kernel@vger.kernel.org --- fs/xfs/xfs_pnfs.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/xfs/xfs_pnfs.c b/fs/xfs/xfs_pnfs.c index a339bd5fa260..b2f6f1e3d9c4 100644 --- a/fs/xfs/xfs_pnfs.c +++ b/fs/xfs/xfs_pnfs.c @@ -12,6 +12,7 @@ #include "xfs_trans.h" #include "xfs_bmap.h" #include "xfs_iomap.h" +#include "xfs_pnfs.h" /* * Ensure that we do not have any outstanding pNFS layouts that can be used by -- 2.23.0
[PATCH] [V2] net: hwbm: if CONFIG_NET_HWBM unset, make stub functions static
If CONFIG_NET_HWBM is not set, then these stub functions in
should be declared static to avoid trying to
export them from any driver that includes this.
Fixes the following sparse warnings:
./include/net/hwbm.h:24:6: warning: symbol 'hwbm_buf_free' was not declared.
Should it be static?
./include/net/hwbm.h:25:5: warning: symbol 'hwbm_pool_refill' was not declared.
Should it be static?
./include/net/hwbm.h:26:5: warning: symbol 'hwbm_pool_add' was not declared.
Should it be static?
Signed-off-by: Ben Dooks (Codethink)
---
Cc: "David S. Miller"
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
include/net/hwbm.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/net/hwbm.h b/include/net/hwbm.h
index 81643cf8a1c4..76a303b2925c 100644
--- a/include/net/hwbm.h
+++ b/include/net/hwbm.h
@@ -21,9 +21,9 @@ void hwbm_buf_free(struct hwbm_pool *bm_pool, void *buf);
int hwbm_pool_refill(struct hwbm_pool *bm_pool, gfp_t gfp);
int hwbm_pool_add(struct hwbm_pool *bm_pool, unsigned int buf_num);
#else
-void hwbm_buf_free(struct hwbm_pool *bm_pool, void *buf) {}
-int hwbm_pool_refill(struct hwbm_pool *bm_pool, gfp_t gfp) { return 0; }
-int hwbm_pool_add(struct hwbm_pool *bm_pool, unsigned int buf_num)
+static inline void hwbm_buf_free(struct hwbm_pool *bm_pool, void *buf) {}
+static inline int hwbm_pool_refill(struct hwbm_pool *bm_pool, gfp_t gfp) {
return 0; }
+static inline int hwbm_pool_add(struct hwbm_pool *bm_pool, unsigned int
buf_num)
{ return 0; }
#endif /* CONFIG_HWBM */
#endif /* _HWBM_H */
--
2.23.0
Re: [PATCH] net: hwbm: if CONFIG_NET_HWBM unset, make stub functions static
On 22/10/2019 16:18, Ben Dooks (Codethink) wrote:
If CONFIG_NET_HWBM is not set, then these stub functions in
should be declared static to avoid trying to
export them from any driver that includes this.
Note, add __maybe_unused as the marvell mvneta.c driver will
otherwise cause gcc warnings from these.
urgh, static inline was what I was actually searching for here.
Fixes the following sparse warnings:
./include/net/hwbm.h:24:6: warning: symbol 'hwbm_buf_free' was not declared.
Should it be static?
./include/net/hwbm.h:25:5: warning: symbol 'hwbm_pool_refill' was not declared.
Should it be static?
./include/net/hwbm.h:26:5: warning: symbol 'hwbm_pool_add' was not declared.
Should it be static?
Signed-off-by: Ben Dooks (Codethink)
---
Cc: "David S. Miller"
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
include/net/hwbm.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/net/hwbm.h b/include/net/hwbm.h
index 81643cf8a1c4..cb5e6de8b7cd 100644
--- a/include/net/hwbm.h
+++ b/include/net/hwbm.h
@@ -21,9 +21,9 @@ void hwbm_buf_free(struct hwbm_pool *bm_pool, void *buf);
int hwbm_pool_refill(struct hwbm_pool *bm_pool, gfp_t gfp);
int hwbm_pool_add(struct hwbm_pool *bm_pool, unsigned int buf_num);
#else
-void hwbm_buf_free(struct hwbm_pool *bm_pool, void *buf) {}
-int hwbm_pool_refill(struct hwbm_pool *bm_pool, gfp_t gfp) { return 0; }
-int hwbm_pool_add(struct hwbm_pool *bm_pool, unsigned int buf_num)
+static void __maybe_unused hwbm_buf_free(struct hwbm_pool *bm_pool, void *buf)
{}
+static int __maybe_unused hwbm_pool_refill(struct hwbm_pool *bm_pool, gfp_t
gfp) { return 0; }
+static int __maybe_unused hwbm_pool_add(struct hwbm_pool *bm_pool, unsigned
int buf_num)
{ return 0; }
#endif /* CONFIG_HWBM */
#endif /* _HWBM_H */
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
https://www.codethink.co.uk/privacy.html
[PATCH] net: mvneta: make stub functions static inline
If the CONFIG_MVNET_BA is not set, then make the stub functions
static inline to avoid trying to export them, and remove hte
following sparse warnings:
drivers/net/ethernet/marvell/mvneta_bm.h:163:6: warning: symbol
'mvneta_bm_pool_destroy' was not declared. Should it be static?
drivers/net/ethernet/marvell/mvneta_bm.h:165:6: warning: symbol
'mvneta_bm_bufs_free' was not declared. Should it be static?
drivers/net/ethernet/marvell/mvneta_bm.h:167:5: warning: symbol
'mvneta_bm_construct' was not declared. Should it be static?
drivers/net/ethernet/marvell/mvneta_bm.h:168:5: warning: symbol
'mvneta_bm_pool_refill' was not declared. Should it be static?
drivers/net/ethernet/marvell/mvneta_bm.h:170:23: warning: symbol
'mvneta_bm_pool_use' was not declared. Should it be static?
drivers/net/ethernet/marvell/mvneta_bm.h:181:18: warning: symbol
'mvneta_bm_get' was not declared. Should it be static?
drivers/net/ethernet/marvell/mvneta_bm.h:182:6: warning: symbol 'mvneta_bm_put'
was not declared. Should it be static?
Signed-off-by: Ben Dooks (Codethink)
---
Cc: "David S. Miller"
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/ethernet/marvell/mvneta_bm.h | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvneta_bm.h
b/drivers/net/ethernet/marvell/mvneta_bm.h
index c8425d35c049..9c0c6e20cf80 100644
--- a/drivers/net/ethernet/marvell/mvneta_bm.h
+++ b/drivers/net/ethernet/marvell/mvneta_bm.h
@@ -160,14 +160,14 @@ static inline u32 mvneta_bm_pool_get_bp(struct mvneta_bm
*priv,
(bm_pool->id << MVNETA_BM_POOL_ACCESS_OFFS));
}
#else
-void mvneta_bm_pool_destroy(struct mvneta_bm *priv,
- struct mvneta_bm_pool *bm_pool, u8 port_map) {}
-void mvneta_bm_bufs_free(struct mvneta_bm *priv, struct mvneta_bm_pool
*bm_pool,
-u8 port_map) {}
-int mvneta_bm_construct(struct hwbm_pool *hwbm_pool, void *buf) { return 0; }
-int mvneta_bm_pool_refill(struct mvneta_bm *priv,
- struct mvneta_bm_pool *bm_pool) {return 0; }
-struct mvneta_bm_pool *mvneta_bm_pool_use(struct mvneta_bm *priv, u8 pool_id,
+static inline void mvneta_bm_pool_destroy(struct mvneta_bm *priv,
+ struct mvneta_bm_pool *bm_pool, u8
port_map) {}
+static inline void mvneta_bm_bufs_free(struct mvneta_bm *priv, struct
mvneta_bm_pool *bm_pool,
+ u8 port_map) {}
+static inline int mvneta_bm_construct(struct hwbm_pool *hwbm_pool, void *buf)
{ return 0; }
+static inline int mvneta_bm_pool_refill(struct mvneta_bm *priv,
+ struct mvneta_bm_pool *bm_pool) {return
0; }
+static inline struct mvneta_bm_pool *mvneta_bm_pool_use(struct mvneta_bm
*priv, u8 pool_id,
enum mvneta_bm_type type, u8 port_id,
int pkt_size) { return NULL; }
@@ -178,7 +178,7 @@ static inline void mvneta_bm_pool_put_bp(struct mvneta_bm
*priv,
static inline u32 mvneta_bm_pool_get_bp(struct mvneta_bm *priv,
struct mvneta_bm_pool *bm_pool)
{ return 0; }
-struct mvneta_bm *mvneta_bm_get(struct device_node *node) { return NULL; }
-void mvneta_bm_put(struct mvneta_bm *priv) {}
+static inline struct mvneta_bm *mvneta_bm_get(struct device_node *node) {
return NULL; }
+static inline void mvneta_bm_put(struct mvneta_bm *priv) {}
#endif /* CONFIG_MVNETA_BM */
#endif
--
2.23.0
[PATCH] net: hwbm: if CONFIG_NET_HWBM unset, make stub functions static
If CONFIG_NET_HWBM is not set, then these stub functions in
should be declared static to avoid trying to
export them from any driver that includes this.
Note, add __maybe_unused as the marvell mvneta.c driver will
otherwise cause gcc warnings from these.
Fixes the following sparse warnings:
./include/net/hwbm.h:24:6: warning: symbol 'hwbm_buf_free' was not declared.
Should it be static?
./include/net/hwbm.h:25:5: warning: symbol 'hwbm_pool_refill' was not declared.
Should it be static?
./include/net/hwbm.h:26:5: warning: symbol 'hwbm_pool_add' was not declared.
Should it be static?
Signed-off-by: Ben Dooks (Codethink)
---
Cc: "David S. Miller"
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
include/net/hwbm.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/net/hwbm.h b/include/net/hwbm.h
index 81643cf8a1c4..cb5e6de8b7cd 100644
--- a/include/net/hwbm.h
+++ b/include/net/hwbm.h
@@ -21,9 +21,9 @@ void hwbm_buf_free(struct hwbm_pool *bm_pool, void *buf);
int hwbm_pool_refill(struct hwbm_pool *bm_pool, gfp_t gfp);
int hwbm_pool_add(struct hwbm_pool *bm_pool, unsigned int buf_num);
#else
-void hwbm_buf_free(struct hwbm_pool *bm_pool, void *buf) {}
-int hwbm_pool_refill(struct hwbm_pool *bm_pool, gfp_t gfp) { return 0; }
-int hwbm_pool_add(struct hwbm_pool *bm_pool, unsigned int buf_num)
+static void __maybe_unused hwbm_buf_free(struct hwbm_pool *bm_pool, void *buf)
{}
+static int __maybe_unused hwbm_pool_refill(struct hwbm_pool *bm_pool, gfp_t
gfp) { return 0; }
+static int __maybe_unused hwbm_pool_add(struct hwbm_pool *bm_pool, unsigned
int buf_num)
{ return 0; }
#endif /* CONFIG_HWBM */
#endif /* _HWBM_H */
--
2.23.0
[PATCH] pinctrl: amd: fix __iomem annotation in amd_gpio_irq_handler()
The regs pointer in amd_gpio_irq_handler() should have __iomem on it, so add that to fix the following sparse warnings: drivers/pinctrl/pinctrl-amd.c:555:14: warning: incorrect type in assignment (different address spaces) drivers/pinctrl/pinctrl-amd.c:555:14:expected unsigned int [usertype] *regs drivers/pinctrl/pinctrl-amd.c:555:14:got void [noderef] *base drivers/pinctrl/pinctrl-amd.c:563:34: warning: incorrect type in argument 1 (different address spaces) drivers/pinctrl/pinctrl-amd.c:563:34:expected void const volatile [noderef] *addr drivers/pinctrl/pinctrl-amd.c:563:34:got unsigned int [usertype] * drivers/pinctrl/pinctrl-amd.c:580:34: warning: incorrect type in argument 1 (different address spaces) drivers/pinctrl/pinctrl-amd.c:580:34:expected void const volatile [noderef] *addr drivers/pinctrl/pinctrl-amd.c:580:34:got unsigned int [usertype] * drivers/pinctrl/pinctrl-amd.c:587:25: warning: incorrect type in argument 2 (different address spaces) drivers/pinctrl/pinctrl-amd.c:587:25:expected void volatile [noderef] *addr drivers/pinctrl/pinctrl-amd.c:587:25:got unsigned int [usertype] * Signed-off-by: Ben Dooks (Codethink) --- Cc: Linus Walleij Cc: linux-g...@vger.kernel.org Cc: linux-kernel@vger.kernel.org --- drivers/pinctrl/pinctrl-amd.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/pinctrl/pinctrl-amd.c b/drivers/pinctrl/pinctrl-amd.c index 2c61141519f8..eab078244a4c 100644 --- a/drivers/pinctrl/pinctrl-amd.c +++ b/drivers/pinctrl/pinctrl-amd.c @@ -540,7 +540,8 @@ static irqreturn_t amd_gpio_irq_handler(int irq, void *dev_id) irqreturn_t ret = IRQ_NONE; unsigned int i, irqnr; unsigned long flags; - u32 *regs, regval; + u32 __iomem *regs; + u32 regval; u64 status, mask; /* Read the wake status */ -- 2.23.0
[PATCH] ipv6: include for missing declarations
Include for the missing declarations of various functions. Fixes the following sparse warnings: net/ipv6/addrconf_core.c:94:5: warning: symbol 'register_inet6addr_notifier' was not declared. Should it be static? net/ipv6/addrconf_core.c:100:5: warning: symbol 'unregister_inet6addr_notifier' was not declared. Should it be static? net/ipv6/addrconf_core.c:106:5: warning: symbol 'inet6addr_notifier_call_chain' was not declared. Should it be static? net/ipv6/addrconf_core.c:112:5: warning: symbol 'register_inet6addr_validator_notifier' was not declared. Should it be static? net/ipv6/addrconf_core.c:118:5: warning: symbol 'unregister_inet6addr_validator_notifier' was not declared. Should it be static? net/ipv6/addrconf_core.c:125:5: warning: symbol 'inet6addr_validator_notifier_call_chain' was not declared. Should it be static? net/ipv6/addrconf_core.c:237:6: warning: symbol 'in6_dev_finish_destroy' was not declared. Should it be static? Signed-off-by: Ben Dooks (Codethink) --- Cc: "David S. Miller" Cc: Alexey Kuznetsov Cc: Hideaki YOSHIFUJI Cc: net...@vger.kernel.org Cc: linux-kernel@vger.kernel.org --- net/ipv6/addrconf_core.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/ipv6/addrconf_core.c b/net/ipv6/addrconf_core.c index 783f3c1466da..2fc079284ca4 100644 --- a/net/ipv6/addrconf_core.c +++ b/net/ipv6/addrconf_core.c @@ -7,6 +7,7 @@ #include #include #include +#include #include /* if ipv6 module registers this function is used by xfrm to force all -- 2.23.0
[PATCH] timers/sched_clock: include local timekeeping.h for missing declarations
Include the timekeeping.h header to get the declaration of the
sched_clock_{suspend,resume} functions. Fixes the following
sparse warnings:
kernel/time/sched_clock.c:275:5: warning: symbol 'sched_clock_suspend' was not
declared. Should it be static?
kernel/time/sched_clock.c:286:6: warning: symbol 'sched_clock_resume' was not
declared. Should it be static?
Signed-off-by: Ben Dooks (Codethink)
---
Cc: Thomas Gleixner
Cc: linux-kernel@vger.kernel.org
---
kernel/time/sched_clock.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/time/sched_clock.c b/kernel/time/sched_clock.c
index 142b07619918..dbd69052eaa6 100644
--- a/kernel/time/sched_clock.c
+++ b/kernel/time/sched_clock.c
@@ -17,6 +17,8 @@
#include
#include
+#include "timekeeping.h"
+
/**
* struct clock_read_data - data required to read from sched_clock()
*
--
2.23.0
[PATCH] xdp: fix type of string pointer in __XDP_ACT_SYM_TAB
The table entry in __XDP_ACT_SYM_TAB for the last item is set
to { -1, 0 } where it should be { -1, NULL } as the second item
is a pointer to a string.
Fixes the following sparse warnings:
./include/trace/events/xdp.h:28:1: warning: Using plain integer as NULL pointer
./include/trace/events/xdp.h:53:1: warning: Using plain integer as NULL pointer
./include/trace/events/xdp.h:82:1: warning: Using plain integer as NULL pointer
./include/trace/events/xdp.h:140:1: warning: Using plain integer as NULL pointer
./include/trace/events/xdp.h:155:1: warning: Using plain integer as NULL pointer
./include/trace/events/xdp.h:190:1: warning: Using plain integer as NULL pointer
./include/trace/events/xdp.h:225:1: warning: Using plain integer as NULL pointer
./include/trace/events/xdp.h:260:1: warning: Using plain integer as NULL pointer
./include/trace/events/xdp.h:318:1: warning: Using plain integer as NULL pointer
./include/trace/events/xdp.h:356:1: warning: Using plain integer as NULL pointer
./include/trace/events/xdp.h:390:1: warning: Using plain integer as NULL pointer
Signed-off-by: Ben Dooks (Codethink)
---
Cc: Alexei Starovoitov
Cc: Daniel Borkmann
Cc: Martin KaFai Lau
Cc: Song Liu
Cc: Yonghong Song
Cc: Steven Rostedt
Cc: Ingo Molnar
Cc: "David S. Miller"
Cc: Jakub Kicinski
Cc: Jesper Dangaard Brouer
Cc: John Fastabend
Cc: net...@vger.kernel.org
Cc: b...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
include/trace/events/xdp.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/trace/events/xdp.h b/include/trace/events/xdp.h
index 8c8420230a10..c7e3c9c5bad3 100644
--- a/include/trace/events/xdp.h
+++ b/include/trace/events/xdp.h
@@ -22,7 +22,7 @@
#define __XDP_ACT_SYM_FN(x)\
{ XDP_##x, #x },
#define __XDP_ACT_SYM_TAB \
- __XDP_ACT_MAP(__XDP_ACT_SYM_FN) { -1, 0 }
+ __XDP_ACT_MAP(__XDP_ACT_SYM_FN) { -1, NULL }
__XDP_ACT_MAP(__XDP_ACT_TP_FN)
TRACE_EVENT(xdp_exception,
--
2.23.0
[PATCH] cpu-topology: declare parse_acpi_topology in
The parse_acpi_topology() is not declared anywhere which causes the following sparse warning: drivers/base/arch_topology.c:522:19: warning: symbol 'parse_acpi_topology' was not declared. Should it be static? Signed-off-by: Ben Dooks (Codethink) --- Cc: Sudeep Holla Cc: linux-kernel@vger.kernel.org Cc: gre...@linuxfoundation.org --- include/linux/arch_topology.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/linux/arch_topology.h b/include/linux/arch_topology.h index 42f2b5126094..3015ecbb90b1 100644 --- a/include/linux/arch_topology.h +++ b/include/linux/arch_topology.h @@ -57,6 +57,7 @@ const struct cpumask *cpu_coregroup_mask(int cpu); void update_siblings_masks(unsigned int cpu); void remove_cpu_topology(unsigned int cpuid); void reset_cpu_topology(void); +int parse_acpi_topology(void); #endif #endif /* _LINUX_ARCH_TOPOLOGY_H_ */ -- 2.23.0
Re: [PATCH] RFC: cpu-topology: declare parse_acpi_topology in
On 21/10/2019 17:52, Sudeep Holla wrote: On Mon, Oct 21, 2019 at 05:25:30PM +0100, Ben Dooks (Codethink) wrote: The parse_acpi_topology() is not declared anywhere which causes the following sparse warning: drivers/base/arch_topology.c:522:19: warning: symbol 'parse_acpi_topology' was not declared. Should it be static? RFC: is this the best place to put it? Signed-off-by: Ben Dooks (Codethink) --- Cc: Sudeep Holla Cc: linux-kernel@vger.kernel.org --- include/linux/arch_topology.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/linux/arch_topology.h b/include/linux/arch_topology.h index 42f2b5126094..7ae32900d9a2 100644 --- a/include/linux/arch_topology.h +++ b/include/linux/arch_topology.h @@ -59,4 +59,6 @@ void remove_cpu_topology(unsigned int cpuid); void reset_cpu_topology(void); #endif +extern int parse_acpi_topology(void); + Can we drop extern like other declarations here ? Also move this inside CONFIG_GENERIC_ARCH_TOPOLOGY ? Please cc Greg with these changes, I will ack and ask Greg to pick up. Thanks. Ok, thank you for the input. -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius https://www.codethink.co.uk/privacy.html
[PATCH] RFC: cpu-topology: declare parse_acpi_topology in
The parse_acpi_topology() is not declared anywhere which causes the following sparse warning: drivers/base/arch_topology.c:522:19: warning: symbol 'parse_acpi_topology' was not declared. Should it be static? RFC: is this the best place to put it? Signed-off-by: Ben Dooks (Codethink) --- Cc: Sudeep Holla Cc: linux-kernel@vger.kernel.org --- include/linux/arch_topology.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/linux/arch_topology.h b/include/linux/arch_topology.h index 42f2b5126094..7ae32900d9a2 100644 --- a/include/linux/arch_topology.h +++ b/include/linux/arch_topology.h @@ -59,4 +59,6 @@ void remove_cpu_topology(unsigned int cpuid); void reset_cpu_topology(void); #endif +extern int parse_acpi_topology(void); + #endif /* _LINUX_ARCH_TOPOLOGY_H_ */ -- 2.23.0
sparse: __pure declaration only
I'm seeing the following sparse warnings where the declaration has __pure but the implementation does not. lib/bitmap.c:62:6: error: symbol '__bitmap_or_equal' redeclared with different type (originally declared at ./include/linux/bitmap.h:123) - different modifiers is this a valid warning? if not, should sparse be ignoring these. Note: include/linux/bitmap.h:extern bool __pure __bitmap_or_equal(const unsigned long *src1, lib/bitmap.c:bool __bitmap_or_equal(const unsigned long *bitmap1, -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius https://www.codethink.co.uk/privacy.html
Re: [PATCH] ptp_pch: include ethernet driver for external functions
On 18/10/2019 11:51, Ben Dooks (Codethink) wrote: The driver uses a number of functions from the ethernet driver so include the header to remove the following warnings from sparse about undeclared functions: drivers/ptp/ptp_pch.c:182:5: warning: symbol 'pch_ch_control_read' was not declared. Should it be static? drivers/ptp/ptp_pch.c:193:6: warning: symbol 'pch_ch_control_write' was not declared. Should it be static? drivers/ptp/ptp_pch.c:201:5: warning: symbol 'pch_ch_event_read' was not declared. Should it be static? drivers/ptp/ptp_pch.c:212:6: warning: symbol 'pch_ch_event_write' was not declared. Should it be static? drivers/ptp/ptp_pch.c:220:5: warning: symbol 'pch_src_uuid_lo_read' was not declared. Should it be static? drivers/ptp/ptp_pch.c:231:5: warning: symbol 'pch_src_uuid_hi_read' was not declared. Should it be static? drivers/ptp/ptp_pch.c:242:5: warning: symbol 'pch_rx_snap_read' was not declared. Should it be static? drivers/ptp/ptp_pch.c:259:5: warning: symbol 'pch_tx_snap_read' was not declared. Should it be static? drivers/ptp/ptp_pch.c:300:5: warning: symbol 'pch_set_station_address' was not declared. Should it be static? Should we include the header file from the ethernet driver directly or if not, where should the declarations go? Signed-off-by: Ben Dooks (Codethink) --- Cc: Richard Cochran Cc: net...@vger.kernel.org Cc: linux-kernel@vger.kernel.org --- drivers/ptp/ptp_pch.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/ptp/ptp_pch.c b/drivers/ptp/ptp_pch.c index dcd6e00c8046..2bb1184b6359 100644 --- a/drivers/ptp/ptp_pch.c +++ b/drivers/ptp/ptp_pch.c @@ -20,6 +20,8 @@ #include #include +#include <../net/ethernet/oki-semi/pch_gbe/pch_gbe.h> oops, missed saving the version with ../../drivers/net + #define STATION_ADDR_LEN 20 #define PCI_DEVICE_ID_PCH_15880x8819 #define IO_MEM_BAR 1 -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius https://www.codethink.co.uk/privacy.html
[PATCH] ptp_pch: include ethernet driver for external functions
The driver uses a number of functions from the ethernet driver so include the header to remove the following warnings from sparse about undeclared functions: drivers/ptp/ptp_pch.c:182:5: warning: symbol 'pch_ch_control_read' was not declared. Should it be static? drivers/ptp/ptp_pch.c:193:6: warning: symbol 'pch_ch_control_write' was not declared. Should it be static? drivers/ptp/ptp_pch.c:201:5: warning: symbol 'pch_ch_event_read' was not declared. Should it be static? drivers/ptp/ptp_pch.c:212:6: warning: symbol 'pch_ch_event_write' was not declared. Should it be static? drivers/ptp/ptp_pch.c:220:5: warning: symbol 'pch_src_uuid_lo_read' was not declared. Should it be static? drivers/ptp/ptp_pch.c:231:5: warning: symbol 'pch_src_uuid_hi_read' was not declared. Should it be static? drivers/ptp/ptp_pch.c:242:5: warning: symbol 'pch_rx_snap_read' was not declared. Should it be static? drivers/ptp/ptp_pch.c:259:5: warning: symbol 'pch_tx_snap_read' was not declared. Should it be static? drivers/ptp/ptp_pch.c:300:5: warning: symbol 'pch_set_station_address' was not declared. Should it be static? Should we include the header file from the ethernet driver directly or if not, where should the declarations go? Signed-off-by: Ben Dooks (Codethink) --- Cc: Richard Cochran Cc: net...@vger.kernel.org Cc: linux-kernel@vger.kernel.org --- drivers/ptp/ptp_pch.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/ptp/ptp_pch.c b/drivers/ptp/ptp_pch.c index dcd6e00c8046..2bb1184b6359 100644 --- a/drivers/ptp/ptp_pch.c +++ b/drivers/ptp/ptp_pch.c @@ -20,6 +20,8 @@ #include #include +#include <../net/ethernet/oki-semi/pch_gbe/pch_gbe.h> + #define STATION_ADDR_LEN 20 #define PCI_DEVICE_ID_PCH_1588 0x8819 #define IO_MEM_BAR 1 -- 2.23.0
[PATCH] remoteproc: fix argument 2 of rproc_mem_entry_init
The rproc_mem_entry_init() call takes a pointer to a vm
as the second argument. The code is currently using a
plain 0 as "NULL". Change to using NULL to fix the
following sparse warnings:
drivers/remoteproc/remoteproc_core.c:339:49: warning: Using plain integer as
NULL pointer
drivers/remoteproc/remoteproc_core.c:916:46: warning: Using plain integer as
NULL pointer
Signed-off-by: Ben Dooks
---
Cc: Ohad Ben-Cohen
Cc: Bjorn Andersson
Cc: linux-remotep...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/remoteproc/remoteproc_core.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/remoteproc/remoteproc_core.c
b/drivers/remoteproc/remoteproc_core.c
index 3c5fbbbfb0f1..943af836fa0f 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -336,7 +336,8 @@ int rproc_alloc_vring(struct rproc_vdev *rvdev, int i)
return -ENOMEM;
} else {
/* Register carveout in in list */
- mem = rproc_mem_entry_init(dev, 0, 0, size, rsc->vring[i].da,
+ mem = rproc_mem_entry_init(dev, NULL, 0,
+ size, rsc->vring[i].da,
rproc_alloc_carveout,
rproc_release_carveout,
"vdev%dvring%d",
@@ -913,7 +914,7 @@ static int rproc_handle_carveout(struct rproc *rproc,
}
/* Register carveout in in list */
- carveout = rproc_mem_entry_init(dev, 0, 0, rsc->len, rsc->da,
+ carveout = rproc_mem_entry_init(dev, NULL, 0, rsc->len, rsc->da,
rproc_alloc_carveout,
rproc_release_carveout, rsc->name);
if (!carveout) {
--
2.23.0
[PATCH] rapidio: fix missing include of
Include for the missing declarations of functions exported from this file. Fixes the following sparse warnings: drivers/rapidio/rio-access.c:59:1: warning: symbol '__rio_local_read_config_8' was not declared. Should it be static? drivers/rapidio/rio-access.c:60:1: warning: symbol '__rio_local_read_config_16' was not declared. Should it be static? drivers/rapidio/rio-access.c:61:1: warning: symbol '__rio_local_read_config_32' was not declared. Should it be static? drivers/rapidio/rio-access.c:62:1: warning: symbol '__rio_local_write_config_8' was not declared. Should it be static? drivers/rapidio/rio-access.c:63:1: warning: symbol '__rio_local_write_config_16' was not declared. Should it be static? drivers/rapidio/rio-access.c:64:1: warning: symbol '__rio_local_write_config_32' was not declared. Should it be static? drivers/rapidio/rio-access.c:112:1: warning: symbol 'rio_mport_read_config_8' was not declared. Should it be static? drivers/rapidio/rio-access.c:113:1: warning: symbol 'rio_mport_read_config_16' was not declared. Should it be static? drivers/rapidio/rio-access.c:114:1: warning: symbol 'rio_mport_read_config_32' was not declared. Should it be static? drivers/rapidio/rio-access.c:115:1: warning: symbol 'rio_mport_write_config_8' was not declared. Should it be static? drivers/rapidio/rio-access.c:116:1: warning: symbol 'rio_mport_write_config_16' was not declared. Should it be static? drivers/rapidio/rio-access.c:117:1: warning: symbol 'rio_mport_write_config_32' was not declared. Should it be static? drivers/rapidio/rio-access.c:136:5: warning: symbol 'rio_mport_send_doorbell' was not declared. Should it be static? Signed-off-by: Ben Dooks --- Cc: Matt Porter Cc: Alexandre Bounine Cc: linux-kernel@vger.kernel.org --- drivers/rapidio/rio-access.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/rapidio/rio-access.c b/drivers/rapidio/rio-access.c index 33c8d1ecc988..f9e10647f94e 100644 --- a/drivers/rapidio/rio-access.c +++ b/drivers/rapidio/rio-access.c @@ -9,6 +9,8 @@ #include #include +#include + /* * Wrappers for all RIO configuration access functions. They just check * alignment and call the low-level functions pointed to by rio_mport->ops. -- 2.23.0
[PATCH] rapidio: fix missing include of
Include for the missing declarations of functions exported from this file. Fixes the following sparse warnings: drivers/rapidio/rio-driver.c:53:16: warning: symbol 'rio_dev_get' was not declared. Should it be static? drivers/rapidio/rio-driver.c:70:6: warning: symbol 'rio_dev_put' was not declared. Should it be static? drivers/rapidio/rio-driver.c:150:5: warning: symbol 'rio_register_driver' was not declared. Should it be static? drivers/rapidio/rio-driver.c:169:6: warning: symbol 'rio_unregister_driver' was not declared. Should it be static? Signed-off-by: Ben Dooks --- Cc: Matt Porter Cc: Alexandre Bounine Cc: linux-kernel@vger.kernel.org --- drivers/rapidio/rio-driver.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/rapidio/rio-driver.c b/drivers/rapidio/rio-driver.c index 2d99a3712b72..72874153972e 100644 --- a/drivers/rapidio/rio-driver.c +++ b/drivers/rapidio/rio-driver.c @@ -10,6 +10,7 @@ #include #include #include +#include #include "rio.h" -- 2.23.0
[PATCH] pcmcia: include for pcmcia_parse_tuple
Include for pcmcia_parse_tuple declaration
to fix the following sparse warning:
drivers/pcmcia/cistpl.c:1287:5: warning: symbol 'pcmcia_parse_tuple' was not
declared. Should it be static?
Signed-off-by: Ben Dooks
---
Cc: Dominik Brodowski
Cc: Greg Kroah-Hartman
Cc: linux-kernel@vger.kernel.org
.. (open list)
---
drivers/pcmcia/cistpl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/pcmcia/cistpl.c b/drivers/pcmcia/cistpl.c
index 629359fe3513..cf109d9a1112 100644
--- a/drivers/pcmcia/cistpl.c
+++ b/drivers/pcmcia/cistpl.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include "cs_internal.h"
static const u_char mantissa[] = {
--
2.23.0
[PATCH] pcmcia: include cs_internal.h for missing declarations
Include cs_internal.h (and pcmcia/cistpl.h as required by
cs_internal.h) for the declearions of cb_alloc and cb_free
to silence the following sparse warnings;
drivers/pcmcia/cardbus.c:64:11: warning: symbol 'cb_alloc' was not declared.
Should it be static?
drivers/pcmcia/cardbus.c:103:6: warning: symbol 'cb_free' was not declared.
Should it be static?
Signed-off-by: Ben Dooks
---
Cc: Dominik Brodowski
Cc: Greg Kroah-Hartman
Cc: linux-kernel@vger.kernel.org
---
drivers/pcmcia/cardbus.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/pcmcia/cardbus.c b/drivers/pcmcia/cardbus.c
index c502dfbf66e3..45c8252c8edc 100644
--- a/drivers/pcmcia/cardbus.c
+++ b/drivers/pcmcia/cardbus.c
@@ -22,7 +22,9 @@
#include
#include
+#include
+#include "cs_internal.h"
static void cardbus_config_irq_and_cls(struct pci_bus *bus, int irq)
{
--
2.23.0
[PATCH] irqchip/gic-v3-its: fix u64 to __le64 warnings
The its_cmd_block struct can either have u64 or __le64
data in it, so make a anonymous union to remove the
sparse warnings when converting to/from these.
Signed-off-by: Ben Dooks
---
Cc: Thomas Gleixner
Cc: Jason Cooper
Cc: Marc Zyngier
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/irqchip/irq-gic-v3-its.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 62e54f1a248b..f2b585905ba0 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -289,7 +289,10 @@ struct its_cmd_desc {
* The ITS command block, which is what the ITS actually parses.
*/
struct its_cmd_block {
- u64 raw_cmd[4];
+ union {
+ u64 raw_cmd[4];
+ __le64 raw_cmd_le[4];
+ };
};
#define ITS_CMD_QUEUE_SZ SZ_64K
@@ -398,10 +401,10 @@ static void its_encode_vpt_size(struct its_cmd_block
*cmd, u8 vpt_size)
static inline void its_fixup_cmd(struct its_cmd_block *cmd)
{
/* Let's fixup BE commands */
- cmd->raw_cmd[0] = cpu_to_le64(cmd->raw_cmd[0]);
- cmd->raw_cmd[1] = cpu_to_le64(cmd->raw_cmd[1]);
- cmd->raw_cmd[2] = cpu_to_le64(cmd->raw_cmd[2]);
- cmd->raw_cmd[3] = cpu_to_le64(cmd->raw_cmd[3]);
+ cmd->raw_cmd_le[0] = cpu_to_le64(cmd->raw_cmd[0]);
+ cmd->raw_cmd_le[1] = cpu_to_le64(cmd->raw_cmd[1]);
+ cmd->raw_cmd_le[2] = cpu_to_le64(cmd->raw_cmd[2]);
+ cmd->raw_cmd_le[3] = cpu_to_le64(cmd->raw_cmd[3]);
}
static struct its_collection *its_build_mapd_cmd(struct its_node *its,
--
2.23.0
Re: [PATCH] net: stmmac: fix argument to stmmac_pcs_ctrl_ane()
On 16/10/2019 21:28, David Miller wrote: From: "Ben Dooks (Codethink)" Date: Wed, 16 Oct 2019 09:22:05 +0100 The stmmac_pcs_ctrl_ane() expects a register address as argument 1, but for some reason the mac_device_info is being passed. Fix the warning (and possible bug) from sparse: drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2613:17: warning: incorrect type in argument 1 (different address spaces) drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2613:17:expected void [noderef] *ioaddr drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2613:17:got struct mac_device_info *hw Signed-off-by: Ben Dooks I'm still reviewing this but FYI you did not have to send this twice. Yes, I accidentally sent the wrong patch out (already apologised on the re-send as I noticed it about 10 minutes after sending). -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius https://www.codethink.co.uk/privacy.html
[PATCH] [V2] NFSv4: add declaration of current_stateid
From: Ben Dooks
The current_stateid is exported from nfs4state.c but not
declared in any of the headers. Add to nfs4_fs.h to
remove the following warning:
fs/nfs/nfs4state.c:80:20: warning: symbol 'current_stateid' was not declared.
Should it be static?
Signed-off-by: Ben Dooks
---
Cc: Trond Myklebust
Cc: Anna Schumaker
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
chnages since v1:
- removed extra definition of current_stateid
- renamed nfs4_stateid_is_current's current_stateid to avoid shadow
---
fs/nfs/nfs4_fs.h | 2 ++
fs/nfs/nfs4proc.c | 6 +++---
fs/nfs/pnfs.c | 2 --
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/fs/nfs/nfs4_fs.h b/fs/nfs/nfs4_fs.h
index 16b2e5cc3e94..330f45268060 100644
--- a/fs/nfs/nfs4_fs.h
+++ b/fs/nfs/nfs4_fs.h
@@ -445,6 +445,8 @@ extern void nfs4_set_lease_period(struct nfs_client *clp,
/* nfs4state.c */
+extern const nfs4_stateid current_stateid;
+
const struct cred *nfs4_get_clid_cred(struct nfs_client *clp);
const struct cred *nfs4_get_machine_cred(struct nfs_client *clp);
const struct cred *nfs4_get_renew_cred(struct nfs_client *clp);
diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
index ab8ca20fd579..ef914d8ba5b7 100644
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -5101,12 +5101,12 @@ static bool nfs4_stateid_is_current(nfs4_stateid
*stateid,
const struct nfs_lock_context *l_ctx,
fmode_t fmode)
{
- nfs4_stateid current_stateid;
+ nfs4_stateid _current_stateid;
/* If the current stateid represents a lost lock, then exit */
- if (nfs4_set_rw_stateid(_stateid, ctx, l_ctx, fmode) == -EIO)
+ if (nfs4_set_rw_stateid(&_current_stateid, ctx, l_ctx, fmode) == -EIO)
return true;
- return nfs4_stateid_match(stateid, _stateid);
+ return nfs4_stateid_match(stateid, &_current_stateid);
}
static bool nfs4_error_stateid_expired(int err)
diff --git a/fs/nfs/pnfs.c b/fs/nfs/pnfs.c
index bb80034a7661..cec3070ab577 100644
--- a/fs/nfs/pnfs.c
+++ b/fs/nfs/pnfs.c
@@ -2160,8 +2160,6 @@ _pnfs_grab_empty_layout(struct inode *ino, struct
nfs_open_context *ctx)
return NULL;
}
-extern const nfs4_stateid current_stateid;
-
static void _lgopen_prepare_attached(struct nfs4_opendata *data,
struct nfs_open_context *ctx)
{
--
2.23.0
Re: [PATCH] NFSv4: add declaration of current_stateid
On 15/10/2019 17:31, Christoph Hellwig wrote: On Tue, Oct 15, 2019 at 01:19:53PM +0100, Ben Dooks wrote: The current_stateid is exported from nfs4state.c but not declared in any of the headers. Add to nfs4_fs.h to remove the following warning: I think you also need to remove the extern in pnfs.c as well. ok, thanks, will sort. Also nfs4_stateid_is_current has a local variable with the same name, so you might want to rename that so that we don't get symbol shadowing warnings. ok, will do. -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius https://www.codethink.co.uk/privacy.html
Re: [Linux-kernel] [PATCH] net: bpf: add static in net/core/filter.c
On 16/10/2019 14:11, Ben Dooks wrote:
On 16/10/2019 14:10, Daniel Borkmann wrote:
On Wed, Oct 16, 2019 at 02:02:31PM +0100, Ben Dooks wrote:
On 16/10/2019 13:26, Daniel Borkmann wrote:
On Wed, Oct 16, 2019 at 12:04:46PM +0100, Ben Dooks (Codethink) wrote:
There are a number of structs in net/core/filter.c
that are not exported or declared outside of the
file. Fix the following warnings by making these
all static:
net/core/filter.c:8465:31: warning: symbol 'sk_filter_verifier_ops'
was not declared. Should it be static?
net/core/filter.c:8472:27: warning: symbol 'sk_filter_prog_ops' was
not declared. Should it be static?
[...]
net/core/filter.c:8935:27: warning: symbol 'sk_reuseport_prog_ops'
was not declared. Should it be static?
Signed-off-by: Ben Dooks
---
Cc: Alexei Starovoitov
Cc: Daniel Borkmann
Cc: Martin KaFai Lau
Cc: Song Liu
Cc: Yonghong Song
Cc: "David S. Miller"
Cc: Jakub Kicinski
Cc: Jesper Dangaard Brouer
Cc: John Fastabend
Cc: net...@vger.kernel.org
Cc: b...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
net/core/filter.c | 60
+++
1 file changed, 30 insertions(+), 30 deletions(-)
diff --git a/net/core/filter.c b/net/core/filter.c
index ed6563622ce3..f7338fee41f8 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -8462,18 +8462,18 @@ static u32 sk_msg_convert_ctx_access(enum
bpf_access_type type,
return insn - insn_buf;
}
-const struct bpf_verifier_ops sk_filter_verifier_ops = {
+static const struct bpf_verifier_ops sk_filter_verifier_ops = {
.get_func_proto = sk_filter_func_proto,
.is_valid_access = sk_filter_is_valid_access,
.convert_ctx_access = bpf_convert_ctx_access,
.gen_ld_abs = bpf_gen_ld_abs,
};
Big obvious NAK. I'm puzzled that you try to fix a compile warning,
but without
even bothering to compile the result after your patch ...
builds fine. maybe some effort to stop this happening again should be
made.
It doesn't build, because they are used/needed outside:
Hmm, your config it does, I get /none/ of these warnings.
I guess a lot of this is being built whether or not is then used.
Without CONFIG_BPF_SYSCALL, a part of net/core/filter.c is being
built but then not declared or used. Should this be split up or
the areas not being built be removed?
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
https://www.codethink.co.uk/privacy.html
Re: [PATCH] net: bpf: add static in net/core/filter.c
On 16/10/2019 14:10, Daniel Borkmann wrote:
On Wed, Oct 16, 2019 at 02:02:31PM +0100, Ben Dooks wrote:
On 16/10/2019 13:26, Daniel Borkmann wrote:
On Wed, Oct 16, 2019 at 12:04:46PM +0100, Ben Dooks (Codethink) wrote:
There are a number of structs in net/core/filter.c
that are not exported or declared outside of the
file. Fix the following warnings by making these
all static:
net/core/filter.c:8465:31: warning: symbol 'sk_filter_verifier_ops' was not
declared. Should it be static?
net/core/filter.c:8472:27: warning: symbol 'sk_filter_prog_ops' was not
declared. Should it be static?
[...]
net/core/filter.c:8935:27: warning: symbol 'sk_reuseport_prog_ops' was not
declared. Should it be static?
Signed-off-by: Ben Dooks
---
Cc: Alexei Starovoitov
Cc: Daniel Borkmann
Cc: Martin KaFai Lau
Cc: Song Liu
Cc: Yonghong Song
Cc: "David S. Miller"
Cc: Jakub Kicinski
Cc: Jesper Dangaard Brouer
Cc: John Fastabend
Cc: net...@vger.kernel.org
Cc: b...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
net/core/filter.c | 60 +++
1 file changed, 30 insertions(+), 30 deletions(-)
diff --git a/net/core/filter.c b/net/core/filter.c
index ed6563622ce3..f7338fee41f8 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -8462,18 +8462,18 @@ static u32 sk_msg_convert_ctx_access(enum
bpf_access_type type,
return insn - insn_buf;
}
-const struct bpf_verifier_ops sk_filter_verifier_ops = {
+static const struct bpf_verifier_ops sk_filter_verifier_ops = {
.get_func_proto = sk_filter_func_proto,
.is_valid_access= sk_filter_is_valid_access,
.convert_ctx_access = bpf_convert_ctx_access,
.gen_ld_abs = bpf_gen_ld_abs,
};
Big obvious NAK. I'm puzzled that you try to fix a compile warning, but without
even bothering to compile the result after your patch ...
builds fine. maybe some effort to stop this happening again should be made.
It doesn't build, because they are used/needed outside:
Hmm, your config it does, I get /none/ of these warnings.
I guess a lot of this is being built whether or not is then used.
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
https://www.codethink.co.uk/privacy.html
Re: [PATCH] net: bpf: add static in net/core/filter.c
On 16/10/2019 13:26, Daniel Borkmann wrote:
On Wed, Oct 16, 2019 at 12:04:46PM +0100, Ben Dooks (Codethink) wrote:
There are a number of structs in net/core/filter.c
that are not exported or declared outside of the
file. Fix the following warnings by making these
all static:
net/core/filter.c:8465:31: warning: symbol 'sk_filter_verifier_ops' was not
declared. Should it be static?
net/core/filter.c:8472:27: warning: symbol 'sk_filter_prog_ops' was not
declared. Should it be static?
[...]
net/core/filter.c:8935:27: warning: symbol 'sk_reuseport_prog_ops' was not
declared. Should it be static?
Signed-off-by: Ben Dooks
---
Cc: Alexei Starovoitov
Cc: Daniel Borkmann
Cc: Martin KaFai Lau
Cc: Song Liu
Cc: Yonghong Song
Cc: "David S. Miller"
Cc: Jakub Kicinski
Cc: Jesper Dangaard Brouer
Cc: John Fastabend
Cc: net...@vger.kernel.org
Cc: b...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
net/core/filter.c | 60 +++
1 file changed, 30 insertions(+), 30 deletions(-)
diff --git a/net/core/filter.c b/net/core/filter.c
index ed6563622ce3..f7338fee41f8 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -8462,18 +8462,18 @@ static u32 sk_msg_convert_ctx_access(enum
bpf_access_type type,
return insn - insn_buf;
}
-const struct bpf_verifier_ops sk_filter_verifier_ops = {
+static const struct bpf_verifier_ops sk_filter_verifier_ops = {
.get_func_proto = sk_filter_func_proto,
.is_valid_access= sk_filter_is_valid_access,
.convert_ctx_access = bpf_convert_ctx_access,
.gen_ld_abs = bpf_gen_ld_abs,
};
Big obvious NAK. I'm puzzled that you try to fix a compile warning, but without
even bothering to compile the result after your patch ...
builds fine. maybe some effort to stop this happening again should be made.
Seen BPF_PROG_TYPE() ?
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
https://www.codethink.co.uk/privacy.html
[PATCH] pstore: make 'pstore_choose_compression' static
The pstore_choose_compression function is not exported
so make it static to avoid the following sparse warning:
fs/pstore/platform.c:796:13: warning: symbol 'pstore_choose_compression' was
not declared. Should it be static?
Signed-off-by: Ben Dooks
---
Cc: Kees Cook
Cc: Anton Vorontsov
Cc: Colin Cross
Cc: Tony Luck
Cc: linux-kernel@vger.kernel.org
---
fs/pstore/platform.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c
index 3d7024662d29..d896457e7c11 100644
--- a/fs/pstore/platform.c
+++ b/fs/pstore/platform.c
@@ -793,7 +793,7 @@ static void pstore_timefunc(struct timer_list *unused)
jiffies + msecs_to_jiffies(pstore_update_ms));
}
-void __init pstore_choose_compression(void)
+static void __init pstore_choose_compression(void)
{
const struct pstore_zbackend *step;
--
2.23.0
[PATCH] crypto: atmel - fix data types for __be{32,64}
The driver uses a couple of buffers that seem to be __be32 or __be64 fields, but declares them as u32. This means there are a number of warnings from sparse due to casting to/from __beXXX. Fix these by changing the types of the buffer and the associated variables. drivers/crypto/atmel-aes.c:1023:15: warning: cast to restricted __be32 drivers/crypto/atmel-aes.c:1023:15: warning: cast to restricted __be32 drivers/crypto/atmel-aes.c:1023:15: warning: cast to restricted __be32 drivers/crypto/atmel-aes.c:1023:15: warning: cast to restricted __be32 drivers/crypto/atmel-aes.c:1023:15: warning: cast to restricted __be32 drivers/crypto/atmel-aes.c:1023:15: warning: cast to restricted __be32 drivers/crypto/atmel-aes.c:1059:28: warning: incorrect type in assignment (different base types) drivers/crypto/atmel-aes.c:1059:28:expected unsigned int drivers/crypto/atmel-aes.c:1059:28:got restricted __be32 [usertype] drivers/crypto/atmel-aes.c:1550:28: warning: incorrect type in assignment (different base types) drivers/crypto/atmel-aes.c:1550:28:expected unsigned int drivers/crypto/atmel-aes.c:1550:28:got restricted __be32 [usertype] drivers/crypto/atmel-aes.c:1561:39: warning: incorrect type in assignment (different base types) drivers/crypto/atmel-aes.c:1561:39:expected unsigned long long [usertype] drivers/crypto/atmel-aes.c:1561:39:got restricted __be64 [usertype] drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32 drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32 drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32 drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32 drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32 drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32 drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32 drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32 drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32 drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32 drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32 drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32 drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32 drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32 drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32 drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32 drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32 drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32 drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32 drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32 drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32 drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32 drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32 drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32 drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32 drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32 drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32 drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32 drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32 drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32 drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32 drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32 drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32 drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32 drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32 drivers/crypto/atmel-aes.c:1599:17: warning: cast to restricted __be32 drivers/crypto/atmel-aes.c:1599:15: warning: incorrect type in assignment (different base types) drivers/crypto/atmel-aes.c:1599:15:expected unsigned int [usertype] drivers/crypto/atmel-aes.c:1599:15:got restricted __be32 [usertype] drivers/crypto/atmel-aes.c:1692:17: warning: incorrect type in assignment (different base types) drivers/crypto/atmel-aes.c:1692:17:expected unsigned long long [usertype] drivers/crypto/atmel-aes.c:1692:17:got restricted __be64 [usertype] drivers/crypto/atmel-aes.c:1693:17: warning: incorrect type in assignment (different base types) drivers/crypto/atmel-aes.c:1693:17:expected unsigned long long [usertype] drivers/crypto/atmel-aes.c:1693:17:got restricted __be64 [usertype] drivers/crypto/atmel-aes.c:1888:63: warning: incorrect type in initializer (different base types) drivers/crypto/atmel-aes.c:1888:63:expected unsigned int drivers/crypto/atmel-aes.c:1888:63:got restricted __le32 [usertype] Signed-off-by: Ben Dooks --- Cc: Herbert Xu Cc: "David S. M
[PATCH] crypto: inside-secure - fix unexported warnings
The safexcel_pci_remove, pcireg_rc and ofreg_rc are
not exported or declared externally so make them static.
This avoids the following sparse warnings:
drivers/crypto/inside-secure/safexcel.c:1760:6: warning: symbol
'safexcel_pci_remove' was not declared. Should it be static?
drivers/crypto/inside-secure/safexcel.c:1794:5: warning: symbol 'pcireg_rc' was
not declared. Should it be static?
drivers/crypto/inside-secure/safexcel.c:1797:5: warning: symbol 'ofreg_rc' was
not declared. Should it be static?
Signed-off-by: Ben Dooks
---
Cc: Antoine Tenart
Cc: Herbert Xu
Cc: "David S. Miller"
Cc: linux-cry...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/crypto/inside-secure/safexcel.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/crypto/inside-secure/safexcel.c
b/drivers/crypto/inside-secure/safexcel.c
index 4ab1bde8dd9b..223d1bfdc7e6 100644
--- a/drivers/crypto/inside-secure/safexcel.c
+++ b/drivers/crypto/inside-secure/safexcel.c
@@ -1757,7 +1757,7 @@ static int safexcel_pci_probe(struct pci_dev *pdev,
return rc;
}
-void safexcel_pci_remove(struct pci_dev *pdev)
+static void safexcel_pci_remove(struct pci_dev *pdev)
{
struct safexcel_crypto_priv *priv = pci_get_drvdata(pdev);
int i;
@@ -1791,10 +1791,10 @@ static struct pci_driver safexcel_pci_driver = {
/* Unfortunately, we have to resort to global variables here */
#if IS_ENABLED(CONFIG_PCI)
-int pcireg_rc = -EINVAL; /* Default safe value */
+static int pcireg_rc = -EINVAL; /* Default safe value */
#endif
#if IS_ENABLED(CONFIG_OF)
-int ofreg_rc = -EINVAL; /* Default safe value */
+static int ofreg_rc = -EINVAL; /* Default safe value */
#endif
static int __init safexcel_init(void)
--
2.23.0
[PATCH] RFC: Bluetooth: missed cpu_to_le16 conversion in hci_init4_req
It looks like in hci_init4_req() the request is being
initialised from cpu-endian data but the packet is specified
to be little-endian. This causes an warning from sparse due
to __le16 to u16 conversion.
Fix this by using cpu_to_le16() on the two fields in the packet.
net/bluetooth/hci_core.c:845:27: warning: incorrect type in assignment
(different base types)
net/bluetooth/hci_core.c:845:27:expected restricted __le16 [usertype] tx_len
net/bluetooth/hci_core.c:845:27:got unsigned short [usertype] le_max_tx_len
net/bluetooth/hci_core.c:846:28: warning: incorrect type in assignment
(different base types)
net/bluetooth/hci_core.c:846:28:expected restricted __le16 [usertype]
tx_time
net/bluetooth/hci_core.c:846:28:got unsigned short [usertype] le_max_tx_time
Signed-off-by: Ben Dooks
---
Cc: Marcel Holtmann
Cc: Johan Hedberg
Cc: "David S. Miller"
Cc: linux-blueto...@vger.kernel.org
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
net/bluetooth/hci_core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 04bc79359a17..b2559d4bed81 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -842,8 +842,8 @@ static int hci_init4_req(struct hci_request *req, unsigned
long opt)
if (hdev->le_features[0] & HCI_LE_DATA_LEN_EXT) {
struct hci_cp_le_write_def_data_len cp;
- cp.tx_len = hdev->le_max_tx_len;
- cp.tx_time = hdev->le_max_tx_time;
+ cp.tx_len = cpu_to_le16(hdev->le_max_tx_len);
+ cp.tx_time = cpu_to_le16(hdev->le_max_tx_time);
hci_req_add(req, HCI_OP_LE_WRITE_DEF_DATA_LEN, sizeof(cp), );
}
--
2.23.0
[PATCH] kthread: make __kthread_queue_delayed_work static
The __kthread_queue_delayed_work is not exported so
make it static, to avoid the following sparse warning:
kernel/kthread.c:869:6: warning: symbol '__kthread_queue_delayed_work' was not
declared. Should it be static?
Signed-off-by: Ben Dooks
---
Cc: linux-kernel@vger.kernel.org
Cc: torva...@linux-foundation.org
---
kernel/kthread.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/kernel/kthread.c b/kernel/kthread.c
index 621467c33fef..b262f47046ca 100644
--- a/kernel/kthread.c
+++ b/kernel/kthread.c
@@ -866,9 +866,9 @@ void kthread_delayed_work_timer_fn(struct timer_list *t)
}
EXPORT_SYMBOL(kthread_delayed_work_timer_fn);
-void __kthread_queue_delayed_work(struct kthread_worker *worker,
- struct kthread_delayed_work *dwork,
- unsigned long delay)
+static void __kthread_queue_delayed_work(struct kthread_worker *worker,
+struct kthread_delayed_work *dwork,
+unsigned long delay)
{
struct timer_list *timer = >timer;
struct kthread_work *work = >work;
--
2.23.0
[PATCH] net: bpf: type fixes for __be16/__be32
In bpf_skb_load_helper_8_no_cache and
bpf_skb_load_helper_16_no_cache they
read a u16/u32 where actually these
are __be16 and __be32.
Fix the following by making the types
match:
net/core/filter.c:215:32: warning: cast to restricted __be16
net/core/filter.c:215:32: warning: cast to restricted __be16
net/core/filter.c:215:32: warning: cast to restricted __be16
net/core/filter.c:215:32: warning: cast to restricted __be16
net/core/filter.c:215:32: warning: cast to restricted __be16
net/core/filter.c:215:32: warning: cast to restricted __be16
net/core/filter.c:215:32: warning: cast to restricted __be16
net/core/filter.c:215:32: warning: cast to restricted __be16
net/core/filter.c:242:32: warning: cast to restricted __be32
net/core/filter.c:242:32: warning: cast to restricted __be32
net/core/filter.c:242:32: warning: cast to restricted __be32
net/core/filter.c:242:32: warning: cast to restricted __be32
net/core/filter.c:242:32: warning: cast to restricted __be32
net/core/filter.c:242:32: warning: cast to restricted __be32
net/core/filter.c:242:32: warning: cast to restricted __be32
net/core/filter.c:242:32: warning: cast to restricted __be32
net/core/filter.c:242:32: warning: cast to restricted __be32
net/core/filter.c:242:32: warning: cast to restricted __be32
net/core/filter.c:242:32: warning: cast to restricted __be32
net/core/filter.c:242:32: warning: cast to restricted __be32
Signed-off-by: Ben Dooks
---
Cc: Alexei Starovoitov
Cc: Daniel Borkmann
Cc: Martin KaFai Lau
Cc: Song Liu
Cc: Yonghong Song
Cc: "David S. Miller"
Cc: net...@vger.kernel.org
Cc: b...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
net/core/filter.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/core/filter.c b/net/core/filter.c
index f7338fee41f8..eefb1545b4c6 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -205,7 +205,7 @@ BPF_CALL_2(bpf_skb_load_helper_8_no_cache, const struct
sk_buff *, skb,
BPF_CALL_4(bpf_skb_load_helper_16, const struct sk_buff *, skb, const void *,
data, int, headlen, int, offset)
{
- u16 tmp, *ptr;
+ __be16 tmp, *ptr;
const int len = sizeof(tmp);
if (offset >= 0) {
@@ -232,7 +232,7 @@ BPF_CALL_2(bpf_skb_load_helper_16_no_cache, const struct
sk_buff *, skb,
BPF_CALL_4(bpf_skb_load_helper_32, const struct sk_buff *, skb, const void *,
data, int, headlen, int, offset)
{
- u32 tmp, *ptr;
+ __be32 tmp, *ptr;
const int len = sizeof(tmp);
if (likely(offset >= 0)) {
--
2.23.0
[PATCH] net: bpf: add static in net/core/filter.c
There are a number of structs in net/core/filter.c
that are not exported or declared outside of the
file. Fix the following warnings by making these
all static:
net/core/filter.c:8465:31: warning: symbol 'sk_filter_verifier_ops' was not
declared. Should it be static?
net/core/filter.c:8472:27: warning: symbol 'sk_filter_prog_ops' was not
declared. Should it be static?
net/core/filter.c:8476:31: warning: symbol 'tc_cls_act_verifier_ops' was not
declared. Should it be static?
net/core/filter.c:8484:27: warning: symbol 'tc_cls_act_prog_ops' was not
declared. Should it be static?
net/core/filter.c:8488:31: warning: symbol 'xdp_verifier_ops' was not declared.
Should it be static?
net/core/filter.c:8495:27: warning: symbol 'xdp_prog_ops' was not declared.
Should it be static?
net/core/filter.c:8499:31: warning: symbol 'cg_skb_verifier_ops' was not
declared. Should it be static?
net/core/filter.c:8505:27: warning: symbol 'cg_skb_prog_ops' was not declared.
Should it be static?
net/core/filter.c:8509:31: warning: symbol 'lwt_in_verifier_ops' was not
declared. Should it be static?
net/core/filter.c:8515:27: warning: symbol 'lwt_in_prog_ops' was not declared.
Should it be static?
net/core/filter.c:8519:31: warning: symbol 'lwt_out_verifier_ops' was not
declared. Should it be static?
net/core/filter.c:8525:27: warning: symbol 'lwt_out_prog_ops' was not declared.
Should it be static?
net/core/filter.c:8529:31: warning: symbol 'lwt_xmit_verifier_ops' was not
declared. Should it be static?
net/core/filter.c:8536:27: warning: symbol 'lwt_xmit_prog_ops' was not
declared. Should it be static?
net/core/filter.c:8540:31: warning: symbol 'lwt_seg6local_verifier_ops' was not
declared. Should it be static?
net/core/filter.c:8546:27: warning: symbol 'lwt_seg6local_prog_ops' was not
declared. Should it be static?
net/core/filter.c:8550:31: warning: symbol 'cg_sock_verifier_ops' was not
declared. Should it be static?
net/core/filter.c:8556:27: warning: symbol 'cg_sock_prog_ops' was not declared.
Should it be static?
net/core/filter.c:8559:31: warning: symbol 'cg_sock_addr_verifier_ops' was not
declared. Should it be static?
net/core/filter.c:8565:27: warning: symbol 'cg_sock_addr_prog_ops' was not
declared. Should it be static?
net/core/filter.c:8568:31: warning: symbol 'sock_ops_verifier_ops' was not
declared. Should it be static?
net/core/filter.c:8574:27: warning: symbol 'sock_ops_prog_ops' was not
declared. Should it be static?
net/core/filter.c:8577:31: warning: symbol 'sk_skb_verifier_ops' was not
declared. Should it be static?
net/core/filter.c:8584:27: warning: symbol 'sk_skb_prog_ops' was not declared.
Should it be static?
net/core/filter.c:8587:31: warning: symbol 'sk_msg_verifier_ops' was not
declared. Should it be static?
net/core/filter.c:8594:27: warning: symbol 'sk_msg_prog_ops' was not declared.
Should it be static?
net/core/filter.c:8597:31: warning: symbol 'flow_dissector_verifier_ops' was
not declared. Should it be static?
net/core/filter.c:8603:27: warning: symbol 'flow_dissector_prog_ops' was not
declared. Should it be static?
net/core/filter.c:8929:31: warning: symbol 'sk_reuseport_verifier_ops' was not
declared. Should it be static?
net/core/filter.c:8935:27: warning: symbol 'sk_reuseport_prog_ops' was not
declared. Should it be static?
Signed-off-by: Ben Dooks
---
Cc: Alexei Starovoitov
Cc: Daniel Borkmann
Cc: Martin KaFai Lau
Cc: Song Liu
Cc: Yonghong Song
Cc: "David S. Miller"
Cc: Jakub Kicinski
Cc: Jesper Dangaard Brouer
Cc: John Fastabend
Cc: net...@vger.kernel.org
Cc: b...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
net/core/filter.c | 60 +++
1 file changed, 30 insertions(+), 30 deletions(-)
diff --git a/net/core/filter.c b/net/core/filter.c
index ed6563622ce3..f7338fee41f8 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -8462,18 +8462,18 @@ static u32 sk_msg_convert_ctx_access(enum
bpf_access_type type,
return insn - insn_buf;
}
-const struct bpf_verifier_ops sk_filter_verifier_ops = {
+static const struct bpf_verifier_ops sk_filter_verifier_ops = {
.get_func_proto = sk_filter_func_proto,
.is_valid_access= sk_filter_is_valid_access,
.convert_ctx_access = bpf_convert_ctx_access,
.gen_ld_abs = bpf_gen_ld_abs,
};
-const struct bpf_prog_ops sk_filter_prog_ops = {
+static const struct bpf_prog_ops sk_filter_prog_ops = {
.test_run = bpf_prog_test_run_skb,
};
-const struct bpf_verifier_ops tc_cls_act_verifier_ops = {
+static const struct bpf_verifier_ops tc_cls_act_verifier_ops = {
.get_func_proto = tc_cls_act_func_proto,
.is_valid_access= tc_cls_act_is_valid_access,
.convert_ctx_access = tc_cls_act_convert_ctx_access,
@@ -8481,126 +8481,126 @@ const struct bpf_verifier_ops tc_cls_act_verifier_ops
= {
.gen_ld_abs = bpf_
[PATCH] char/random: include for add_hwgenerator_randomness
The add_hwgenerator_randomness() is declared in but this is not being included in drivers/char/random.c so fix the following sparse warning by including it: drivers/char/random.c:2489:6: warning: symbol 'add_hwgenerator_randomness' was not declared. Should it be static? Signed-off-by: Ben Dooks --- Cc: "Theodore Ts'o" Cc: Arnd Bergmann Cc: Greg Kroah-Hartman Cc: linux-kernel@vger.kernel.org --- drivers/char/random.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/char/random.c b/drivers/char/random.c index de434feb873a..da9a58068621 100644 --- a/drivers/char/random.c +++ b/drivers/char/random.c @@ -336,6 +336,7 @@ #include #include #include +#include #include #include -- 2.23.0
[PATCH] fs/direct-io: include internal.h for sb_init_dio_done_wq
The sb_init_dio_done_wq() is declared in internal.h but fs/direct-io.c does not include this file. Fix the warning by including internal.h fs/direct-io.c:612:5: warning: symbol 'sb_init_dio_done_wq' was not declared. Should it be static? Signed-off-by: Ben Dooks --- Cc: Alexander Viro Cc: linux-fsde...@vger.kernel.org Cc: linux-kernel@vger.kernel.org --- fs/direct-io.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/direct-io.c b/fs/direct-io.c index 9329ced91f1d..babdc9ed2cc0 100644 --- a/fs/direct-io.c +++ b/fs/direct-io.c @@ -39,6 +39,8 @@ #include #include +#include "internal.h" + /* * How many user pages to map in one call to get_user_pages(). This determines * the size of a structure in the slab cache -- 2.23.0
[PATCH] ubifs: fix type of sup->hash_algo
The sup->hash_algo is a __le16, and whilst 0x is
the same in __le16 and u16, it would be better to use
cpu_to_le16() anyway (which should deal with constants)
and silence the following sparse warning:
fs/ubifs/sb.c:187:32: warning: incorrect type in assignment (different base
types)
fs/ubifs/sb.c:187:32:expected restricted __le16 [usertype] hash_algo
fs/ubifs/sb.c:187:32:got int
Signed-off-by: Ben Dooks
---
Cc: Richard Weinberger
Cc: Artem Bityutskiy
Cc: Adrian Hunter
Cc: linux-...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
fs/ubifs/sb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ubifs/sb.c b/fs/ubifs/sb.c
index a551eb3e9b89..2b7c04bf8983 100644
--- a/fs/ubifs/sb.c
+++ b/fs/ubifs/sb.c
@@ -184,7 +184,7 @@ static int create_default_filesystem(struct ubifs_info *c)
if (err)
goto out;
} else {
- sup->hash_algo = 0x;
+ sup->hash_algo = cpu_to_le16(0x);
}
sup->ch.node_type = UBIFS_SB_NODE;
--
2.23.0
[PATCH] ubifs: possible missed le64_to_cpu() in journal
In the ubifs_jnl_write_inode() functon, it calls ubifs_iget()
with xent->inum. The xent->inum is __le64, but the ubifs_iget()
takes native cpu endian.
I think that this should be changed to passing le64_to_cpu(xent->inum)
to fix the following sparse warning:
fs/ubifs/journal.c:902:58: warning: incorrect type in argument 2 (different
base types)
fs/ubifs/journal.c:902:58:expected unsigned long inum
fs/ubifs/journal.c:902:58:got restricted __le64 [usertype] inum
Signed-off-by: Ben Dooks
---
Cc: Richard Weinberger
Cc: Artem Bityutskiy
Cc: Adrian Hunter
Cc: linux-...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
fs/ubifs/journal.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ubifs/journal.c b/fs/ubifs/journal.c
index d6136f7c1cfc..388fe8f5dc51 100644
--- a/fs/ubifs/journal.c
+++ b/fs/ubifs/journal.c
@@ -899,7 +899,7 @@ int ubifs_jnl_write_inode(struct ubifs_info *c, const
struct inode *inode)
fname_name() = xent->name;
fname_len() = le16_to_cpu(xent->nlen);
- xino = ubifs_iget(c->vfs_sb, xent->inum);
+ xino = ubifs_iget(c->vfs_sb, le64_to_cpu(xent->inum));
if (IS_ERR(xino)) {
err = PTR_ERR(xino);
ubifs_err(c, "dead directory entry '%s', error
%d",
--
2.23.0
[PATCH] ubifs: force prandom result to __le32
In set_dent_cookie() the result of prandom_u32() is
assinged to an __le32 type. Make this a forced conversion
to remove the following sparse warning:
fs/ubifs/journal.c:506:30: warning: incorrect type in assignment (different
base types)
fs/ubifs/journal.c:506:30:expected restricted __le32 [usertype] cookie
fs/ubifs/journal.c:506:30:got unsigned int
Signed-off-by: Ben Dooks
---
Cc: Richard Weinberger
Cc: Artem Bityutskiy
Cc: Adrian Hunter
Cc: linux-...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
fs/ubifs/journal.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ubifs/journal.c b/fs/ubifs/journal.c
index 4fd9683b8245..d6136f7c1cfc 100644
--- a/fs/ubifs/journal.c
+++ b/fs/ubifs/journal.c
@@ -503,7 +503,7 @@ static void mark_inode_clean(struct ubifs_info *c, struct
ubifs_inode *ui)
static void set_dent_cookie(struct ubifs_info *c, struct ubifs_dent_node *dent)
{
if (c->double_hash)
- dent->cookie = prandom_u32();
+ dent->cookie = (__force __le32) prandom_u32();
else
dent->cookie = 0;
}
--
2.23.0
[PATCH] fsnotify/fdinfo: exportfs_encode_inode_fh() takes pointer as 4th argument
The call to exportfs_encode_inode_fh() takes an pointer
as the 4th argument, so replace the integer 0 with the
NULL pointer.
This fixes the following sparse warning:
fs/notify/fdinfo.c:53:87: warning: Using plain integer as NULL pointer
Signed-off-by: Ben Dooks
---
Cc: Jan Kara
Cc: Amir Goldstein
Cc: linux-fsde...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
fs/notify/fdinfo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/notify/fdinfo.c b/fs/notify/fdinfo.c
index 1e2bfd26b352..ef83f4020554 100644
--- a/fs/notify/fdinfo.c
+++ b/fs/notify/fdinfo.c
@@ -50,7 +50,7 @@ static void show_mark_fhandle(struct seq_file *m, struct
inode *inode)
f.handle.handle_bytes = sizeof(f.pad);
size = f.handle.handle_bytes >> 2;
- ret = exportfs_encode_inode_fh(inode, (struct fid *)f.handle.f_handle,
, 0);
+ ret = exportfs_encode_inode_fh(inode, (struct fid *)f.handle.f_handle,
, NULL);
if ((ret == FILEID_INVALID) || (ret < 0)) {
WARN_ONCE(1, "Can't encode file handler for inotify: %d\n",
ret);
return;
--
2.23.0
[PATCH] mm: huge_pte_offset() returns pte_t *, not integer
The huge_pte_offset() returns a pte_t *, not an integer
so when huge-tlb is off, the replacement inline macro
should return a pte_t * too.
This fixes the following sparse warning:
mm/page_vma_mapped.c:156:29: warning: Using plain integer as NULL pointer
Signed-off-by: Ben Dooks
---
Cc: Mike Kravetz
Cc: linux...@kvack.org
Cc: linux-kernel@vger.kernel.org
---
include/linux/hugetlb.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 53fc34f930d0..e42c76aa1577 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -185,7 +185,7 @@ static inline void hugetlb_show_meminfo(void)
#define hugetlb_free_pgd_range(tlb, addr, end, floor, ceiling) ({BUG(); 0; })
#define hugetlb_mcopy_atomic_pte(dst_mm, dst_pte, dst_vma, dst_addr, \
src_addr, pagep)({ BUG(); 0; })
-#define huge_pte_offset(mm, address, sz) 0
+#define huge_pte_offset(mm, address, sz) (pte_t *)NULL
static inline bool isolate_huge_page(struct page *page, struct list_head *list)
{
--
2.23.0
[PATCH] mm: include for vm_committed_as_batch
mm_init.c needs to include for the definition of vm_committed_as_batch. Fixes the following sparse warning: mm/mm_init.c:141:5: warning: symbol 'vm_committed_as_batch' was not declared. Should it be static? Signed-off-by: Ben Dooks --- Cc: Andrew Morton Cc: linux...@kvack.org Cc: linux-kernel@vger.kernel.org --- mm/init-mm.c | 1 + 1 file changed, 1 insertion(+) diff --git a/mm/init-mm.c b/mm/init-mm.c index fb1e15028ef0..19603302a77f 100644 --- a/mm/init-mm.c +++ b/mm/init-mm.c @@ -5,6 +5,7 @@ #include #include #include +#include #include #include -- 2.23.0
Re: [PATCH] net: stmmac: fix argument to stmmac_pcs_ctrl_ane()
On 16/10/2019 09:22, Ben Dooks (Codethink) wrote: The stmmac_pcs_ctrl_ane() expects a register address as argument 1, but for some reason the mac_device_info is being passed. Fix the warning (and possible bug) from sparse: drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2613:17: warning: incorrect type in argument 1 (different address spaces) drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2613:17:expected void [noderef] *ioaddr drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2613:17:got struct mac_device_info *hw apologies, looks like I reposted this by accident. -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius https://www.codethink.co.uk/privacy.html
[PATCH] net: stmmac: fix argument to stmmac_pcs_ctrl_ane()
The stmmac_pcs_ctrl_ane() expects a register address as argument 1, but for some reason the mac_device_info is being passed. Fix the warning (and possible bug) from sparse: drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2613:17: warning: incorrect type in argument 1 (different address spaces) drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2613:17:expected void [noderef] *ioaddr drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2613:17:got struct mac_device_info *hw Signed-off-by: Ben Dooks --- Cc: Giuseppe Cavallaro Cc: Alexandre Torgue Cc: Jose Abreu Cc: "David S. Miller" Cc: Maxime Coquelin Cc: net...@vger.kernel.org Cc: linux-st...@st-md-mailman.stormreply.com Cc: linux-arm-ker...@lists.infradead.org Cc: linux-kernel@vger.kernel.org --- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c index c76a1336a451..3947c95121c6 100644 --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c @@ -2610,7 +2610,7 @@ static int stmmac_hw_setup(struct net_device *dev, bool init_ptp) } if (priv->hw->pcs) - stmmac_pcs_ctrl_ane(priv, priv->hw, 1, priv->hw->ps, 0); + stmmac_pcs_ctrl_ane(priv, priv->ioaddr, 1, priv->hw->ps, 0); /* set TX and RX rings length */ stmmac_set_rings_length(priv); -- 2.23.0
Re: [PATCH] PCI: sysfs: remove pci_bridge_groups and pcie_dev_groups
On 16/10/2019 07:28, Christoph Hellwig wrote: On Tue, Oct 15, 2019 at 03:00:59PM +0100, Ben Dooks wrote: The pci_bridge_groups and pcie_dev_groups objects are not exported and not used at-all, so remove them to fix the following warnings from sparse: drivers/pci/pci-sysfs.c:1546:30: warning: symbol 'pci_bridge_groups' was not declared. Should it be static? drivers/pci/pci-sysfs.c:1555:30: warning: symbol 'pcie_dev_groups' was not declared. Should it be static? But now pci_bridge_group is unused, and if you remove that the attributes, etc.. Ok, thanks for spotting, i've removed those too. I've no idea why we're not getting compiler warnings for this. -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius https://www.codethink.co.uk/privacy.html
[PATCH] [V2] PCI: sysfs: remove pci_bridge_groups and pcie_dev_groups
From: Ben Dooks
The pci_bridge_groups and pcie_dev_groups objects are
not exported and not used at-all, so remove them to
fix the following warnings from sparse:
drivers/pci/pci-sysfs.c:1546:30: warning: symbol 'pci_bridge_groups' was not
declared. Should it be static?
drivers/pci/pci-sysfs.c:1555:30: warning: symbol 'pcie_dev_groups' was not
declared. Should it be static?
Also remove the unused pci_bridge_group and pcie_dev_group
as they are not used any more.
Signed-off-by: Ben Dooks
---
Cc: Bjorn Helgaas
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
fixup - more unused pci bits
---
drivers/pci/pci-sysfs.c | 18 --
1 file changed, 18 deletions(-)
diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index 793412954529..eaffb477c5bf 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -1539,24 +1539,6 @@ const struct attribute_group *pci_dev_groups[] = {
NULL,
};
-static const struct attribute_group pci_bridge_group = {
- .attrs = pci_bridge_attrs,
-};
-
-const struct attribute_group *pci_bridge_groups[] = {
- _bridge_group,
- NULL,
-};
-
-static const struct attribute_group pcie_dev_group = {
- .attrs = pcie_dev_attrs,
-};
-
-const struct attribute_group *pcie_dev_groups[] = {
- _dev_group,
- NULL,
-};
-
static const struct attribute_group pci_dev_hp_attr_group = {
.attrs = pci_dev_hp_attrs,
.is_visible = pci_dev_hp_attrs_are_visible,
--
2.23.0
Re: [PATCH] bus: moxtet: declare moxtet_bus_type
On 15/10/2019 17:32, Christoph Hellwig wrote: On Tue, Oct 15, 2019 at 01:25:35PM +0100, Ben Dooks wrote: The moxtet_bus_type object is exported from the bus driver, but not declared. Add a declaration for use and to silence the following warning: The symbol can be marked static instead. Then it would have to be un-exported as it's listed as EXPORT_SYMBOL_GPL(moxtet_bus_type); -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius https://www.codethink.co.uk/privacy.html
Re: [PATCH] PCI: sysfs: remove pci_bridge_groups and pcie_dev_groups
On 16/10/2019 07:28, Christoph Hellwig wrote: On Tue, Oct 15, 2019 at 03:00:59PM +0100, Ben Dooks wrote: The pci_bridge_groups and pcie_dev_groups objects are not exported and not used at-all, so remove them to fix the following warnings from sparse: drivers/pci/pci-sysfs.c:1546:30: warning: symbol 'pci_bridge_groups' was not declared. Should it be static? drivers/pci/pci-sysfs.c:1555:30: warning: symbol 'pcie_dev_groups' was not declared. Should it be static? But now pci_bridge_group is unused, and if you remove that the attributes, etc.. Hmm, didn't get a warning for that. I'll go check. -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius https://www.codethink.co.uk/privacy.html
[PATCH] net: stmmac: fix argument to stmmac_pcs_ctrl_ane()
The stmmac_pcs_ctrl_ane() expects a register address as argument 1, but for some reason the mac_device_info is being passed. Fix the warning (and possible bug) from sparse: drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2613:17: warning: incorrect type in argument 1 (different address spaces) drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2613:17:expected void [noderef] *ioaddr drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2613:17:got struct mac_device_info *hw Signed-off-by: Ben Dooks --- Cc: Giuseppe Cavallaro Cc: Alexandre Torgue Cc: Jose Abreu Cc: "David S. Miller" Cc: Maxime Coquelin Cc: net...@vger.kernel.org Cc: linux-st...@st-md-mailman.stormreply.com Cc: linux-arm-ker...@lists.infradead.org Cc: linux-kernel@vger.kernel.org --- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c index c76a1336a451..3947c95121c6 100644 --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c @@ -2610,7 +2610,7 @@ static int stmmac_hw_setup(struct net_device *dev, bool init_ptp) } if (priv->hw->pcs) - stmmac_pcs_ctrl_ane(priv, priv->hw, 1, priv->hw->ps, 0); + stmmac_pcs_ctrl_ane(priv, priv->ioaddr, 1, priv->hw->ps, 0); /* set TX and RX rings length */ stmmac_set_rings_length(priv); -- 2.23.0
[PATCH] net: stmmac: make tc_flow_parsers static
The tc_flow_parsers is not used outside of the driver, so
make it static to avoid the following sparse warning:
drivers/net/ethernet/stmicro/stmmac/stmmac_tc.c:516:3: warning: symbol
'tc_flow_parsers' was not declared. Should it be static?
Signed-off-by: Ben Dooks
---
Cc: Giuseppe Cavallaro
Cc: Alexandre Torgue
Cc: Jose Abreu
Cc: "David S. Miller"
Cc: Maxime Coquelin
Cc: net...@vger.kernel.org
Cc: linux-st...@st-md-mailman.stormreply.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/ethernet/stmicro/stmmac/stmmac_tc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_tc.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_tc.c
index e231098061b6..f9a9a9d82233 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_tc.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_tc.c
@@ -510,7 +510,7 @@ static struct stmmac_flow_entry *tc_find_flow(struct
stmmac_priv *priv,
return NULL;
}
-struct {
+static struct {
int (*fn)(struct stmmac_priv *priv, struct flow_cls_offload *cls,
struct stmmac_flow_entry *entry);
} tc_flow_parsers[] = {
--
2.23.0
[PATCH] davinci_cpdma: make cpdma_chan_split_pool static
The cpdma_chan_split_pool() function is not used outside of
the driver, so make it static to avoid the following sparse
warning:
drivers/net/ethernet/ti/davinci_cpdma.c:725:5: warning: symbol
'cpdma_chan_split_pool' was not declared. Should it be static?
Signed-off-by: Ben Dooks
---
Cc: Grygorii Strashko
Cc: "David S. Miller"
Cc: linux-o...@vger.kernel.org
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/ethernet/ti/davinci_cpdma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/ti/davinci_cpdma.c
b/drivers/net/ethernet/ti/davinci_cpdma.c
index a65edd2770e6..37ba708ac781 100644
--- a/drivers/net/ethernet/ti/davinci_cpdma.c
+++ b/drivers/net/ethernet/ti/davinci_cpdma.c
@@ -722,7 +722,7 @@ static void cpdma_chan_set_descs(struct cpdma_ctlr *ctlr,
* cpdma_chan_split_pool - Splits ctrl pool between all channels.
* Has to be called under ctlr lock
*/
-int cpdma_chan_split_pool(struct cpdma_ctlr *ctlr)
+static int cpdma_chan_split_pool(struct cpdma_ctlr *ctlr)
{
int tx_per_ch_desc = 0, rx_per_ch_desc = 0;
int free_rx_num = 0, free_tx_num = 0;
--
2.23.0
[PATCH] PCI: mvebu: mvebu_pcie_map_registers __iomem fix
Fix the return type of mvebu_pcie_map_registers in the error path to have __iomem on it. Fixes the following sparse warning: drivers/pci/controller/pci-mvebu.c:716:31: warning: incorrect type in return expression (different address spaces) drivers/pci/controller/pci-mvebu.c:716:31:expected void [noderef] * drivers/pci/controller/pci-mvebu.c:716:31:got void * Signed-off-by: Ben Dooks --- Cc: Thomas Petazzoni Cc: Jason Cooper Cc: Lorenzo Pieralisi Cc: Andrew Murray Cc: Bjorn Helgaas Cc: linux-...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-kernel@vger.kernel.org --- drivers/pci/controller/pci-mvebu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pci/controller/pci-mvebu.c b/drivers/pci/controller/pci-mvebu.c index ed032e9a3156..153a64676bc9 100644 --- a/drivers/pci/controller/pci-mvebu.c +++ b/drivers/pci/controller/pci-mvebu.c @@ -713,7 +713,7 @@ static void __iomem *mvebu_pcie_map_registers(struct platform_device *pdev, ret = of_address_to_resource(np, 0, ); if (ret) - return ERR_PTR(ret); + return (void __iomem *)ERR_PTR(ret); return devm_ioremap_resource(>dev, ); } -- 2.23.0
[PATCH] PCI: mvebu: make mvebu_pci_bridge_emul_ops static
The mvebu_pci_bridge_emul_ops is not exported outside
of the driver, so make it static to avoid the following
sparse warning:
drivers/pci/controller/pci-mvebu.c:557:28: warning: symbol
'mvebu_pci_bridge_emul_ops' was not declared. Should it be static?
Signed-off-by: Ben Dooks
---
Cc: Thomas Petazzoni
Cc: Jason Cooper
Cc: Lorenzo Pieralisi
Cc: Andrew Murray
Cc: Bjorn Helgaas
Cc: linux-...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/pci/controller/pci-mvebu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/controller/pci-mvebu.c
b/drivers/pci/controller/pci-mvebu.c
index d3a0419e42f2..ed032e9a3156 100644
--- a/drivers/pci/controller/pci-mvebu.c
+++ b/drivers/pci/controller/pci-mvebu.c
@@ -554,7 +554,7 @@ mvebu_pci_bridge_emul_pcie_conf_write(struct
pci_bridge_emul *bridge,
}
}
-struct pci_bridge_emul_ops mvebu_pci_bridge_emul_ops = {
+static struct pci_bridge_emul_ops mvebu_pci_bridge_emul_ops = {
.write_base = mvebu_pci_bridge_emul_base_conf_write,
.read_pcie = mvebu_pci_bridge_emul_pcie_conf_read,
.write_pcie = mvebu_pci_bridge_emul_pcie_conf_write,
--
2.23.0
[PATCH] pci: iproc-msi: fix __iomem annotation in decode_msi_hwirq()
Fix __iomem attribute on msg variable passed to readl() in
the decode_msi_hwirq() function. Fixes the following sparse
warning:
drivers/pci/controller/pcie-iproc-msi.c:301:17: warning: incorrect type in
argument 1 (different address spaces)
drivers/pci/controller/pcie-iproc-msi.c:301:17:expected void const volatile
[noderef] *addr
drivers/pci/controller/pcie-iproc-msi.c:301:17:got unsigned int [usertype]
*[assigned] msg
Signed-off-by: Ben Dooks
---
Cc: Lorenzo Pieralisi
Cc: Andrew Murray
Cc: Bjorn Helgaas
Cc: Ray Jui
Cc: Scott Branden
Cc: bcm-kernel-feedback-l...@broadcom.com
Cc: linux-...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
.. (open list)
---
drivers/pci/controller/pcie-iproc-msi.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/controller/pcie-iproc-msi.c
b/drivers/pci/controller/pcie-iproc-msi.c
index 0a3f61be5625..3176ad3ab0e5 100644
--- a/drivers/pci/controller/pcie-iproc-msi.c
+++ b/drivers/pci/controller/pcie-iproc-msi.c
@@ -293,11 +293,12 @@ static const struct irq_domain_ops msi_domain_ops = {
static inline u32 decode_msi_hwirq(struct iproc_msi *msi, u32 eq, u32 head)
{
- u32 *msg, hwirq;
+ u32 __iomem *msg;
+ u32 hwirq;
unsigned int offs;
offs = iproc_msi_eq_offset(msi, eq) + head * sizeof(u32);
- msg = (u32 *)(msi->eq_cpu + offs);
+ msg = (u32 __iomem *)(msi->eq_cpu + offs);
hwirq = readl(msg);
hwirq = (hwirq >> 5) + (hwirq & 0x1f);
--
2.23.0
[PATCH 1/2] phy: phy-brcm-usb-init: fix __iomem annotations
-brcm-usb-init.c:434:13:expected void *reg
drivers/phy/broadcom/phy-brcm-usb-init.c:434:13:got void [noderef] *
drivers/phy/broadcom/phy-brcm-usb-init.c:435:38: warning: incorrect type in
argument 1 (different address spaces)
drivers/phy/broadcom/phy-brcm-usb-init.c:435:38:expected void [noderef]
*addr
drivers/phy/broadcom/phy-brcm-usb-init.c:435:38:got void *reg
drivers/phy/broadcom/phy-brcm-usb-init.c:435:51: warning: incorrect type in
argument 2 (different address spaces)
drivers/phy/broadcom/phy-brcm-usb-init.c:435:51:expected void [noderef]
*addr
drivers/phy/broadcom/phy-brcm-usb-init.c:435:51:got void *reg
drivers/phy/broadcom/phy-brcm-usb-init.c:434:13: warning: incorrect type in
assignment (different address spaces)
drivers/phy/broadcom/phy-brcm-usb-init.c:434:13:expected void *reg
drivers/phy/broadcom/phy-brcm-usb-init.c:434:13:got void [noderef] *
drivers/phy/broadcom/phy-brcm-usb-init.c:435:38: warning: incorrect type in
argument 1 (different address spaces)
drivers/phy/broadcom/phy-brcm-usb-init.c:435:38:expected void [noderef]
*addr
drivers/phy/broadcom/phy-brcm-usb-init.c:435:38:got void *reg
drivers/phy/broadcom/phy-brcm-usb-init.c:435:51: warning: incorrect type in
argument 2 (different address spaces)
drivers/phy/broadcom/phy-brcm-usb-init.c:435:51:expected void [noderef]
*addr
drivers/phy/broadcom/phy-brcm-usb-init.c:435:51:got void *reg
drivers/phy/broadcom/phy-brcm-usb-init.c:422:13: warning: too many warnings
Signed-off-by: Ben Dooks
---
Cc: Al Cooper
Cc: Kishon Vijay Abraham I
Cc: linux-kernel@vger.kernel.org
Cc: bcm-kernel-feedback-l...@broadcom.com
---
drivers/phy/broadcom/phy-brcm-usb-init.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/phy/broadcom/phy-brcm-usb-init.c
b/drivers/phy/broadcom/phy-brcm-usb-init.c
index 3c53625f8bc2..fa6dd117c40e 100644
--- a/drivers/phy/broadcom/phy-brcm-usb-init.c
+++ b/drivers/phy/broadcom/phy-brcm-usb-init.c
@@ -126,8 +126,8 @@ enum {
USB_CTRL_SELECTOR_COUNT,
};
-#define USB_CTRL_REG(base, reg)((void *)base + USB_CTRL_##reg)
-#define USB_XHCI_EC_REG(base, reg) ((void *)base + USB_XHCI_EC_##reg)
+#define USB_CTRL_REG(base, reg)((void __iomem *)base + USB_CTRL_##reg)
+#define USB_XHCI_EC_REG(base, reg) ((void __iomem *)base + USB_XHCI_EC_##reg)
#define USB_CTRL_MASK(reg, field) \
USB_CTRL_##reg##_##field##_MASK
#define USB_CTRL_MASK_FAMILY(params, reg, field) \
@@ -416,7 +416,7 @@ void usb_ctrl_unset_family(struct brcm_usb_init_params
*params,
u32 reg_offset, u32 field)
{
u32 mask;
- void *reg;
+ void __iomem *reg;
mask = params->usb_reg_bits_map[field];
reg = params->ctrl_regs + reg_offset;
@@ -428,7 +428,7 @@ void usb_ctrl_set_family(struct brcm_usb_init_params
*params,
u32 reg_offset, u32 field)
{
u32 mask;
- void *reg;
+ void __iomem *reg;
mask = params->usb_reg_bits_map[field];
reg = params->ctrl_regs + reg_offset;
--
2.23.0
[PATCH 2/2] phy: phy-brcm-usb-init: fix use of integer as pointer
The xhci_ec_base variable is a pointer, so don't compare it with an integer. Signed-off-by: Ben Dooks --- Cc: Al Cooper Cc: Kishon Vijay Abraham I Cc: linux-kernel@vger.kernel.org Cc: bcm-kernel-feedback-l...@broadcom.com --- drivers/phy/broadcom/phy-brcm-usb-init.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/phy/broadcom/phy-brcm-usb-init.c b/drivers/phy/broadcom/phy-brcm-usb-init.c index fa6dd117c40e..91b5b09589d6 100644 --- a/drivers/phy/broadcom/phy-brcm-usb-init.c +++ b/drivers/phy/broadcom/phy-brcm-usb-init.c @@ -707,7 +707,7 @@ static void brcmusb_usb3_otp_fix(struct brcm_usb_init_params *params) void __iomem *xhci_ec_base = params->xhci_ec_regs; u32 val; - if (params->family_id != 0x74371000 || xhci_ec_base == 0) + if (params->family_id != 0x74371000 || !xhci_ec_base) return; brcmusb_writel(0xa20c, USB_XHCI_EC_REG(xhci_ec_base, IRAADR)); val = brcmusb_readl(USB_XHCI_EC_REG(xhci_ec_base, IRADAT)); -- 2.23.0
