Re: crash by cdc_acm driver in kernels 4.8-rc1/5

On Wed, Sep 28, 2016 at 05:23:30PM +0200, Oliver Neukum wrote: > > > > HP src # sync > > HP src # [ 3744.914184] BUG: unable to handle kernel NULL pointer > > dereference at 0249 > > The last view lines before that please with the debugging level ramped > up to 9 please. Recompiled again,

Re: crash by cdc_acm driver in kernels 4.8-rc1/5

On Wed, Sep 28, 2016 at 05:23:30PM +0200, Oliver Neukum wrote: > > > > HP src # sync > > HP src # [ 3744.914184] BUG: unable to handle kernel NULL pointer > > dereference at 0249 > > The last view lines before that please with the debugging level ramped > up to 9 please. Recompiled again,

Re: [RFC][PATCH 0/7] printk: use alt_printk to handle printk() recursive calls

On Tue 2016-09-27 23:22:30, Sergey Senozhatsky wrote: > Hello, > > RFC > > This patch set extends a lock-less NMI per-cpu buffers idea to > handle recursive printk() calls. The basic mechanism is pretty much the > same -- at the beginning of a deadlock-prone section we switch

Re: [RFC][PATCH 0/7] printk: use alt_printk to handle printk() recursive calls

On Tue 2016-09-27 23:22:30, Sergey Senozhatsky wrote: > Hello, > > RFC > > This patch set extends a lock-less NMI per-cpu buffers idea to > handle recursive printk() calls. The basic mechanism is pretty much the > same -- at the beginning of a deadlock-prone section we switch

Re: [PATCH] Add ability to override kernel release check

On 09/29/2016 04:14 PM, Nikolay Borisov wrote: > From: Nikolay Borisov > > In some situation it might be useful to disable checking the > kernel release. This happens when a kernel module is being rebuilt > and then probed. Without this override one has to reboot the

Re: [PATCH] Add ability to override kernel release check

On 09/29/2016 04:14 PM, Nikolay Borisov wrote: > From: Nikolay Borisov > > In some situation it might be useful to disable checking the > kernel release. This happens when a kernel module is being rebuilt > and then probed. Without this override one has to reboot the machine > with the new

Re: [PATCH] s390x/spinlock: Provide vcpu_is_preempted globally

On 09/29/2016 03:11 PM, Martin Schwidefsky wrote: > On Thu, 29 Sep 2016 13:54:16 +0200 > Christian Borntraeger wrote: > >> this implements the s390 backend for commit >> "kernel/sched: introduce vcpu preempted check interface" >> by simply reusing the existing

Re: [PATCH] s390x/spinlock: Provide vcpu_is_preempted globally

On 09/29/2016 03:11 PM, Martin Schwidefsky wrote: > On Thu, 29 Sep 2016 13:54:16 +0200 > Christian Borntraeger wrote: > >> this implements the s390 backend for commit >> "kernel/sched: introduce vcpu preempted check interface" >> by simply reusing the existing cpu_is_preempted function. >> >>

Re: [PATCH] s390x/spinlock: Provide vcpu_is_preempted globally

On Thu, 29 Sep 2016 13:54:16 +0200 Christian Borntraeger wrote: > this implements the s390 backend for commit > "kernel/sched: introduce vcpu preempted check interface" > by simply reusing the existing cpu_is_preempted function. > > Signed-off-by: Christian Borntraeger

Re: [PATCH] s390x/spinlock: Provide vcpu_is_preempted globally

On Thu, 29 Sep 2016 13:54:16 +0200 Christian Borntraeger wrote: > this implements the s390 backend for commit > "kernel/sched: introduce vcpu preempted check interface" > by simply reusing the existing cpu_is_preempted function. > > Signed-off-by: Christian Borntraeger > --- > Martin, Heiko, >

[RFC PATCH] ipc/sem.c: Add cond_resched in exit_sme

In CONFIG_PREEMPT=n kernel a softlockup was observed while the for loop in exit_sem. Apparently it's possible for the loop to take quite a long time and it doesn't have a scheduling point in it. Since the codes is executing under an rcu read section this may also cause rcu stalls, which in turn

[RFC PATCH] ipc/sem.c: Add cond_resched in exit_sme

In CONFIG_PREEMPT=n kernel a softlockup was observed while the for loop in exit_sem. Apparently it's possible for the loop to take quite a long time and it doesn't have a scheduling point in it. Since the codes is executing under an rcu read section this may also cause rcu stalls, which in turn

[PATCH] Add ability to override kernel release check

From: Nikolay Borisov In some situation it might be useful to disable checking the kernel release. This happens when a kernel module is being rebuilt and then probed. Without this override one has to reboot the machine with the new kernel (and module) and then use

[PATCH] Add ability to override kernel release check

