Skip to content

K
Kernel Liteos A

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

通知 475
Star 414
Fork 55
K
Kernel Liteos A
切换分支/标签
  1. 22 12月, 2021 1 次提交
  3. 04 11月, 2021 1 次提交
  5. 02 11月, 2021 3 次提交
    • L
      修复ppoll接口"[ERR]OsMemFree check error!"报错 · 951d2336
      由 lnlan 提交于 
      【背景】
1.内核中释放用户空间指针报错:"[ERR]OsMemFree check error!"
2.现有ppoll实现存在问题
3.相关用例需要整理
【修改方案】
1.去掉释放用户空间指针操作
2.更正逻辑错误
3.更正掩码设置与恢复不起作用
4.修复补充现有用例
【影响】
对现有的产品编译不会有影响。

re #I47YWZ

Change-Id: Ib2f60986e9cafb2ea5ef1097ab8552cbb1ede5b4
Signed-off-by: Nlnlan <lanleinan@163.com>
      951d2336
    • 悟空又丢了's avatar
      修复ppoll接口"[ERR]OsMemFree check error!"报错 · ca70dc4d
      由 悟空又丢了 提交于 
      【背景】
内核中释放用户空间指针报错:"[ERR]OsMemFree check error!"

【修改方案】
修改SysPpoll函数。

【影响】
对现有的产品编译不会有影响。

re #I47YWZ

Change-Id: Id7f86036870d4f32be8fc438b9aad85cdda59546
Signed-off-by: 悟空又丢了's avatarpef <cyd1997@126.com>
      ca70dc4d
    • T
      fix: fix ppoll · a693cd41
      由 teamol 提交于 
      1.modifications:
modified:   syscall/fs_syscall.c
2.modify 2 testcases:
IO/full/IO_test_ppoll_001.cpp
IO/full/IO_test_ppoll_002.cpp
3.influence:
none
Signed-off-by: 悟空又丢了's avatarpef <cyd1997@126.com>
Change-Id: I85fc091098a6dfef1a4694a3bbc489640ee6dda2
      a693cd41
  7. 27 10月, 2021 1 次提交
    • L
      fix: 修复PR520缺陷 · d71db999
      由 lnlan 提交于 
      【背景】
https://gitee.com/openharmony/kernel_liteos_a/pulls/520
上面修改，信号处理时才会释放申请的内存，当信号被屏蔽，且一直发送该信号时，
内存占用会不断变大
【修改方案】
1.
信号发送时已经有该信号的siginfo在链表中时，不再重新申请，重复使用之前的siginfo.

【影响】
对现有的产品编译不会有影响。

re#I4DEG5
Signed-off-by: Nlanleinan <lanleinan@163.com>

Change-Id: I74b3b7ff0b9efb0179313af9a0c8d1e12d1db5bb
      d71db999
  9. 11 10月, 2021 1 次提交
  11. 30 9月, 2021 2 次提交
    • L
      feat: page cache backed by vnode instead of filep · 027fa613
      由 Leon Chan 提交于 
      1, change the owner of page to vnode
2, save the file path in vnode

close: #I4AGBR
Signed-off-by: NLeon Chan <chenwei26@huawei.com>
Change-Id: I04f93e344c7231d1731746456babc419a6139e52
Signed-off-by: NLeon Chan <chenwei26@huawei.com>
      027fa613
    • G
      fix: dyload open close failed · e5c7549b
      由 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
      e5c7549b
  13. 27 9月, 2021 1 次提交
    • H
      fixed 9fdb80f8 from https://gitee.com/harylee/kernel_liteos_a/pulls/628 · 42fdaffe
      由 Haryslee 提交于 
      fix: 共享内存问题修复
Signed-off-by: NHaryslee <lihao189@huawei.com>
背景：父进程移除共享内存并标记SHM_SEG_REMOVE,当子进程资源回收时在
ShmFindSeg接口中判断该共享内存具有SHM_SEG_REMOVE时返回空，但是此时
seg->ds.shm_nattch不为0，不应返回空。
方案：ShmFindSeg接口中增加seg->ds.shm_nattch为0的判断。

close #I47X2Z

Change-Id: I8735cd11ac237b17fa745c50313da0fd0649bb9f
      42fdaffe
  15. 26 9月, 2021 1 次提交
    • L
      fix: 修复sigwait等待到的信号值与获取的siginfo中的值不一致 · ed7defbd
      由 lnlan 提交于 
      【背景】
