Hi Tang, One minor point. On Tue, Jan 15, 2013 at 9:54 PM, Tang Chen <tangchen@xxxxxxxxxxxxxx> wrote: > It is unsafe to return an entry pointer and release the map_entries_lock. So we should > not hold the map_entries_lock separately in firmware_map_find_entry() and > firmware_map_remove_entry(). Hold the map_entries_lock across find and remove > /sys/firmware/memmap/X operation. > > And also, users of these two functions need to be careful to hold the lock when using > these two functions. > > The suggestion is from Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> > > Signed-off-by: Tang Chen <tangchen@xxxxxxxxxxxxxx> > --- > drivers/firmware/memmap.c | 25 +++++++++++++++++-------- > 1 files changed, 17 insertions(+), 8 deletions(-) > > diff --git a/drivers/firmware/memmap.c b/drivers/firmware/memmap.c > index 4211da5..940c4e9 100644 > --- a/drivers/firmware/memmap.c > +++ b/drivers/firmware/memmap.c > @@ -188,23 +188,28 @@ static inline void remove_sysfs_fw_map_entry(struct firmware_map_entry *entry) > } > > /* > - * Search memmap entry > + * firmware_map_find_entry: Search memmap entry. > + * @start: Start of the memory range. > + * @end: End of the memory range (exclusive). > + * @type: Type of the memory range. > + * > + * This function is to find the memmap entey of a given memory range. > + * The caller must hold map_entries_lock, and must not release the lock > + * until the processing of the returned entry has completed. > + * > + * Return pointer to the entry to be found on success, or NULL on failure. Why not make this completely kernel-doc compliant as you're already re-writing the comment? Thanks, -- Julian Calaby Email: julian.calaby@xxxxxxxxx Profile: http://www.google.com/profiles/julian.calaby/ .Plan: http://sites.google.com/site/juliancalaby/ -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
