On Thu, May 31 2018, Dilger, Andreas wrote:
> On May 31, 2018, at 18:54, Greg Kroah-Hartman
> wrote:
>>
>> On Tue, May 29, 2018 at 10:21:45AM -0400, James Simmons wrote:
>>> From: "John L. Hammond"
>>>
>>> Pre 2.10.1 MDTs will crash when they receive a listxattr (MDS_GETXATTR
>>> with
On Thu, May 31 2018, Dilger, Andreas wrote:
> On May 31, 2018, at 18:54, Greg Kroah-Hartman
> wrote:
>>
>> On Tue, May 29, 2018 at 10:21:45AM -0400, James Simmons wrote:
>>> From: "John L. Hammond"
>>>
>>> Pre 2.10.1 MDTs will crash when they receive a listxattr (MDS_GETXATTR
>>> with
Hello everybody.
I am modifying ufshcd driver:
https://elixir.bootlin.com/linux/v3.8/source/drivers/scsi/ufs/ufshcd.c
I do a read of a file on ext4 filesystem and want to obtain the file's
inode. But it seems that there are no structures contatin any
references to inode at this level of
Hello everybody.
I am modifying ufshcd driver:
https://elixir.bootlin.com/linux/v3.8/source/drivers/scsi/ufs/ufshcd.c
I do a read of a file on ext4 filesystem and want to obtain the file's
inode. But it seems that there are no structures contatin any
references to inode at this level of
ST/CZ SoC have 2 channels for capture in the I2SSP path.
The DMA though these channels is done using the same dma
descriptors.
We configure the channel and enable it on the basis of
channel selected by machine driver. Machine driver knows
which codec sits on which channel and thus sends the
ST/CZ SoC have 2 channels for capture in the I2SSP path.
The DMA though these channels is done using the same dma
descriptors.
We configure the channel and enable it on the basis of
channel selected by machine driver. Machine driver knows
which codec sits on which channel and thus sends the
> -Original Message-
> From: Petr Mladek [mailto:pmla...@suse.com]
> Sent: Wednesday, May 30, 2018 5:32 PM
> To: Sergey Senozhatsky
> Cc: Hoeun Ryu ; Sergey Senozhatsky
> ; Steven Rostedt ;
> Hoeun Ryu ; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] printk: make printk_safe_flush
> -Original Message-
> From: Petr Mladek [mailto:pmla...@suse.com]
> Sent: Wednesday, May 30, 2018 5:32 PM
> To: Sergey Senozhatsky
> Cc: Hoeun Ryu ; Sergey Senozhatsky
> ; Steven Rostedt ;
> Hoeun Ryu ; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] printk: make printk_safe_flush
On Fri, Jun 01, 2018 at 04:18:29AM +0100, Al Viro wrote:
> +void umount_on_fput(struct vfsmount *mnt)
> {
which needs to do mntput() in case if it's attached.
On Fri, Jun 01, 2018 at 04:18:29AM +0100, Al Viro wrote:
> +void umount_on_fput(struct vfsmount *mnt)
> {
which needs to do mntput() in case if it's attached.
On 25-05-18, 12:15, Srinivas Kandagatla wrote:
> This patchset adds support to basic version of Qualcomm NGD SLIMBus
> controller driver found SoCs from B family.
>
> This controller is light-weight SLIMBus controller driver responsible for
> communicating with slave HW directly over the bus
On 25-05-18, 12:15, Srinivas Kandagatla wrote:
> This patchset adds support to basic version of Qualcomm NGD SLIMBus
> controller driver found SoCs from B family.
>
> This controller is light-weight SLIMBus controller driver responsible for
> communicating with slave HW directly over the bus
The user requests a pseudo-locked region by providing a schemata to a
resource group that is in the pseudo-locksetup mode. This is the
functionality that consumes the parsed user data and creates the
pseudo-locked region.
First, required information is deduced from user provided data.
This
The user requests a pseudo-locked region by providing a schemata to a
resource group that is in the pseudo-locksetup mode. This is the
functionality that consumes the parsed user data and creates the
pseudo-locked region.
First, required information is deduced from user provided data.
This
On 2018/6/1 12:32 PM, Yisheng Xie wrote:
> Hi Coly,
>
> On 2018/6/1 11:45, Coly Li wrote:
>> On 2018/5/31 7:11 PM, Yisheng Xie wrote:
>>> match_string() returns the index of an array for a matching string,
>>> which can be used instead of open coded variant.
>>>
>>> Cc: Kent Overstreet
>>> Cc:
On 2018/6/1 12:32 PM, Yisheng Xie wrote:
> Hi Coly,
>
> On 2018/6/1 11:45, Coly Li wrote:
>> On 2018/5/31 7:11 PM, Yisheng Xie wrote:
>>> match_string() returns the index of an array for a matching string,
>>> which can be used instead of open coded variant.
>>>
>>> Cc: Kent Overstreet
>>> Cc:
On Mon, May 07, 2018 at 02:21:17PM -0400, Steven Rostedt wrote:
> Peter, Ingo or Thomas,
>
> Can you queue this up? Or would you prefer that I take it?
This patch is a bug fix, could it be queued for v4.17 -rc cycle or for
linux-next?
I have also included it below again:
thanks,
- Joel
On Mon, May 07, 2018 at 02:21:17PM -0400, Steven Rostedt wrote:
> Peter, Ingo or Thomas,
>
> Can you queue this up? Or would you prefer that I take it?
This patch is a bug fix, could it be queued for v4.17 -rc cycle or for
linux-next?
I have also included it below again:
thanks,
- Joel
Free useless ucode_patch entry when it's replaced.
Signed-off-by: Zhenzhong Duan
---
arch/x86/kernel/cpu/microcode/intel.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kernel/cpu/microcode/intel.c
b/arch/x86/kernel/cpu/microcode/intel.c
index
We have enabled GCC_PLUGINS for COMPILE_TEST, but allmodconfig now
produces new warnings.
CC [M] drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.o
drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function
‘wlc_phy_workarounds_nphy_rev7’:
Free useless ucode_patch entry when it's replaced.
Signed-off-by: Zhenzhong Duan
---
arch/x86/kernel/cpu/microcode/intel.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kernel/cpu/microcode/intel.c
b/arch/x86/kernel/cpu/microcode/intel.c
index
We have enabled GCC_PLUGINS for COMPILE_TEST, but allmodconfig now
produces new warnings.
CC [M] drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.o
drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function
‘wlc_phy_workarounds_nphy_rev7’:
On (05/31/18 14:21), Petr Mladek wrote:
> >
> > Upstream printk has no printing kthread. And we also run
> > printk()->console_unlock() with disabled preemption.
>
> Yes, the comment was wrong
Yes, that was the only thing I meant.
I really didn't have any time to look at the patch yesterday,
On (05/31/18 14:21), Petr Mladek wrote:
> >
> > Upstream printk has no printing kthread. And we also run
> > printk()->console_unlock() with disabled preemption.
>
> Yes, the comment was wrong
Yes, that was the only thing I meant.
I really didn't have any time to look at the patch yesterday,
Hi Coly,
On 2018/6/1 11:45, Coly Li wrote:
> On 2018/5/31 7:11 PM, Yisheng Xie wrote:
>> match_string() returns the index of an array for a matching string,
>> which can be used instead of open coded variant.
>>
>> Cc: Kent Overstreet
>> Cc: linux-bca...@vger.kernel.org
>> Signed-off-by:
Hi Coly,
On 2018/6/1 11:45, Coly Li wrote:
> On 2018/5/31 7:11 PM, Yisheng Xie wrote:
>> match_string() returns the index of an array for a matching string,
>> which can be used instead of open coded variant.
>>
>> Cc: Kent Overstreet
>> Cc: linux-bca...@vger.kernel.org
>> Signed-off-by:
On Thu, May 31 2018 at 10:40pm -0400,
Martin K. Petersen wrote:
>
> Mike,
>
> > 1) container A is tasked with managing some dedicated NVMe technology
> > that absolutely needs native NVMe multipath.
>
> > 2) container B is tasked with offering some canned layered product
> > that was
On Thu, May 31 2018 at 10:40pm -0400,
Martin K. Petersen wrote:
>
> Mike,
>
> > 1) container A is tasked with managing some dedicated NVMe technology
> > that absolutely needs native NVMe multipath.
>
> > 2) container B is tasked with offering some canned layered product
> > that was
On Thu, May 31, 2018 at 5:54 PM, Linus Torvalds
wrote:
> On Thu, May 31, 2018 at 7:43 PM Kees Cook wrote:
>>
>> So, while nothing does:
>> kmalloc_array(a, b, ...) -> kmalloc(array_size(a, b), ...)
>> the treewide changes DO perform changes like this:
>> kmalloc(a * b, ...) ->
On Thu, May 31, 2018 at 5:54 PM, Linus Torvalds
wrote:
> On Thu, May 31, 2018 at 7:43 PM Kees Cook wrote:
>>
>> So, while nothing does:
>> kmalloc_array(a, b, ...) -> kmalloc(array_size(a, b), ...)
>> the treewide changes DO perform changes like this:
>> kmalloc(a * b, ...) ->
On Thu, May 31 2018 at 12:34pm -0400,
Christoph Hellwig wrote:
> On Thu, May 31, 2018 at 08:37:39AM -0400, Mike Snitzer wrote:
> > I saw your reply to the 1/3 patch.. I do agree it is broken for not
> > checking if any handles are active. But that is easily fixed no?
>
> Doing a switch at
On Thu, May 31 2018 at 12:34pm -0400,
Christoph Hellwig wrote:
> On Thu, May 31, 2018 at 08:37:39AM -0400, Mike Snitzer wrote:
> > I saw your reply to the 1/3 patch.. I do agree it is broken for not
> > checking if any handles are active. But that is easily fixed no?
>
> Doing a switch at
On Thu, May 31, 2018 at 6:56 PM, Masahiro Yamada
wrote:
> 2018-05-31 12:53 GMT+09:00 Kees Cook :
>> On Wed, May 30, 2018 at 6:26 PM, Kees Cook wrote:
>>> On Wed, May 30, 2018 at 6:12 PM, Masahiro Yamada
>>> wrote:
Hi.
(+CC Kees)
2018-05-31 7:40 GMT+09:00 Stephen Rothwell :
On Thu, May 31, 2018 at 6:56 PM, Masahiro Yamada
wrote:
> 2018-05-31 12:53 GMT+09:00 Kees Cook :
>> On Wed, May 30, 2018 at 6:26 PM, Kees Cook wrote:
>>> On Wed, May 30, 2018 at 6:12 PM, Masahiro Yamada
>>> wrote:
Hi.
(+CC Kees)
2018-05-31 7:40 GMT+09:00 Stephen Rothwell :
On 2018/5/31 7:11 PM, Yisheng Xie wrote:
> match_string() returns the index of an array for a matching string,
> which can be used instead of open coded variant.
>
> Cc: Kent Overstreet
> Cc: linux-bca...@vger.kernel.org
> Signed-off-by: Yisheng Xie
Hi Yishenng,
Andy Shevchenko submitted a
On 2018/5/31 7:11 PM, Yisheng Xie wrote:
> match_string() returns the index of an array for a matching string,
> which can be used instead of open coded variant.
>
> Cc: Kent Overstreet
> Cc: linux-bca...@vger.kernel.org
> Signed-off-by: Yisheng Xie
Hi Yishenng,
Andy Shevchenko submitted a
2018-05-25 14:40 GMT+09:00 Viresh Kumar :
> The cooling device properties, like "#cooling-cells" and
> "dynamic-power-coefficient", should either be present for all the CPUs
> of a cluster or none. If these are present only for a subset of CPUs of
> a cluster then things will start falling apart
2018-05-25 14:40 GMT+09:00 Viresh Kumar :
> The cooling device properties, like "#cooling-cells" and
> "dynamic-power-coefficient", should either be present for all the CPUs
> of a cluster or none. If these are present only for a subset of CPUs of
> a cluster then things will start falling apart
2018-05-25 19:31 GMT+09:00 Viresh Kumar :
> The cooling device properties, like "#cooling-cells" and
> "dynamic-power-coefficient", should either be present for all the CPUs
> of a cluster or none. If these are present only for a subset of CPUs of
> a cluster then things will start falling apart
2018-05-25 19:31 GMT+09:00 Viresh Kumar :
> The cooling device properties, like "#cooling-cells" and
> "dynamic-power-coefficient", should either be present for all the CPUs
> of a cluster or none. If these are present only for a subset of CPUs of
> a cluster then things will start falling apart
There are two new events generated by dell-wmi, rfkill and fn-lock, from
Dell Systems.
When Fn-lock hotkey gets pressed to switch to function mode:
[85951.591542] dell_wmi: Unknown key with type 0x0010 and code 0xe035
pressed
[85951.591546] dell_wmi: Unknown key with type 0x0010 and code 0x
There are two new events generated by dell-wmi, rfkill and fn-lock, from
Dell Systems.
When Fn-lock hotkey gets pressed to switch to function mode:
[85951.591542] dell_wmi: Unknown key with type 0x0010 and code 0xe035
pressed
[85951.591546] dell_wmi: Unknown key with type 0x0010 and code 0x
FWIW, this on top of your current branch (I'll fold and reorder) gets
your move_mount(2) test work, AFAICS:
diff --git a/fs/file_table.c b/fs/file_table.c
index 06e979e1347e..6dd9760b3ddc 100644
--- a/fs/file_table.c
+++ b/fs/file_table.c
@@ -200,9 +200,6 @@ static void __fput(struct file *file)
FWIW, this on top of your current branch (I'll fold and reorder) gets
your move_mount(2) test work, AFAICS:
diff --git a/fs/file_table.c b/fs/file_table.c
index 06e979e1347e..6dd9760b3ddc 100644
--- a/fs/file_table.c
+++ b/fs/file_table.c
@@ -200,9 +200,6 @@ static void __fput(struct file *file)
On 2018-05-25 14:13, Byungchul Park wrote:
On 2018-05-09 15:33, Byungchul Park wrote:
On Thu, Jan 11, 2018 at 10:07:16AM +0100, Peter Zijlstra wrote:
Sorry for the huge delay on this, but I'll have to postpone further.
Still busy with meltdown/spectre stuff.
Please consider this. Even
On 2018-05-25 14:13, Byungchul Park wrote:
On 2018-05-09 15:33, Byungchul Park wrote:
On Thu, Jan 11, 2018 at 10:07:16AM +0100, Peter Zijlstra wrote:
Sorry for the huge delay on this, but I'll have to postpone further.
Still busy with meltdown/spectre stuff.
Please consider this. Even
From: Honghui Zhang
The MTCMOS of PCIe Host for MT2712 will be off when system suspend, and all
the internal control register will be reset after system resume. The PCIe
link should be re-established and the related control register values
should be re-set after system resume.
Signed-off-by:
From: Honghui Zhang
The MTCMOS of PCIe Host for MT2712 will be off when system suspend, and all
the internal control register will be reset after system resume. The PCIe
link should be re-established and the related control register values
should be re-set after system resume.
Signed-off-by:
Mike,
> 1) container A is tasked with managing some dedicated NVMe technology
> that absolutely needs native NVMe multipath.
> 2) container B is tasked with offering some canned layered product
> that was developed ontop of dm-multipath with its own multipath-tools
> oriented APIs, etc. And it
Mike,
> 1) container A is tasked with managing some dedicated NVMe technology
> that absolutely needs native NVMe multipath.
> 2) container B is tasked with offering some canned layered product
> that was developed ontop of dm-multipath with its own multipath-tools
> oriented APIs, etc. And it
Plugging in a USB-C power source on my Dell XPS 9550 trips an ACPI
BUG_ON [1], reproducible with mainline 4.14.44, suggesting other
threads are waiting for semaphore acquisition due to
"BUG_ON(!list_empty(>wait_list))".
This is the current 1.7.0 BIOS with Ubuntu 18.04 userspace, plugging
in an LG
Plugging in a USB-C power source on my Dell XPS 9550 trips an ACPI
BUG_ON [1], reproducible with mainline 4.14.44, suggesting other
threads are waiting for semaphore acquisition due to
"BUG_ON(!list_empty(>wait_list))".
This is the current 1.7.0 BIOS with Ubuntu 18.04 userspace, plugging
in an LG
Hi Rob,
On 2018-05-31 10:45 PM, Rob Herring wrote:
On Wed, May 30, 2018 at 10:27 PM, wrote:
From: Levin Du
In Rockchip RK3328, the output only GPIO_MUTE pin, originally for codec
mute control, can also be used for general purpose. It is manipulated by
the GRF_SOC_CON10 register.
Hi Rob,
On 2018-05-31 10:45 PM, Rob Herring wrote:
On Wed, May 30, 2018 at 10:27 PM, wrote:
From: Levin Du
In Rockchip RK3328, the output only GPIO_MUTE pin, originally for codec
mute control, can also be used for general purpose. It is manipulated by
the GRF_SOC_CON10 register.
Currently, the range of jiffies_till_{first,next}_fqs are checked and
adjusted on and on in the loop of rcu_gp_kthread on runtime.
However, it's enough to check them only when setting them, not every
time in the loop. So make them handled on a setting time via sysfs.
Signed-off-by: Byungchul
On 5/31/2018 2:10 AM, Michal Hocko wrote:
On Thu 31-05-18 10:55:32, Michal Hocko wrote:
On Thu 31-05-18 04:35:31, Eric Dumazet wrote:
[...]
I merely copied/pasted from alloc_skb_with_frags() :/
I will have a look at it. Thanks!
OK, so this is an example of an incremental development ;).
Currently, the range of jiffies_till_{first,next}_fqs are checked and
adjusted on and on in the loop of rcu_gp_kthread on runtime.
However, it's enough to check them only when setting them, not every
time in the loop. So make them handled on a setting time via sysfs.
Signed-off-by: Byungchul
On 5/31/2018 2:10 AM, Michal Hocko wrote:
On Thu 31-05-18 10:55:32, Michal Hocko wrote:
On Thu 31-05-18 04:35:31, Eric Dumazet wrote:
[...]
I merely copied/pasted from alloc_skb_with_frags() :/
I will have a look at it. Thanks!
OK, so this is an example of an incremental development ;).
Add checks in the .round_rate and .set_rate ops for zero requested
rate or zero parent rate. If either are zero in .round_rate, just
return zero. If either are zero in .set_rate, return -EINVAL.
Signed-off-by: Steve Longerbeam
---
drivers/clk/clk-versaclock5.c | 25 +
1
Add checks in the .round_rate and .set_rate ops for zero requested
rate or zero parent rate. If either are zero in .round_rate, just
return zero. If either are zero in .set_rate, return -EINVAL.
Signed-off-by: Steve Longerbeam
---
drivers/clk/clk-versaclock5.c | 25 +
1
Recently Kiril Tkhai reported that mm_update_next_ownerwas executing
it's expensive for_each_process fallback. Reading the code reveals
that all that is needed to trigger this is a multi-threaded process
where the thread group leader exits. AKA something anyone can easily
trigger an any time.
Recently Kiril Tkhai reported that mm_update_next_ownerwas executing
it's expensive for_each_process fallback. Reading the code reveals
that all that is needed to trigger this is a multi-threaded process
where the thread group leader exits. AKA something anyone can easily
trigger an any time.
2018-05-31 12:53 GMT+09:00 Kees Cook :
> On Wed, May 30, 2018 at 6:26 PM, Kees Cook wrote:
>> On Wed, May 30, 2018 at 6:12 PM, Masahiro Yamada
>> wrote:
>>> Hi.
>>> (+CC Kees)
>>>
>>> 2018-05-31 7:40 GMT+09:00 Stephen Rothwell :
Hi Masahiro,
After merging the kbuild tree, today's
2018-05-31 12:53 GMT+09:00 Kees Cook :
> On Wed, May 30, 2018 at 6:26 PM, Kees Cook wrote:
>> On Wed, May 30, 2018 at 6:12 PM, Masahiro Yamada
>> wrote:
>>> Hi.
>>> (+CC Kees)
>>>
>>> 2018-05-31 7:40 GMT+09:00 Stephen Rothwell :
Hi Masahiro,
After merging the kbuild tree, today's
Hi all,
Today's linux-next merge of the vfs tree got a conflict in:
include/linux/fs.h
between commit:
29aca8b3f7cd ("fsnotify: introduce prototype struct fsnotify_obj")
from the ext3 tree and commit:
d9a08a9e616b ("fs: Add aio iopriority support")
from the vfs tree.
I fixed it up
Hi all,
Today's linux-next merge of the vfs tree got a conflict in:
include/linux/fs.h
between commit:
29aca8b3f7cd ("fsnotify: introduce prototype struct fsnotify_obj")
from the ext3 tree and commit:
d9a08a9e616b ("fs: Add aio iopriority support")
from the vfs tree.
I fixed it up
On Fri, Jun 01, 2018 at 05:01:00PM +0800, Jin Yao wrote:
> When doing pmu sampling and then running a script with
> perf script -s script.py, the process_event function gets
> dictionary with some fields from the perf ring buffer
> (like ip, sym, callchain etc).
>
> But we miss quite a few fields
On Fri, Jun 01, 2018 at 05:01:00PM +0800, Jin Yao wrote:
> When doing pmu sampling and then running a script with
> perf script -s script.py, the process_event function gets
> dictionary with some fields from the perf ring buffer
> (like ip, sym, callchain etc).
>
> But we miss quite a few fields
I appreciate the detailed correction.
I will reflect the corrections in the next patch.
plus, the explanation in the code will be fixed.
> -Original Message-
> From: Petr Mladek [mailto:pmla...@suse.com]
> Sent: Wednesday, May 30, 2018 5:32 PM
> To: Sergey Senozhatsky
> Cc: Hoeun Ryu ;
I appreciate the detailed correction.
I will reflect the corrections in the next patch.
plus, the explanation in the code will be fixed.
> -Original Message-
> From: Petr Mladek [mailto:pmla...@suse.com]
> Sent: Wednesday, May 30, 2018 5:32 PM
> To: Sergey Senozhatsky
> Cc: Hoeun Ryu ;
On Thu, May 31, 2018 at 08:19:55PM +0100, Al Viro wrote:
> On Fri, May 25, 2018 at 01:07:34AM +0100, David Howells wrote:
> > + if (unlikely(file->f_mode & FMODE_NEED_UNMOUNT))
> > + __detach_mounts(dentry);
> > +
>
> This is completely wrong. First of all, you want to dissolve the
On Thu, May 31, 2018 at 08:19:55PM +0100, Al Viro wrote:
> On Fri, May 25, 2018 at 01:07:34AM +0100, David Howells wrote:
> > + if (unlikely(file->f_mode & FMODE_NEED_UNMOUNT))
> > + __detach_mounts(dentry);
> > +
>
> This is completely wrong. First of all, you want to dissolve the
Hi Al,
Today's linux-next merge of the vfs tree got a conflict in:
fs/afs/fsclient.c
between commit:
684b0f68cf1c ("afs: Fix AFSFetchStatus decoder to provide OpenAFS
compatibility")
from Linus' tree and commit:
c875c76a061d ("afs: Fix a Sparse warning in xdr_decode_AFSFetchStatus()")
Hi Al,
Today's linux-next merge of the vfs tree got a conflict in:
fs/afs/fsclient.c
between commit:
684b0f68cf1c ("afs: Fix AFSFetchStatus decoder to provide OpenAFS
compatibility")
from Linus' tree and commit:
c875c76a061d ("afs: Fix a Sparse warning in xdr_decode_AFSFetchStatus()")
On 05/31/2018 12:37 PM, Marek Vasut wrote:
On 05/31/2018 08:52 PM, Steve Longerbeam wrote:
On 05/31/2018 11:35 AM, Marek Vasut wrote:
On 05/31/2018 08:32 PM, Steve Longerbeam wrote:
Hi Marek,
On 05/31/2018 11:25 AM, Marek Vasut wrote:
On 05/31/2018 08:23 PM, Steve Longerbeam wrote:
On 05/31/2018 12:37 PM, Marek Vasut wrote:
On 05/31/2018 08:52 PM, Steve Longerbeam wrote:
On 05/31/2018 11:35 AM, Marek Vasut wrote:
On 05/31/2018 08:32 PM, Steve Longerbeam wrote:
Hi Marek,
On 05/31/2018 11:25 AM, Marek Vasut wrote:
On 05/31/2018 08:23 PM, Steve Longerbeam wrote:
On 2018-05-31 20:17, Paul E. McKenney wrote:
On Thu, May 31, 2018 at 11:51:40AM +0900, Byungchul Park wrote:
On 2018-05-31 11:18, Byungchul Park wrote:
On 2018-05-29 21:01, Paul E. McKenney wrote:
One approach would be to embed the kernel_params_ops structure inside
another structure
On 2018-05-31 20:17, Paul E. McKenney wrote:
On Thu, May 31, 2018 at 11:51:40AM +0900, Byungchul Park wrote:
On 2018-05-31 11:18, Byungchul Park wrote:
On 2018-05-29 21:01, Paul E. McKenney wrote:
One approach would be to embed the kernel_params_ops structure inside
another structure
From: Steve Longerbeam
This patch adds support for the input capture function in the
i.MX GPT. Output compare and input capture functions are mixed
in the same register block, so we need to modify the irq ack/enable/
disable primitives to not stomp on the other function.
The input capture API
From: Steve Longerbeam
This patch adds support for the input capture function in the
i.MX GPT. Output compare and input capture functions are mixed
in the same register block, so we need to modify the irq ack/enable/
disable primitives to not stomp on the other function.
The input capture API
On Thu, 2018-05-31 at 17:13 -0700, Andrew Morton wrote:
> On Wed, 30 May 2018 17:18:55 +0800 Ian Kent wrote:
>
> > > I actually had an alternative approach that I tried out successfully
> > > but discarded as being too different from the original code. Just for
> > > reference, this one would
On Thu, 2018-05-31 at 17:13 -0700, Andrew Morton wrote:
> On Wed, 30 May 2018 17:18:55 +0800 Ian Kent wrote:
>
> > > I actually had an alternative approach that I tried out successfully
> > > but discarded as being too different from the original code. Just for
> > > reference, this one would
Jia-Ju Bai wrote:
>
>
> On 2018/5/31 22:30, Christopher Lameter wrote:
>> On Thu, 31 May 2018, Matthew Wilcox wrote:
>>
Freeing a page in the page allocator also was traditionally not sleeping.
That has changed?
>>> No. "Your bug" being "The bug in your static analysis tool". It
Jia-Ju Bai wrote:
>
>
> On 2018/5/31 22:30, Christopher Lameter wrote:
>> On Thu, 31 May 2018, Matthew Wilcox wrote:
>>
Freeing a page in the page allocator also was traditionally not sleeping.
That has changed?
>>> No. "Your bug" being "The bug in your static analysis tool". It
On 2018/5/31 22:30, Christopher Lameter wrote:
On Thu, 31 May 2018, Matthew Wilcox wrote:
Freeing a page in the page allocator also was traditionally not sleeping.
That has changed?
No. "Your bug" being "The bug in your static analysis tool". It probably
isn't following the data flow
On 2018/5/31 22:30, Christopher Lameter wrote:
On Thu, 31 May 2018, Matthew Wilcox wrote:
Freeing a page in the page allocator also was traditionally not sleeping.
That has changed?
No. "Your bug" being "The bug in your static analysis tool". It probably
isn't following the data flow
Hi Brian,
On 05/31/2018 05:32 PM, Brian Norris wrote:
This driver was originally submitted for the TI BQ20Z75 battery IC
(commit a7640bfa10c5 ("power_supply: Add driver for TI BQ20Z75 gas gauge
IC")) and later renamed to express generic SBS support. While it's
mostly true that this driver
Hi Brian,
On 05/31/2018 05:32 PM, Brian Norris wrote:
This driver was originally submitted for the TI BQ20Z75 battery IC
(commit a7640bfa10c5 ("power_supply: Add driver for TI BQ20Z75 gas gauge
IC")) and later renamed to express generic SBS support. While it's
mostly true that this driver
On 2018/5/31 22:09, Christopher Lameter wrote:
On Thu, 31 May 2018, Jia-Ju Bai wrote:
I write a static analysis tool (DSAC), and it finds that kfree() can sleep.
That should not happen.
Here is the call path for kfree().
Please look at it *from the bottom up*.
[FUNC]
On 2018/5/31 22:09, Christopher Lameter wrote:
On Thu, 31 May 2018, Jia-Ju Bai wrote:
I write a static analysis tool (DSAC), and it finds that kfree() can sleep.
That should not happen.
Here is the call path for kfree().
Please look at it *from the bottom up*.
[FUNC]
On 2018/5/31 22:08, Matthew Wilcox wrote:
On Thu, May 31, 2018 at 09:10:07PM +0800, Jia-Ju Bai wrote:
I write a static analysis tool (DSAC), and it finds that kfree() can sleep.
Here is the call path for kfree().
Please look at it *from the bottom up*.
[FUNC] alloc_pages(GFP_KERNEL)
On 2018/5/31 22:08, Matthew Wilcox wrote:
On Thu, May 31, 2018 at 09:10:07PM +0800, Jia-Ju Bai wrote:
I write a static analysis tool (DSAC), and it finds that kfree() can sleep.
Here is the call path for kfree().
Please look at it *from the bottom up*.
[FUNC] alloc_pages(GFP_KERNEL)
Hi Al,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 0512e0134582ef85dee77d51aae77dcd1edec495
commit: ee076e81fc14ca79334d02970cea66604f183a14 sparc: trivial conversions to
{COMPAT_,}SYSCALL_DEFINE()
date: 2
Hi Al,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 0512e0134582ef85dee77d51aae77dcd1edec495
commit: ee076e81fc14ca79334d02970cea66604f183a14 sparc: trivial conversions to
{COMPAT_,}SYSCALL_DEFINE()
date: 2
Michal Hocko writes:
> On Thu 26-04-18 14:00:19, Kirill Tkhai wrote:
>> This function searches for a new mm owner in children and siblings,
>> and then iterates over all processes in the system in unlikely case.
>> Despite the case is unlikely, its probability growths with the number
>> of
Michal Hocko writes:
> On Thu 26-04-18 14:00:19, Kirill Tkhai wrote:
>> This function searches for a new mm owner in children and siblings,
>> and then iterates over all processes in the system in unlikely case.
>> Despite the case is unlikely, its probability growths with the number
>> of
When doing pmu sampling and then running a script with
perf script -s script.py, the process_event function gets
dictionary with some fields from the perf ring buffer
(like ip, sym, callchain etc).
But we miss quite a few fields we report now, for example,
LBRs,data
This patch creates a new function get_dsoname() and move the
code which gets the dsoname string to this function.
That's because in next patch, when we process LBR data, we will
also need get_dsoname() to return dsoname for branch from/to.
Signed-off-by: Jin Yao
---
When doing pmu sampling and then running a script with
perf script -s script.py, the process_event function gets
dictionary with some fields from the perf ring buffer
(like ip, sym, callchain etc).
But we miss quite a few fields we report now, for example,
LBRs,data
When doing pmu sampling and then running a script with
perf script -s script.py, the process_event function gets
dictionary with some fields from the perf ring buffer
(like ip, sym, callchain etc).
But we miss quite a few fields we report now, for example,
LBRs,data
1 - 100 of 1222 matches
Mail list logo