From: Nikolay Borisov In some situation it might be useful to disable checking the kernel release. This happens when a kernel module is being rebuilt and then probed. Without this override one has to reboot the machine with the new kernel (and module) and then use systemtap. To rectify the

[PATCH] dmaengine: pxa_dma: remove unused function

We get 1 warning when building kernel with W=1: drivers/dma/pxa_dma.c:1525:5: warning: no previous prototype for 'pxad_toggle_reserved_channel' [-Wmissing-prototypes] In fact, this function is called by no one, so this patch removes it. Signed-off-by: Baoyou Xie ---

Re: 4.7 regression: ACPI: No IRQ available for PCI Interrupt Link [LNKD]. Try pci=noacpi or acpi=off

On 2016-09-29 05:10, Ondrej Zary wrote: On Thursday 29 September 2016, Sinan Kaya wrote: On 9/28/2016 3:23 PM, Ondrej Zary wrote: > On Wednesday 28 September 2016 20:22:40 Sinan Kaya wrote: >> On 9/28/2016 1:02 PM, Ondrej Zary wrote: Thanks, It sounds like you have more than one machine

[PATCH] dmaengine: pxa_dma: remove unused function

We get 1 warning when building kernel with W=1: drivers/dma/pxa_dma.c:1525:5: warning: no previous prototype for 'pxad_toggle_reserved_channel' [-Wmissing-prototypes] In fact, this function is called by no one, so this patch removes it. Signed-off-by: Baoyou Xie --- drivers/dma/pxa_dma.c | 9

Re: 4.7 regression: ACPI: No IRQ available for PCI Interrupt Link [LNKD]. Try pci=noacpi or acpi=off

On 2016-09-29 05:10, Ondrej Zary wrote: On Thursday 29 September 2016, Sinan Kaya wrote: On 9/28/2016 3:23 PM, Ondrej Zary wrote: > On Wednesday 28 September 2016 20:22:40 Sinan Kaya wrote: >> On 9/28/2016 1:02 PM, Ondrej Zary wrote: Thanks, It sounds like you have more than one machine

Re: [PATCH v2] drm: tilcdc: add a workaround for failed clk_set_rate()

2016-09-29 9:55 GMT+02:00 Jyri Sarha : > On 09/28/16 15:41, Bartosz Golaszewski wrote: >> Some architectures don't use the common clock framework and don't >> implement all the clk interfaces for every clock. This is the case >> for da850-lcdk where clk_set_rate() only works for

Re: [PATCH v2] drm: tilcdc: add a workaround for failed clk_set_rate()

2016-09-29 9:55 GMT+02:00 Jyri Sarha : > On 09/28/16 15:41, Bartosz Golaszewski wrote: >> Some architectures don't use the common clock framework and don't >> implement all the clk interfaces for every clock. This is the case >> for da850-lcdk where clk_set_rate() only works for PLL0 and PLL1. >>

[BUG] block: bdi_register_owner() failure cause NULL pointer dereference

Hi, Folks We observed the hard lockup while trying raid assemble with sas3ircu, it was start with the failure inside bdi_register_owner() with duplicated kobj path, and later comeup the NULL pointer dereference, after that system hang and we saw hard lockup on screen. The duplicated issue could

[BUG] block: bdi_register_owner() failure cause NULL pointer dereference

Hi, Folks We observed the hard lockup while trying raid assemble with sas3ircu, it was start with the failure inside bdi_register_owner() with duplicated kobj path, and later comeup the NULL pointer dereference, after that system hang and we saw hard lockup on screen. The duplicated issue could

Re: [PATCH 0/4] Add DMA support for ti_am335x_adc driver

On Sunday 25 September 2016 03:11 PM, Jonathan Cameron wrote: > On 21/09/16 17:11, Mugunthan V N wrote: >> > The ADC has a 64 work depth fifo length which holds the ADC data >> > till the CPU reads. So when a user program needs a large ADC data >> > to operate on, then it has to do multiple reads

Re: [PATCH 0/4] Add DMA support for ti_am335x_adc driver

On Sunday 25 September 2016 03:11 PM, Jonathan Cameron wrote: > On 21/09/16 17:11, Mugunthan V N wrote: >> > The ADC has a 64 work depth fifo length which holds the ADC data >> > till the CPU reads. So when a user program needs a large ADC data >> > to operate on, then it has to do multiple reads

Re: dm snapshot: Use kmalloc_array() in init_origin_hash()

On Thu, Sep 29, 2016 at 01:45:41PM +0200, SF Markus Elfring wrote: > > We have no hope of fixing Markus' homegrown coccinelle script. > > I have got an other impression. I see further possibilities > to clarify involved communication and software development challenges > for a few source code

Re: dm snapshot: Use kmalloc_array() in init_origin_hash()

On Thu, Sep 29, 2016 at 01:45:41PM +0200, SF Markus Elfring wrote: > > We have no hope of fixing Markus' homegrown coccinelle script. > > I have got an other impression. I see further possibilities > to clarify involved communication and software development challenges > for a few source code

