date:20210228

Re: [PATCH 08/11] pragma once: convert scripts/atomic/

2021-02-28 Thread Peter Zijlstra

On Sun, Feb 28, 2021 at 08:03:18PM +0300, Alexey Dobriyan wrote:
> From f10fe79897fa9600f144c76bc5df52dba28b7a66 Mon Sep 17 00:00:00 2001
> From: Alexey Dobriyan 
> Date: Tue, 9 Feb 2021 01:37:55 +0300
> Subject: [PATCH 08/11] pragma once: convert scripts/atomic/
> 
> Generate atomic headers without include guards.

-ENOCONTEXT, why ?

Re: [PATCH] mm: Generalize HUGETLB_PAGE_SIZE_VARIABLE

2021-02-28 Thread Christoph Hellwig

On Mon, Mar 01, 2021 at 01:13:41PM +0530, Anshuman Khandual wrote:
> > doesn't this need a 'if HUGETLB_PAGE'
> 
> While making HUGETLB_PAGE_SIZE_VARIABLE a generic option, also made it
> dependent on HUGETLB_PAGE. Should not that gate HUGETLB_PAGE_SIZE_VARIABLE
> when HUGETLB_PAGE is not available irrespective of the select statement on
> the platforms ?

depends doesn't properly work for variables that are selected.

Re: [PATCH] vdpa/mlx5: Fix wrong use of bit numbers

2021-02-28 Thread Jason Wang




On 2021/3/1 2:28 下午, Eli Cohen wrote:

VIRTIO_F_VERSION_1 is a bit number. Use BIT_ULL() with mask
conditionals.

Also, in mlx5_vdpa_is_little_endian() use BIT_ULL for consistency with
the rest of the code.

Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported mlx5 devices")
Signed-off-by: Eli Cohen 



Acked-by: Jason Wang 



---
  drivers/vdpa/mlx5/net/mlx5_vnet.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c 
b/drivers/vdpa/mlx5/net/mlx5_vnet.c
index dc7031132fff..7d21b857a94a 100644
--- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
+++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
@@ -821,7 +821,7 @@ static int create_virtqueue(struct mlx5_vdpa_net *ndev, 
struct mlx5_vdpa_virtque
MLX5_SET(virtio_q, vq_ctx, event_qpn_or_msix, mvq->fwqp.mqp.qpn);
MLX5_SET(virtio_q, vq_ctx, queue_size, mvq->num_ent);
MLX5_SET(virtio_q, vq_ctx, virtio_version_1_0,
-!!(ndev->mvdev.actual_features & VIRTIO_F_VERSION_1));
+!!(ndev->mvdev.actual_features & BIT_ULL(VIRTIO_F_VERSION_1)));
MLX5_SET64(virtio_q, vq_ctx, desc_addr, mvq->desc_addr);
MLX5_SET64(virtio_q, vq_ctx, used_addr, mvq->device_addr);
MLX5_SET64(virtio_q, vq_ctx, available_addr, mvq->driver_addr);
@@ -1578,7 +1578,7 @@ static void teardown_virtqueues(struct mlx5_vdpa_net 
*ndev)
  static inline bool mlx5_vdpa_is_little_endian(struct mlx5_vdpa_dev *mvdev)
  {
return virtio_legacy_is_little_endian() ||
-   (mvdev->actual_features & (1ULL << VIRTIO_F_VERSION_1));
+   (mvdev->actual_features & BIT_ULL(VIRTIO_F_VERSION_1));
  }
  
  static __virtio16 cpu_to_mlx5vdpa16(struct mlx5_vdpa_dev *mvdev, u16 val)

Re: [PATCH] dts: remove c6x dts hard link file

2021-02-28 Thread Geert Uytterhoeven

Hi Wolfram,

On Mon, Mar 1, 2021 at 7:28 AM Wolfram Sang
 wrote:
> The architecture has gone and indexing software like 'mkid' complains
> about the broken link.
>
> Signed-off-by: Wolfram Sang 

Thanks for your patch!

With s/hard/symbolic/ in the oneline-summary:
Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH] perf trace: Ensure read cmdlines are null terminated.

2021-02-28 Thread Namhyung Kim

Hi Ian,

On Sat, Feb 27, 2021 at 7:14 AM Ian Rogers  wrote:
>
> Issue detected by address sanitizer.
>
> Fixes: cd4ceb63438e (perf util: Save pid-cmdline mapping into tracing header)
> Signed-off-by: Ian Rogers 

