Messages in this thread | | | From | Thomas Gleixner <> | Subject | Re: [PATCH v2 2/2] mm: fix boundary judgment issues in kernel/resource.c | Date | Sun, 20 Jun 2021 00:16:45 +0200 |
| |
Yaohui!
On Fri, Jun 11 2021 at 12:21, Yaohui Wang wrote:
The same formal issues as with patch #1
> The original boundary judgment may ignore @end if @end equals @start. For
May means it can but it must not. But this is not the case here. end equals start is always ignored.
Also 'original' is meaningless here. Before the patch is applied the code is that way.
find_next_iomem_res() and __walk_iomem_res_desc() require that the provided end address is larger than the start address, which ...
> example, if we call ioremap(phys, 1), then @end == @start, and the memory > check will not be applied on the page where @end lives, which is > unexpected.
Please avoid 'we' and 'I':
is incorrect when ioremap() is invoked with length=1.
> In kernel/resource.c:find_next_iomem_res, the mem region is a closed
See the reply to #1 vs. function names. Also please write out 'memory', there is no shortage of space in change logs.
> interval (i.e. [@start..@end]). So @start == @end should be allowed.
closed interval reads strange. The usual terminology is: The end address is inclusive.
Resources are described with the start address and the inclusive end address, which means for a resource with 1 byte length the start address is the same as the end address.
find_next_iomem_res() and __walk_iomem_res_desc() ignore resources with 1 byte length, which prevents that ioremap(phys, 1) is checked whether it touches non ioremappable resources.
...
Thanks,
tglx
| |