March 2019 - kernelnewbies@kernelnewbies.org - Kernelnewbies Mailing Lists

What will happen if 2 processes map same physical page
by Lev Olshvang March 22, 2019

March 22, 2019

Hi all, The question is it ipossiblle in Linux/MMU/TLB that 2 processes map to the same physical address? Will CPU or TLB discover that second process tries to reach occupied physical page? What if first process set page permission to read and second whats to write to this page ? Perhaps during context switch all page access permissions of first process is flashed out from MMU ? I confess I do not know what exactly happens in TLB and between Linux and hardware view of pages. I am particularly intereste in ARMv7, perhaps its architecture have some solutions to these question. Regards, Lev

3 6

fsync slowness + XFS -- Regd.
by Jeno P March 19, 2019

March 19, 2019

Dear folks, Hoping all are doing good. *Issue*:- Slowness in fsync() *System details*:- OS:- CentOS Linux *7.4* Linux Kernel:- *3.10.0-514 x86-64* File system:- *XFS* One of my module *(C/C++)* is writing to log files and periodically flushes it using *fsync()*. Even for small amount of data, *fsync* is taking more time *(>15 seconds)* than expected. Consequently, the main process was timed-out and got killed. Confirmed the slowness through strace. Observed the same behavior with *fsync* alternatives - *fdatasync & syncfs *as well *. *The odd thing is even with very very minimal disk I/O, same issue is happening. Did anybody face the issue ? I saw in this forum that performance improvements with respect to *fysnc* has already been made in file systems *ext2, ext3, brtfs* and *f2fs *in latest Kernels. I saw a similar improvement in quite old Kernel *(2.6.34)* for *XFS*. But, I didn't see any such improvements *(for XFS)* in *newer Kernels*. Should I need to downgrade my Kernel and observe the issue ? I fear that downgrading may lead to other performance issues. Is there a patch being planned in latest Kernel for CentOS ? Looking forward to hear back from you all. Thanks, Jeno

3 2

vmalloc_to_page is contiguous ?
by Ranran March 18, 2019

March 18, 2019

Hello, Does vmalloc_to_page() returns contiguous physical memory ? I ask becuase I see that its return value is used for DMA and DMA uses contiguous memory. see here: https://elixir.bootlin.com/linux/latest/source/drivers/mtd/nand/onenand/sam… Yet, in vmalloc_to_page implementation: https://elixir.bootlin.com/linux/v4.5/source/mm/vmalloc.c#L234 it does not seem that it creates a contiguous allocation. Thank you, ranran

2 1

Reentrant Interrupt Handler
by ksourav March 17, 2019

March 17, 2019

Hi, AFAIK, when cpu run an interrupt handler, local interrupt is disabled. It means that this cpu is not going to be interrupted until it executes the current interrupt handler. Can same interrupt occur on other cpus? Suppose a device interrupts and its handler starts running on cpu0. What happens if this device issue another interrupt before the handler running on cpu0 is finished? Will interrupt handler run on another (say cpu1) concurrently? Any explanation regarding arm/gic will helpful. Thanks in advance!

1 0

majordomo@vger.kernel.org subscription list error
by moo can March 15, 2019

March 15, 2019

Hello, I'm trying to subscribe to the linux-usb mailing list using majordomo(a)vger.kernel.org I'm facing exactly the same bug like these one and after two days of searching everywhere I have found these: https://www.mail-archive.com/linux-usb@vger.kernel.org/msg102138.html https://bugs.gentoo.org/show_bug.cgi?id=612704 Every time I trying to register I have this answer :failure notice policy analysis reported: Your address is not liked source for email I tried using yahoo and outlook and I can't register. Which email provider are not banned from majordomo(a)vger.kernel.org ? Many thanks in advance for your return. Kind Regards Fabien

1 0

HID Driver
by Pratyush Das March 15, 2019

March 15, 2019

Hi, I have a device operated via an Arduino UNO board. I would like to write a driver for it so that my computer running linux recognises it natively. I have no experience writing drivers. Where should I start to specifically do something like this? Are there any templates or guides for drivers for this sort of thing specifically? Do I need to start over from scratch - learning how to write drivers? If so, could you recommend any resources in particular which would take me on the path to write drivers for HIDs in particular(to begin with)? Thanks, -- Pratyush Das(Reik)

3 4

mm/vmscan.c: reclaim unevictable pages
by Pankaj Suryawanshi March 15, 2019

March 15, 2019

