On Thu, Dec 10, 2015 at 12:27 PM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > On Thu, Dec 10, 2015 at 11:47:18AM -0800, Kees Cook wrote: > >> In open, sure, but what about under mm/memory.c where we're trying to >> twiddle it from vma->file->f_flags as in my patch? That seemed like it >> would want atomic safety. > > Sigh... Again, I'm not at all convinced that this is the right approach, I'm open to any suggestions. Every path I've tried has been ultimately blocked by mmap_sem. :( > but generally you need ->f_lock. And in situations where the bit can > go only off->on, check it lockless, skip the whole thing entirely if it's > already set and grab the spinlock otherwise. And I can take f_lock safely under mmap_sem? -Kees -- Kees Cook Chrome OS & Brillo Security -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>