Acked-by: Namhyung Kim 

Thanks,
Namhyung

> ---
>  tools/perf/util/trace-event-read.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/tools/perf/util/trace-event-read.c 
> b/tools/perf/util/trace-event-read.c
> index f507dff713c9..8a01af783310 100644
> --- a/tools/perf/util/trace-event-read.c
> +++ b/tools/perf/util/trace-event-read.c
> @@ -361,6 +361,7 @@ static int read_saved_cmdline(struct tep_handle *pevent)
> pr_debug("error reading saved cmdlines\n");
> goto out;
> }
> +   buf[ret] = '\0';
>
> parse_saved_cmdline(pevent, buf, size);
> ret = 0;
> --
> 2.30.1.766.gb4fecdf3b7-goog
>

Re: [PATCH] mm: Generalize HUGETLB_PAGE_SIZE_VARIABLE

2021-02-28 Thread Anshuman Khandual




On 3/1/21 11:53 AM, Christoph Hellwig wrote:
> On Mon, Mar 01, 2021 at 11:20:53AM +0530, Anshuman Khandual wrote:
>> HUGETLB_PAGE_SIZE_VARIABLE need not be defined for each individual
>> platform subscribing it. Instead just make it generic.
>>
>> Cc: Michael Ellerman 
>> Cc: Benjamin Herrenschmidt 
>> Cc: Paul Mackerras 
>> Cc: Andrew Morton 
>> Cc: Christoph Hellwig 
>> Cc: linux-i...@vger.kernel.org
>> Cc: linuxppc-...@lists.ozlabs.org
>> Cc: linux...@kvack.org
>> Cc: linux-kernel@vger.kernel.org
>> Suggested-by: Christoph Hellwig 
>> Signed-off-by: Anshuman Khandual 
>> ---
>> This change was originally suggested in an earilier discussion. This
>> applies on v5.12-rc1 and has been build tested on all applicable
>> platforms i.e ia64 and powerpc.
>>
>> https://patchwork.kernel.org/project/linux-mm/patch/1613024531-19040-3-git-send-email-anshuman.khand...@arm.com/
>>
>>  arch/ia64/Kconfig| 6 +-
>>  arch/powerpc/Kconfig | 6 +-
>>  mm/Kconfig   | 8 
>>  3 files changed, 10 insertions(+), 10 deletions(-)
>>
>> diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
>> index 2ad7a8d29fcc..6b3e3f6c29ae 100644
>> --- a/arch/ia64/Kconfig
>> +++ b/arch/ia64/Kconfig
>> @@ -32,6 +32,7 @@ config IA64
>>  select TTY
>>  select HAVE_ARCH_TRACEHOOK
>>  select HAVE_VIRT_CPU_ACCOUNTING
>> +select HUGETLB_PAGE_SIZE_VARIABLE
> 
> doesn't this need a 'if HUGETLB_PAGE'

While making HUGETLB_PAGE_SIZE_VARIABLE a generic option, also made it
dependent on HUGETLB_PAGE. Should not that gate HUGETLB_PAGE_SIZE_VARIABLE
when HUGETLB_PAGE is not available irrespective of the select statement on
the platforms ?

> 
> or did you verify that HUGETLB_PAGE_SIZE_VARIABLE checks are always
> nested inside of HUGETLB_PAGE ones?
>

Re: [GIT PULL] Driver core / debugfs changes for 5.12-rc1

2021-02-28 Thread Saravana Kannan

