October 2016 - kernelnewbies@kernelnewbies.org

if/else block default coding style question
by Nicholas Mc Guire Oct. 8, 2016

Oct. 8, 2016

Hi ! There are quite a few places (roughly 90) in the kernel where an if/else if/else block repeats the last "case" presumably as default e.g. drivers/net/wireless/realtek/rtlwifi/rtl8192c/dm_common.c if ((rtlpcipriv->bt_coexist.bt_service == BT_BUSY) && (rtlpcipriv->bt_coexist.bt_rssi_state & BT_RSSI_STATE_NORMAL_POWER)) { rtl_write_byte(rtlpriv, REG_GPIO_MUXCFG, 0xa0); } else if ((rtlpcipriv->bt_coexist.bt_service == BT_OTHER_ACTION) && (rtlpriv->mac80211.mode < WIRELESS_MODE_N_24G) && (rtlpcipriv->bt_coexist.bt_rssi_state & BT_RSSI_STATE_SPECIAL_LOW)) { rtl_write_byte(rtlpriv, REG_GPIO_MUXCFG, 0xa0); } else if (rtlpcipriv->bt_coexist.bt_service == BT_PAN) { rtl_write_byte(rtlpriv, REG_GPIO_MUXCFG, tmp1byte); } else { rtl_write_byte(rtlpriv, REG_GPIO_MUXCFG, tmp1byte); } with the last else if and else being identical. So the question is if this is accepted coding style (notably without a coment) or if things like this should be flagged. I personally find this irritating as (without a comment) it is hard to say if this is a trivial type -> missed case, or if this is intended as a default behavior. So - before starting to generate a series of patches - should stuff like this be flagged ? thx! hofrat

3 5

walk up pagetables on ARM
by Oscar Salvador Oct. 6, 2016

Oct. 6, 2016

Hi all, for learning purposes, I wanted to emulate "lookup_address" function for ARM platforms, but I'm having some troubles which I don't know how to get over them. I'll explain it: I start by retrieving the value of swapper_pg_dir from TTBR1 register (during head.S executions the physical address of swapper_pg_dir is being saved in this register). So far this works, I can compare it with gdb: (gdb) p swapper_pg_dir Cannot access memory at address 0xc0004000 (gdb) p init_mm.pgd $5 = (pgd_t *) 0xc0004000 (gdb) And from my code: static pgd_t *get_global_pgd (void) { pgd_t *pgd; unsigned int ttb_reg; asm volatile ( " mrc p15, 0, %0, c2, c0, 1" : "=r" (ttb_reg)); ttb_reg &= ~0x3fff; pgd = phys_to_virt (ttb_reg); return pgd; } and the output: kernel: [18604.342604] mod: get_global_pgd: 0x0 - c0004000 So far, it's ok, but now the fun begins. I'm walking the page table to get the PTE related to an X address: static pte_t *lookup_address (unsigned long addr) { pgd_t *pgd; pud_t *pud; pmd_t *pmd; pgd = get_global_pgd() + pgd_index (addr); pud = pud_offset (pgd, addr); pmd = pmd_offset (pud, addr); if (pmd == NULL || pmd_none (*pmd)) { pr_info ("%s: pmd == NULL\n", r2_devname); return NULL; } return pte_offset_kernel (pmd, addr); } After that, I'd to check if the PTE has the PRESENT flag. Since ARM processor doesn't provide those flags Linux had to workaround that by adding these flags: (f.i: http://lxr.free-electrons.com/source/arch/arm/include/asm/pgtable-2level.h#… ) I'm checking the flags with pte_present or pte_write But I think I'm getting the wrong PTE's because I've tried with some address from /proc/kallsyms, and it's saying that the page is not present, and I'm getting diferent values for different pages in the same range. For instance: for: 0xc0009244: bananapi kernel: [18604.419142] mod: pte_present: 0 bananapi kernel: [18604.428025] mod: pte_write: 0 bananapi kernel: [18604.436592] mod: pte_young: 2 bananapi kernel: [18604.445318] mod: pte_dirty: 0 and for 0xc0012904: bananapi kernel: [18883.095749] r2k: pte_present: 0 bananapi kernel: [18883.104607] r2k: pte_write: 1 bananapi kernel: [18883.113159] r2k: pte_young: 0 bananapi kernel: [18883.121670] r2k: pte_dirty: 0 It's saying that is not present, but I can read from those addresses with gdb: (gdb) x/2x 0xc0009244 0xc0009244 <vfp_flush_hwstate>: 0xe92d4010 0xe1a04000 (gdb) x/2x 0xc0012904 0xc0012904 <__readwrite_bug>: 0xe1a01000 0xe30505ec (gdb) What am I doing wrong? Thanks in advance

