* [bug report] fsdax: output address in dax_iomap_pfn() and rename it
@ 2022-06-07 7:59 Dan Carpenter
2022-06-07 8:54 ` Shiyang Ruan
0 siblings, 1 reply; 4+ messages in thread
From: Dan Carpenter @ 2022-06-07 7:59 UTC (permalink / raw)
To: ruansy.fnst; +Cc: linux-fsdevel
Hello Shiyang Ruan,
The patch 1447ac26a964: "fsdax: output address in dax_iomap_pfn() and
rename it" from Jun 3, 2022, leads to the following Smatch static
checker warning:
fs/dax.c:1085 dax_iomap_direct_access()
error: uninitialized symbol 'rc'.
fs/dax.c
1052 static int dax_iomap_direct_access(const struct iomap *iomap, loff_t pos,
1053 size_t size, void **kaddr, pfn_t *pfnp)
1054 {
1055 pgoff_t pgoff = dax_iomap_pgoff(iomap, pos);
1056 int id, rc;
1057 long length;
1058
1059 id = dax_read_lock();
1060 length = dax_direct_access(iomap->dax_dev, pgoff, PHYS_PFN(size),
1061 DAX_ACCESS, kaddr, pfnp);
1062 if (length < 0) {
1063 rc = length;
1064 goto out;
1065 }
1066 if (!pfnp)
1067 goto out_check_addr;
Is this an error path?
1068 rc = -EINVAL;
1069 if (PFN_PHYS(length) < size)
1070 goto out;
1071 if (pfn_t_to_pfn(*pfnp) & (PHYS_PFN(size)-1))
1072 goto out;
1073 /* For larger pages we need devmap */
1074 if (length > 1 && !pfn_t_devmap(*pfnp))
1075 goto out;
1076 rc = 0;
1077
1078 out_check_addr:
1079 if (!kaddr)
1080 goto out;
How is it supposed to be handled if both "pfnp" and "kaddr" are NULL?
Smatch says that "kaddr" can never be NULL so this code is just future
proofing but I didn't look at it carefully.
1081 if (!*kaddr)
1082 rc = -EFAULT;
1083 out:
1084 dax_read_unlock(id);
--> 1085 return rc;
1086 }
regards,
dan carpenter
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bug report] fsdax: output address in dax_iomap_pfn() and rename it
2022-06-07 7:59 [bug report] fsdax: output address in dax_iomap_pfn() and rename it Dan Carpenter
@ 2022-06-07 8:54 ` Shiyang Ruan
2022-06-07 9:04 ` Dan Carpenter
0 siblings, 1 reply; 4+ messages in thread
From: Shiyang Ruan @ 2022-06-07 8:54 UTC (permalink / raw)
To: Dan Carpenter; +Cc: linux-fsdevel
在 2022/6/7 15:59, Dan Carpenter 写道:
> Hello Shiyang Ruan,
>
> The patch 1447ac26a964: "fsdax: output address in dax_iomap_pfn() and
> rename it" from Jun 3, 2022, leads to the following Smatch static
> checker warning:
>
> fs/dax.c:1085 dax_iomap_direct_access()
> error: uninitialized symbol 'rc'.
>
> fs/dax.c
> 1052 static int dax_iomap_direct_access(const struct iomap *iomap, loff_t pos,
> 1053 size_t size, void **kaddr, pfn_t *pfnp)
> 1054 {
> 1055 pgoff_t pgoff = dax_iomap_pgoff(iomap, pos);
> 1056 int id, rc;
> 1057 long length;
> 1058
> 1059 id = dax_read_lock();
> 1060 length = dax_direct_access(iomap->dax_dev, pgoff, PHYS_PFN(size),
> 1061 DAX_ACCESS, kaddr, pfnp);
> 1062 if (length < 0) {
> 1063 rc = length;
> 1064 goto out;
> 1065 }
> 1066 if (!pfnp)
> 1067 goto out_check_addr;
>
> Is this an error path?
>
> 1068 rc = -EINVAL;
> 1069 if (PFN_PHYS(length) < size)
> 1070 goto out;
> 1071 if (pfn_t_to_pfn(*pfnp) & (PHYS_PFN(size)-1))
> 1072 goto out;
> 1073 /* For larger pages we need devmap */
> 1074 if (length > 1 && !pfn_t_devmap(*pfnp))
> 1075 goto out;
> 1076 rc = 0;
> 1077
> 1078 out_check_addr:
> 1079 if (!kaddr)
> 1080 goto out;
>
> How is it supposed to be handled if both "pfnp" and "kaddr" are NULL?
>
> Smatch says that "kaddr" can never be NULL so this code is just future
> proofing but I didn't look at it carefully.
Yes, we always pass the @kaddr in all caller, it won't be NULL now. And
even @kaddr and @pfnp are both NULL, it won't cause any error. So, I
think the rc should be initialized to 0 :
{
pgoff_t pgoff = dax_iomap_pgoff(iomap, pos);
- int id, rc;
+ int id, rc = 0;
long length;
Do I need to fix this and resend a patch to the list? Or you could help
me fix this?
--
Thanks,
Ruan.
>
> 1081 if (!*kaddr)
> 1082 rc = -EFAULT;
> 1083 out:
> 1084 dax_read_unlock(id);
> --> 1085 return rc;
> 1086 }
>
> regards,
> dan carpenter
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bug report] fsdax: output address in dax_iomap_pfn() and rename it
2022-06-07 8:54 ` Shiyang Ruan
@ 2022-06-07 9:04 ` Dan Carpenter
2022-06-07 9:09 ` Shiyang Ruan
0 siblings, 1 reply; 4+ messages in thread
From: Dan Carpenter @ 2022-06-07 9:04 UTC (permalink / raw)
To: Shiyang Ruan; +Cc: linux-fsdevel
On Tue, Jun 07, 2022 at 04:54:29PM +0800, Shiyang Ruan wrote:
>
>
> 在 2022/6/7 15:59, Dan Carpenter 写道:
> > Hello Shiyang Ruan,
> >
> > The patch 1447ac26a964: "fsdax: output address in dax_iomap_pfn() and
> > rename it" from Jun 3, 2022, leads to the following Smatch static
> > checker warning:
> >
> > fs/dax.c:1085 dax_iomap_direct_access()
> > error: uninitialized symbol 'rc'.
> >
> > fs/dax.c
> > 1052 static int dax_iomap_direct_access(const struct iomap *iomap, loff_t pos,
> > 1053 size_t size, void **kaddr, pfn_t *pfnp)
> > 1054 {
> > 1055 pgoff_t pgoff = dax_iomap_pgoff(iomap, pos);
> > 1056 int id, rc;
> > 1057 long length;
> > 1058
> > 1059 id = dax_read_lock();
> > 1060 length = dax_direct_access(iomap->dax_dev, pgoff, PHYS_PFN(size),
> > 1061 DAX_ACCESS, kaddr, pfnp);
> > 1062 if (length < 0) {
> > 1063 rc = length;
> > 1064 goto out;
> > 1065 }
> > 1066 if (!pfnp)
> > 1067 goto out_check_addr;
> >
> > Is this an error path?
> >
> > 1068 rc = -EINVAL;
> > 1069 if (PFN_PHYS(length) < size)
> > 1070 goto out;
> > 1071 if (pfn_t_to_pfn(*pfnp) & (PHYS_PFN(size)-1))
> > 1072 goto out;
> > 1073 /* For larger pages we need devmap */
> > 1074 if (length > 1 && !pfn_t_devmap(*pfnp))
> > 1075 goto out;
> > 1076 rc = 0;
> > 1077
> > 1078 out_check_addr:
> > 1079 if (!kaddr)
> > 1080 goto out;
> >
> > How is it supposed to be handled if both "pfnp" and "kaddr" are NULL?
> >
> > Smatch says that "kaddr" can never be NULL so this code is just future
> > proofing but I didn't look at it carefully.
>
> Yes, we always pass the @kaddr in all caller, it won't be NULL now. And
> even @kaddr and @pfnp are both NULL, it won't cause any error. So, I think
> the rc should be initialized to 0 :
>
> {
> pgoff_t pgoff = dax_iomap_pgoff(iomap, pos);
> - int id, rc;
> + int id, rc = 0;
> long length;
>
> Do I need to fix this and resend a patch to the list? Or you could help me
> fix this?
Could you handle this? Is this in Andrew's tree? I think you send a
follow on patch and he'll eventually fold it into the original patch.
regards,
dan carpenter
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bug report] fsdax: output address in dax_iomap_pfn() and rename it
2022-06-07 9:04 ` Dan Carpenter
@ 2022-06-07 9:09 ` Shiyang Ruan
0 siblings, 0 replies; 4+ messages in thread
From: Shiyang Ruan @ 2022-06-07 9:09 UTC (permalink / raw)
To: Dan Carpenter; +Cc: linux-fsdevel
在 2022/6/7 17:04, Dan Carpenter 写道:
> On Tue, Jun 07, 2022 at 04:54:29PM +0800, Shiyang Ruan wrote:
>>
>>
>> 在 2022/6/7 15:59, Dan Carpenter 写道:
>>> Hello Shiyang Ruan,
>>>
>>> The patch 1447ac26a964: "fsdax: output address in dax_iomap_pfn() and
>>> rename it" from Jun 3, 2022, leads to the following Smatch static
>>> checker warning:
>>>
>>> fs/dax.c:1085 dax_iomap_direct_access()
>>> error: uninitialized symbol 'rc'.
>>>
>>> fs/dax.c
>>> 1052 static int dax_iomap_direct_access(const struct iomap *iomap, loff_t pos,
>>> 1053 size_t size, void **kaddr, pfn_t *pfnp)
>>> 1054 {
>>> 1055 pgoff_t pgoff = dax_iomap_pgoff(iomap, pos);
>>> 1056 int id, rc;
>>> 1057 long length;
>>> 1058
>>> 1059 id = dax_read_lock();
>>> 1060 length = dax_direct_access(iomap->dax_dev, pgoff, PHYS_PFN(size),
>>> 1061 DAX_ACCESS, kaddr, pfnp);
>>> 1062 if (length < 0) {
>>> 1063 rc = length;
>>> 1064 goto out;
>>> 1065 }
>>> 1066 if (!pfnp)
>>> 1067 goto out_check_addr;
>>>
>>> Is this an error path?
>>>
>>> 1068 rc = -EINVAL;
>>> 1069 if (PFN_PHYS(length) < size)
>>> 1070 goto out;
>>> 1071 if (pfn_t_to_pfn(*pfnp) & (PHYS_PFN(size)-1))
>>> 1072 goto out;
>>> 1073 /* For larger pages we need devmap */
>>> 1074 if (length > 1 && !pfn_t_devmap(*pfnp))
>>> 1075 goto out;
>>> 1076 rc = 0;
>>> 1077
>>> 1078 out_check_addr:
>>> 1079 if (!kaddr)
>>> 1080 goto out;
>>>
>>> How is it supposed to be handled if both "pfnp" and "kaddr" are NULL?
>>>
>>> Smatch says that "kaddr" can never be NULL so this code is just future
>>> proofing but I didn't look at it carefully.
>>
>> Yes, we always pass the @kaddr in all caller, it won't be NULL now. And
>> even @kaddr and @pfnp are both NULL, it won't cause any error. So, I think
>> the rc should be initialized to 0 :
>>
>> {
>> pgoff_t pgoff = dax_iomap_pgoff(iomap, pos);
>> - int id, rc;
>> + int id, rc = 0;
>> long length;
>>
>> Do I need to fix this and resend a patch to the list? Or you could help me
>> fix this?
>
> Could you handle this? Is this in Andrew's tree? I think you send a
> follow on patch and he'll eventually fold it into the original patch.
OK, got it.
--
Thanks,
Ruan.
>
> regards,
> dan carpenter
>
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2022-06-07 9:09 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-06-07 7:59 [bug report] fsdax: output address in dax_iomap_pfn() and rename it Dan Carpenter
2022-06-07 8:54 ` Shiyang Ruan
2022-06-07 9:04 ` Dan Carpenter
2022-06-07 9:09 ` Shiyang Ruan
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.