since the decision is already done at open time(from path to fd)
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Change-Id: Idc1df3c1d7fe60927b0643173f3f40895aaffd4c
Note: this patch can get file path from root pseudo file handle,
but a general infrastructure is setup for other file system too.
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Change-Id: I86cd79ebb741f2f43fdd398bb7498c40687d949b
it's more simple to reuse the resolve argument as the recursive count
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Change-Id: I826b2fef3af8b12aae230e4766ab09f8de988f8a
ensure the behaviour is same in all ioctl function variant
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Change-Id: Ie67cfbc579004c8488ef5004c9be7fb179e77041
Fix bug that select() did not return when the nfds argument
was set to a negative value. The specification is that -1 is
set to the return value and EINVAL is set to errno.
let's call either nx_dup/nx_dup2 or file_dup/file_dup2
instead just like other fs api: xxx->nx_xxx->file_xxx
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Change-Id: I1aacfb9e25dc7b3fcb0345ff7b269b1953a01e5b
the argument passed to file_dup2 doesn't always come from task file list
so it doesn't make sense to hold the file list lock and then it is better
to do the protection in the new function files_dupfd2
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Change-Id: Ibf02cea9b0b275e7472f9c04fd66b9242285b957
these functions are the implementation detail and then
don't need expose to external
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Change-Id: Ief832391d5b42d1f1645907eb465631650490234
the kernel user should call file_open directly instead
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Change-Id: I5bf7f661006f5d43739bc8618abfb4b983fde78d
on the other hand, open/nx_open call file_open instead
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Change-Id: I66990a77cdeb6ff18f7bf48a65bbc7b701dad552
let's replace the content of file in place instead
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Change-Id: I538910d55815c7aec656c05dba4eab2fa1d6d964
NULL inode passed to files_allocate doesn't mark file struct in the
allocated state, so other threads which invovle in file allocation
(e.g. open or dup) may allocate the same file struct again.
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Change-Id: I53ff876eae3c7a1e311e7f671686b73a4b4ef891
since the internal function normally return the error code directly
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Change-Id: Ifccbcfb07d2f8f7d5fef1b2a867538f51b73655c
In current implementation, the asynchronous call "epoll_ctl()" unable
to wakeup the thread if pending on "epoll_wait()", the newly
added/delete FD cannot be used in the current waiting list,
this patch uses a reserved file object to wake up pending poll internal,
re-traverse the waiting list when a new event comes.
Signed-off-by: chao.an <anchao@xiaomi.com>
since the stdin, stdout and stderr may initialize later
in userspace if CONFIG_DEV_CONSOLE isn't enabled.
Note: it isn't bigger issue here to skip the check because
vfs will check the validation again in read and write syscall
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
The unique minor limit of 255 will overflow easily in
some scenarios where eventfd needs to be create/destroy
frequently:
while (1)
{
fd = eventfd(0, 0); // minor++
sleep(1);
close(fd);
}
remove the unique minor limit.
Change-Id: I0ea1c825ce9b542c883166cb3e72574455ffdd0d
Signed-off-by: chao.an <anchao@xiaomi.com>
There is a good case on sim platform:
When we input some cmd and click enter key to start application in terminal,
this context will change to application from IDLE loop. Althrough entey key '\r'
has been received to recv buffer and complete post semaphore of reader, but
pollnotify may not be called because context change. So when application run
poll function, because no events happend and poll enter wait, context will
again change to IDLE loop, this pollnotify of IDLE loop will run to send poll
events, poll function of applicaton will wake up. It's wrong!
Change-Id: I812a889f2e90781a9c3cb4b0251cccc4d32bebd1
Signed-off-by: dongjiuzhu <dongjiuzhu1@xiaomi.com>