On Sat, Feb 27, 2021 at 6:27 AM Greg KH  wrote:
>
> On Wed, Feb 24, 2021 at 10:20:44AM -0800, Linus Torvalds wrote:
> > On Wed, Feb 24, 2021 at 6:27 AM Greg KH  wrote:
> > >
> > >  [..] I've reverted that change at
> > > the very end so we don't have to worry about regressions in 5.12.
> >
> > Side note: it would have been really nice to see links to the actual
> > problem reports in the revert commit.
>
> Odd, this showed up in my gmail spam folder, just saw this now :(

Yup, went to spam for me too!

> > Yes, there's a "Link:" line there, but that points to the
> > less-than-useful patch submission for the revert, not to the actual
> > _reasons_ for the revert.
> >
> > Now I'm looking at that revert, and I have absolutely no idea why it
> > happened. Only a very vague "there are still reported regressions
> > happening".
> >
> > I've pulled it, but wanted to just point out that when there's some
> > fairly fundamental revert like this, it really would be good to link
> > to the problems, so that when people try to re-enable it, they have
> > the history for why it didn't work the first time.
> >
> > Now all that history is basically lost (well, hopefully Saravana and
> > you actually remember, but you get my point).
>
> Sorry, the history is on the original commit Link that was reverted, and
> in lots of other emails on lkml over the past few weeks.  Next time I'll
> include links to those threads as well.

These are links of interest. All the fixes are at least linked to from
these two threads. And if they are not, they all mention "Fixes" and
list the commit that was reverted. So it's all trackable if we really
find the need to do so in the future.

The original series that set fw_devlink=on where most of the issues
were reported.
[1] - 
https://lore.kernel.org/lkml/20201218031703.3053753-1-sarava...@google.com/

This is the series that made fw_devlink=on more forgiving. And a few
issues were reported there.
[2] - 
https://lore.kernel.org/lkml/20210205222644.2357303-1-sarava...@google.com/

To summarize, the issues fell into one of these types:
* Drivers would initialize the hardware without actually probing a
struct device that existed AND didn't use the existing mechanisms (Eg:
IRQCHIP_DECLARE) meant to allow this. So fw_devlink makes their
consumers wait forever. Bunch of driver fixes for this, but [2] also
workaround most of these by making fw_devlink/fwnode code a bit
smarter.
* Drivers would initialize the hardware without creating a struct
device at all despite the DT node having a compatible property. [2]
handles this by making fw_devlink a bit smarter.
* Some device link status not getting updated correctly when a driver
is force bound with a device (I know the fix, haven't gotten around to
submitting it).
* fw_devlink causing some probe reordering that should technically be
harmless (all suppliers probed before the consumer), but drivers still
don't like it. Bunch of fixes + reducing/removing unnecessary
reordering of probes by fw_devlink (latter is under review).
* Spinlock/corruption errors that fw_devlink exposed by reordering
some probes, but the actual issue was unrelated to fw_devlink.

So it was a mix of making fw_devlink smarter to deal with existing
code and fixing some drivers.

Thanks,
Saravana

Re: Re: [PATCH] iwlegacy: Add missing check in il4965_commit_rxon

2021-02-28 Thread dinghao . liu

