- 16 9月, 2022 1 次提交
-
-
由 openharmony_ci 提交于
Merge pull request !135 from yinjiaming/OpenHarmony-3.0-LTS
-
- 06 9月, 2022 1 次提交
-
-
由 Yansira 提交于
错误场景: OHOS: mount -t nfs 192.168.1.1:/nfs nfs (cwd: /) OHOS: ls /nfs (成功) OHOS: ls nfs (成功) OHOS: cd nfs OHOS: ls (失败) 错误路径: 1. 以相对路径mount任意文件系统 2. open挂载点获得文件描述符fd 3. 通过fstat接口获取挂载点属性则会发生错误 错误根因: 1. 内核mount接口直接将入参target(挂载点)拷贝到Vnode的filePath字段,如果target为相对路径,则filePath为相对路径; 2. 打开挂载点时,Vnode的filePath直接赋值给文件接口提file的f_path字段; 3. 通过fstat接口查询挂载点属性,内核会调用get_path_from_fd接口获取file的f_path,再调用stat接口查询属性; 4. 由于此时f_path为相对路径,如果fstat时,进程的cwd与挂载时不一致,则导致查找目录失败。 re #I55W66 Signed-off-by: NKiita <zhanyan@huawei.com> Change-Id: I51a2b1e5a38702555adec5bd345e27f2d3eb74e4
-
- 15 7月, 2022 2 次提交
-
-
由 openharmony_ci 提交于
Merge pull request !130 from Hongjin Li/cherry-pick-1657846796
-
https://gitee.com/hongjin-li/third_party_NuttX/pulls/128由 JinuineLi 提交于
fix: memory leak memory allocated by calloc is never released when error returned Signed-off-by: NJinuineLi <lihongjin1@huawei.com> Change-Id: I593bad4a833a225d2f91dc036a23e4fffdc6fd6d
-
- 24 1月, 2022 2 次提交
-
-
由 openharmony_ci 提交于
Merge pull request !111 from pjscc/OpenHarmony-3.0-LTS
-
由 openharmony_ci 提交于
Merge pull request !111 from pjscc/OpenHarmony-3.0-LTS
-
- 13 1月, 2022 1 次提交
-
-
由 pjscc 提交于
Signed-off-by: Npjscc <pangjiashuai@huawei.com>
-
- 31 12月, 2021 1 次提交
-
-
由 openharmony_ci 提交于
Merge pull request !107 from huangshan/cherry-pick-1640571463
-
- 29 12月, 2021 1 次提交
-
-
由 openharmony_ci 提交于
Merge pull request !105 from Far/cherry-pick-1640053555
-
- 27 12月, 2021 1 次提交
-
-
https://gitee.com/uhamc/third_party_NuttX/pulls/98由 huangshan 提交于
适配内核修改,CheckMagicKey()传入consoleID Signed-off-by: Nhuangshan <huangshan9@huawei.com> Change-Id: I3f4edbda4ca2dc0f6c6e38beffc28b4ed0b93fcd
-
- 24 12月, 2021 2 次提交
-
-
由 openharmony_ci 提交于
Merge pull request !106 from LeonChan/cherry-pick-1640317964
-
https://gitee.com/leonchan5/third_party_NuttX/pulls/85由 Leon Chan 提交于
fix: add null check in rmdir/unlinkat close: #I4ATUC Signed-off-by: NLeon Chan <chenwei26@huawei.com>
-
- 21 12月, 2021 1 次提交
-
-
https://gitee.com/yesiyuanjim/third_party_NuttX/pulls/94由 Far 提交于
fix: 修复在NFS服务端修改文件引起的页数据不一致的错误 在NFS服务端修改文件数据,客户端不感知。如果在此之前在客户端执行过内存映射,可能会导致数据不一致,引起错误。 因此,在打开前校验文件的fhandle和时间戳,若文件发生改变,则使文件的映射失效。 Close #I4D5J4 Signed-off-by: NFar <yesiyuan2@huawei.com>
-
- 24 11月, 2021 1 次提交
-
-
由 openharmony_ci 提交于
Merge pull request !101 from LeonChan/pg3
-
- 23 11月, 2021 1 次提交
-
-
由 Leon Chan 提交于
close: I4JEBV Signed-off-by: NLeon Chan <chenwei26@huawei.com>
-
- 11 11月, 2021 1 次提交
-
-
由 openharmony_ci 提交于
Merge pull request !100 from Far/cherry-pick-1636458683
-
- 09 11月, 2021 1 次提交
-
-
https://gitee.com/yesiyuanjim/third_party_NuttX/pulls/96由 Far 提交于
fix: 修复NFS使用不可靠父节点信息的错误 NFS的read/write/readpage/writepage接口在读写数据前会尝试更新当前节点的fhandle,更新时会取用父节点vnode的私有数据。 此时如果父节点已经被释放,则可能导致访问空指针或错误数据。因此需要将父节点fhandle保存在当前节点私有数据中。 Close #I4EZ0V Signed-off-by: NFar <yesiyuan2@huawei.com>
-
- 08 10月, 2021 1 次提交
-
-
由 openharmony_ci 提交于
Merge pull request !93 from LeonChan/pg3
-
- 30 9月, 2021 1 次提交
-
-
由 Leon Chan 提交于
1, change the owner of page to the vnode instead of filep 2, store the file path in struct Vnode close: #I44TBS Signed-off-by: NLeon Chan <chenwei26@huawei.com>
-
- 28 9月, 2021 2 次提交
-
-
由 openharmony_ci 提交于
Merge pull request !92 from Kiita/LTS_3.0_toybox_mv
-
由 Yansira 提交于
【背景】3516 taurus toybox mv 命令进行重名文件移动时出现失败的问题 【修改方案】 修改patch_cache.c文件,新增已创建目的地址节点的备份操作。 Signed-off-by: yansira <yansira@hotmail.com> Change-Id: If1df3d5a08e2e27396e3915778802419563e4da8
-
- 26 9月, 2021 2 次提交
-
-
由 openharmony_ci 提交于
Merge pull request !89 from Caoruihong/cherry-pick-1632642935
-
https://gitee.com/caoruihong/third_party_NuttX/pulls/88由 Caoruihong 提交于
chore(oat): update OAT data Signed-off-by: NCaoruihong <crh.cao@huawei.com> Change-Id: Ib00f1634b3f3948c5469b79b0588ddb8de6d8119
-
- 02 9月, 2021 1 次提交
-
-
由 openharmony_ci 提交于
Merge pull request !80 from bigA2021/0830usb
-
- 31 8月, 2021 1 次提交
-
-
由 openharmony_ci 提交于
Merge pull request !79 from jason_gitee/master
-
- 30 8月, 2021 1 次提交
-
-
由 bigA2021 提交于
Signed-off-by: NbigA2021 <yanyin1@huawei.com> Change-Id: I9c97187a7d21cb07d91003ae27a5d863d3ec9ad1
-
- 26 8月, 2021 1 次提交
-
-
由 jason_gitee 提交于
Signed-off-by: Njason_gitee <yangjie140@huawei.com>
-
- 23 8月, 2021 1 次提交
-
-
由 openharmony_ci 提交于
Merge pull request !75 from Caoruihong/remove_dwc3
-
- 22 8月, 2021 1 次提交
-
-
由 Caoruihong 提交于
Signed-off-by: NCaoruihong <crh.cao@huawei.com> Change-Id: I84184ea450c4abf8d1123ef54d2527e4b1478364
-
- 19 8月, 2021 2 次提交
-
-
由 openharmony_ci 提交于
Merge pull request !74 from Caoruihong/update_musl
-
由 Caoruihong 提交于
Signed-off-by: NCaoruihong <crh.cao@huawei.com> Change-Id: I1c84a4c7dffe80ceb3b2d0daa643f2468e071717
-
- 18 8月, 2021 1 次提交
-
-
由 openharmony_ci 提交于
Merge pull request !71 from 野生毛霉君/master
-
- 13 8月, 2021 1 次提交
-
-
由 openharmony_ci 提交于
Merge pull request !67 from lnlan/fix_mqueue
-
- 12 8月, 2021 2 次提交
-
-
由 openharmony_ci 提交于
Merge pull request !72 from phchang/fixfifo
-
由 openharmony_ci 提交于
Merge pull request !44 from MGY917/master
-
- 11 8月, 2021 2 次提交
-
-
由 vcbchang 提交于
【背景】在测试fork通过fifo进行进程间通信时,进程同时进行open操作时会出现close失败的情况. 【修改方案】 pipecommon_close/open函数中在进行vnode->usecount++/--时没有进行加锁和解锁处理,会造成读出数据错误的情况,现在给予修正。 re #I41PBB Signed-off-by: Nvcbchang <vcbchang@qq.com> Change-Id: Ie944769617042c4d85e7cc52f5e4e341471d7d99
-
由 mucor 提交于
close: #I44WH1 Signed-off-by: Nmucor <mucorwang@gmail.com>
-
- 10 8月, 2021 3 次提交
-
-
由 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: I2bdf8d81f629b43810a642148b6e31fb815fe288 Signed-off-by: NGuangyao Ma <guangyao.ma@outlook.com>
-
由 lnlan 提交于
【背景】 1.mqueue用例关于NFILE错误码压力测试中,不符合预期结果 2.mq_unlink对于fork出的mqueue不起效 3.已打开的mqueue,在fork后两进程共用一份mqpersonal不合理 【修改方案】 1. 确认是内核关于mqueue的fd_set定义位置不合理导致的, 将fd_set定义位置由mqarray结构体调未全局变量后,问题解决 2.不合理的unlink_ref++导致的,去除相关操作,使用mq_personal 链表判断何时需要删除 3.fork时内核复制一份mqpersonal 【影响】 对现有的产品编译不会有影响。 re #I43P4T Signed-off-by: Nlanleinan <lanleinan@163.com> Change-Id: Iab40b097b4b4a0600e4c415b4702507634c4cd15
-
由 openharmony_ci 提交于
Merge pull request !68 from Caoruihong/oat2
-