集成测试发送两个不同的信号，sigwait第二次等到的仍是第一个信号
经定位，信号在kill时会将相关的siginfo信息拷贝到taskcb的unbinfo中，sigwait
处理时从unbinfo拷贝给用户。若此信号发送时处于屏蔽状态，再有其他信号发送会覆盖
掉unbinfo，此时sigwait等待这个信号获取到的info已经被覆盖
【修改方案】
1. 每个任务添加一个siginfo缓存链表，在处理信号前夕从缓存链表取出info到unbinfo中

【影响】
对现有的产品编译不会有影响。

re #I3M12H
Signed-off-by: Nlanleinan <lanleinan@163.com>

Change-Id: If4b064c18773f8eca7419c665977260167b09810
      ed7defbd
  17. 31 8月, 2021 2 次提交
    • L
      feat: L0-L1 支持Trace · dc9ec685
      由 LiteOS2021 提交于 
              1.【需求描述】
            L0~L1 支持Trace，提供两种工作模式：在线模式、离线缓存模式， 用于按时间线追踪系统事件，如任务切换、中断、ipc等。
        2.【方案描述】
            L0:
            (1).在内核模块预置静态代码桩
            (2).触发桩后，收集系统上下文信息
            (3).离线模式则写入内存，用户可通过dump导出；
            (4).在线模式通过pipeline对接IDE进行可视化解析和展示；
            L1:
            新增trace字符设备，位于"/dev/trace",通过对设备节点的read\write\ioctl，实现用户态trace；

        BREAKING CHANGE:
        1.新增一系列trace的对外API，位于los_trace.h中.
        LOS_TRACE_EASY简易插桩
        LOS_TRACE标准插桩
        LOS_TraceInit配置Trace缓冲区的地址和大小
        LOS_TraceStart开启事件记录
        LOS_TraceStop停止事件记录
        LOS_TraceRecordDump输出Trace缓冲区数据
        LOS_TraceRecordGet获取Trace缓冲区的首地址
        LOS_TraceReset清除Trace缓冲区中的事件
        LOS_TraceEventMaskSet设置事件掩码，仅记录某些模块的事件
        LOS_TraceHwiFilterHookReg注册过滤特定中断号事件的钩子函数

        Close #I46WA0
Signed-off-by: NLiteOS2021 <dinglu@huawei.com>

Change-Id: I6a8e64794c4852f2c2980993a06180e09ec6ee0d
      dc9ec685
    • C
      chore: optimize build scripts and add lto config entry · 055295b6
      由 Caoruihong 提交于 
      Signed-off-by: NCaoruihong <crh.cao@huawei.com>
Change-Id: Ibf8df58696b7f1ccb3b5b21154c3b94dda1e8ad2
      055295b6
  19. 30 8月, 2021 1 次提交
  21. 28 8月, 2021 1 次提交
  23. 23 8月, 2021 1 次提交
  25. 22 8月, 2021 1 次提交
  27. 17 8月, 2021 1 次提交
  29. 14 8月, 2021 1 次提交
  31. 12 8月, 2021 1 次提交
    • W
      feat: 支持killpg和waitid · dc3cc094
      由 wjj 提交于 
      killpg：给进程组发信号
waitid：等待进程结束
修改测试用例到full里面

Change-Id: Ice058ab4a6eede8ecbaacea0894c2161e3b9dce2
Signed-off-by: Nwjj <502004968@qq.com>
      dc3cc094
  33. 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
  35. 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
  37. 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
  39. 06 8月, 2021 1 次提交
  41. 05 8月, 2021 1 次提交
  43. 04 8月, 2021 1 次提交
  45. 03 8月, 2021 1 次提交
  47. 02 8月, 2021 1 次提交
  49. 30 7月, 2021 3 次提交
  51. 27 7月, 2021 1 次提交
  53. 22 7月, 2021 2 次提交
  55. 21 7月, 2021 2 次提交
  57. 20 7月, 2021 3 次提交
    • 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
    • C
      fix: OsGetArgsAddr声明所在头文件不正确 · 14bd753a
      由 chenjing 提交于 
      close #I41MWM
Signed-off-by: Nchenjing <chenjing139@huawei.com>
Change-Id: Iad136b3b8b63fed63fa69c594ec39bd90d5513b7
      14bd753a
    • F
      feat: 增加mount的MS_RDONLY标志的支持 · 8729f6ee
      由 Far 提交于 
      增加mount的MS_RDONLY标志的支持，并修改vfs主要接口相关支持。
1. fatfs lseek接口在分区以MS_RDONLY方式和文件以只读打开时不再能够扩大文件的大小。
2. 直接在镜像中创建storage目录，而不是在挂载根文件系统时创建storage目录。
3. 增加了MS_RDONLY的测试用例。

Close #I3Z1W6
Signed-off-by: NFar <yesiyuan2@huawei.com>
      8729f6ee