1 0

data structure for NT_386_LTS note entry in coredump
by 慕冬亮 Oct. 5, 2016

Oct. 5, 2016

Dear all, I have a question about data structure for NT_386_LTS note entry in coredump and where is the code to store this entry into coredump. When I analyzed coredump and corresponding assembly code, I found there is one memory addressing with gs. GS is a selector used by glibc. But its base address is stored in the kernel space which I don't know from "gdb executable core". But fortunately I find a note entry with type NT_386_LTS in my coredump. The following is the content of this note entry, >> LINUX 48 386_TLS >> index: 6, base: 0xb7fd57c0, limit: 0x000fffff, flags: 0x00000051 >> index: 7, base: 0x00000000, limit: 0x00000000, flags: 0x00000028 >> index: 8, base: 0x00000000, limit: 0x00000000, flags: 0x00000028 Q1: Is there a data structure defined in header file like /usr/include/elf.h? Q2: Where is the code to store this entry into coredump? -- My best regards to you. No System Is Safe! Dongliang Mu

1 0

unsubscribe
by 고영준 Oct. 5, 2016

Oct. 5, 2016

unsubscribe 블로그서명ohojang님의 블로그 소프트웨어 프로그램개발

1 0

Char device write repeating
by Kenneth Adam Miller Oct. 5, 2016

Oct. 5, 2016

I have a character device that I am calling write on and which is succeeding, but which is repeatedly executing. I have hard coded the return value to one, so I don't think the userland standard library is retrying but I could be wrong. Can anybody tell me why write would be re-executed by the kernel and how to fix it? I dont actually copy_from_user, I just need this in order to signal kernel land.

5 5

[PATCH] INITEST: Documentation: Explains how INITEST works.
by Amit Kumar Oct. 5, 2016

Oct. 5, 2016

Signed-off-by: Amit Kumar <free.amit.kumar(a)gmail.com> This is a test patch. Is this patch in right format? --- Documentation/initest.txt | 7 +++++++ 1 file changed, 7 insertions(+) create mode 100644 Documentation/initest.txt diff --git a/Documentation/initest.txt b/Documentation/initest.txt new file mode 100644 index 0000000..eed4124 --- /dev/null +++ b/Documentation/initest.txt @@ -0,0 +1,7 @@ +INITEST + +1) This is the same user space program /sbin/init, but for the purpose of testing kernel system calls. + +2) It will also use testing drivers to test internal kernel API. + +3) This is a test patch. -- 2.7.4

4 6

seq_file calls stop() after show()
by Gaurav Kalra Oct. 5, 2016

Oct. 5, 2016

