调用futime时，系统调用接口函数直接使用了file结构体的f_path字段，该字段在退出前被错误地释放了。
避免该问题需要拷贝一份路径
Signed-off-by: NFar <yesiyuan2@huawei.com>
Change-Id: I519ccb38bec323c93aa8cff920143bb3f9931c22

Merge pull request !759 from Harylee/mmu

Merge pull request !764 from xuxinyu/master

背景：同一个进程的多个线程读写同一个PTE时，由于PTE无保护，存在竞态问题。
方案：新增spinlock保护PTE，包括大锁跟小锁。大锁：一个进程只有一个spinlock锁，多个线程
读写PTE时竞争一把锁，锁的内存占用小，但系统性能降低；小锁：每个页表持有一把spinlock，
由于锁是page结构体的一个字段，内存消耗较大，但是相对大锁性能较优。系统默认使用大锁,用
户可根据具体需要配置使用大锁还是小锁。

close #I2WARC
Signed-off-by: NHaryslee <lihao189@huawei.com>
Change-Id: I5612eeac1f65507160035eae16af61f285182eda

【背景】
 Codex扫描告警清除

【修改方案】
 将不可屏蔽告警进行修复

 re #I4PNO3
Signed-off-by: Nxuiny <xuxinyu6@huawei.com>

Change-Id: If6f85eb9679d47e6256f24cdc74246df78da579d

Merge pull request !749 from maweiye/master

Merge pull request !763 from Far/master

Close #I4PEVP
Signed-off-by: NFar <yesiyuan2@huawei.com>

Merge pull request !756 from Harylee/print

背景：重复执行内存测试用例约几百次，系统大概率出现卡死现象，经分析知，系统卡在
内存spinlock锁中，CPU1在获取内存spinlock锁后打印异常信息，此时循环buffer满了，
CPU0此时进入异常且尝试拿取内存spinlock锁，两个核都处于锁中断锁任务状态，CPU1
写事件触发调度打印输出失败，进而在write接口中死循环无法退出，导致两个核都卡住。
方案：在write接口中增加一个判断条件：当前核处于锁任务状态且循环buffer满了时候，
直接退出循环，丢弃打印信息（持有spinlock锁后一般禁止输出打印信息）。

close #I4F7PO
Signed-off-by: NHaryslee <lihao189@huawei.com>
Change-Id: I3f49a1bb211821e9c5d1d220d6867962d6a45a79

Merge pull request !738 from Harylee/readme

Merge pull request !747 from LeonChan/master

Signed-off-by: Nmaweiye <maweiye@huawei.com>

close: #I4NY49
Signed-off-by: NLeon Chan <chenwei26@huawei.com>

Merge pull request !744 from zhangfanfan2/master

用例异常时出现Domain fault或者unknown fault，经分析发现是TLB缓存一致性问题，
在缺页异常入口，对上述两种异常类型做异常地址TLB缓存清理即可。

close #I3ZJ1D
Signed-off-by: NHaryslee <lihao189@huawei.com>
Change-Id: Ib84e3e87047fcac392b83a4cf6cca0d91754e66f

close: #I4NOC7
Signed-off-by: Nzff <zhangfanfan2@huawei.com>
Change-Id: I7f28e79293d3388e2b1d7208c2b8ff8ff133528a

Merge pull request !735 from shenchenkai/master

Change-Id: I5d23deaada5939bbb6fb57505f72c2348bd6afe9
Signed-off-by: Nshenchenkai <shenchenkai@huawei.com>

Merge pull request !730 from 雷电_SWAT/master

Merge pull request !734 from 尹树清/master

Merge pull request !733 from Zhaotianyu/1213cirbuf_refactor

Merge pull request !732 from wangchen/kernel_build

【背景】编译框架在做编译入口的统一，a核两种编译方式生成结果有差异

【修改方案】
1，修改kernel依赖

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

re #I4KRQN
Signed-off-by: Nwangchen <253227059@qq.com>

Signed-off-by: Nyinshuqing <yinshuqing@huawei.com>

将循环buf的上/解锁操作合进读/写操作里，删除对外上/解锁接口

BREAKING CHANGE:
1. 删除 LOS_CirBufLock()，LOS_CirBufUnlock()内核对外接口
2. LOS_CirBufWrite()，LOS_CirBufRead()由原先内部不进行上/解锁操作，变为默认已包含上/解锁操作。

close: #I4MC13
Signed-off-by: Narvinzzz <zhaotianyu9@huawei.com>
Change-Id: Ie3cc1abde7fa0e5479ccbf4e596426e509b5cef5

Merge pull request !731 from Far/master

1. 在必要处增加宏开关关闭部分代码的编译；
2. 由于驱动是一个独立的内核线程，在一些场景下文件系统会将用户态地址透传给驱动，这会导致内核崩溃。
因此在需要透传用户态地址时增加了一个内核buffer作为中转。

Close #I3T3N0
Signed-off-by: NFar <yesiyuan2@huawei.com>

去除不必要分支，使用三元操作符优化简单分支
Signed-off-by: Nlcjh <120989324@qq.com>

Merge pull request !728 from Caoruihong/remove_visibility

Merge pull request !703 from Kiita/1109_dmesg

Signed-off-by: NCaoruihong <crh.cao@huawei.com>
Change-Id: I83616f794d169c8637ab79b2dd96d3858d11fce7

Merge pull request !643 from Caoruihong/support_gcc

【背景】自研shell或者mksh拉起后使用dmesg -s命令出现自旋锁double lock的问题。

【修改方案】
dmesg -s参数设置dmesg缓冲区过程需要访问UartOutput所访问的全局缓冲区，这意味着两个功能模块
使用了同一把自旋锁，若在dmesg命令执行过程使用了打印，则就可能会导致double lock。因此拆分
了dmesg -s命令过程中自旋锁的使用区域，避开内核中必要的打印。

re #I4HIJK
Signed-off-by: yansira <yansira@hotmail.com>
Change-Id: Iad74c058c9a8090fd3d9f338caab7d8f2170f9ac

Signed-off-by: NCaoruihong <crh.cao@huawei.com>
Change-Id: I6f2dea19cbd2e5b562bb51e30592205a2bb4fbdb

Merge pull request !726 from kenneth/los_pmm.h

Merge pull request !727 from kenneth/page_idx

修改los_arch_mmu.c中的page_idx 为scanIndex，修改pmm_alloc_page为LOS_PhysPageAlloc。

fix #I4KMMJ
Signed-off-by: Nkenneth <zhushangyuan@huawei.com>

删除无用的头文件kernel\base\include\los_pmm.h

fix #I4KN63
Signed-off-by: Nkenneth <zhushangyuan@huawei.com>

Merge pull request !722 from zhangfanfan2/other3