On Sat, Jul 24, 2010 at 11:14 PM, Vasiliy Kulikov <segooon@xxxxxxxxx> wrote:
> Hi,
>
> I wonder how file->f_pos is protected in read()/lseek()/etc.
>
>
> Code from fs/read_write.c:
>
> static inline loff_t file_pos_read(struct file *file)
> {
> return file->f_pos;
> }
>
If u are reading a single value of the structure, there is no need to
lock it. but if u are reading a few fields of that structure, and to
ensure integrity protection as the fields are correlated with one
another, u have to lock it, so that reading all the individual fields
will be coherent as a whole.
If u are writing one field, if it can be guaranteed that it can be
completed in a single atomic instruction, then no locking is needed,
as there is no way another processor or interrupt can hijack the
changes. But for pointer traversal...several CPU instructions may be
needed so locking is needed, and to illustrate with example - from
fs/seq_file.c:
loff_t seq_lseek(struct file *file, loff_t offset, int origin)
{
struct seq_file *m = (struct seq_file *)file->private_data;
loff_t retval = -EINVAL;
mutex_lock(&m->lock);
m->version = file->f_version;
switch (origin) {
case 1:
offset += file->f_pos;
case 0:
if (offset < 0)
break;
retval = offset;
if (offset != m->read_pos) {
while ((retval=traverse(m, offset)) == -EAGAIN)
;
if (retval) {
/* with extreme prejudice... */
file->f_pos = 0;
m->read_pos = 0;
m->version = 0;
m->index = 0;
m->count = 0;
} else {
m->read_pos = offset;
retval = file->f_pos = offset;
>From above we can deduce that m->lock is the field to lock before
modifying file->f_pos is possible.
--
Regards,
Peter Teoh
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
