Re: DIAGNOSTIC panic in unp_gc function

[christos%zoulas.com@localhost (Christos Zoulas)]

On Feb 27,  8:23pm, ritesh.agrawal%teznetworks.com@localhost (Ritesh Agrawal) wrote:
-- Subject: Re: DIAGNOSTIC panic in unp_gc function

| > Yes, I've seen that too but it is rare. Can you make an example program
| > that triggers it?

| I agree, this is not easily reproducible but I am able to reproduce this 
| in my setup using in house developed automation tool.
| It occurs in specific condition and I am not sure whether I will be able 
| to write a sample code which can reproduce this issue at will. And might 
| need a complete infrastructure and similar setup to reproduce this. We 
| will need to simulate closing of socket by process 2 when the "unp_gc" 
| has marked the socket as "FDEFER".
| We hit upon this issue by mistake, we were suppose to pass the regular 
| file descriptor but due to some bug in code the original file descriptor 
| got closed. And the communicating AF_LOCAL socket took the same fd 
| number and got passed along the message.
| Do you think how we should fix this issue as we can definitely reproduce 
| this in closed environment?
| I put a check instead of "KASSERT(fp->f_count != 0);" and did continue.
| 
| 1713c1713,1716
| <                 KASSERT(fp->f_count != 0);
| ---
|  >                 if (fp->f_count == 0) {
|  >                     mutex_exit(&fp->f_lock);
|  >                     continue;
|  >                 }
| 
| But I know this is not a better method to fix it and we will need a 
| better fix for this problem.

Well, the only other place where we decrement the f_count is in
kern_descrip.c closef(), and that does not pay attention to FDEFER,
so that fix is probably correct (or we will have to make closef()
pay attention to FDEFER). Assuming that my guess is right and closef()
is called while we are gc'ing.

christos