Hi, Jeffrey.

I have looked into the sources of the kernel 4.19.13.

After the series of checks the fcntl(F_SETFL) just stores flags into the file 
descriptor, and that's all:

fs/fcntl.c:

| int setfl(int fd, struct file * filp, unsigned long arg)
| {
|     int error = 0;
|     ...
|     if (filp->f_op->check_flags)
|         error = filp->f_op->check_flags(arg);
|
|     if (!error && filp->f_op->setfl)
|         error = filp->f_op->setfl(filp, arg);
|
|     if (error)
|         return error;
|     ...
|     /* #define SETFL_MASK (O_APPEND | O_NONBLOCK | O_NDELAY | O_DIRECT | 
O_NOATIME) */
|     filp->f_flags = (arg & SETFL_MASK) | (filp->f_flags & ~SETFL_MASK);
|     ...
|     return error;
| }

You can see two filesystem-specific hooks above, ->check_flags() and ->setfl().

But, to my surprise, ->setfl() is not used by any filesystem in the kernel tree. 
->check_flags() is used by nfs only, and just checks the flags, as it's name 
suggests.

Regards, Konstantin Andreev

Jeffrey Walton, 12 Nov 2019 02:21 MSK:

I have one more question related to my problem of my program losing data. I 
want to ensure I'm not using an anti-pattern that's causing the problem.

I have a worker thread that blocks on read(2). When the read() occurs, the fd 
is switch from blocking to non-blocking. Additional reads are performed until 
EAGAIN or EWOULDBLOCK. Then the fd is switched back to blocking mode.

Does switching a socket between blocking and non-blocking mode cause the kernel 
to reset or delete queued data (that has not been read by the application yet)?
----------

Here are the functions that switch between blocking and non-blocking mode. 
There's not much to them.

void make_blocking_fd(int fd)
{
     const int old = fcntl(fd, F_GETFL, 0);
     fcntl(fd, F_SETFL, old & ~(int)O_NONBLOCK);
}

void make_nonblocking_fd(int fd)
{
     const int old = fcntl(fd, F_GETFL, 0);
     fcntl(fd, F_SETFL, old | (int)O_NONBLOCK);
}

_______________________________________________
Kernelnewbies mailing list
[email protected]
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Reply via email to