- 10 11月, 2021 1 次提交
-
-
由 kenneth 提交于
修复社区反馈问题Percpu结构体注释错误,排查下其他拼写错误。 close #I4GMLH Signed-off-by: Nkenneth <zhushangyuan@huawei.com>
-
- 11 10月, 2021 1 次提交
-
-
由 Haryslee 提交于
方案:硬随机不可用时,默认使用软随机数代替硬随机数 close #I4D4TK Signed-off-by: NHaryslee <lihao189@huawei.com> Change-Id: Ia7d2a9583257d7b8041b8994a70a7c36149c33fb
-
- 30 9月, 2021 2 次提交
-
-
由 Leon Chan 提交于
TEE需要借用TCB中的execFile来校验打开的文件,pagecache修改后,可执行程序在mmap之后,会被立即关闭,因此将execFile改为execVnode close: #I4CLL9 Signed-off-by: NLeon Chan <chenwei26@huawei.com>
-
由 Haryslee 提交于
背景:不开地址随机化时,用户态栈CANARY值是固定值 方案:支持AT_RANDOM,CANARY从AT_RANDOM获取随机值以增强用户态栈保护能力 close #I4CB8M Signed-off-by: NHaryslee <lihao189@huawei.com> Change-Id: I28cef09f7016a5096e2096d4f6aa72722fcf1fd7
-
- 27 9月, 2021 1 次提交
-
-
由 Far 提交于
Close #I4BL3S Signed-off-by: NFar <yesiyuan2@huawei.com>
-
- 18 9月, 2021 1 次提交
-
-
由 Leon Chan 提交于
close: #I4ATQX Signed-off-by: NLeon Chan <chenwei26@huawei.com>
-
- 14 9月, 2021 1 次提交
-
-
由 Leon Chan 提交于
1, change the owner of page to vnode 2, save the file path in vnode close: #I44TBS Signed-off-by: NLeon Chan <chenwei26@huawei.com>
-
- 07 9月, 2021 1 次提交
-
-
由 Guangyao Ma 提交于
本次提交修复内核加载器,异常情况分支的一个bug:mksh通过exec命令(mksh内置命令 ,正常情况下,该命令成功执行会复用mksh进程空间,拉起新的指定进程)。但是如果 进程没有成功加载的情况下,内核加载器的异常分支会错误释放mksh的fd句柄。最终导致 下次拉起其他进程时(fork + exec方式),新的进程会继承fd,映射了早就释放的sysfd ,此时的sysfd可能已经被复用,issue场景下这个sysfd被加载过程中打开的libc.so占用 ,exec时会释放procfd->sysfd(错误的映射关系),最终新进程libc.so被关闭。 导致内核崩溃。 close #I452Z7 Signed-off-by: NGuangyao Ma <guangyao.ma@outlook.com> Change-Id: Ifca809f88b5ffcfb879dc5520d1f6adf5cf92bcd
-
- 11 8月, 2021 1 次提交
-
-
由 Guangyao Ma 提交于
首先,POSIX规范规定文件描述符需要支持close-on-exec属性,修改前的vfs不支持close-on-exec,当exec系列函数执行时,进程所有的文件将会被关闭(0,1,2也重新被打开)。但是,系统有些时候是不能在exec时关闭全部文件的,例如在执行exec之前,就需要重定向进程的某些文件描述符时(使用dup2),就希望该文件不被关闭,继续保持重定向属性,shell执行进程并重定向其标准输出到文件,这是我们经常做的事情。 BREAKING CHANGE: 执行exec类函数后,进程拥有的文件描述符情况发生变化:修改前,默认关闭所有的进程文件描述符,0,1,2重新打开;修改后,除非文件描述符拥有FD_CLOEXEC标记,否则该描述符不会被关闭。 re #I3U81W Change-Id: I54e841ac88e9835ec23e97de0cbc906c4e11f5a4 Signed-off-by: NGuangyao Ma <guangyao.ma@outlook.com>
-
- 10 8月, 2021 1 次提交
-
-
由 Haryslee 提交于
背景:进程加载的时候,先预申请一个页用作参数拷贝,另外通过mmap方式申请 额外的虚拟栈空间,此时便有两个地址连续的区间。 方案:新增内部接口OsStackAlloc,用于申请一个连续的虚拟地址区间,并对其 中指定区间做物理内存的映射。 close #I43QYJ Signed-off-by: NHaryslee <lihao189@huawei.com> Change-Id: I224cca3671c42a94c2f74b2da5a11403849e33d3
-
- 26 6月, 2021 1 次提交
-
-
由 Haryslee 提交于
背景:LOS_UserMemClear接口原有实现是通过在内核中 申请一块堆内存并对其清零,调用copy_to_user来达到 对用户态内存清零的目的,需要使用堆内存。 修改方案:基于汇编实现内核对用户态内存清零的功能。 close #I3XXT0 Change-Id: I27cb1e45559cb75a9b330799fe427abd54f51c15 Signed-off-by: NHaryslee <lihao189@huawei.com>
-
- 19 6月, 2021 1 次提交
-
-
由 mucor 提交于
1.remove redundant headfile in kernel, such as: compiler.h;debug.h;automount.h;inode.h;syslog.h;net.h; 2.split fs.h to file.h and driver.h 3.move vnode.h and path_cache.h to vfs/include 4.remove redundant interface and defines close: #I3RTNR Signed-off-by: Nmucor <mucorwang@gmail.com>
-
- 16 6月, 2021 1 次提交
-
-
由 zhushy_ 提交于
rename function OsCreateUserVmSpace to fix typo close https://gitee.com/openharmony/kernel_liteos_a/issues/I3QD42Signed-off-by: kenneth <459864689@qq.com>
-
- 20 5月, 2021 1 次提交
-
-
由 arvinzzz 提交于
close: #I3I768 Change-Id: I4f801df4abe1a9afdf43391c28276e96a5e81513
-
- 19 4月, 2021 1 次提交
-
-
由 Caoruihong 提交于
Change-Id: I052d930d54e63179b17b77f02c107a015f3cfc3f
-
- 11 3月, 2021 1 次提交
-
-
由 mamingshuai 提交于
-
- 13 10月, 2020 1 次提交
-
-
由 Caoruihong 提交于
Change-Id: Ia6c1f6302407a707b3ec9b805f4c92d8a7970b86
-
- 28 9月, 2020 1 次提交
-
-
由 weixin_51919493 提交于
-
- 08 9月, 2020 1 次提交
-
-
由 wenjun 提交于
-