Skip to content

K
Kernel Liteos A

OpenHarmony / Kernel Liteos A
大约 1 年 前同步成功

通知 454
Star 414
Fork 55
K
Kernel Liteos A

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 11 8月, 2021 1 次提交
    • G
      feat(vfs): vfs支持FD_CLOEXEC标记 · 27dca4d8
      由 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>
      27dca4d8
  3. 10 8月, 2021 2 次提交
    • H
      fix: 合并进程栈两个地址连续的region · 42f374dd
      由 Haryslee 提交于 
      背景：进程加载的时候，先预申请一个页用作参数拷贝，另外通过mmap方式申请
额外的虚拟栈空间，此时便有两个地址连续的区间。
方案：新增内部接口OsStackAlloc，用于申请一个连续的虚拟地址区间，并对其
中指定区间做物理内存的映射。

close #I43QYJ
Signed-off-by: NHaryslee <lihao189@huawei.com>
Change-Id: I224cca3671c42a94c2f74b2da5a11403849e33d3
      42f374dd
    • Z
      fix: 修改DoNanoSleep 以纳秒为单位 · 6917e084
      由 zhushengle 提交于 
         DoNanoSleep 接口以微秒为单位，纳秒级别的在转换成微秒时被整除为0，
导致转换成tick时为0，导致延时时触发yield，导致延时时间超大
Close #I3Z9DP
Signed-off-by: Nzhushengle <zhushengle@huawei.com>
Change-Id: Ib662fdc80707be6040b2bb06a1b457344bd48b30
      6917e084
  5. 09 8月, 2021 1 次提交
    • Z
      fix: tick 动态化计算优化，消除中断执行时间对系统总体时间的影响，保证软件定时器的响应精度。 · 8df3e8c9
      由 zhushengle 提交于 
      方案描述：
    1.周期软件定时器超时添加一个startTime字段，用于记录当前软件定时器的开始计时的时间，
    在定时器响应时，开始时间修改为上一次响应的结束时间(消除了中断执行时间对软件定时器
    的影响)。
    2.在执行tick中断的过程当中，持有tick动态计算锁，保证在该过程中不会触发tick周期
    的计算，在tick中断结束时统一计算设置。 --- 提升tick中断的执行效率
    3.在设置tick周期时，减掉tick中断执行的时间，减小周期动态化带来的时间误差
    4.新增LOSCFG_BASE_CORE_TICK_PER_SECOND_MINI配置宏，用于配置tick中断的最小响应精度
Close #I43UQJ
Signed-off-by: Nzhushengle <zhushengle@huawei.com>
Change-Id: Icd1159a1890046b13602b7a18dcd6234d5c61a89
      8df3e8c9
  7. 06 8月, 2021 1 次提交
  9. 03 8月, 2021 1 次提交
  11. 30 7月, 2021 1 次提交
  13. 21 7月, 2021 2 次提交
  15. 20 7月, 2021 1 次提交
    • Y
      fix: init进程收到子进程退出信号后，调用fork重新拉起进程，会导致系统卡死 · 35a2f3af
      由 YOUR_NAME 提交于 
      问题原因：init进程执行信号时，线程栈底预留了部分空间给信号上下文使用，
从而导致处理信号时线程栈底比线程控制块里面记录的大，这样在fork的过程中内核
从init线程栈底copy线程上下文给新进程时，copy的不是实际运行的栈底，以致于
新进程的线程上下文不对，在实际运行时跑飞，引发系统卡死。
解决方案：在fork过程copy线程上下文时，判断是否预留了信号上下文空间，如果预留
了，则copy的栈底要基于预留后的栈底去copy线程上下文。

close: #I41HOY
Signed-off-by: Nzff <zhangfanfan2@huawei.com>
Change-Id: I61cb05183c78919730e3a68c1c85b72fa1decd16
      35a2f3af
  17. 19 7月, 2021 1 次提交
  19. 16 7月, 2021 1 次提交
  21. 14 7月, 2021 2 次提交
    • Q
      feat: add blackbox for liteos_a · a195aac9
      由 qidechun 提交于 
      1、在内核增加BlackBox核心框架，对外提供模块回调接口注册和故障处理接口。
2、增加默认的系统模块适配层，处理通用内核态和用户态故障日志抓取和保存。
3、BBOX特性默认关闭，若想使用此特性，请在内核配置文件中增加如下编译选项：
LOSCFG_BLACKBOX=y
LOSCFG_SAVE_EXCINFO=y
LOSCFG_SAVE_EXCINFO可以帮助抓取更多的故障日志。
4、若已经打开BBOX特性，想快速验证此特性，请添加如下编译选项：
LOSCFG_HIDUMPER=y

Close #I406NP
Signed-off-by: Nqidechun <qidechun@huawei.com>
      a195aac9
    • Z
      fix : futex requeue机制中，头节点的queueList 为NULL, 导致系统异常 · 1157c4a2
      由 zhushengle 提交于 
          queuelist中的普通节点在调整为futexList的节点时，
未校验其queueList的有效性，导致queueList未初始化，
出现访问空指针；且在从旧链表迁移节点到新链表时，
节点从旧链表删除之后又插入到另一个链表中，导致对
旧链表的为NULL判断出错。