Hello , shrink_page_list() returns , number of pages reclaimed, when pages is unevictable it returns VM_BUG_ON_PAGE(PageLRU(page) || PageUnevicatble(page),page); We can add the unevictable pages in reclaim list in shrink_page_list(), return total number of reclaim pages including unevictable pages, let the caller handle unevictable pages. Below is the Error Msg/Kerenl Crash : [ 24.718792] page dumped because: VM_BUG_ON_PAGE(PageLRU(page) || PageUnevictable(page)) [ 24.726949] page->mem_cgroup:bd008c00 [ 24.730693] ------------[ cut here ]------------ [ 24.735304] kernel BUG at mm/vmscan.c:1350! [ 24.739478] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM Solved the issue by below patch. diff --git a/mm/vmscan.c b/mm/vmscan.c index be56e2e..12ac353 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -998,7 +998,7 @@ static unsigned long shrink_page_list(struct list_head *page_list, sc->nr_scanned++; if (unlikely(!page_evictable(page))) - goto activate_locked; + goto cull_mlocked; if (!sc->may_unmap && page_mapped(page)) goto keep_locked; @@ -1331,7 +1331,12 @@ static unsigned long shrink_page_list(struct list_head *page_list, } else list_add(&page->lru, &free_pages); continue; - +cull_mlocked: + if (PageSwapCache(page)) + try_to_free_swap(page); + unlock_page(page); + list_add(&page->lru, &ret_pages); + continue; activate_locked: /* Not a candidate for swapping, so reclaim swap space. */ if (PageSwapCache(page) && (mem_cgroup_swap_full(page) || Regards, Pankaj ************************************************************************************************************************************************************* eInfochips Business Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated. Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. *************************************************************************************************************************************************************

1 0

Using binary attributes for configuration sysfs entries
by Jay Aurabind March 14, 2019

March 14, 2019

Hi, Before I send this patch to actual mailing list, I'd appreciate if someone could tell me if this is a bad idea! The driver in staging for pi433 (a wireless transceiver) uses IOCTLs at the moment. I wish to add a sysfs interface to it that control the various transmission and reception parameters. In the ioctl interface, it uses two structs that have about 40 parameters in total. For the corresponding sysfs interface, since there are a lot of parameters, would it be justified to use the same binary format though sysfs_create_binary_file() ? The rationale is that it would be easier to simply pack all the config options in the struct and send it in once rather than individually write 40 files. This is what the attached patch follows. Interface is added only for reception parameters as of now. Any others suggestions welcome! -- Thanks and Regards, Jay

3 6

Re: [PATCH 1/1] staging: erofs: Add function comment for erofs/super.c
by valdis.kletnieks＠vt.edu March 13, 2019

March 13, 2019

On Wed, 13 Mar 2019 08:48:26 +0800, Gao Xiang said: (Reversing order of comments) > "Release slab Memory" is not a very useful description for this function. Agreed. > i_callback is used to free inode structure and other memory related to this inode However, that's not a bad description at all. :) (Though I'd consider renaming the function to 'reap_inode_mem()' or something like that so no description is needed. :)

2 1

[PATCH 1/1] staging: erofs: Add function comment for erofs/super.c
by arshad hussain March 13, 2019

March 13, 2019

Re-sending. Previous patch I put in very old kernel-newbies address. Subject: [PATCH 1/1] staging: erofs: Add function comment for erofs/super.c This patch adds functions comment for file erofs/super.c in sphinx format. Signed-off-by: Arshad Hussain <arshad.super(a)gmail.com> --- drivers/staging/erofs/super.c | 133 +++++++++++++++++++++++++++++++++++++++++- 1 file changed, 130 insertions(+), 3 deletions(-) diff --git a/drivers/staging/erofs/super.c b/drivers/staging/erofs/super.c index 15c784fba879..6d2b93d94839 100644 --- a/drivers/staging/erofs/super.c +++ b/drivers/staging/erofs/super.c @@ -30,6 +30,11 @@ static void init_once(void *ptr) inode_init_once(&vi->vfs_inode); } +/* + * erofs_init_inode_cache(): Create & initialize inode cache + * + * Returns: 0 on Success. Errno Otherwise. + */ static int __init erofs_init_inode_cache(void) { erofs_inode_cachep = kmem_cache_create("erofs_inode", @@ -39,11 +44,21 @@ static int __init erofs_init_inode_cache(void) return erofs_inode_cachep != NULL ? 0 : -ENOMEM; } +/* + * erofs_exit_inode_cache(): Destroy inode cache + */ static void erofs_exit_inode_cache(void) { kmem_cache_destroy(erofs_inode_cachep); } +/* + * alloc_inode(): Allocate and initialize inode + * + * @sb: VFS superblock structure + * + * Returns: Pointer to inode structure + */ static struct inode *alloc_inode(struct super_block *sb) { struct erofs_vnode *vi = @@ -57,6 +72,11 @@ static struct inode *alloc_inode(struct super_block *sb) return &vi->vfs_inode; } +/* + * i_callback(): Release slab Memory + * + * @head: RCU callback structure + */ static void i_callback(struct rcu_head *head) { struct inode *inode = container_of(head, struct inode, i_rcu); @@ -71,11 +91,23 @@ static void i_callback(struct rcu_head *head) kmem_cache_free(erofs_inode_cachep, vi); } +/* + * destroy_inode(): Release Inode Resources allocated by alloc_inode() + * + * @inode: VFS Inode structure + */ static void destroy_inode(struct inode *inode) { call_rcu(&inode->i_rcu, i_callback); } +/* + * superblock_read(): Read superblock into buffer + * + * @sb: VFS Superblock structure + * + * Returns: 0 on Success. Errno otherwise + */ static int superblock_read(struct super_block *sb) { struct erofs_sb_info *sbi; @@ -230,6 +262,14 @@ static match_table_t erofs_tokens = { {Opt_err, NULL} }; +/* + * parse_options(): Parse and set additional mount option for erofs + * + * @sb: VFS superblock structure + * @options: Mount options + * + * Returns: 0 on Success. Errno otherwise + */ static int parse_options(struct super_block *sb, char *options) { substring_t args[MAX_OPT_ARGS]; @@ -351,6 +391,22 @@ static struct inode *erofs_init_managed_cache(struct super_block *sb) #endif +/* + * erofs_read_super(): Helper function to erofs_fill_super() + * + * @sb: VFS superblock structure + * @dev_name: Name of device where erofs is mounted + * @data: Additional mount options + * @silent: if TRUE print message on error. + * Silent/quite otherwise + * + * Helper function to actual callback function erofs_fill_super + * This function sets the blocksize. Reads the superblock into + * buffer. Parses and sets mount options. Populates root inode + * and creates root directory. + * + * Returns: 0 on Success. Errno otherwise + */ static int erofs_read_super(struct super_block *sb, const char *dev_name, void *data, int silent) { @@ -473,7 +529,11 @@ static int erofs_read_super(struct super_block *sb, } /* - * could be triggered after deactivate_locked_super() + * erofs_put_super(): Free superblock structure + * + * @sb: VFS superblock structure + * + * Could be triggered after deactivate_locked_super() * is called, thus including umount and failed to initialize. */ static void erofs_put_super(struct super_block *sb) @@ -513,7 +573,20 @@ struct erofs_mount_private { char *options; }; -/* support mount_bdev() with options */ +/* + * erofs_fill_super(): Fill erofs superblock + * + * @sb: VFS superblock structure + * @_priv: Additional Mount options + * @silent: if TRUE print message on error. + * Silent/quite otherwise + * + * This function fills erofs superblock information into + * the VFS superblock stucture. Additionally it supports + * mount_bdev() with options + * + * Returns: 0 on Success + */ static int erofs_fill_super(struct super_block *sb, void *_priv, int silent) { @@ -523,6 +596,17 @@ static int erofs_fill_super(struct super_block *sb, priv->options, silent); } +/* + * erofs_mount(): Function called when erofs is mounted + * + * @fs_type: Describes the erofs filesystem + * @flags: Mount flags/options + * @dev_name: Name of device where erofs is mounted + * @data: Mount options + * + * Returns: Pointer to VFS dentry structure. + * The root dentry. + */ static struct dentry *erofs_mount( struct file_system_type *fs_type, int flags, const char *dev_name, void *data) @@ -532,10 +616,21 @@ static struct dentry *erofs_mount( .options = data }; + /* + * Mount filesystem residing on a block device + * provide a callback (erofs_fill_super) to + * populate superblock + */ return mount_bdev(fs_type, flags, dev_name, &priv, erofs_fill_super); } +/* + * erofs_kill_sb(): Called when erofs is getting shutdown/killed + * + * @sb: VFS superblock structure + * + */ static void erofs_kill_sb(struct super_block *sb) { kill_block_super(sb); @@ -550,6 +645,11 @@ static struct file_system_type erofs_fs_type = { }; MODULE_ALIAS_FS("erofs"); +/* + * erofs_module_init(): Called when module is loaded + * + * returns: 0 on Success. Error Otherwise + */ static int __init erofs_module_init(void) { int err; @@ -586,6 +686,9 @@ static int __init erofs_module_init(void) return err; } +/* + * erofs_module_exit(): Called when module is un-loaded + */ static void __exit erofs_module_exit(void) { unregister_filesystem(&erofs_fs_type); @@ -595,7 +698,14 @@ static void __exit erofs_module_exit(void) infoln("successfully finalize erofs"); } -/* get filesystem statistics */ +/* + * erofs_statfs(): Get erofs statistics + * + * @dentry: Directory from where stats is collected + * @buf: Buffer where stats info is stored + * + * Returns: 0 on Success + */ static int erofs_statfs(struct dentry *dentry, struct kstatfs *buf) { struct super_block *sb = dentry->d_sb; @@ -617,6 +727,14 @@ static int erofs_statfs(struct dentry *dentry, struct kstatfs *buf) return 0; } +/* + * erofs_show_options(): + * + * @dentry: + * @buf: + * + * Returns: 0 on Success + */ static int erofs_show_options(struct seq_file *seq, struct dentry *root) { struct erofs_sb_info *sbi __maybe_unused = EROFS_SB(root->d_sb); @@ -639,6 +757,15 @@ static int erofs_show_options(struct seq_file *seq, struct dentry *root) return 0; } +/* + * erofs_remount(): Called when erofs is remounted + * + * @sb: VFS superblock structure + * @flags: Mount flags/options + * @data: Mount options + * + * Returns: 0 on Success. Errno otherwise + */ static int erofs_remount(struct super_block *sb, int *flags, char *data) { struct erofs_sb_info *sbi = EROFS_SB(sb); -- 2.14.3

4 3