Hi, I am trying to duplicate the purpose of /proc/pid/io for a homework to understand how procfs / seq_file works. Although there is no mandate to use seq_file but it seems very interesting to me. The aim is to print an output similar to /proc/pid/io but for all processes at once using a custom proc file name "/proc/proc_io". The project is organized as follows: main.c -> It is responsible for kernel module init / deinit sequence.c -> This is where I have put in the processing logic utils.h -> bunch of macros for debugging The debugging logs come as follows: ========= [ +4.814129] <pl_open:15> [ +0.000017] <pl_seq_start:53> [ +0.000003] <pl_seq_start:55> init_task: [ffffffff81e11500] pos: [0] [ +0.000001] <pl_seq_show:103> [ +0.000004] <pl_seq_next:72> [ +0.000001] <pl_seq_next:79> n_tsk: [ffff880225a28000] [ +0.000002] <pl_seq_show:103> [ +0.000003] <pl_seq_next:72> [ +0.000002] <pl_seq_next:79> n_tsk: [ffff880225a28dc0] [ +0.000001] <pl_seq_show:103> [ +0.000003] <pl_seq_next:72> [ +0.000001] <pl_seq_next:79> n_tsk: [ffff880225a29b80] [ +0.000002] <pl_seq_show:103> [ +0.000002] <pl_seq_next:72> [ +0.000002] <pl_seq_next:79> n_tsk: [ffff880225a2b700] [ +0.000001] <pl_seq_show:103> [ +0.000003] <pl_seq_next:72> [ +0.000001] <pl_seq_next:79> n_tsk: [ffff880225a2d280] [ +0.000002] <pl_seq_show:103> [ +0.000002] <pl_seq_next:72> [ +0.000001] <pl_seq_next:79> n_tsk: [ffff880225a2e040] [ +0.000002] <pl_seq_show:103> [ +0.000002] <pl_seq_next:72> [ +0.000002] <pl_seq_next:79> n_tsk: [ffff880225a2ee00] [ +0.000001] <pl_seq_show:103> [ +0.000003] <pl_seq_next:72> [ +0.000001] <pl_seq_next:79> n_tsk: [ffff880225a78000] [ +0.000002] <pl_seq_show:103> [ +0.000002] <pl_seq_next:72> [ +0.000002] <pl_seq_next:79> n_tsk: [ffff880225a7ee00] [ +0.000001] <pl_seq_show:103> [ +0.000003] <pl_seq_next:72> [ +0.000001] <pl_seq_next:79> n_tsk: [ffff880225aa8000] [ +0.000001] <pl_seq_show:103> [ +0.000003] <pl_seq_next:72> [ +0.000002] <pl_seq_next:79> n_tsk: [ffff880225aa8dc0] [ +0.000001] <pl_seq_show:103> [ +0.000002] <pl_seq_next:72> [ +0.000002] <pl_seq_next:79> n_tsk: [ffff880225aaa940] [ +0.000001] <pl_seq_show:103> [ +0.000003] <pl_seq_next:72> [ +0.000001] <pl_seq_next:79> n_tsk: [ffff880225aab700] [ +0.000002] <pl_seq_show:103> [ +0.000002] <pl_seq_next:72> [ +0.000002] <pl_seq_next:79> n_tsk: [ffff880225aac4c0] [ +0.000001] <pl_seq_show:103> [ +0.000003] <pl_seq_next:72> [ +0.000001] <pl_seq_next:79> n_tsk: [ffff880225aad280] [ +0.000001] <pl_seq_show:103> [ +0.000003] <pl_seq_next:72> [ +0.000001] <pl_seq_next:79> n_tsk: [ffff880225aaee00] [ +0.000002] <pl_seq_show:103> [ +0.000002] <pl_seq_next:72> [ +0.000002] <pl_seq_next:79> n_tsk: [ffff880225048000] [ +0.000001] <pl_seq_show:103> [ +0.000003] <pl_seq_next:72> [ +0.000001] <pl_seq_next:79> n_tsk: [ffff880225048dc0] [ +0.000002] <pl_seq_show:103> [ +0.000002] <pl_seq_next:72> [ +0.000002] <pl_seq_next:79> n_tsk: [ffff880225049b80] [ +0.000001] <pl_seq_show:103> [ +0.000003] <pl_seq_next:72> [ +0.000001] <pl_seq_next:79> n_tsk: [ffff88022504b700] [ +0.000001] <pl_seq_show:103> [ +0.000003] <pl_seq_next:72> [ +0.000002] <pl_seq_next:79> n_tsk: [ffff88022504c4c0] [ +0.000001] <pl_seq_show:103> [ +0.000002] <pl_seq_next:72> [ +0.000002] <pl_seq_next:79> n_tsk: [ffff88022504d280] [ +0.000001] <pl_seq_show:103> [ +0.000003] <pl_seq_next:72> [ +0.000001] <pl_seq_next:79> n_tsk: [ffff88022504e040] [ +0.000002] <pl_seq_show:103> [ +0.000002] <pl_seq_next:72> [ +0.000001] <pl_seq_next:79> n_tsk: [ffff8802250f0000] [ +0.000002] <pl_seq_show:103> [ +0.000002] <pl_seq_next:72> [ +0.000002] <pl_seq_next:79> n_tsk: [ffff8802250f0dc0] [ +0.000001] <pl_seq_show:103> [ +0.000003] <pl_seq_next:72> [ +0.000001] <pl_seq_next:79> n_tsk: [ffff8802250f1b80] [ +0.000002] <pl_seq_show:103> [ +0.000002] <pl_seq_next:72> [ +0.000002] <pl_seq_next:79> n_tsk: [ffff8802250f2940] [ +0.000001] <pl_seq_show:103> [ +0.000002] <pl_seq_next:72> [ +0.000002] <pl_seq_next:79> n_tsk: [ffff8802250f44c0] [ +0.000001] <pl_seq_show:103> [ +0.000003] <pl_seq_next:72> [ +0.000001] <pl_seq_next:79> n_tsk: [ffff8802250f5280] [ +0.000002] <pl_seq_show:103> [ +0.000002] <pl_seq_next:72> [ +0.000002] <pl_seq_next:79> n_tsk: [ffff8802250f6040] [ +0.000001] <pl_seq_show:103> [ +0.000003] <pl_seq_next:72> [ +0.000001] <pl_seq_next:79> n_tsk: [ffff8802250f6e00] [ +0.000001] <pl_seq_show:103> [ +0.000003] <pl_seq_next:72> [ +0.000001] <pl_seq_next:79> n_tsk: [ffff8802251a0dc0] [ +0.000002] <pl_seq_show:103> [ +0.000002] <pl_seq_next:72> [ +0.000002] <pl_seq_next:79> n_tsk: [ffff8802251a1b80] [ +0.000001] <pl_seq_show:103> [ +0.000003] <pl_seq_stop:92> [ +0.000276] <pl_seq_start:53> [ +0.000002] <pl_seq_start:55> init_task: [ffffffff81e11500] pos: [1] [ +0.000001] <pl_seq_stop:92> ========= Towards the end, the sequence is as follows: [ +0.000001] <pl_seq_show:103> [ +0.000003] <pl_seq_stop:92> i.e. stop() is called after show(). This is making my output truncated to only first few processes. Although I always return 0 from show(), I fail to understand why stop() is being invoked just after show(). Can you please help me or redirect me somewhere to understand why this is happening? Thank You. Gaurav