> On Sun, Feb 28, 2021 at 08:25:22PM +0800, Dinghao Liu wrote:
> > There is one il_set_tx_power() call in this function without
> > return value check. Print error message and return error code
> > on failure just like the other il_set_tx_power() call.
> 
> We have few calls for il_set_tx_power(), on some cases we
> check return on some not. That correct as setting tx power
> can be deferred internally if not possible at the moment.
> 
> > Signed-off-by: Dinghao Liu 
> > ---
> >  drivers/net/wireless/intel/iwlegacy/4965.c | 6 +-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/net/wireless/intel/iwlegacy/4965.c 
> > b/drivers/net/wireless/intel/iwlegacy/4965.c
> > index 9fa556486511..3235b8be1894 100644
> > --- a/drivers/net/wireless/intel/iwlegacy/4965.c
> > +++ b/drivers/net/wireless/intel/iwlegacy/4965.c
> > @@ -1361,7 +1361,11 @@ il4965_commit_rxon(struct il_priv *il)
> >  * We do not commit tx power settings while channel changing,
> >  * do it now if tx power changed.
> >  */
> > -   il_set_tx_power(il, il->tx_power_next, false);
> > +   ret = il_set_tx_power(il, il->tx_power_next, false);
> > +   if (ret) {
> > +   IL_ERR("Error sending TX power (%d)\n", ret);
> > +   return ret;
> > +   
> 
> This is not good change. We do not check return value of
> il_commit_rxon(), except when creating interface. So this change might
> broke creating interface, what worked otherwise when il_set_tx_power()
> returned error.
> 

It's clear to me, Thanks for your explanation!

Regards,
Dinghao

[PATCH] sata_dwc_460ex: Fix missing check in sata_dwc_isr

2021-02-28 Thread Dinghao Liu

ata_qc_from_tag() may return a null pointer and further lead to
null-pointer-dereference. Add a return value check to avoid such case.

Signed-off-by: Dinghao Liu 
---
 drivers/ata/sata_dwc_460ex.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/ata/sata_dwc_460ex.c b/drivers/ata/sata_dwc_460ex.c
index 9dcef6ac643b..0068247ffc06 100644
--- a/drivers/ata/sata_dwc_460ex.c
+++ b/drivers/ata/sata_dwc_460ex.c
@@ -548,8 +548,10 @@ static irqreturn_t sata_dwc_isr(int irq, void 
*dev_instance)
 * active tag.  It is the tag that matches the command about to
 * be completed.
 */
-   qc->ap->link.active_tag = tag;
-   sata_dwc_bmdma_start_by_tag(qc, tag);
+   if (qc) {
+   qc->ap->link.active_tag = tag;
+   sata_dwc_bmdma_start_by_tag(qc, tag);
+   }
 
handled = 1;
goto DONE;
-- 
2.17.1

Re: [PATCH v2 2/3] mm: Force update of mem cgroup soft limit tree on usage excess

2021-02-28 Thread Michal Hocko

On Fri 26-02-21 16:56:28, Tim Chen wrote:
> 
> 
> On 2/26/21 12:52 AM, Michal Hocko wrote:
> 
> >>
> >> Michal,
> >>
> >> Let's take an extreme case where memcg 1 always generate the
> >> first event and memcg 2 generates the rest of 128*8-1 events
> >> and the pattern repeat.
> > 
> > I do not follow. Events are per-memcg, aren't they?
> > __this_cpu_read(memcg->vmstats_percpu->targets[target]);
> > [...]
> > __this_cpu_write(memcg->vmstats_percpu->targets[target], next);
> > 
> 
> You are right. My previous reasoning is incorrect as the sampling is done per 
> memcg.
> I'll do some additional debugging on why memcg is not on the tree.

OK, thanks for the confirmation. I think we want to do 2 things. Remove
the soft limit specific threshold and stay with a single one and
recognize THPs.
-- 
Michal Hocko
SUSE Labs

Re: Question about the "EXPERIMENTAL" tag for dax in XFS

2021-02-28 Thread Yasunori Goto

Hello, Dan-san,

On 2021/02/27 4:24, Dan Williams wrote:

On Fri, Feb 26, 2021 at 11:05 AM Darrick J. Wong wrote:

On Fri, Feb 26, 2021 at 09:45:45AM +, ruansy.f...@fujitsu.com wrote:

Hi, guys

Beside this patchset, I'd like to confirm something about the
"EXPERIMENTAL" tag for dax in XFS.

In XFS, the "EXPERIMENTAL" tag, which is reported in waring message
when we mount a pmem device with dax option, has been existed for a
while. It's a bit annoying when using fsdax feature. So, my initial
intention was to remove this tag. And I started to find out and solve
the problems which prevent it from being removed.

As is talked before, there are 3 main problems. The first one is "dax
semantics", which has been resolved. The rest two are "RMAP for
fsdax" and "support dax reflink for filesystem", which I have been
working on.

So, what I want to confirm is: does it means that we can remove the
"EXPERIMENTAL" tag when the rest two problem are solved?

Yes. I'd keep the experimental tag for a cycle or two to make sure that
nothing new pops up, but otherwise the two patchsets you've sent close
those two big remaining gaps. Thank you for working on this!

Or maybe there are other important problems need to be fixed before
removing it? If there are, could you please show me that?

That remains to be seen through QA/validation, but I think that's it.

Granted, I still have to read through the two patchsets...

I've been meaning to circle back here as well.

My immediate concern is the issue Jason recently highlighted [1] with
respect to invalidating all dax mappings when / if the device is
ripped out from underneath the fs. I don't think that will collide
with Ruan's implementation, but it does need new communication from
driver to fs about removal events.

[1]:
http://lore.kernel.org/r/capcyv4i+pzhyziepf2pah0dt5jdfkmkdx-3usqy1fahf6lp...@mail.gmail.com

I'm not sure why there is a race condition between unbinding operation
and accessing mmaped file on filesystem dax yet.

May be silly question, but could you tell me why the "unbinding"
operation of the namespace which is mounted by filesystem dax must be

allowed?
If "unbinding" is rejected when the filesystem is mounted with dax
enabled, what is inconvenience?

I can imagine if a device like usb memory stick is removed surprisingly,
kernel/filesystem need to reject writeback at the time, and discard page
cache. Then, I can understand that unbinding operation is essential for
such case.
But I don't know why PMEM device/namespace allows unbinding operation
like surprising removal event.

1 2 3 4 >

1 - 100 of 362 matches

Mail list logo