On Fri, Oct 31 2014, Florian Fainelli wrote: > I agree that the CMA allocation should not be allowed to succeed, but > the dma_alloc_coherent() allocation should succeed. If we look at the > sysport driver, there are kmalloc() calls to initialize private > structures, those will succeed (except under high memory pressure), so > by the same token, a driver expects DMA allocations to succeed (unless > we are under high memory pressure) > > What are we trying to solve exactly with the fatal_signal_pending() > check here? Are we just optimizing for the case where a process has > allocated from a CMA region to allow this region to be returned to the > pool of free pages when it gets killed? Could there be another mechanism > used to reclaim those pages if we know the process is getting killed > anyway? We're guarding against situations where process may hang around arbitrarily long time after receiving SIGKILL. If user does “kill -9 $pid” the usual expectation is that the $pid process will die within seconds and anything longer is perceived by user as a bug. What problem are *you* trying to solve? If user sent SIGKILL to a process that imitated device initialisation, what is the point of continuing initialising the device? Just recover and return -EINTR. > Well, not really. This driver is not an isolated case, there are tons of > other networking drivers that do exactly the same thing, and we do > expect these dma_alloc_* calls to succeed. Again, why do you expect them to succeed? The code must handle failures correctly anyway so why do you wish to ignore fatal signal? -- Best regards, _ _ .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o ..o | Computer Science, Michał “mina86” Nazarewicz (o o) ooo +--<mpn@xxxxxxxxxx>--<xmpp:mina86@xxxxxxxxxx>--ooO--(_)--Ooo-- -- 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