On Thu, 7 Dec 2017 01:27:03 +0000 "Su, David W" <david.w...@intel.com> wrote:
> >And spin_lock() turns into a mutex in PREEMPT_RT, which means it can > >sleep. You can't sleep in hard interrupt context. This will eventually > >crash the kernel. > > Steve, thanks for your review and comment. > > I can think of 2 scenarios where there is contention for the eventfd > context lock. > > One scenario is an eventfd is used to notify a VFIO application of > 2 or more IRQs. But in this case the application wouldn't be able to > tell which IRQ occurred and so I think it should be considered a > programming error of the application and not a proper usage of > VFIO. Remember, if there is contention, the system will CRASH! Boom, panic, end of story. Are you blowing this off to just a programming error of the application? I'm sure lots of root kit developers are excited about this. > > The other is a device IRQ is configured to be delivered to multiple > CPU cores at the same time. However, I have never seen such a > device and cannot think of any good reason for a device to be > designed this way. > > So, IMHO it is safe to set vfio-pci ISR to non-threaded. Please tell me that you are not arguing that it's OK to have a sleeping mutex in a hard threaded IRQ handler because "proper programming will prevent contention". If that is truly your argument, then I'm done here, with a perpetual NACK on your patches. -- Steve > > > > >And no, we are not going to convert the ctx->wqh.lock into a > >raw_spin_lock. > >
