lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 9 Nov 2015 16:27:01 -0800 From: Laura Abbott <labbott@...hat.com> To: "Murtaza, Alexandru" <alexandru.murtaza@...el.com>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org> Cc: "Baluta, Teodora" <teodora.baluta@...el.com> Subject: Re: [RFC][PATCH] Oops messages transfer using QR codes On 11/04/2015 03:32 AM, Murtaza, Alexandru wrote: >> The preferred style is to not have #ifdef in functions if it can be >> avoided. #ifdef in the header file for print_qr_err would be better. > > Could you please refer some example? I don't exactly understand what is > the desired way in this case. > In print_oops.h you can do #ifdef CONFIG_QR_OOPS void print_qr_err(void); #else static inline void print_qr_err(void); #endif This way if CONFIG_QR_OOPS is disabled the function just gets stubbed out. >> I gave it a quick test with just a 'echo c > /proc/sysrq-trigger' >> and got a scheduling while atomic warning in addition to not seeing a >> QR code. I don't think waking up a thread on panic is the correct approach >> here. Can you elaborate more on what problem you were trying to solve by >> adding a thread? > > You are right. It doesn't do anything for panics. Currently only Oopses are > handled, but this approach should work fine for panics too, with some code > changes. Basically, what runs inside the qr_thread_func can run after the panic > with no problem (at least the ASCII version of QR codes). > Even without the waking up of the thread or the panic there still seem to be scheduling while atomic issues. This is the rough code flow: print_qr_err make_bk1_message (mutexes) make_bk1_packet (vmalloc) compress compr_init (vmalloc) qrcode_encode_data qrcode_encode_data_real qrcode_encode_mask init_rs init_rs_internal (mutex) x86 oops_begin takes spinlocks and disables IRQs (as does ARM) so everything that happens in the oops needs to be done in atomic mode which means no vmalloc or mutexes. Most of this in kernel_oops can be refactored pretty easily but you might need to think about how the Reed-Solomon code can be refactored to avoid the mutex. One other point I noticed: qr_thread_func has an msleep(100). Polling like that isn't good style in the kernel. You should look into converting that to the completion API (wait_for_completion, complete) Can you share what you used for testing? I'm still not seeing any QR output. Thanks, Laura -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists