Re: Which types of locking should I use?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, May 04, 2004 at 18:53:59 +0900, Tetsuo Handa wrote:
> Hello, Jan.
> 
> (NOTE: I listed some functions where I want to use 'current',
> and the following is Jan's answer.
> Not applicable to all functions defined in fs/*.c !)
> "Jan Hudec <bulb@ucw.cz>" wrote:

Well, I actualy think it DOES apply to ALL those functions. But I would
have to check each of them.

> > Summary: All of the functions can safely use current without any special
> > precautions whatsoever. All of them may (and usualy do) sleep, since
> > they need 
> 
> I'm relieved to hear that. Thank you very much.
> 
> Now I can proceed to the next and the final problem,
> "Which types of locking should I use". Until now I was using
> spin_lock_irqsave() and spin_unlock_irqrestore() because (I thought)
> functions I listed may be called from interrupt context.
> 
> But now it turned out functions I listed are called only from processes,
> I no longer need to disable hardware IRQ, software IRQ, tasklets or BHs.
> 
> Functions I wrote don't call functions that may sleep.
> (I use kmalloc(GFP_ATOMIC) to not to sleep.)
> So I can use spin_lock() instead of spin_lock_irqsave(), can't I?
> Or (since functions I listed may sleep,) should I use semaphores
> to avoid using kmalloc(GFP_ATOMIC) ?
> 
> If I'm wrong please mention it.

Ad GFP_ATOMIC: With GFP_ATOMIC allocations, you must expect them to fail
and deal with it as a pretty much normal condition. That is, it
especialy must not lead to the syscall failing!! So you should use
GFP_NOFS in writeout path (->writepage and below) and GFP_KERNEL in all
the other places. These will get the memory almost always. You should
still check, but if these fail, the system is in such a horrible state,
that you can just throw up your hands and return an error (unlock locks,
however). Of course, you must move your allocations out of the critical
section, which you should do anyway.

Ad spinlocks: If other users of a spinlock don't disable irq, you don't
have to either. You probably should not be introducing new locks, at
least unless you introduce new structures.

You should really study the existing locking scheme a bit. You should
know, what can happen when and what states are considered consistent.

-------------------------------------------------------------------------------
						 Jan 'Bulb' Hudec <bulb@ucw.cz>

Attachment: signature.asc
Description: Digital signature


[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux