Kernel Newbies archive mirror
 help / color / mirror / Atom feed
From: mlin@mail.ustc.edu.cn
To: kernelnewbies@kernelnewbies.org
Subject: What situation will an anonymous writer come?
Date: Tue, 7 Nov 2023 16:59:41 +0800 (GMT+08:00)	[thread overview]
Message-ID: <1bc456fd.140c3.18ba9024a0c.Coremail.mlin@mail.ustc.edu.cn> (raw)


[-- Attachment #1.1: Type: text/plain, Size: 3744 bytes --]

Hi,


I find this function __up_writer refering to an anonymous a writer? How does it occur?

```
// kernel/locking/rwsem.c

static inline void __up_write(struct rw_semaphore *sem)                        
{                                                                              
        long tmp;                                                              
                                                                               
        DEBUG_RWSEMS_WARN_ON(sem->magic != sem, sem);                          
        /*                                                                     
         * sem->owner may differ from current if the ownership is transferred  
         * to an anonymous writer by setting the RWSEM_NONSPINNABLE bits.      
         */                                                                    
        DEBUG_RWSEMS_WARN_ON((rwsem_owner(sem) != current) &&                  
                            !rwsem_test_oflags(sem, RWSEM_NONSPINNABLE), sem);                <------------------  is it necessary?
                                                                               
        preempt_disable();                                                     
        rwsem_clear_owner(sem);                                                
        tmp = atomic_long_fetch_add_release(-RWSEM_WRITER_LOCKED, &sem->count);
        if (unlikely(tmp & RWSEM_FLAG_WAITERS))                                
                rwsem_wake(sem);                                               
        preempt_enable();                                                      
}                                                                              
```


I do a search by using `git blame` and find it's added in this commit 02f1082b003a0cd48f48f12533d969cdbf1c2b63,
and in this commit d7d760efad70c7a030725499bf9f342f04af24dd, it refers to below situation that can have an anonymous writer:


> There are use cases where a rwsem can be acquired by one task, but
> released by another task. In thess cases, optimistic spinning may need
> to be disabled. One example will be the filesystem freeze/thaw code
> where the task that freezes the filesystem will acquire a write lock
> on a rwsem and then un-owns it before returning to userspace. Later on,
> another task will come along, acquire the ownership, thaw the filesystem
> and release the rwsem.
>
> Bit 0 of the owner field was used to designate that it is a reader
> owned rwsem. It is now repurposed to mean that the owner of the rwsem
> is not known. If only bit 0 is set, the rwsem is reader owned. If bit
> 0 and other bits are set, it is writer owned with an unknown owner.
> One such value for the latter case is (-1L). So we can set owner to 1 for
> reader-owned, -1 for writer-owned. The owner is unknown in both cases.
> 
> To handle transfer of rwsem ownership, the higher level code should
> set the owner field to -1 to indicate a write-locked rwsem with unknown
> owner. Optimistic spinning will be disabled in this case.
> 
> Once the higher level code figures who the new owner is, it can then
> set the owner field accordingly.


As it mentions that at higher level, we set -1 to owner subjectively in order to do an owner migration, and I only find it's used in only
one place, i.e. percpu-rwsem in this commit 5a817641f68a6399a5fac8b7d2da67a73698ffed which has been removed in commit 
7f26482a872c36b2ee87ea95b9dcd96e3d5805df.


So does it mean an anonymous writer don't exist at current kernel? should we remove the second condition in this assert check?


DEBUG_RWSEMS_WARN_ON((rwsem_owner(sem) != current) &&                  
                            !rwsem_test_oflags(sem, RWSEM_NONSPINNABLE), sem);


Thanks,
Mu

[-- Attachment #1.2: Type: text/html, Size: 10081 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

             reply	other threads:[~2023-11-07  9:02 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-07  8:59 mlin [this message]
2023-11-11  0:36 ` What situation will an anonymous writer come? jim.cromie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1bc456fd.140c3.18ba9024a0c.Coremail.mlin@mail.ustc.edu.cn \
    --to=mlin@mail.ustc.edu.cn \
    --cc=kernelnewbies@kernelnewbies.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).