Hi all,
Kindly ping :)!
Are there any further comments for this v4 series? Please let me know if
there
is still something that needs fixing.
Or is this v4 series fine enough to be queued? Most of the patches have been
added with Reviewed-by. If there are merge conflicts with the newest
Hi,
This v4 series can mainly include two parts.
Based on kvm queue branch:
https://git.kernel.org/pub/scm/virt/kvm/kvm.git/log/?h=queue
Links of v1:
https://lore.kernel.org/lkml/20210208090841.333724-1-wangyana...@huawei.com/
Links of v2:
On (09/06/19 16:01), Peter Zijlstra wrote:
> In fact, i've gotten output that is plain impossible with
> the current junk.
Peter, can you post any of those backtraces? Very curious.
-ss
On Fri, Sep 06, 2019 at 04:01:26PM +0200, Peter Zijlstra wrote:
> On Fri, Sep 06, 2019 at 02:42:11PM +0200, Petr Mladek wrote:
> > 7. People would complain when continuous lines become less
> >reliable. It might be most visible when mixing backtraces
> >from all CPUs. Simple sorting by
On 2019-09-06, Peter Zijlstra wrote:
>> I wish it was that simple. It is possible that I see it too
>> complicated. But this comes to my mind:
>>
>> 1. The simple printk_buffer_store(buf, n) is not NMI safe. For this,
>>we might need the reserve-store approach.
>
> Of course it is, and sure
On (09/06/19 16:01), Peter Zijlstra wrote:
> > 2. The simple approach works only with lockless consoles. We need
> >something else for the rest at least for NMI. Simle offloading
> >to a kthread has been blocked for years. People wanted the
> >trylock-and-flush-immediately approach.
>
On Fri, Sep 06, 2019 at 04:01:26PM +0200, Peter Zijlstra wrote:
> On Fri, Sep 06, 2019 at 02:42:11PM +0200, Petr Mladek wrote:
> > 7. People would complain when continuous lines become less
> >reliable. It might be most visible when mixing backtraces
> >from all CPUs. Simple sorting by
On Fri, Sep 06, 2019 at 02:42:11PM +0200, Petr Mladek wrote:
> I wish it was that simple. It is possible that I see it too
> complicated. But this comes to my mind:
>
> 1. The simple printk_buffer_store(buf, n) is not NMI safe. For this,
>we might need the reserve-store approach.
Of course
On (09/06/19 12:49), Peter Zijlstra wrote:
> On Fri, Sep 06, 2019 at 07:09:43PM +0900, Sergey Senozhatsky wrote:
>
> > ---
> > diff --git a/kernel/printk/printk_safe.c b/kernel/printk/printk_safe.c
> > index 139c310049b1..9c73eb6259ce 100644
> > --- a/kernel/printk/printk_safe.c
> > +++
On Fri 2019-09-06 11:06:27, Peter Zijlstra wrote:
> On Thu, Sep 05, 2019 at 04:31:18PM +0200, Peter Zijlstra wrote:
> > So I have something roughly like the below; I'm suggesting you add the
> > line with + on:
> >
> > int early_vprintk(const char *fmt, va_list args)
> > {
> > char
On Fri, Sep 06, 2019 at 07:09:43PM +0900, Sergey Senozhatsky wrote:
> ---
> diff --git a/kernel/printk/printk_safe.c b/kernel/printk/printk_safe.c
> index 139c310049b1..9c73eb6259ce 100644
> --- a/kernel/printk/printk_safe.c
> +++ b/kernel/printk/printk_safe.c
> @@ -103,7 +103,10 @@ static
On (09/06/19 11:06), Peter Zijlstra wrote:
> Another approach is something like:
>
> DEFINE_PER_CPU(int, printk_nest);
> DEFINE_PER_CPU(char, printk_line[4][256]);
>
> int vprintk(const char *fmt, va_list args)
> {
> int c, n, i;
> char *buf;
>
> preempt_disable();
> i =
On Thu 2019-09-05 12:11:01, Steven Rostedt wrote:
>
> [ Added Ted and Linux Plumbers ]
>
> On Thu, 5 Sep 2019 17:38:21 +0200 (CEST)
> Thomas Gleixner wrote:
>
> > On Thu, 5 Sep 2019, Peter Zijlstra wrote:
> > > On Thu, Sep 05, 2019 at 03:05:13PM +0200, Petr Mladek wrote:
> > > > The
On Thu, Sep 05, 2019 at 04:31:18PM +0200, Peter Zijlstra wrote:
> So I have something roughly like the below; I'm suggesting you add the
> line with + on:
>
> int early_vprintk(const char *fmt, va_list args)
> {
> char buf[256]; // teh suck!
> int old, n = vscnprintf(buf,
On 2019-09-05, Steven Rostedt wrote:
>>> But per the above argument of needing the CPU serialization
>>> _anyway_, I don't see a compelling reason not to use it.
>>>
>>> It is simple, it works. Let's use it.
>>>
>>> If you really fancy a multi-writer buffer, you can always switch to
>>> one
[ Added Ted and Linux Plumbers ]
On Thu, 5 Sep 2019 17:38:21 +0200 (CEST)
Thomas Gleixner wrote:
> On Thu, 5 Sep 2019, Peter Zijlstra wrote:
> > On Thu, Sep 05, 2019 at 03:05:13PM +0200, Petr Mladek wrote:
> > > The alternative lockless approach is still more complicated than
> > > the
On Thu, 5 Sep 2019, Peter Zijlstra wrote:
> On Thu, Sep 05, 2019 at 03:05:13PM +0200, Petr Mladek wrote:
> > The alternative lockless approach is still more complicated than
> > the serialized one. But I think that it is manageable thanks to
> > the simplified state tracking. And I might safe use
On Thu, Sep 05, 2019 at 03:05:13PM +0200, Petr Mladek wrote:
> The serialized approach used a lock. It was re-entrant and thus less
> error-prone but still a lock.
>
> The lock was planed to be used not only to access the buffer but also
> for eventual locking inside lockless consoles. It might
On Wed 2019-09-04 14:35:31, Peter Zijlstra wrote:
> On Thu, Aug 08, 2019 at 12:32:25AM +0206, John Ogness wrote:
> > Hello,
> >
> > This is a follow-up RFC on the work to re-implement much of
> > the core of printk. The threads for the previous RFC versions
> > are here: v1[0], v2[1], v3[2].
> >
On Thu, Aug 08, 2019 at 12:32:25AM +0206, John Ogness wrote:
> Hello,
>
> This is a follow-up RFC on the work to re-implement much of
> the core of printk. The threads for the previous RFC versions
> are here: v1[0], v2[1], v3[2].
>
> This series only builds upon v3 (i.e. the first part of this
Hello,
This is a follow-up RFC on the work to re-implement much of
the core of printk. The threads for the previous RFC versions
are here: v1[0], v2[1], v3[2].
This series only builds upon v3 (i.e. the first part of this
series is exactly v3). The main purpose of this series is to
replace the
On 08/06/2015 04:31 PM, Shawn Lin wrote:
> 在 2015/8/6 15:08, Jaehoon Chung 写道:
>> Hi, Shawn.
>>
>> I remembered that Krzysztof has mentioned "Fix the title of cover letter."
>> Your cover letter's title is nothing.. "[RFC PATCH v4 0/9] " ??
>>
在 2015/8/6 15:08, Jaehoon Chung 写道:
Hi, Shawn.
I remembered that Krzysztof has mentioned "Fix the title of cover letter."
Your cover letter's title is nothing.. "[RFC PATCH v4 0/9] " ??
[RFC PATCH v4 0/9] your title...
Sorry, I forgot it, and will fix in next versi
Hi, Shawn.
I remembered that Krzysztof has mentioned "Fix the title of cover letter."
Your cover letter's title is nothing.. "[RFC PATCH v4 0/9] " ??
[RFC PATCH v4 0/9] your title...
Best Regards,
Jaehoon Chung
On 08/06/2015 03:44 PM, Shawn Lin wrote:
> Add external d
Add external dma support for Synopsys MSHC
Synopsys DesignWare mobile storage host controller supports three
types of transfer mode: pio, internal dma and external dma. However,
dw_mmc can only supports pio and internal dma now. Thus some platforms
using dw-mshc integrated with generic dma can't
Add external dma support for Synopsys MSHC
Synopsys DesignWare mobile storage host controller supports three
types of transfer mode: pio, internal dma and external dma. However,
dw_mmc can only supports pio and internal dma now. Thus some platforms
using dw-mshc integrated with generic dma can't
Hi, Shawn.
I remembered that Krzysztof has mentioned Fix the title of cover letter.
Your cover letter's title is nothing.. [RFC PATCH v4 0/9] ??
[RFC PATCH v4 0/9] your title...
Best Regards,
Jaehoon Chung
On 08/06/2015 03:44 PM, Shawn Lin wrote:
Add external dma support for Synopsys MSHC
在 2015/8/6 15:08, Jaehoon Chung 写道:
Hi, Shawn.
I remembered that Krzysztof has mentioned Fix the title of cover letter.
Your cover letter's title is nothing.. [RFC PATCH v4 0/9] ??
[RFC PATCH v4 0/9] your title...
Sorry, I forgot it, and will fix in next version...
Best Regards,
Jaehoon
On 08/06/2015 04:31 PM, Shawn Lin wrote:
在 2015/8/6 15:08, Jaehoon Chung 写道:
Hi, Shawn.
I remembered that Krzysztof has mentioned Fix the title of cover letter.
Your cover letter's title is nothing.. [RFC PATCH v4 0/9] ??
[RFC PATCH v4 0/9] your title...
Sorry, I forgot it, and will fix
Hi,
This patchset removes CPU hotplug's dependence on stop_machine() from the CPU
offline path and provides an alternative (set of APIs) to preempt_disable() to
prevent CPUs from going offline, which can be invoked from atomic context.
This is an RFC patchset with only a few call-sites of
Hi,
This patchset removes CPU hotplug's dependence on stop_machine() from the CPU
offline path and provides an alternative (set of APIs) to preempt_disable() to
prevent CPUs from going offline, which can be invoked from atomic context.
This is an RFC patchset with only a few call-sites of
31 matches
Mail list logo
