On 06/01/2017 05:37 AM, Lu Baolu wrote: > Hi, > > On 05/31/2017 05:38 PM, Vlastimil Babka wrote: >> On 05/31/2017 05:27 AM, Lu Baolu wrote: >>> Hi, >>> >>> On 05/30/2017 09:46 PM, Vlastimil Babka wrote: >>>> On 03/21/2017 09:01 AM, Lu Baolu wrote: >>>> Did you forget to remove the #define XDBC_TRACE? >>>> >>>> Enabling this driver brings the "trace_printk() being used. Allocating >>>> extra memory. This means that this is a DEBUG kernel and it is unsafe >>>> for production use." message in 4.12-rcX dmesg. >>> This feature is only for a DEBUG kernel, should not be enabled for >>> any production kernel. This was the reason I enabled trace_printk() >>> by default. >> Hmm, but it seems we generally enable all these early printk >> features/drivers in our distro kernels. They are not active without a >> early_printk=X bootparam anyway, right? It's much more convenient to >> e.g. just tell customer to change a param when debugging something than >> to install a debug kernel. So I wouldn't agree that only a DEBUG kernel >> should have this compiled in. > > Okay, I will try to find a fix. Thanks. I didn't make it clear that the trace_printk() warning is there even if the code using it doesn't actually execute (i.e. I didn't specify any early_printk bootparam). There are some roastedy tricks to detect the potential users, so that the buffers can be allocated in advance to allow the first trace_printk() from any context, I guess. I'm not sure if there's a way to change it so that your driver reports the trace_printk usage only in response to the bootparam (which could also be a safe point to allocate ftrace buffers?). Vlastimil -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
