On Mon, Mar 09, 2020 at 06:12:03PM +0900, Jaewon Kim wrote: > On 2020년 03월 08일 21:36, Matthew Wilcox wrote: > > On Sun, Mar 08, 2020 at 06:58:47PM +0900, Jaewon Kim wrote: > >> On 2020년 03월 08일 10:58, Matthew Wilcox wrote: > >>> On Sat, Mar 07, 2020 at 03:47:44PM -0800, Andrew Morton wrote: > >>>> On Fri, 6 Mar 2020 15:16:22 +0900 Jaewon Kim <jaewon31.kim@xxxxxxxxxxx> wrote: > >>>>> Even on 64 bit kernel, the mmap failure can happen for a 32 bit task. > >>>>> Virtual memory space shortage of a task on mmap is reported to userspace > >>>>> as -ENOMEM. It can be confused as physical memory shortage of overall > >>>>> system. > >>> But userspace can trigger this printk. We don't usually allow printks > >>> under those circumstances, even ratelimited. > >> Hello thank you your comment. > >> > >> Yes, userspace can trigger printk, but this was useful for to know why > >> a userspace task was crashed. There seems to be still many userspace > >> applications which did not check error of mmap and access invalid address. > >> > >> Additionally in my AARCH64 Android environment, display driver tries to > >> get userspace address to map its display memory. The display driver > >> report -ENOMEM from vm_unmapped_area and but also from GPU related > >> address space. > >> > >> Please let me know your comment again if this debug is now allowed > >> in that userspace triggered perspective. > > The scenario that worries us is an attacker being able to fill the log > > files and so also fill (eg) the /var partition. Once it's full, future > > kernel messages cannot be stored anywhere and so there will be no traces > > of their privilege escalation. > Although up to 10 times within 5 secs is not many, I think those log may remove > other important log in log buffer if it is the system which produces very few log. > In my Android phone device system, there seems to be much more kernel log though. I've never seen the logs on my android phone. All that a ratelimit is going to do is make the attacker be more patient. > > Maybe a tracepoint would be a better idea? Usually they are disabled, > > but they can be enabled by a sysadmin to gain insight into why an > > application is crashing. > In Android phone device system, we cannot get sysadmin permission if it is built > for end user. And it is not easy to reproduce this symptom because it is an user's app. > > Anyway let me try pr_devel_ratelimited which is disabled by default. I hope this is > good enough. Additionally I moved the code from mm.h to mmap.c. https://source.android.com/devices/tech/debug/ftrace