1 0

Linux Kernel Based Research Projects
by Shyam Saini Oct. 4, 2016

Oct. 4, 2016

Hi everyone, I'm final year computer science undergraduate student. I want to do my major project based on linux kernel. Would you please suggest me some areas in the kernel which have some projects. To be more specific, I want know on going research areas in kernel. Or some ideas which are not yet implemented. Thanks, Shyam

4 8

memblock_reserve or memblock_remove to reserve a page
by Nikhil Utane Oct. 4, 2016

Oct. 4, 2016

I want to reserve a physical memory page with a fixed PFN. I do not want this page to be used by anyone else. I am calling memblock_reserve() to supposedly reserve the page. I am writing some content into this page. What I see is that during some runs the content of this page is modified (either fully or sometimes partially). In few runs, I see it as intact. Is it expected that even after calling memblock_reserve() the kernel can allocate this physical page for any other purpose? How is memblock_remove() different from memblock_reserve? I tried reading up but didn't see any useful information. What I understood is memblock_remove will completely remove from kernel's allocation mechanism. Should I then be using remove instead of reserve? -Thanks Nikhil

3 15

opinion about fs and gs in linux
by 慕冬亮 Oct. 3, 2016

Oct. 3, 2016

Dear all, When I analyzed one coredump and read some assembly code, I encounter one specific segment register : gs. I googled it and found the following links: [1] http://stackoverflow.com/questions/10810203/what-is-the-fs-gs-register-inte… [2] http://reverseengineering.stackexchange.com/questions/2006/how-are-the-segm… [3] http://stackoverflow.com/questions/6611346/how-are-the-fs-gs-registers-used… In IA32 FS is used by Windows and GS by glibc to reference TLS entry. And in my 32bit linux, I found fs is 0 in my coredump and gs is 0x33. -- My best regards to you. No System Is Safe! Dongliang Mu

1 0