Hello Stephen,
On 7/13/2018 1:55 PM, spa...@codeaurora.org wrote:
On 2018-07-13 01:11, Stephen Boyd wrote:
Quoting Taniya Das (2018-07-12 10:21:33)
++ Display driver team,
On 7/9/2018 8:36 PM, Stephen Boyd wrote:
> Quoting Taniya Das (2018-07-09 02:34:07)
>>
>>
>> On 7/9/2018 1:07 PM,
Hello Stephen,
On 7/13/2018 1:55 PM, spa...@codeaurora.org wrote:
On 2018-07-13 01:11, Stephen Boyd wrote:
Quoting Taniya Das (2018-07-12 10:21:33)
++ Display driver team,
On 7/9/2018 8:36 PM, Stephen Boyd wrote:
> Quoting Taniya Das (2018-07-09 02:34:07)
>>
>>
>> On 7/9/2018 1:07 PM,
SPDX headers updated for common/branch/pll/regmap files.
Signed-off-by: Taniya Das
---
drivers/clk/qcom/clk-alpha-pll.c | 10 +-
drivers/clk/qcom/clk-alpha-pll.h | 14 ++
drivers/clk/qcom/clk-branch.c| 10 +-
drivers/clk/qcom/clk-branch.h| 14 ++
SPDX headers updated for common/branch/pll/regmap files.
Signed-off-by: Taniya Das
---
drivers/clk/qcom/clk-alpha-pll.c | 10 +-
drivers/clk/qcom/clk-alpha-pll.h | 14 ++
drivers/clk/qcom/clk-branch.c| 10 +-
drivers/clk/qcom/clk-branch.h| 14 ++
Hi Ted,
After merging the random tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:
drivers/char/random.c: In function 'write_pool.constprop':
drivers/char/random.c:1912:11: warning: 't' may be used uninitialized in this
function [-Wmaybe-uninitialized]
buf[i] ^=
Hi Ted,
After merging the random tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:
drivers/char/random.c: In function 'write_pool.constprop':
drivers/char/random.c:1912:11: warning: 't' may be used uninitialized in this
function [-Wmaybe-uninitialized]
buf[i] ^=
Fix the spelling of 'varibles' -> 'variables' in
shadows->vars.txt file.
Signed-off-by: Kamalesh Babulal
---
Documentation/livepatch/shadow-vars.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/livepatch/shadow-vars.txt
Fix the spelling of 'varibles' -> 'variables' in
shadows->vars.txt file.
Signed-off-by: Kamalesh Babulal
---
Documentation/livepatch/shadow-vars.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/livepatch/shadow-vars.txt
Hi Paul,
> > --- linux-jhogan-test.orig/fs/binfmt_elf.c 2018-03-21 17:14:55.0
> > +
> > +++ linux-jhogan-test/fs/binfmt_elf.c 2018-05-09 23:25:50.742255000
> > +0100
> > @@ -1739,7 +1739,7 @@ static int fill_thread_core_info(struct
> > const struct user_regset
Hi Paul,
> > --- linux-jhogan-test.orig/fs/binfmt_elf.c 2018-03-21 17:14:55.0
> > +
> > +++ linux-jhogan-test/fs/binfmt_elf.c 2018-05-09 23:25:50.742255000
> > +0100
> > @@ -1739,7 +1739,7 @@ static int fill_thread_core_info(struct
> > const struct user_regset
QUPv3 clocks support DFS and thus register the RCGs which require support
for the same.
Signed-off-by: Taniya Das
---
drivers/clk/qcom/gcc-sdm845.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/clk/qcom/gcc-sdm845.c b/drivers/clk/qcom/gcc-sdm845.c
index
QUPv3 clocks support DFS and thus register the RCGs which require support
for the same.
Signed-off-by: Taniya Das
---
drivers/clk/qcom/gcc-sdm845.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/clk/qcom/gcc-sdm845.c b/drivers/clk/qcom/gcc-sdm845.c
index
Dynamic Frequency switch is a feature of clock controller by which request
from peripherals allows automatic switching frequency of input clock
without SW intervention. There are various performance levels associated
with a root clock. When the input performance state changes, the source
clocks
Dynamic Frequency switch is a feature of clock controller by which request
from peripherals allows automatic switching frequency of input clock
without SW intervention. There are various performance levels associated
with a root clock. When the input performance state changes, the source
clocks
[v3]
* Rename clk_rcg2_calculate_m_and_n with clk_rcg2_calculate_freq, as this
function would now calculate the frequency.
* Rename dfs_freq_tbl to freq_tbl.
* Remove the logic to remove duplicate frequencies.
* Remove recalc_rate & set_rate clock ops.
* clk_rcg2_dfs_ops clock ops
[v3]
* Rename clk_rcg2_calculate_m_and_n with clk_rcg2_calculate_freq, as this
function would now calculate the frequency.
* Rename dfs_freq_tbl to freq_tbl.
* Remove the logic to remove duplicate frequencies.
* Remove recalc_rate & set_rate clock ops.
* clk_rcg2_dfs_ops clock ops
Hello Stephen,
Thanks for your review comments.
On 7/9/2018 12:34 PM, Stephen Boyd wrote:
Quoting Taniya Das (2018-06-28 04:47:30)
Dynamic Frequency switch is a feature of clock controller by which request
from peripherals allows automatic switching frequency of input clock.
There are various
Hello Stephen,
Thanks for your review comments.
On 7/9/2018 12:34 PM, Stephen Boyd wrote:
Quoting Taniya Das (2018-06-28 04:47:30)
Dynamic Frequency switch is a feature of clock controller by which request
from peripherals allows automatic switching frequency of input clock.
There are various
On 12-07-18, 23:35, Taniya Das wrote:
> +static int qcom_cpu_resources_init(struct platform_device *pdev,
> +struct device_node *np, unsigned int cpu)
> +{
> + struct cpufreq_qcom *c;
> + struct resource res;
> + struct device *dev = >dev;
> +
On 12-07-18, 23:35, Taniya Das wrote:
> +static int qcom_cpu_resources_init(struct platform_device *pdev,
> +struct device_node *np, unsigned int cpu)
> +{
> + struct cpufreq_qcom *c;
> + struct resource res;
> + struct device *dev = >dev;
> +
On 12-07-18, 23:35, Taniya Das wrote:
> The CPUfreq HW present in some QCOM chipsets offloads the steps necessary
> for changing the frequency of CPUs. The driver implements the cpufreq
> driver interface for this hardware engine.
>
> Signed-off-by: Saravana Kannan
> Signed-off-by: Taniya Das
>
On 12-07-18, 23:35, Taniya Das wrote:
> The CPUfreq HW present in some QCOM chipsets offloads the steps necessary
> for changing the frequency of CPUs. The driver implements the cpufreq
> driver interface for this hardware engine.
>
> Signed-off-by: Saravana Kannan
> Signed-off-by: Taniya Das
>
GPC registers are NOT continuous, some registers are
reserved and accessing them from userspace will trigger
external abort, add regmap register access table to
avoid below abort:
root@imx6slevk:~# cat /sys/kernel/debug/regmap/20dc000.gpc/registers
[ 108.480477] Unhandled fault: imprecise
GPC registers are NOT continuous, some registers are
reserved and accessing them from userspace will trigger
external abort, add regmap register access table to
avoid below abort:
root@imx6slevk:~# cat /sys/kernel/debug/regmap/20dc000.gpc/registers
[ 108.480477] Unhandled fault: imprecise
On Sat, Jul 7, 2018 at 4:00 PM, Souptick Joarder wrote:
> Use new return type vm_fault_t for fault handler
> ext4_filemap_fault.
>
> Signed-off-by: Souptick Joarder
Any comment on this patch ?
> ---
> fs/ext4/ext4.h | 2 +-
> fs/ext4/inode.c | 8
> 2 files changed, 5 insertions(+), 5
On Sat, Jul 7, 2018 at 4:00 PM, Souptick Joarder wrote:
> Use new return type vm_fault_t for fault handler
> ext4_filemap_fault.
>
> Signed-off-by: Souptick Joarder
Any comment on this patch ?
> ---
> fs/ext4/ext4.h | 2 +-
> fs/ext4/inode.c | 8
> 2 files changed, 5 insertions(+), 5
On 05-07-18, 10:39, Viresh Kumar wrote:
> Allow cooling devices sharing same trip point with same contribution
> value to share the cooling map as well. Otherwise the same information
> will be duplicated for each device sharing the trip point.
>
> Signed-off-by: Viresh Kumar
> ---
>
On 05-07-18, 10:39, Viresh Kumar wrote:
> Allow cooling devices sharing same trip point with same contribution
> value to share the cooling map as well. Otherwise the same information
> will be duplicated for each device sharing the trip point.
>
> Signed-off-by: Viresh Kumar
> ---
>
On 29-06-18, 11:49, Viresh Kumar wrote:
> Hi,
>
> This series improves the OPP core (and a bit of genpd core as well) to
> support multiple phandles in the "required-opps" property, which are
> only used for multiple power-domains per device for now.
>
> We still don't propagate the changes to
On 29-06-18, 11:49, Viresh Kumar wrote:
> Hi,
>
> This series improves the OPP core (and a bit of genpd core as well) to
> support multiple phandles in the "required-opps" property, which are
> only used for multiple power-domains per device for now.
>
> We still don't propagate the changes to
On 13-07-18, 16:36, Srinivas Kandagatla wrote:
> During discussion regarding card re-binding when components unregister
> and register back at https://lkml.org/lkml/2018/7/9/785 it was suggested
> that component framework can be added into core to provide this feature.
>
> With this new changes
On 13-07-18, 16:36, Srinivas Kandagatla wrote:
> During discussion regarding card re-binding when components unregister
> and register back at https://lkml.org/lkml/2018/7/9/785 it was suggested
> that component framework can be added into core to provide this feature.
>
> With this new changes
When using unknown pti boot options other than on/off/auto, we
select auto silently, which is sometimes confusing. Add warning for
unknown pti boot options like we do in
spectre_v2_select_mitigation().
Signed-off-by: Jiang Biao
---
arch/x86/mm/pti.c | 10 +-
1 file changed, 5
When using unknown pti boot options other than on/off/auto, we
select auto silently, which is sometimes confusing. Add warning for
unknown pti boot options like we do in
spectre_v2_select_mitigation().
Signed-off-by: Jiang Biao
---
arch/x86/mm/pti.c | 10 +-
1 file changed, 5
pti_user_pagetable_walk_p4d() may return NULL, we should check the
return value to avoid NULL pointer dereference.
Signed-off-by: Jiang Biao
---
arch/x86/mm/pti.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/x86/mm/pti.c b/arch/x86/mm/pti.c
index
pti_set_kernel_image_nonglobal() is only used in pti.c, make it
static.
Signed-off-by: Jiang Biao
---
arch/x86/mm/pti.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/mm/pti.c b/arch/x86/mm/pti.c
index bb6f608..a76b2cc 100644
--- a/arch/x86/mm/pti.c
+++
pti_user_pagetable_walk_p4d() may return NULL, we should check the
return value to avoid NULL pointer dereference.
Signed-off-by: Jiang Biao
---
arch/x86/mm/pti.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/x86/mm/pti.c b/arch/x86/mm/pti.c
index
pti_set_kernel_image_nonglobal() is only used in pti.c, make it
static.
Signed-off-by: Jiang Biao
---
arch/x86/mm/pti.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/mm/pti.c b/arch/x86/mm/pti.c
index bb6f608..a76b2cc 100644
--- a/arch/x86/mm/pti.c
+++
Addresses passed in pti_user_pagetable_walk_*() are not supposed to
change at runtime, make them const to aviod future slipups.
Signed-off-by: Jiang Biao
---
arch/x86/mm/pti.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86/mm/pti.c b/arch/x86/mm/pti.c
index
pti_user_pagetable_walk_pmd() may return NULL, we should check the
return value in pti_user_pagetable_walk_pte() to avoid NULL pointer
dereference like it is checked in pti_clone_pmds().
Signed-off-by: Jiang Biao
---
arch/x86/mm/pti.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Addresses passed in pti_user_pagetable_walk_*() are not supposed to
change at runtime, make them const to aviod future slipups.
Signed-off-by: Jiang Biao
---
arch/x86/mm/pti.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86/mm/pti.c b/arch/x86/mm/pti.c
index
pti_user_pagetable_walk_pmd() may return NULL, we should check the
return value in pti_user_pagetable_walk_pte() to avoid NULL pointer
dereference like it is checked in pti_clone_pmds().
Signed-off-by: Jiang Biao
---
arch/x86/mm/pti.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
This is a short series of fixes and cleanups found when reading the
code, no functional changes.
Jiang Biao (5):
x86/pti: check the return value of pti_user_pagetable_walk_p4d
x86/pti: check the return value of pti_user_pagetable_walk_pmd
x86/pti: make pti_set_kernel_image_nonglobal static
This is a short series of fixes and cleanups found when reading the
code, no functional changes.
Jiang Biao (5):
x86/pti: check the return value of pti_user_pagetable_walk_p4d
x86/pti: check the return value of pti_user_pagetable_walk_pmd
x86/pti: make pti_set_kernel_image_nonglobal static
On 10-07-18, 15:59, Greg KH wrote:
> On Mon, Jul 02, 2018 at 02:19:47PM +0530, Viresh Kumar wrote:
> > From: Waldemar Rymarkiewicz
> >
> > Original commit c5c2a97b3ac7 ("PM / OPP: Update voltage in case freq ==
> > old_freq").
Looking for this ^^ information ?
> Always give me a hint as to
On 10-07-18, 15:59, Greg KH wrote:
> On Mon, Jul 02, 2018 at 02:19:47PM +0530, Viresh Kumar wrote:
> > From: Waldemar Rymarkiewicz
> >
> > Original commit c5c2a97b3ac7 ("PM / OPP: Update voltage in case freq ==
> > old_freq").
Looking for this ^^ information ?
> Always give me a hint as to
> now need to dive in deep into the actual implementation. Simple question: is
> this a bug?
These are derived events from MEM_TRANS_RETIRED.LOAD_LATENCY, which is in
the SDM. It's not a bug. In general the event lists used by perf are
newer versions than what is in the SDM.
-Andi
In preparing to remove all stack VLA usage from the kernel[1], this
removes the discouraged use of AHASH_REQUEST_ON_STACK in favor of
the smaller SHASH_DESC_ON_STACK by converting from ahash-wrapped-shash
to direct shash. The stack allocation will be made a fixed size in a
later patch to the
> now need to dive in deep into the actual implementation. Simple question: is
> this a bug?
These are derived events from MEM_TRANS_RETIRED.LOAD_LATENCY, which is in
the SDM. It's not a bug. In general the event lists used by perf are
newer versions than what is in the SDM.
-Andi
In preparing to remove all stack VLA usage from the kernel[1], this
removes the discouraged use of AHASH_REQUEST_ON_STACK in favor of
the smaller SHASH_DESC_ON_STACK by converting from ahash-wrapped-shash
to direct shash. The stack allocation will be made a fixed size in a
later patch to the
In the quest to remove all stack VLA usage from the kernel[1], this
removes the discouraged use of AHASH_REQUEST_ON_STACK by switching to
shash directly and allocating the descriptor in heap memory (which should
be fine: the tfm has already been allocated there too).
[1]
In the quest to remove all stack VLA usage from the kernel[1], this
removes the discouraged use of AHASH_REQUEST_ON_STACK by switching to
shash directly and allocating the descriptor in heap memory (which should
be fine: the tfm has already been allocated there too).
[1]
On Mon, Jul 16, 2018 at 11:09 AM, Shakeel Butt wrote:
> On Sun, Jul 15, 2018 at 6:50 PM Yafang Shao wrote:
>>
>> On Sun, Jul 15, 2018 at 11:04 PM, Shakeel Butt wrote:
>> > On Sun, Jul 15, 2018 at 1:02 AM Yafang Shao wrote:
>> >>
>> >> On Sun, Jul 15, 2018 at 2:34 PM, Shakeel Butt wrote:
>> >>
On Mon, Jul 16, 2018 at 11:09 AM, Shakeel Butt wrote:
> On Sun, Jul 15, 2018 at 6:50 PM Yafang Shao wrote:
>>
>> On Sun, Jul 15, 2018 at 11:04 PM, Shakeel Butt wrote:
>> > On Sun, Jul 15, 2018 at 1:02 AM Yafang Shao wrote:
>> >>
>> >> On Sun, Jul 15, 2018 at 2:34 PM, Shakeel Butt wrote:
>> >>
Hi Jae,
In originally, we reserved these register bits for debug purpose. But for some
error handling case, we found it is also useful to help to clarify some error
conditions. So driver also can use these fields information to check something.
As for how driver use these information in their
Hi Jae,
In originally, we reserved these register bits for debug purpose. But for some
error handling case, we found it is also useful to help to clarify some error
conditions. So driver also can use these fields information to check something.
As for how driver use these information in their
Hi, Bjorn, Lorenzo,
could you kindly take a look at this serial?
thanks.
On Mon, 2018-07-02 at 15:57 +0800, honghui.zh...@mediatek.com wrote:
> From: Honghui Zhang
>
> This patchset includes misc patchs:
>
> The first patch fixup the mtk_pcie_find_port logical which will cause system
> could
Hi, Bjorn, Lorenzo,
could you kindly take a look at this serial?
thanks.
On Mon, 2018-07-02 at 15:57 +0800, honghui.zh...@mediatek.com wrote:
> From: Honghui Zhang
>
> This patchset includes misc patchs:
>
> The first patch fixup the mtk_pcie_find_port logical which will cause system
> could
Hello,
syzbot found the following crash on:
HEAD commit:483d835c8189 Add linux-next specific files for 20180713
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=13689bb240
kernel config: https://syzkaller.appspot.com/x/.config?x=60e5ac2478928314
Hello,
syzbot found the following crash on:
HEAD commit:483d835c8189 Add linux-next specific files for 20180713
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=13689bb240
kernel config: https://syzkaller.appspot.com/x/.config?x=60e5ac2478928314
On Sun, Jul 15, 2018 at 6:50 PM Yafang Shao wrote:
>
> On Sun, Jul 15, 2018 at 11:04 PM, Shakeel Butt wrote:
> > On Sun, Jul 15, 2018 at 1:02 AM Yafang Shao wrote:
> >>
> >> On Sun, Jul 15, 2018 at 2:34 PM, Shakeel Butt wrote:
> >> > On Sat, Jul 14, 2018 at 10:26 PM Yafang Shao
> >> > wrote:
On Sun, Jul 15, 2018 at 6:50 PM Yafang Shao wrote:
>
> On Sun, Jul 15, 2018 at 11:04 PM, Shakeel Butt wrote:
> > On Sun, Jul 15, 2018 at 1:02 AM Yafang Shao wrote:
> >>
> >> On Sun, Jul 15, 2018 at 2:34 PM, Shakeel Butt wrote:
> >> > On Sat, Jul 14, 2018 at 10:26 PM Yafang Shao
> >> > wrote:
On Thu, 12 Jul 2018, at 05:51, Rob Herring wrote:
> On Wed, Jul 04, 2018 at 12:14:26PM +0300, Tomer Maimon wrote:
> > Added device tree binding documentation for Nuvoton BMC
> > NPCM7xx BIOS Post Code (BPC).
> > The NPCM7xx BPC monitoring two configurable I/O addresses
> > written by the host on
On Thu, 12 Jul 2018, at 05:51, Rob Herring wrote:
> On Wed, Jul 04, 2018 at 12:14:26PM +0300, Tomer Maimon wrote:
> > Added device tree binding documentation for Nuvoton BMC
> > NPCM7xx BIOS Post Code (BPC).
> > The NPCM7xx BPC monitoring two configurable I/O addresses
> > written by the host on
On Fri, Jul 13, 2018 at 07:58:25PM -0700, Linus Torvalds wrote:
> On Fri, Jul 13, 2018 at 6:51 PM Alan Stern wrote:
> >
> > The point being that the scenarios under discussion in this thread all
> > fall most definitely into the "Non-standard usage; you'd better know
> > exactly what you're
FYI, we noticed the following commit (built with gcc-4.9):
commit: 3f96d20fafb19e6dd869362ace53662b06e6f6c1 ("[PATCH] debugobjects:
Disable lockdep tracking of debugobjects internal locks")
url:
On Fri, Jul 13, 2018 at 07:58:25PM -0700, Linus Torvalds wrote:
> On Fri, Jul 13, 2018 at 6:51 PM Alan Stern wrote:
> >
> > The point being that the scenarios under discussion in this thread all
> > fall most definitely into the "Non-standard usage; you'd better know
> > exactly what you're
FYI, we noticed the following commit (built with gcc-4.9):
commit: 3f96d20fafb19e6dd869362ace53662b06e6f6c1 ("[PATCH] debugobjects:
Disable lockdep tracking of debugobjects internal locks")
url:
On Mon, Jul 16, 2018 at 12:03:39AM +0200, Ingo Molnar wrote:
>
> * Jann Horn wrote:
>
> > - A malicious user can pass an arbitrary file to a setuid binary as
> > stdin/stdout/stderr. When the setuid binary (expecting stdin/stdout to
> > be something normal, like a proper file or a pipe) then
On Mon, Jul 16, 2018 at 12:03:39AM +0200, Ingo Molnar wrote:
>
> * Jann Horn wrote:
>
> > - A malicious user can pass an arbitrary file to a setuid binary as
> > stdin/stdout/stderr. When the setuid binary (expecting stdin/stdout to
> > be something normal, like a proper file or a pipe) then
On Mon, Jul 16, 2018 at 11:23:43AM +1000, NeilBrown wrote:
>
> kmem_cache_free() directly. For this, I need rhashtable to be safe if
> an object is deleted and immediately re-inserted into the same hash
> chain.
This means that
rcu_read_lock();
A = rhashtable_lookup();
On Mon, Jul 16, 2018 at 11:23:43AM +1000, NeilBrown wrote:
>
> kmem_cache_free() directly. For this, I need rhashtable to be safe if
> an object is deleted and immediately re-inserted into the same hash
> chain.
This means that
rcu_read_lock();
A = rhashtable_lookup();
On 14 July 2018 at 14:29, Pavel Machek wrote:
>
>> @@ -446,4 +455,14 @@ static inline void
>> led_classdev_notify_brightness_hw_changed(
>> struct led_classdev *led_cdev, enum led_brightness brightness) { }
>> #endif
>>
>> +/**
>> + * struct led_pattern - brigheness value in a pattern
>
>
On 14 July 2018 at 14:29, Pavel Machek wrote:
>
>> @@ -446,4 +455,14 @@ static inline void
>> led_classdev_notify_brightness_hw_changed(
>> struct led_classdev *led_cdev, enum led_brightness brightness) { }
>> #endif
>>
>> +/**
>> + * struct led_pattern - brigheness value in a pattern
>
>
On 2018/7/13 4:34, Hamish Martin wrote:
Hi Xiubo,
Tested-by: Hamish Martin
I see these were already merged into Linus' tree but I wanted to let you
know that I tested v4.18-rc4 (which contains these three patches) and
the issue which led to my original series is still fixed and this patch
On 2018/7/13 4:34, Hamish Martin wrote:
Hi Xiubo,
Tested-by: Hamish Martin
I see these were already merged into Linus' tree but I wanted to let you
know that I tested v4.18-rc4 (which contains these three patches) and
the issue which led to my original series is still fixed and this patch
On 2018/7/14 20:47, Dominique Martinet wrote:
> jiangyiwen wrote on Sat, Jul 14, 2018:
>> On 2018/7/14 17:05, Dominique Martinet wrote:
>>> jiangyiwen wrote on Sat, Jul 14, 2018:
When client has multiple threads that issue io requests all the
time, and the server has a very good
On 2018/7/14 20:47, Dominique Martinet wrote:
> jiangyiwen wrote on Sat, Jul 14, 2018:
>> On 2018/7/14 17:05, Dominique Martinet wrote:
>>> jiangyiwen wrote on Sat, Jul 14, 2018:
When client has multiple threads that issue io requests all the
time, and the server has a very good
On Sun, Jul 15, 2018 at 11:04 PM, Shakeel Butt wrote:
> On Sun, Jul 15, 2018 at 1:02 AM Yafang Shao wrote:
>>
>> On Sun, Jul 15, 2018 at 2:34 PM, Shakeel Butt wrote:
>> > On Sat, Jul 14, 2018 at 10:26 PM Yafang Shao wrote:
>> >>
>> >> On Sun, Jul 15, 2018 at 12:25 PM, Shakeel Butt
>> >>
On Sun, Jul 15, 2018 at 11:04 PM, Shakeel Butt wrote:
> On Sun, Jul 15, 2018 at 1:02 AM Yafang Shao wrote:
>>
>> On Sun, Jul 15, 2018 at 2:34 PM, Shakeel Butt wrote:
>> > On Sat, Jul 14, 2018 at 10:26 PM Yafang Shao wrote:
>> >>
>> >> On Sun, Jul 15, 2018 at 12:25 PM, Shakeel Butt
>> >>
On Sun, Jul 15, 2018 at 6:33 PM Jann Horn wrote:
>
> +Linus, Andy, Al from the other thread
>
> On Mon, Jul 16, 2018 at 12:03 AM Ingo Molnar wrote:
> >
> > BTW., a naive question: would it make sense to simply disallow 'special'
> > fds to be passed to setuid binaries, and fix any user-space
On Sun, Jul 15, 2018 at 6:33 PM Jann Horn wrote:
>
> +Linus, Andy, Al from the other thread
>
> On Mon, Jul 16, 2018 at 12:03 AM Ingo Molnar wrote:
> >
> > BTW., a naive question: would it make sense to simply disallow 'special'
> > fds to be passed to setuid binaries, and fix any user-space
+Linus, Andy, Al from the other thread
On Mon, Jul 16, 2018 at 12:03 AM Ingo Molnar wrote:
> * Jann Horn wrote:
>
> > - A malicious user can pass an arbitrary file to a setuid binary as
> > stdin/stdout/stderr. When the setuid binary (expecting stdin/stdout to
> > be something normal, like a
+Linus, Andy, Al from the other thread
On Mon, Jul 16, 2018 at 12:03 AM Ingo Molnar wrote:
> * Jann Horn wrote:
>
> > - A malicious user can pass an arbitrary file to a setuid binary as
> > stdin/stdout/stderr. When the setuid binary (expecting stdin/stdout to
> > be something normal, like a
Hi Dominique,
On 2018/7/12 15:01, Dominique Martinet wrote:
> piaojun wrote on Thu, Jul 12, 2018:
>> In p9_read_work(), we use spin_lock for client->lock, but misuse
>> spin_lock_irqsave for it in p9_fid_create(). As p9_client lock won't be
>> locked in irq context, so spin_lock is enough. And
Hi Dominique,
On 2018/7/12 15:01, Dominique Martinet wrote:
> piaojun wrote on Thu, Jul 12, 2018:
>> In p9_read_work(), we use spin_lock for client->lock, but misuse
>> spin_lock_irqsave for it in p9_fid_create(). As p9_client lock won't be
>> locked in irq context, so spin_lock is enough. And
On Mon, Jul 16 2018, Herbert Xu wrote:
> On Mon, Jul 16, 2018 at 09:57:11AM +1000, NeilBrown wrote:
>>
>> Some users of rhashtable might need to change the key
>> of an object and move it to a different location in the table.
>> Other users might want to allocate objects using
>>
On Mon, Jul 16 2018, Herbert Xu wrote:
> On Mon, Jul 16, 2018 at 09:57:11AM +1000, NeilBrown wrote:
>>
>> Some users of rhashtable might need to change the key
>> of an object and move it to a different location in the table.
>> Other users might want to allocate objects using
>>
* Rik van Riel wrote:
> On Mon, 2018-07-16 at 00:59 +0200, Ingo Molnar wrote:
> > * Rik van Riel wrote:
> >
> > > The mm_struct always contains a cpumask bitmap, regardless of
> > > CONFIG_CPUMASK_OFFSTACK. That means the first step can be to
> > > simplify things, and simply have one
* Rik van Riel wrote:
> On Mon, 2018-07-16 at 00:59 +0200, Ingo Molnar wrote:
> > * Rik van Riel wrote:
> >
> > > The mm_struct always contains a cpumask bitmap, regardless of
> > > CONFIG_CPUMASK_OFFSTACK. That means the first step can be to
> > > simplify things, and simply have one
* Rik van Riel wrote:
> On Mon, 2018-07-16 at 01:04 +0200, Ingo Molnar wrote:
> > * Rik van Riel wrote:
> >
> > > + /*
> > > + * Stop remote flushes for the previous mm.
> > > + * Skip the idle task; we never send init_mm TLB
> > > flushing IPIs,
> > > + *
* Rik van Riel wrote:
> On Mon, 2018-07-16 at 01:04 +0200, Ingo Molnar wrote:
> > * Rik van Riel wrote:
> >
> > > + /*
> > > + * Stop remote flushes for the previous mm.
> > > + * Skip the idle task; we never send init_mm TLB
> > > flushing IPIs,
> > > + *
* Prakhya, Sai Praneeth wrote:
> > > diff --git a/arch/x86/platform/efi/quirks.c
> > > b/arch/x86/platform/efi/quirks.c index 36c1f8b9f7e0..6af39dc40325
> > > 100644
> > > --- a/arch/x86/platform/efi/quirks.c
> > > +++ b/arch/x86/platform/efi/quirks.c
> > > @@ -105,12 +105,11 @@
* Prakhya, Sai Praneeth wrote:
> > > diff --git a/arch/x86/platform/efi/quirks.c
> > > b/arch/x86/platform/efi/quirks.c index 36c1f8b9f7e0..6af39dc40325
> > > 100644
> > > --- a/arch/x86/platform/efi/quirks.c
> > > +++ b/arch/x86/platform/efi/quirks.c
> > > @@ -105,12 +105,11 @@
On 07/15/2018 07:22 AM, Jacek Anaszewski wrote:
On 07/15/2018 12:39 AM, Pavel Machek wrote:
On Sun 2018-07-15 00:29:25, Pavel Machek wrote:
On Sun 2018-07-15 00:02:57, Jacek Anaszewski wrote:
Hi Pavel,
On 07/14/2018 11:20 PM, Pavel Machek wrote:
Hi!
It also drew my attention to the issue
On 07/15/2018 07:22 AM, Jacek Anaszewski wrote:
On 07/15/2018 12:39 AM, Pavel Machek wrote:
On Sun 2018-07-15 00:29:25, Pavel Machek wrote:
On Sun 2018-07-15 00:02:57, Jacek Anaszewski wrote:
Hi Pavel,
On 07/14/2018 11:20 PM, Pavel Machek wrote:
Hi!
It also drew my attention to the issue
Hi Alexander,
I've rearranged your reply slightly :)
On Sat, 14 Jul 2018, at 00:44, Alexander Amelkin wrote:
>
> So I'm writing this to support your position in this discussion and to
> let Rob and other reviewers know that this feature is actually needed.
Thanks.
So to summarise some other
Hi Alexander,
I've rearranged your reply slightly :)
On Sat, 14 Jul 2018, at 00:44, Alexander Amelkin wrote:
>
> So I'm writing this to support your position in this discussion and to
> let Rob and other reviewers know that this feature is actually needed.
Thanks.
So to summarise some other
On Mon, Jul 16, 2018 at 09:57:11AM +1000, NeilBrown wrote:
>
> Some users of rhashtable might need to change the key
> of an object and move it to a different location in the table.
> Other users might want to allocate objects using
> SLAB_TYPESAFE_BY_RCU which can result in the same memory
On Mon, Jul 16, 2018 at 09:57:11AM +1000, NeilBrown wrote:
>
> Some users of rhashtable might need to change the key
> of an object and move it to a different location in the table.
> Other users might want to allocate objects using
> SLAB_TYPESAFE_BY_RCU which can result in the same memory
1 - 100 of 488 matches
Mail list logo