Re: [RFC][PATCH 6/7] printk: use alternative printk buffers

On Tue 2016-09-27 23:22:36, Sergey Senozhatsky wrote: > Use alt_printk buffer in in printk recursion-prone blocks: > -- around logbuf_lock protected sections in vprintk_emit() and >console_unlock() > -- around down_trylock_console_sem() and up_console_sem() > > Note that it addresses

Re: [RFC][PATCH 6/7] printk: use alternative printk buffers

On Tue 2016-09-27 23:22:36, Sergey Senozhatsky wrote: > Use alt_printk buffer in in printk recursion-prone blocks: > -- around logbuf_lock protected sections in vprintk_emit() and >console_unlock() > -- around down_trylock_console_sem() and up_console_sem() > > Note that it addresses

Re: Race condition between iget_locked() and evict_inodes()

Hi Al, > On 29 Sep 2016, at 13:17, Al Viro wrote: > > On Thu, Sep 29, 2016 at 11:53:21AM +, Anton Altaparmakov wrote: >> Thus if the events happen in this order: >> >> evict_inodes() iget_locked() in >> find_inode_fast() > > ... you

Re: [dm-devel] [PATCH 03/10] md/dm-crypt: Rename a jump label in crypt_message()

On Wed, Sep 28, 2016 at 05:40:14PM +0200, SF Markus Elfring wrote: > From: Markus Elfring > Date: Wed, 28 Sep 2016 14:54:39 +0200 > > Adjust a jump label according to the current Linux coding style convention. In what bizzaro world is the "current Linux coding

Re: [dm-devel] [PATCH 05/10] md/dm-crypt: Rename a jump label in crypt_set_key()