Close #I4024F

Change-Id: I506a10fc5740ce16e682c2c419b9d92a82000b86
Signed-off-by: Nzhushengle <zhushengle@huawei.com>
      1157c4a2
  23. 08 7月, 2021 1 次提交
    • X
      fix:消除编译告警 · e4ff0458
      由 x_xiny 提交于 
      【背景】
 消除编译告警

【修改方案】
 消除编译告警

 re #I3ZC1R

 Change-Id: I594d0f57e4cbbdb246a6bef1c978a38228123a34
Signed-off-by: Nx-xiny <1301913191@qq.com>

Change-Id: I1d75cdcdcf9d06ec28e541cdfea77300da7c6bb1
      e4ff0458
  25. 07 7月, 2021 2 次提交
  27. 06 7月, 2021 1 次提交
    • Q
      feat: add blackbox for liteos_a · 425975e4
      由 qidechun 提交于 
      1、在内核增加BlackBox核心框架，对外提供模块回调接口注册和故障处理接口。
2、增加默认的系统模块适配层，处理通用内核态和用户态故障日志抓取和保存。

Close #I3NN7V
Signed-off-by: Nqidechun <qidechun@huawei.com>
      425975e4
  29. 01 7月, 2021 1 次提交
  31. 26 6月, 2021 1 次提交
    • Z
      fix: 修复kill进程时，因liteipc阻塞的进程概率无法退出问题 · 7de43bb0
      由 zhushengle 提交于 
      　kill进程时，会将因为liteipc阻塞的线程唤醒，使其调度并自动退出，由于liteipc阻塞机制为
循环阻塞方式，会导致将因liteipc阻塞的线程唤醒后又进入等待中。此处在唤醒因liteipc阻塞的
线程后检查是否已有kill标志，如果有使其按接收数据失败退出，在返回用户态之前，该线程会进
入退出流程，结束运行。

Close #I3XX7K
Signed-off-by: Nzhushengle <zhushengle@huawei.com>
Change-Id: Iec4e298dff4aefd2994289067a35cb5673e323f9
      7de43bb0
  33. 24 6月, 2021 1 次提交
  35. 22 6月, 2021 3 次提交
  37. 21 6月, 2021 2 次提交
  39. 19 6月, 2021 1 次提交
    • M
      fix: remove redundant headfile · 73a77777
      由 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>
      73a77777
  41. 16 6月, 2021 2 次提交
  43. 10 6月, 2021 1 次提交
  45. 05 6月, 2021 1 次提交
  47. 04 6月, 2021 1 次提交
    • Yansira's avatar
      feat: timer_create支持以SIGEV_THREAD方式创建定时器 · e5f6bf05
      由 Yansira 提交于 
      【背景】当前timer_create接口不支持以SIGEV_THREAD的方式创建多个定时器

【修改方案】
1、内核timer_create接口在创建software timers相应的线程时，使用线程
taskCB所携带的信息识别各个线程的信号并依据该信息分别派发出信号。
2、关于用户任务操作许可验证的修改，现在允许同一用户线程向其自身派发信
号，软件定时器计时结束，向用户态发送相应的信号，完成用户态线程的回调。

【影响】
对现有的产品暂无影响。

re #I3SRFI
Signed-off-by: Yansira's avataryansira <yansira@hotmail.com>
Change-Id: Ia23f5ef01975bf867dd7f5db797a30c264c50501
      e5f6bf05
  49. 24 5月, 2021 1 次提交
    • Z
      fix: 解决kill进程时无法保证进程的已持有的内核资源合理释放. · cf89f016
      由 zhushengle 提交于 
      背景: 当前信号实现原理是在系统调用结束和中断结束时检查是否有信号处理,
      如果有信号处理就切去处理信号，信号处理结束后回来继续按原来流程执行。
问题：当用户态线程在执行系统调用或缺页异常时，运行在内核态，如果此时有信
      号需要处理，且该线程已经持有了部分内核资源(如：锁，内存等), 此时如
      果有中断发生，则在中断结束时，就会去处理该信号，此时用户态线程持有
      了内核未释放的资源跑到了用户态去运行，如果该线程在用户态出现问题,
      那么它持有的内核资源就无法被释放了。
方案：用户态线程在执行系统调用和缺页异常时暂时屏蔽信号，防止此时有中断去
      处理信号，等系统调用结束或缺页异常结束时再去处理信号。
解决的问题：
  1. 执行系统调用或缺页异常时屏蔽信号，防止中断去处理信号
  2.解决无法kill 因为用户态的锁、ipc等阻塞的用户态线程
  3.进程退出方式转变为: 依次通过kill去杀死该进程的所有线程

Close #I3S0N0

Change-Id: I0c48b9c89382826191b8a9326c71b57ba84124c2
      cf89f016
  51. 21 5月, 2021 1 次提交
  53. 20 5月, 2021 1 次提交
  55. 19 5月, 2021 3 次提交
  57. 18 5月, 2021 1 次提交
  59. 14 5月, 2021 1 次提交