On Wed, Sep 28, 2016 at 05:42:28PM +0200, SF Markus Elfring wrote: > From: Markus Elfring > Date: Wed, 28 Sep 2016 15:21:18 +0200 > > Adjust jump labels according to the current Linux coding style convention. > > - > -out: > +set_memory: > /* Hex key string

Re: Race condition between iget_locked() and evict_inodes()

Hi Al, > On 29 Sep 2016, at 13:17, Al Viro wrote: > > On Thu, Sep 29, 2016 at 11:53:21AM +, Anton Altaparmakov wrote: >> Thus if the events happen in this order: >> >> evict_inodes() iget_locked() in >> find_inode_fast() > > ... you are buggered, because

Re: [dm-devel] [PATCH 03/10] md/dm-crypt: Rename a jump label in crypt_message()

On Wed, Sep 28, 2016 at 05:40:14PM +0200, SF Markus Elfring wrote: > From: Markus Elfring > Date: Wed, 28 Sep 2016 14:54:39 +0200 > > Adjust a jump label according to the current Linux coding style convention. In what bizzaro world is the "current Linux coding style convention" > - > -error: >

Re: [dm-devel] [PATCH 05/10] md/dm-crypt: Rename a jump label in crypt_set_key()

On Wed, Sep 28, 2016 at 05:42:28PM +0200, SF Markus Elfring wrote: > From: Markus Elfring > Date: Wed, 28 Sep 2016 15:21:18 +0200 > > Adjust jump labels according to the current Linux coding style convention. > > - > -out: > +set_memory: > /* Hex key string not needed after here, so wipe

Re: [PATCH v4 3/3] mm/hugetlb: improve locking in dissolve_free_huge_pages()

On Mon 26-09-16 19:28:11, Gerald Schaefer wrote: > For every pfn aligned to minimum_order, dissolve_free_huge_pages() will > call dissolve_free_huge_page() which takes the hugetlb spinlock, even if > the page is not huge at all or a hugepage that is in-use. > > Improve this by doing the

Re: [PATCH v4 3/3] mm/hugetlb: improve locking in dissolve_free_huge_pages()

On Mon 26-09-16 19:28:11, Gerald Schaefer wrote: > For every pfn aligned to minimum_order, dissolve_free_huge_pages() will > call dissolve_free_huge_page() which takes the hugetlb spinlock, even if > the page is not huge at all or a hugepage that is in-use. > > Improve this by doing the

Re: [PATCH v4 2/3] mm/hugetlb: check for reserved hugepages during memory offline

On Mon 26-09-16 19:28:10, Gerald Schaefer wrote: > In dissolve_free_huge_pages(), free hugepages will be dissolved without > making sure that there are enough of them left to satisfy hugepage > reservations. otherwise a poor process with a reservation might get unexpected SIGBUS, right? > Fix

Re: [PATCH v4 2/3] mm/hugetlb: check for reserved hugepages during memory offline

On Mon 26-09-16 19:28:10, Gerald Schaefer wrote: > In dissolve_free_huge_pages(), free hugepages will be dissolved without > making sure that there are enough of them left to satisfy hugepage > reservations. otherwise a poor process with a reservation might get unexpected SIGBUS, right? > Fix

Observed a ecryptFS crash

Hi Tyhicks, We observed a ecryptFS crash occasionally in Linux kernel 4.1.18. The call trace is attached below. Is it a known issue？ Look forward to hearing from you. Thanks in advance! [19314.529479s][pid:2694,cpu3,GAC_Executor[0]]Call trace: [19314.529510s][pid:2694,cpu3,GAC_Executor[0]][]

Observed a ecryptFS crash

Hi Tyhicks, We observed a ecryptFS crash occasionally in Linux kernel 4.1.18. The call trace is attached below. Is it a known issue？ Look forward to hearing from you. Thanks in advance! [19314.529479s][pid:2694,cpu3,GAC_Executor[0]]Call trace: [19314.529510s][pid:2694,cpu3,GAC_Executor[0]][]

Re: [PATCH] pci: remove error message when device not present

On Thursday, September 29, 2016 12:28:43 PM Grant Likely wrote: > It's not an error if the IBM ACPI pseudo-device isn't present, it merely > means the kernel isn't running on that IBM hardware. Get rid of the > error report so as not to pollute the kernel log with an message > irrelevant to the

Re: [PATCH] pci: remove error message when device not present

On Thursday, September 29, 2016 12:28:43 PM Grant Likely wrote: > It's not an error if the IBM ACPI pseudo-device isn't present, it merely > means the kernel isn't running on that IBM hardware. Get rid of the > error report so as not to pollute the kernel log with an message > irrelevant to the

Re: [PATCH 4/5] ACPI / property: Allow holes in reference properties

On Thursday, September 29, 2016 02:56:57 PM Mika Westerberg wrote: > On Thu, Sep 29, 2016 at 01:53:50PM +0200, Rafael J. Wysocki wrote: > > On Thursday, September 29, 2016 09:48:29 AM Mika Westerberg wrote: > > > On Wed, Sep 28, 2016 at 11:36:10PM +0200, Rafael J. Wysocki wrote: > > > > On Fri,

Re: [PATCH 4/5] ACPI / property: Allow holes in reference properties

On Thursday, September 29, 2016 02:56:57 PM Mika Westerberg wrote: > On Thu, Sep 29, 2016 at 01:53:50PM +0200, Rafael J. Wysocki wrote: > > On Thursday, September 29, 2016 09:48:29 AM Mika Westerberg wrote: > > > On Wed, Sep 28, 2016 at 11:36:10PM +0200, Rafael J. Wysocki wrote: > > > > On Fri,

Re: [RFC][PATCH 3/7] printk: introduce per-cpu alt_print seq buffer

On Tue 2016-09-27 23:22:33, Sergey Senozhatsky wrote: > This patch extends the idea of NMI per-cpu buffers to regions > that may cause recursive printk() calls and possible deadlocks. > Namely, printk() can't handle printk calls from schedule code > or printk() calls from lock debugging code

Re: [RFC][PATCH 3/7] printk: introduce per-cpu alt_print seq buffer

On Tue 2016-09-27 23:22:33, Sergey Senozhatsky wrote: > This patch extends the idea of NMI per-cpu buffers to regions > that may cause recursive printk() calls and possible deadlocks. > Namely, printk() can't handle printk calls from schedule code > or printk() calls from lock debugging code

Re: [LINUX PATCH] usb: gadget: Configure bulk maxburst through module parameter in gadget zero.

Hi, Greg KH writes: > On Thu, Sep 29, 2016 at 02:16:44PM +0530, Manish Narani wrote: >> This patch adds support to configure bulk maxburst through >> module parameter. This parameter can be used to modify bulk >> maxburst in case if one wants to measure peak

Re: [LINUX PATCH] usb: gadget: Configure bulk maxburst through module parameter in gadget zero.

Hi, Greg KH writes: > On Thu, Sep 29, 2016 at 02:16:44PM +0530, Manish Narani wrote: >> This patch adds support to configure bulk maxburst through >> module parameter. This parameter can be used to modify bulk >> maxburst in case if one wants to measure peak Bulk/Isoc-IN/OUT >> performance. > >

Re: [PATCH net v2] L2TP:Adjust intf MTU,factor underlay L3,overlay L2

On Wed, 28 Sep 2016 19:36:45 -0700 (PDT), R. Parameswaran wrote: > I'd like to point out one difference with VXLAN - in VXLAN, the > local physical interface is directly specified at the time of > creation of the tunnel, and the data structure seems to have the ifindex > of the local interface

Re: [PATCH net v2] L2TP:Adjust intf MTU,factor underlay L3,overlay L2

On Wed, 28 Sep 2016 19:36:45 -0700 (PDT), R. Parameswaran wrote: > I'd like to point out one difference with VXLAN - in VXLAN, the > local physical interface is directly specified at the time of > creation of the tunnel, and the data structure seems to have the ifindex > of the local interface

Re: [PATCH v4 0/5] Functional dependencies between devices

On Thursday, September 29, 2016 08:58:43 AM Marek Szyprowski wrote: > Hi Rafael, > > On 2016-09-29 02:24, Rafael J. Wysocki wrote: > > Hi Everyone, > > > > On Thursday, September 08, 2016 11:25:44 PM Rafael J. Wysocki wrote: > >>> Hi Everyone, > >>> > >>> This is a refresh of the functional

Re: [PATCH v4 0/5] Functional dependencies between devices

On Thursday, September 29, 2016 08:58:43 AM Marek Szyprowski wrote: > Hi Rafael, > > On 2016-09-29 02:24, Rafael J. Wysocki wrote: > > Hi Everyone, > > > > On Thursday, September 08, 2016 11:25:44 PM Rafael J. Wysocki wrote: > >>> Hi Everyone, > >>> > >>> This is a refresh of the functional

Re: [PATCH 0/5] ACPI / gpio: Updates to properties

On Thursday, September 29, 2016 10:00:15 AM Mika Westerberg wrote: > On Wed, Sep 28, 2016 at 11:32:46PM +0200, Rafael J. Wysocki wrote: > > Hi, > > > > On Fri, Sep 23, 2016 at 4:57 PM, Mika Westerberg > > wrote: > > > Hi, > > > > > > This series brings couple of

Re: [PATCH 0/5] ACPI / gpio: Updates to properties

On Thursday, September 29, 2016 10:00:15 AM Mika Westerberg wrote: > On Wed, Sep 28, 2016 at 11:32:46PM +0200, Rafael J. Wysocki wrote: > > Hi, > > > > On Fri, Sep 23, 2016 at 4:57 PM, Mika Westerberg > > wrote: > > > Hi, > > > > > > This series brings couple of useful GPIO related properties

Re: linux-next: build failure after merge of the tip tree

On Thursday, September 29, 2016 01:20:07 PM Stephen Rothwell wrote: > Hi all, > > After merging the tip tree, today's linux-next build (x86_64 allmodconfig) > failed like this: > > arch/x86/power/hibernate_64.c: In function 'hibernation_e820_save': > arch/x86/power/hibernate_64.c:236:15: error:

Re: linux-next: build failure after merge of the tip tree

On Thursday, September 29, 2016 01:20:07 PM Stephen Rothwell wrote: > Hi all, > > After merging the tip tree, today's linux-next build (x86_64 allmodconfig) > failed like this: > > arch/x86/power/hibernate_64.c: In function 'hibernation_e820_save': > arch/x86/power/hibernate_64.c:236:15: error:

Re: Race condition between iget_locked() and evict_inodes()

On Thu, Sep 29, 2016 at 11:53:21AM +, Anton Altaparmakov wrote: > Thus if the events happen in this order: > > evict_inodes()iget_locked() in > find_inode_fast() ... you are buggered, because somebody is trying to grab a reference to inode on a filesystem

Re: Race condition between iget_locked() and evict_inodes()

On Thu, Sep 29, 2016 at 11:53:21AM +, Anton Altaparmakov wrote: > Thus if the events happen in this order: > > evict_inodes()iget_locked() in > find_inode_fast() ... you are buggered, because somebody is trying to grab a reference to inode on a filesystem

Re: [PATCH] pinctrl: freescale: avoid overwriting pin config when freeing GPIO

On 09/29/2016 09:46 AM, Viresh Kumar wrote: On 28-09-16, 15:07, Vladimir Zapolskiy wrote: I would expect that the change below improves the situation, but I didn't perform any tests and here the core change is governed by the accepted i.MX i2c bus driver specific changes, thus conceptually it

Re: [PATCH] pinctrl: freescale: avoid overwriting pin config when freeing GPIO

On 09/29/2016 09:46 AM, Viresh Kumar wrote: On 28-09-16, 15:07, Vladimir Zapolskiy wrote: I would expect that the change below improves the situation, but I didn't perform any tests and here the core change is governed by the accepted i.MX i2c bus driver specific changes, thus conceptually it

Re: Regression in 4.8 - CPU speed set very low

On Wednesday, September 28, 2016 09:22:59 PM Larry Finger wrote: > On 09/27/2016 06:46 AM, Rafael J. Wysocki wrote: > > On Tue, Sep 27, 2016 at 10:48 AM, Larry Finger > > wrote: > >> On 09/26/2016 10:12 PM, Doug Smythies wrote: > >>> > >>> On 2016.09.26 18:31 Srinivas

Re: Regression in 4.8 - CPU speed set very low

On Wednesday, September 28, 2016 09:22:59 PM Larry Finger wrote: > On 09/27/2016 06:46 AM, Rafael J. Wysocki wrote: > > On Tue, Sep 27, 2016 at 10:48 AM, Larry Finger > > wrote: > >> On 09/26/2016 10:12 PM, Doug Smythies wrote: > >>> > >>> On 2016.09.26 18:31 Srinivas Pandruvada wrote: > >

Re: [PATCH v4 1/3] mm/hugetlb: fix memory offline with hugepage size > memory block size

On Mon 26-09-16 19:28:09, Gerald Schaefer wrote: > dissolve_free_huge_pages() will either run into the VM_BUG_ON() or a > list corruption and addressing exception when trying to set a memory > block offline that is part (but not the first part) of a "gigantic" > hugetlb page with a size > memory

Re: [PATCH v4 1/3] mm/hugetlb: fix memory offline with hugepage size > memory block size

On Mon 26-09-16 19:28:09, Gerald Schaefer wrote: > dissolve_free_huge_pages() will either run into the VM_BUG_ON() or a > list corruption and addressing exception when trying to set a memory > block offline that is part (but not the first part) of a "gigantic" > hugetlb page with a size > memory

[PATCH] af_unix: fix garbage collect vs. MSG_PEEK

Gc assumes that in-flight sockets that don't have an external ref can't gain one while unix_gc_lock is held. That is true because unix_notinflight() will be called before detaching fds, which takes unix_gc_lock. Only MSG_PEEK was somehow overlooked. That one also clones the fds, also keeping

[PATCH] af_unix: fix garbage collect vs. MSG_PEEK

Gc assumes that in-flight sockets that don't have an external ref can't gain one while unix_gc_lock is held. That is true because unix_notinflight() will be called before detaching fds, which takes unix_gc_lock. Only MSG_PEEK was somehow overlooked. That one also clones the fds, also keeping

[PATCH] staging: fbtft: fix NULL comparison checkpatch warning

Fixed the following checkpatch warnings (task #10 of eudyptula challenge): - NULL comparison rewritten to use '!' operator Signed-off-by: Carlos Palminha --- drivers/staging/fbtft/fbtft_device.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[PATCH] staging: fbtft: fix NULL comparison checkpatch warning

Fixed the following checkpatch warnings (task #10 of eudyptula challenge): - NULL comparison rewritten to use '!' operator Signed-off-by: Carlos Palminha --- drivers/staging/fbtft/fbtft_device.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

Re: [PATCH 1/2] f2fs: use crc and cp version to determine roll-forward recovery

On 2016/9/20 10:55, Jaegeuk Kim wrote: > Previously, we used cp_version only to detect recoverable dnodes. > In order to avoid same garbage cp_version, we needed to truncate the next > dnode during checkpoint, resulting in additional discard or data write. > If we can distinguish this by using crc

Re: [PATCH 1/2] f2fs: use crc and cp version to determine roll-forward recovery

On 2016/9/20 10:55, Jaegeuk Kim wrote: > Previously, we used cp_version only to detect recoverable dnodes. > In order to avoid same garbage cp_version, we needed to truncate the next > dnode during checkpoint, resulting in additional discard or data write. > If we can distinguish this by using crc

Race condition between iget_locked() and evict_inodes()

Hi Al, I think there is a race condition between iget_locked() and evict_inodes(). evict_inodes() checks i_count and if zero proceeds to take i_lock then set I_FREEING and eventually disposes of the inode. But a concurrent iget_locked() takes i_lock and then increments i_count. Thus if the

Race condition between iget_locked() and evict_inodes()

Hi Al, I think there is a race condition between iget_locked() and evict_inodes(). evict_inodes() checks i_count and if zero proceeds to take i_lock then set I_FREEING and eventually disposes of the inode. But a concurrent iget_locked() takes i_lock and then increments i_count. Thus if the

Re: [PATCH v2 0/8] pipe: fix limit handling

On 08/29/2016 02:20 AM, Michael Kerrisk (man-pages) wrote: When changing a pipe's capacity with fcntl(F_SETPIPE_SZ), various limits defined by /proc/sys/fs/pipe-* files are checked to see if unprivileged users are exceeding limits on memory consumption. While documenting and testing the

Re: [PATCH v2 0/8] pipe: fix limit handling

On 08/29/2016 02:20 AM, Michael Kerrisk (man-pages) wrote: When changing a pipe's capacity with fcntl(F_SETPIPE_SZ), various limits defined by /proc/sys/fs/pipe-* files are checked to see if unprivileged users are exceeding limits on memory consumption. While documenting and testing the

Re: [PATCH 4/5] ACPI / property: Allow holes in reference properties

On Thu, Sep 29, 2016 at 01:53:50PM +0200, Rafael J. Wysocki wrote: > On Thursday, September 29, 2016 09:48:29 AM Mika Westerberg wrote: > > On Wed, Sep 28, 2016 at 11:36:10PM +0200, Rafael J. Wysocki wrote: > > > On Fri, Sep 23, 2016 at 4:57 PM, Mika Westerberg > > >

Re: [PATCH 4/5] ACPI / property: Allow holes in reference properties

On Thu, Sep 29, 2016 at 01:53:50PM +0200, Rafael J. Wysocki wrote: > On Thursday, September 29, 2016 09:48:29 AM Mika Westerberg wrote: > > On Wed, Sep 28, 2016 at 11:36:10PM +0200, Rafael J. Wysocki wrote: > > > On Fri, Sep 23, 2016 at 4:57 PM, Mika Westerberg > > > wrote: > > > > DT allows

[PATCH] s390x/spinlock: Provide vcpu_is_preempted globally

this implements the s390 backend for commit "kernel/sched: introduce vcpu preempted check interface" by simply reusing the existing cpu_is_preempted function. Signed-off-by: Christian Borntraeger --- Martin, Heiko, this patch is a minimal change by not touching all

[PATCH] s390x/spinlock: Provide vcpu_is_preempted globally

this implements the s390 backend for commit "kernel/sched: introduce vcpu preempted check interface" by simply reusing the existing cpu_is_preempted function. Signed-off-by: Christian Borntraeger --- Martin, Heiko, this patch is a minimal change by not touching all existing users of

Re: [PATCH 2/3] x86/boot: Fix another __read_cr4() case on 486

On Wed, Sep 28, 2016 at 12:34:15PM -0700, Andy Lutomirski wrote: > The condition for reading CR4 was wrong: there are some CPUs with > CPUID but not CR4. Rather than trying to make the condition exact, > using __read_cr4_safe(). > > Reported-by: da...@saggiorato.net > Fixes: 18bc7bd523e0

Re: [PATCH 2/3] x86/boot: Fix another __read_cr4() case on 486

On Wed, Sep 28, 2016 at 12:34:15PM -0700, Andy Lutomirski wrote: > The condition for reading CR4 was wrong: there are some CPUs with > CPUID but not CR4. Rather than trying to make the condition exact, > using __read_cr4_safe(). > > Reported-by: da...@saggiorato.net > Fixes: 18bc7bd523e0

Re: [PATCH 4/5] ACPI / property: Allow holes in reference properties

On Thursday, September 29, 2016 09:48:29 AM Mika Westerberg wrote: > On Wed, Sep 28, 2016 at 11:36:10PM +0200, Rafael J. Wysocki wrote: > > On Fri, Sep 23, 2016 at 4:57 PM, Mika Westerberg > > wrote: > > > DT allows holes or empty phandles for references. This is

Re: [PATCH 4/5] ACPI / property: Allow holes in reference properties

On Thursday, September 29, 2016 09:48:29 AM Mika Westerberg wrote: > On Wed, Sep 28, 2016 at 11:36:10PM +0200, Rafael J. Wysocki wrote: > > On Fri, Sep 23, 2016 at 4:57 PM, Mika Westerberg > > wrote: > > > DT allows holes or empty phandles for references. This is used for example > > > in SPI

Re: [PATCH v2 5/8] pipe: simplify logic in alloc_pipe_info()

On 08/29/2016 02:21 AM, Michael Kerrisk (man-pages) wrote: Replace an 'if' block that covers most of the code in this function with a 'goto'. This makes the code a little simpler to read, and also simplifies the next patch (fix limit checking in alloc_pipe_info()) Cc: Willy Tarreau

Re: [PATCH v2 5/8] pipe: simplify logic in alloc_pipe_info()

On 08/29/2016 02:21 AM, Michael Kerrisk (man-pages) wrote: Replace an 'if' block that covers most of the code in this function with a 'goto'. This makes the code a little simpler to read, and also simplifies the next patch (fix limit checking in alloc_pipe_info()) Cc: Willy Tarreau Cc: Vegard

Re: dm snapshot: Use kmalloc_array() in init_origin_hash()

> We have no hope of fixing Markus' homegrown coccinelle script. I have got an other impression. I see further possibilities to clarify involved communication and software development challenges for a few source code search patterns. How do you think about to discuss the corresponding collateral

Re: dm snapshot: Use kmalloc_array() in init_origin_hash()

> We have no hope of fixing Markus' homegrown coccinelle script. I have got an other impression. I see further possibilities to clarify involved communication and software development challenges for a few source code search patterns. How do you think about to discuss the corresponding collateral

Re: [PATCH 01/10] dm snapshot: Use kmalloc_array() in init_origin_hash()

On Thu, 2016-09-29 at 13:12 +0200, Paul Bolle wrote: > Or did I misread that test? I finally did some digging: commit e367455a9f25 ("checkpatch: emit fewer kmalloc_array/kcalloc conversion warnings") shows I didn't. Paul Bolle

Re: [PATCH 01/10] dm snapshot: Use kmalloc_array() in init_origin_hash()

On Thu, 2016-09-29 at 13:12 +0200, Paul Bolle wrote: > Or did I misread that test? I finally did some digging: commit e367455a9f25 ("checkpatch: emit fewer kmalloc_array/kcalloc conversion warnings") shows I didn't. Paul Bolle

Re: [PATCH 1/3] x86/init: Fix cr4_init_shadow() on CR4-less machines

On Wed, Sep 28, 2016 at 12:34:14PM -0700, Andy Lutomirski wrote: > cr4_init_shadow() will panic on 486-like machines without CR4. Fix > it using __read_cr4_safe(). > > Cc: sta...@vger.kernel.org > Reported-by: da...@saggiorato.net > Fixes: 1e02ce4cccdc ("x86: Store a per-cpu shadow copy of CR4")

Re: [PATCH 1/3] x86/init: Fix cr4_init_shadow() on CR4-less machines

On Wed, Sep 28, 2016 at 12:34:14PM -0700, Andy Lutomirski wrote: > cr4_init_shadow() will panic on 486-like machines without CR4. Fix > it using __read_cr4_safe(). > > Cc: sta...@vger.kernel.org > Reported-by: da...@saggiorato.net > Fixes: 1e02ce4cccdc ("x86: Store a per-cpu shadow copy of CR4")

[PATCH] spmi: regmap: enable userspace writes

Being able to write to spmi registers via userspace is required for quick debug and development. Enable it. The regmap framework uses dev_name to create debugfs dir names. So update the spmi devices to have proper names. Signed-off-by: Kiran Gunda ---

[PATCH] spmi: regmap: enable userspace writes

Being able to write to spmi registers via userspace is required for quick debug and development. Enable it. The regmap framework uses dev_name to create debugfs dir names. So update the spmi devices to have proper names. Signed-off-by: Kiran Gunda --- drivers/base/regmap/regmap-debugfs.c | 2

Re: [PATCH v3] f2fs: introduce get_checkpoint_version for cleanup

On 2016/9/28 2:32, Tiezhu Yang wrote: > There exists almost same codes when get the value of pre_version > and cur_version in function validate_checkpoint, this patch adds > get_checkpoint_version to clean up redundant codes. > > Signed-off-by: Tiezhu Yang > --- >

Re: [PATCH v3] f2fs: introduce get_checkpoint_version for cleanup

On 2016/9/28 2:32, Tiezhu Yang wrote: > There exists almost same codes when get the value of pre_version > and cur_version in function validate_checkpoint, this patch adds > get_checkpoint_version to clean up redundant codes. > > Signed-off-by: Tiezhu Yang > --- > fs/f2fs/checkpoint.c | 68 >

Re: [PATCH v2 00/23] drm/omap: Convert to use videomode from omap_video_timings

On 22/09/16 14:06, Peter Ujfalusi wrote: > Hi, > > Changes since v1: > - separated the patches from the sync drive edge selection series [1] > - commit messages updated as per Tomi's comments > - other comments from Tomi for patch 10 (was 13) and 11 (was 14) addressed > also > > The following

Re: [PATCH v2 00/23] drm/omap: Convert to use videomode from omap_video_timings

On 22/09/16 14:06, Peter Ujfalusi wrote: > Hi, > > Changes since v1: > - separated the patches from the sync drive edge selection series [1] > - commit messages updated as per Tomi's comments > - other comments from Tomi for patch 10 (was 13) and 11 (was 14) addressed > also > > The following

Re: ATA failure regression

Hello, (cc'ing Dan, hi!) On Thu, Sep 29, 2016 at 08:25:58AM -0300, Henrique de Moraes Holschuh wrote: > Actually, according to Shah's post from the 26th to this thread, > everything works just fine even with the IOMMU enabled, as long as the > system is configured to NOT auto-shutdown unused

Re: ATA failure regression

Hello, (cc'ing Dan, hi!) On Thu, Sep 29, 2016 at 08:25:58AM -0300, Henrique de Moraes Holschuh wrote: > Actually, according to Shah's post from the 26th to this thread, > everything works just fine even with the IOMMU enabled, as long as the > system is configured to NOT auto-shutdown unused

[PATCH] pci: remove error message when device not present

It's not an error if the IBM ACPI pseudo-device isn't present, it merely means the kernel isn't running on that IBM hardware. Get rid of the error report so as not to pollute the kernel log with an message irrelevant to the vast majority of users. If someone wants to debug it, they can turn on

Re: [RESEND PATCH 1/1] mm/percpu.c: correct max_distance calculation for pcpu_embed_first_chunk()

On 2016/9/29 18:35, Tejun Heo wrote: > Hello, > > On Sat, Sep 24, 2016 at 07:20:49AM +0800, zijun_hu wrote: >> it is error to represent the max range max_distance spanned by all the >> group areas as the offset of the highest group area plus unit size in >> pcpu_embed_first_chunk(), it should

<    5   6   7   8   9   10   11   12   13   14   >