Re: [PATCH v2 1/1] PCI: pciehp: Skip DLLSC handling if DPC is triggered

2021-03-27 Thread Kuppuswamy, Sathyanarayanan




On 3/16/21 9:13 PM, Lukas Wunner wrote:

On Fri, Mar 12, 2021 at 07:32:08PM -0800, 
sathyanarayanan.kuppusw...@linux.intel.com wrote:

+   if ((events == PCI_EXP_SLTSTA_DLLSC) && is_dpc_reset_active(pdev)) {
+   ctrl_info(ctrl, "Slot(%s): DLLSC event(DPC), skipped\n",
+ slot_name(ctrl));
+   ret = IRQ_HANDLED;
+   goto out;
+   }


Two problems here:

(1) If recovery fails, the link will *remain* down, so there'll be
 no Link Up event.  You've filtered the Link Down event, thus the
 slot will remain in ON_STATE even though the device in the slot is
 no longer accessible.  That's not good, the slot should be brought
 down in this case.

(2) If recovery succeeds, there's a race where pciehp may call
 is_dpc_reset_active() *after* dpc_reset_link() has finished.
 So both the DPC Trigger Status bit as well as pdev->dpc_reset_active
 will be cleared.  Thus, the Link Up event is not filtered by pciehp
 and the slot is brought down and back up even though DPC recovery
 was succesful, which seems undesirable.

The only viable solution I see is to wait until DPC has completed.
Sinan (+cc) proposed something along those lines a couple years back:

https://patchwork.ozlabs.org/project/linux-pci/patch/20180818065126.77912-1-ok...@kernel.org/

Included below please find my suggestion for how to fix this.
I've sort of combined yours and Sinan's approach, but I'm
using a waitqueue (Sinan used polling) and I'm using atomic bitops
on pdev->priv_flags (you're using an atomic_t instead, which needs
additionally space in struct pci_dev).  Note: It's compile-tested
only, I don't have any DPC-capable hardware at my disposal.

Would this work for you?  If so, I can add a commit message to the
patch and submit it properly.  Let me know what you think.  Thanks!





-- >8 --
Subject: [PATCH] PCI: pciehp: Ignore Link Down/Up caused by DPC

Signed-off-by: Lukas Wunner 
---
  drivers/pci/hotplug/pciehp_hpc.c | 11 +
  drivers/pci/pci.h|  4 
  drivers/pci/pcie/dpc.c   | 51 ++--
  3 files changed, 64 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/hotplug/pciehp_hpc.c b/drivers/pci/hotplug/pciehp_hpc.c
index fb3840e..bcc018e 100644
--- a/drivers/pci/hotplug/pciehp_hpc.c
+++ b/drivers/pci/hotplug/pciehp_hpc.c
@@ -707,6 +707,17 @@ static irqreturn_t pciehp_ist(int irq, void *dev_id)
}
  
  	/*

+* Ignore Link Down/Up caused by Downstream Port Containment
+* if recovery from the error succeeded.
+*/
+   if ((events & PCI_EXP_SLTSTA_DLLSC) && pci_dpc_recovered(pdev) &&
+   ctrl->state == ON_STATE) {
+   atomic_and(~PCI_EXP_SLTSTA_DLLSC, >pending_events);

Why modify pending_events here. It should be already be zero right?

+   if (pciehp_check_link_active(ctrl) > 0)
+   events &= ~PCI_EXP_SLTSTA_DLLSC;
+   }
+
+   /*
 * Disable requests have higher priority than Presence Detect Changed
 * or Data Link Layer State Changed events.
 */
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index 9684b46..e5ae5e8 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -392,6 +392,8 @@ static inline bool pci_dev_is_disconnected(const struct 
pci_dev *dev)
  
  /* pci_dev priv_flags */

  #define PCI_DEV_ADDED 0
+#define PCI_DPC_RECOVERED 1
+#define PCI_DPC_RECOVERING 2
  
  static inline void pci_dev_assign_added(struct pci_dev *dev, bool added)

  {
@@ -446,10 +448,12 @@ struct rcec_ea {
  void pci_dpc_init(struct pci_dev *pdev);
  void dpc_process_error(struct pci_dev *pdev);
  pci_ers_result_t dpc_reset_link(struct pci_dev *pdev);
+bool pci_dpc_recovered(struct pci_dev *pdev);
  #else
  static inline void pci_save_dpc_state(struct pci_dev *dev) {}
  static inline void pci_restore_dpc_state(struct pci_dev *dev) {}
  static inline void pci_dpc_init(struct pci_dev *pdev) {}
+static inline bool pci_dpc_recovered(struct pci_dev *pdev) { return false; }
  #endif
  
  #ifdef CONFIG_PCIEPORTBUS

diff --git a/drivers/pci/pcie/dpc.c b/drivers/pci/pcie/dpc.c
index e05aba8..7328d9c4 100644
--- a/drivers/pci/pcie/dpc.c
+++ b/drivers/pci/pcie/dpc.c
@@ -71,6 +71,44 @@ void pci_restore_dpc_state(struct pci_dev *dev)
pci_write_config_word(dev, dev->dpc_cap + PCI_EXP_DPC_CTL, *cap);
  }
  
+static bool dpc_completed(struct pci_dev *pdev)

+{
+   u16 status;
+
+   pci_read_config_word(pdev, pdev->dpc_cap + PCI_EXP_DPC_STATUS, );
+   if (status & PCI_EXP_DPC_STATUS_TRIGGER)
+   return false;
+
+   if (test_bit(PCI_DPC_RECOVERING, >priv_flags))
+   return false;
+
+   return true;
+}
+
+static DECLARE_WAIT_QUEUE_HEAD(dpc_completed_waitqueue);
+
+bool pci_dpc_recovered(struct pci_dev *pdev)
+{
+   struct pci_host_bridge *host;
+
+   if (!pdev->dpc_cap)
+   return false;
+
+   /*
+* 

[TRIVIAL] drm/amd/display: fix typo: liason -> liaison

2021-03-27 Thread Diego Viola
Signed-off-by: Diego Viola 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 573cf17262da..1b4b4f508662 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -121,7 +121,7 @@ MODULE_FIRMWARE(FIRMWARE_NAVI12_DMCU);
  * DOC: overview
  *
  * The AMDgpu display manager, **amdgpu_dm** (or even simpler,
- * **dm**) sits between DRM and DC. It acts as a liason, converting DRM
+ * **dm**) sits between DRM and DC. It acts as a liaison, converting DRM
  * requests into DC requests, and DC responses into DRM responses.
  *
  * The root control structure is  amdgpu_display_manager.
-- 
2.31.1



Re: [PATCH v1] Input: elants_i2c - fix division by zero if firmware reports zero phys size

2021-03-27 Thread Dmitry Torokhov
Hi Dmitry,

On Tue, Mar 02, 2021 at 01:08:24PM +0300, Dmitry Osipenko wrote:
> Touchscreen firmware of ASUS Transformer TF700T reports zeros for the phys
> size. Hence check whether the size is zero and don't set the resolution in
> this case.
> 
> Reported-by: Jasper Korten 
> Signed-off-by: Dmitry Osipenko 
> ---
> 
> Please note that ASUS TF700T isn't yet supported by upstream kernel,
> hence this is not a critical fix.
> 
>  drivers/input/touchscreen/elants_i2c.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/input/touchscreen/elants_i2c.c 
> b/drivers/input/touchscreen/elants_i2c.c
> index 4c2b579f6c8b..a2e1cc4192b0 100644
> --- a/drivers/input/touchscreen/elants_i2c.c
> +++ b/drivers/input/touchscreen/elants_i2c.c
> @@ -1441,14 +1441,16 @@ static int elants_i2c_probe(struct i2c_client *client,
>  
>   touchscreen_parse_properties(ts->input, true, >prop);
>  
> - if (ts->chip_id == EKTF3624) {
> + if (ts->chip_id == EKTF3624 && ts->phy_x && ts->phy_y) {
>   /* calculate resolution from size */
>   ts->x_res = DIV_ROUND_CLOSEST(ts->prop.max_x, ts->phy_x);
>   ts->y_res = DIV_ROUND_CLOSEST(ts->prop.max_y, ts->phy_y);
>   }
>  
> - input_abs_set_res(ts->input, ABS_MT_POSITION_X, ts->x_res);
> - input_abs_set_res(ts->input, ABS_MT_POSITION_Y, ts->y_res);
> + if (ts->x_res > 0)
> + input_abs_set_res(ts->input, ABS_MT_POSITION_X, ts->x_res);

There is absolutely no difference between setting respluton to 0 vs not
setting it at all, so I dropped the conditionals and applied.

> + if (ts->y_res > 0)
> + input_abs_set_res(ts->input, ABS_MT_POSITION_Y, ts->y_res);
>   if (ts->major_res > 0)

We could drop this condition as well.

>   input_abs_set_res(ts->input, ABS_MT_TOUCH_MAJOR, ts->major_res);
>  
> -- 
> 2.29.2
> 

Thanks.

-- 
Dmitry


[PATCH] kernel/printk.c: Fixed mundane typos

2021-03-27 Thread Bhaskar Chowdhury


s/sempahore/semaphore/
s/exacly/exactly/
s/unregistred/unregistered/
s/interation/iteration/


Signed-off-by: Bhaskar Chowdhury 
---
 kernel/printk/printk.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 575a34b88936..95d31886e0d7 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -262,7 +262,7 @@ static void __up_console_sem(unsigned long ip)
  * definitely not the perfect debug tool (we don't know if _WE_
  * hold it and are racing, but it helps tracking those weird code
  * paths in the console code where we end up in places I want
- * locked without the console sempahore held).
+ * locked without the console semaphore held).
  */
 static int console_locked, console_suspended;

@@ -2262,7 +2262,7 @@ static int __init console_setup(char *str)
/*
 * console="" or console=null have been suggested as a way to
 * disable console output. Use ttynull that has been created
-* for exacly this purpose.
+* for exactly this purpose.
 */
if (str[0] == 0 || strcmp(str, "null") == 0) {
__add_preferred_console("ttynull", 0, NULL, NULL, true);
@@ -3042,7 +3042,7 @@ void __init console_init(void)
  *
  * To mitigate this problem somewhat, only unregister consoles whose memory
  * intersects with the init section. Note that all other boot consoles will
- * get unregistred when the real preferred console is registered.
+ * get unregistered when the real preferred console is registered.
  */
 static int __init printk_late_init(void)
 {
@@ -3467,7 +3467,7 @@ bool kmsg_dump_get_buffer(struct kmsg_dumper *dumper, 
bool syslog,
seq = r.info->seq + 1;
}

-   /* last message in next interation */
+   /* last message in next iteration */
next_seq = seq;

/* actually read text into the buffer now */
--
2.26.2



Re: [PATCH bpf-next 3/5] libbpf: add low level TC-BPF API

2021-03-27 Thread Andrii Nakryiko
On Thu, Mar 25, 2021 at 5:02 AM Kumar Kartikeya Dwivedi
 wrote:
>
> This adds functions that wrap the netlink API used for adding,
> manipulating, and removing filters and actions. These functions operate
> directly on the loaded prog's fd, and return a handle to the filter and
> action using an out parameter (id for tc_cls, and index for tc_act).
>
> The basic featureset is covered to allow for attaching, manipulation of
> properties, and removal of filters and actions. Some additional features
> like TCA_BPF_POLICE and TCA_RATE for tc_cls have been omitted. These can
> added on top later by extending the bpf_tc_cls_opts struct.
>
> Support for binding actions directly to a classifier by passing them in
> during filter creation has also been omitted for now. These actions
> have an auto clean up property because their lifetime is bound to the
> filter they are attached to. This can be added later, but was omitted
> for now as direct action mode is a better alternative to it.
>
> An API summary:
>
> The BPF TC-CLS API
>
> bpf_tc_act_{attach, change, replace}_{dev, block} may be used to attach,
> change, and replace SCHED_CLS bpf classifiers. Separate set of functions
> are provided for network interfaces and shared filter blocks.
>
> bpf_tc_cls_detach_{dev, block} may be used to detach existing SCHED_CLS
> filter. The bpf_tc_cls_attach_id object filled in during attach,
> change, or replace must be passed in to the detach functions for them to
> remove the filter and its attached classififer correctly.
>
> bpf_tc_cls_get_info is a helper that can be used to obtain attributes
> for the filter and classififer. The opts structure may be used to
> choose the granularity of search, such that info for a specific filter
> corresponding to the same loaded bpf program can be obtained. By
> default, the first match is returned to the user.
>
> Examples:
>
> struct bpf_tc_cls_attach_id id = {};
> struct bpf_object *obj;
> struct bpf_program *p;
> int fd, r;
>
> obj = bpf_object_open("foo.o");
> if (IS_ERR_OR_NULL(obj))
> return PTR_ERR(obj);
>
> p = bpf_object__find_program_by_title(obj, "classifier");
> if (IS_ERR_OR_NULL(p))
> return PTR_ERR(p);
>
> if (bpf_object__load(obj) < 0)
> return -1;
>
> fd = bpf_program__fd(p);
>
> r = bpf_tc_cls_attach_dev(fd, if_nametoindex("lo"),
>   BPF_TC_CLSACT_INGRESS, ETH_P_IP,
>   NULL, );
> if (r < 0)
> return r;
>
> ... which is roughly equivalent to (after clsact qdisc setup):
>   # tc filter add dev lo ingress bpf obj /home/kkd/foo.o sec classifier
>
> If a user wishes to modify existing options on an attached filter, the
> bpf_tc_cls_change_{dev, block} API may be used. Parameters like
> chain_index, priority, and handle are ignored in the bpf_tc_cls_opts
> struct as they cannot be modified after attaching a filter.
>
> Example:
>
> /* Optional parameters necessary to select the right filter */
> DECLARE_LIBBPF_OPTS(bpf_tc_cls_opts, opts,
> .handle = id.handle,
> .priority = id.priority,
> .chain_index = id.chain_index)
> /* Turn on direct action mode */
> opts.direct_action = true;
> r = bpf_tc_cls_change_dev(fd, id.ifindex, id.parent_id,
>   id.protocol, , );
> if (r < 0)
> return r;
>
> /* Verify that the direct action mode has been set */
> struct bpf_tc_cls_info info = {};
> r = bpf_tc_cls_get_info_dev(fd, id.ifindex, id.parent_id,
> id.protocol, , );
> if (r < 0)
> return r;
>
> assert(info.bpf_flags & TCA_BPF_FLAG_ACT_DIRECT);
>
> This would be roughly equivalent to doing:
>   # tc filter change dev lo egress prio  handle  bpf obj 
> /home/kkd/foo.o section classifier da
>
> ... except a new bpf program will be loaded and replace existing one.
>
> If a user wishes to either replace an existing filter, or create a new
> one with the same properties, they can use bpf_tc_cls_replace_dev. The
> benefit of bpf_tc_cls_change is that it fails if no matching filter
> exists.
>
> The BPF TC-ACT API

Is there some succinct but complete enough documentation/tutorial/etc
that I can reasonably read to understand kernel APIs provided by TC
(w.r.t. BPF, of course). I'm trying to wrap my head around this and
whether API makes sense or not. Please share links, if you have some.

>
> bpf_tc_act_{attach, replace} may be used to attach and replace already
> attached SCHED_ACT actions. Passing an index of 0 has special meaning,
> in that an index will be automatically chosen by the kernel. The index
> chosen by the kernel is the return value of these functions in case of
> success.
>
> 

Re: [PATCH bpf-next 5/5] libbpf: add selftests for TC-BPF API

2021-03-27 Thread Andrii Nakryiko
On Fri, Mar 26, 2021 at 7:15 PM Alexei Starovoitov
 wrote:
>
> On Thu, Mar 25, 2021 at 05:30:03PM +0530, Kumar Kartikeya Dwivedi wrote:
> > This adds some basic tests for the low level bpf_tc_* API and its
> > bpf_program__attach_tc_* wrapper on top.
>
> *_block() apis from patch 3 and 4 are not covered by this selftest.
> Why were they added ? And how were they tested?
>
> Pls trim your cc. bpf@vger and netdev@vger would have been enough.
>
> My main concern with this set is that it adds netlink apis to libbpf while
> we already agreed to split xdp manipulation pieces out of libbpf.
> It would be odd to add tc apis now only to split them later.

We weren't going to split out basic attach APIs at all. So
bpf_set_link_xdp_fd() and bpf_program__attach_xdp() would stay in
libbpf. libxdp/libxsk would contain higher-level APIs which establish
additional conventions, beyond the basic operation of attaching BPF
program to XDP hook. E.g, all the chaining and how individual XDP
"sub-programs" are ordered, processed, updated/replaced, etc. That's
all based on one particular convention that libxdp would establish, so
that part shouldn't live in libbpf.

So in that sense, having TC attach APIs makes sense to complete
libbpf's APIs. I think it's totally in libbpf's domain to provide APIs
of the form "attach BPF program to BPF hook".

> I think it's better to start with new library for tc/xdp and have
> libbpf as a dependency on that new lib.
> For example we can add it as subdir in tools/lib/bpf/.
>
> Similarly I think integerating static linking into libbpf was a mistake.
> It should be a sub library as well.
>
> If we end up with core libbpf and ten sublibs for tc, xdp, af_xdp, linking,
> whatever else the users would appreciate that we don't shove single libbpf
> to them with a ton of features that they might never use.

What's the concern exactly? The size of the library? Having 10
micro-libraries has its own set of downsides, I'm not convinced that's
a better situation for end users. And would certainly cause more
hassle for libbpf developers and packagers.

And what did you include in "core libbpf"?


[PATCH 07/10] locking.c: Fix same typo in couple of places

2021-03-27 Thread Bhaskar Chowdhury
s/Retrun/Return/ . two different places.

Signed-off-by: Bhaskar Chowdhury 
---
 fs/btrfs/locking.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/btrfs/locking.c b/fs/btrfs/locking.c
index 5fafc5e89bb7..313d9d685adb 100644
--- a/fs/btrfs/locking.c
+++ b/fs/btrfs/locking.c
@@ -57,7 +57,7 @@ void btrfs_tree_read_lock(struct extent_buffer *eb)
 /*
  * Try-lock for read.
  *
- * Retrun 1 if the rwlock has been taken, 0 otherwise
+ * Return 1 if the rwlock has been taken, 0 otherwise
  */
 int btrfs_try_tree_read_lock(struct extent_buffer *eb)
 {
@@ -72,7 +72,7 @@ int btrfs_try_tree_read_lock(struct extent_buffer *eb)
 /*
  * Try-lock for write.
  *
- * Retrun 1 if the rwlock has been taken, 0 otherwise
+ * Return 1 if the rwlock has been taken, 0 otherwise
  */
 int btrfs_try_tree_write_lock(struct extent_buffer *eb)
 {
--
2.26.2



[PATCH 09/10] extent-tree.c: Fix a typo

2021-03-27 Thread Bhaskar Chowdhury
s/Otheriwse/Otherwise/

Signed-off-by: Bhaskar Chowdhury 
---
 fs/btrfs/extent-tree.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 36a3c973fda1..d0532754af15 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -1421,7 +1421,7 @@ int btrfs_inc_extent_ref(struct btrfs_trans_handle *trans,
  * bytenr of the parent block. Since new extents are always
  * created with indirect references, this will only be the case
  * when relocating a shared extent. In that case, root_objectid
- * will be BTRFS_TREE_RELOC_OBJECTID. Otheriwse, parent must
+ * will be BTRFS_TREE_RELOC_OBJECTID. Otherwise, parent must
  * be 0
  *
  * @root_objectid:  The id of the root where this modification has originated,
--
2.26.2



[PATCH 10/10] disk-io.c: Fix a typo

2021-03-27 Thread Bhaskar Chowdhury
s/traget/target/

Signed-off-by: Bhaskar Chowdhury 
---
 fs/btrfs/disk-io.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index 289f1f09481d..230918d34f87 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -3367,7 +3367,7 @@ int __cold open_ctree(struct super_block *sb, struct 
btrfs_fs_devices *fs_device
 * At this point we know all the devices that make this filesystem,
 * including the seed devices but we don't know yet if the replace
 * target is required. So free devices that are not part of this
-* filesystem but skip the replace traget device which is checked
+* filesystem but skip the replace target device which is checked
 * below in btrfs_init_dev_replace().
 */
btrfs_free_extra_devids(fs_devices);
--
2.26.2



[PATCH 08/10] volumes.c: Fix a typo

2021-03-27 Thread Bhaskar Chowdhury
s/bondary/boundary/

Signed-off-by: Bhaskar Chowdhury 
---
 fs/btrfs/volumes.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 1c6810bbaf8b..ac85558b91c2 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -7797,7 +7797,7 @@ static int verify_one_dev_extent(struct btrfs_fs_info 
*fs_info,
ret = -EUCLEAN;
}

-   /* Make sure no dev extent is beyond device bondary */
+   /* Make sure no dev extent is beyond device boundary */
dev = btrfs_find_device(fs_info->fs_devices, devid, NULL, NULL);
if (!dev) {
btrfs_err(fs_info, "failed to find devid %llu", devid);
--
2.26.2



[PATCH 06/10] scrub.c: Fix a typo

2021-03-27 Thread Bhaskar Chowdhury
s/reponsible/responsible/

Signed-off-by: Bhaskar Chowdhury 
---
 fs/btrfs/scrub.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/btrfs/scrub.c b/fs/btrfs/scrub.c
index 3d9088eab2fc..14de898967bf 100644
--- a/fs/btrfs/scrub.c
+++ b/fs/btrfs/scrub.c
@@ -2426,7 +2426,7 @@ static void drop_csum_range(struct scrub_ctx *sctx, 
struct btrfs_ordered_sum *su
  * the csum into @csum.
  *
  * The search source is sctx->csum_list, which is a pre-populated list
- * storing bytenr ordered csum ranges.  We're reponsible to cleanup any range
+ * storing bytenr ordered csum ranges.  We're responsible to cleanup any range
  * that is before @logical.
  *
  * Return 0 if there is no csum for the range.
--
2.26.2



[PATCH 05/10] inode.c: Couple of typo fixes

2021-03-27 Thread Bhaskar Chowdhury
s/contaning/containing/
s/clearning/clearing/

Signed-off-by: Bhaskar Chowdhury 
---
 fs/btrfs/inode.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index a520775949a0..dd7cc65db7bd 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -2784,8 +2784,8 @@ static int insert_reserved_file_extent(struct 
btrfs_trans_handle *trans,
/*
 * If we dropped an inline extent here, we know the range where it is
 * was not marked with the EXTENT_DELALLOC_NEW bit, so we update the
-* number of bytes only for that range contaning the inline extent.
-* The remaining of the range will be processed when clearning the
+* number of bytes only for that range containing the inline extent.
+* The remaining of the range will be processed when clearing the
 * EXTENT_DELALLOC_BIT bit through the ordered extent completion.
 */
if (file_pos == 0 && !IS_ALIGNED(drop_args.bytes_found, sectorsize)) {
--
2.26.2



[PATCH 02/10] dev-replace.c: A typo fix

2021-03-27 Thread Bhaskar Chowdhury
s/contans/contains/

Signed-off-by: Bhaskar Chowdhury 
---
 fs/btrfs/dev-replace.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/btrfs/dev-replace.c b/fs/btrfs/dev-replace.c
index d05f73530af7..d029be40ea6f 100644
--- a/fs/btrfs/dev-replace.c
+++ b/fs/btrfs/dev-replace.c
@@ -37,7 +37,7 @@
  * - Write duplication
  *
  *   All new writes will be written to both target and source devices, so even
- *   if replace gets canceled, sources device still contans up-to-date data.
+ *   if replace gets canceled, sources device still contains up-to-date data.
  *
  *   Location: handle_ops_on_dev_replace() from __btrfs_map_block()
  *   Start:btrfs_dev_replace_start()
--
2.26.2



[PATCH 04/10] zoned.c: A typo fix

2021-03-27 Thread Bhaskar Chowdhury
s/beggining/beginning/

Signed-off-by: Bhaskar Chowdhury 
---
 fs/btrfs/zoned.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/btrfs/zoned.c b/fs/btrfs/zoned.c
index 1f972b75a9ab..d6cd0d4eb1a9 100644
--- a/fs/btrfs/zoned.c
+++ b/fs/btrfs/zoned.c
@@ -383,7 +383,7 @@ int btrfs_get_dev_zone_info(struct btrfs_device *device)
}

/*
-* If zones[0] is conventional, always use the beggining of the
+* If zones[0] is conventional, always use the beginning of the
 * zone to record superblock. No need to validate in that case.
 */
if (zone_info->sb_zones[BTRFS_NR_SB_LOG_ZONES * i].type ==
--
2.26.2



[PATCH 03/10] ioctl.c: A typo fix

2021-03-27 Thread Bhaskar Chowdhury
s/termined/terminated/

Signed-off-by: Bhaskar Chowdhury 
---
 fs/btrfs/ioctl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index e8d53fea4c61..98ed14a0682e 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -3022,7 +3022,7 @@ static noinline int btrfs_ioctl_snap_destroy(struct file 
*file,
err = PTR_ERR(subvol_name_ptr);
goto free_parent;
}
-   /* subvol_name_ptr is already NULL termined */
+   /* subvol_name_ptr is already NULL terminated */
subvol_name = (char *)kbasename(subvol_name_ptr);
}
} else {
--
2.26.2



[PATCH 01/10] extent-map-tests.c: A typo fix

2021-03-27 Thread Bhaskar Chowdhury
s/interesects/intersects/

Signed-off-by: Bhaskar Chowdhury 
---
 fs/btrfs/tests/extent-map-tests.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/btrfs/tests/extent-map-tests.c 
b/fs/btrfs/tests/extent-map-tests.c
index c0aefe6dee0b..319fed82d741 100644
--- a/fs/btrfs/tests/extent-map-tests.c
+++ b/fs/btrfs/tests/extent-map-tests.c
@@ -557,7 +557,7 @@ int btrfs_test_extent_map(void)
{
/*
 * Test a chunk with 2 data stripes one of which
-* interesects the physical address of the super block
+* intersects the physical address of the super block
 * is correctly recognised.
 */
.raid_type = BTRFS_BLOCK_GROUP_RAID1,
--
2.26.2



[PATCH 00/10] BTRFS: Mundane typo fixes

2021-03-27 Thread Bhaskar Chowdhury
This patch series fixes trivial typos as they appear in the files.

Bhaskar Chowdhury (10):
  extent-map-tests.c: A typo fix
  dev-replace.c: A typo fix
  ioctl.c: A typo fix
  zoned.c: A typo fix
  inode.c: Couple of typo fixes
  scrub.c: Fix a typo
  locking.c: Fix same typo in couple of places
  volumes.c: Fix a typo
  extent-tree.c: Fix a typo
  disk-io.c: Fix a typo

 fs/btrfs/dev-replace.c| 2 +-
 fs/btrfs/disk-io.c| 2 +-
 fs/btrfs/extent-tree.c| 2 +-
 fs/btrfs/inode.c  | 4 ++--
 fs/btrfs/ioctl.c  | 2 +-
 fs/btrfs/locking.c| 4 ++--
 fs/btrfs/scrub.c  | 2 +-
 fs/btrfs/tests/extent-map-tests.c | 2 +-
 fs/btrfs/volumes.c| 2 +-
 fs/btrfs/zoned.c  | 2 +-
 10 files changed, 12 insertions(+), 12 deletions(-)

--
2.26.2



[PATCH v2] lib: fix kconfig dependency on ARCH_WANT_FRAME_POINTERS

2021-03-27 Thread Julian Braha
When LATENCYTOP is enabled and ARCH_WANT_FRAME_POINTERS
is disabled, Kbuild gives the following warning:

WARNING: unmet direct dependencies detected for FRAME_POINTER
  Depends on [n]: DEBUG_KERNEL [=y] && (M68K || UML || SUPERH) || 
ARCH_WANT_FRAME_POINTERS [=n] || MCOUNT [=n]
  Selected by [y]:
  - LATENCYTOP [=y] && DEBUG_KERNEL [=y] && STACKTRACE_SUPPORT [=y] && PROC_FS 
[=y] && !MIPS && !PPC && !S390 && !MICROBLAZE && !ARM && !ARC && !X86

Depending on ARCH_WANT_FRAME_POINTERS causes a
recursive dependency error.
ARCH_WANT_FRAME_POINTERS is to be selected by the architecture,
and is not supposed to be overridden by other config options.

Signed-off-by: Julian Braha 
---
 lib/Kconfig.debug | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 2779c29d9981..8d53ed423899 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1665,7 +1665,7 @@ config LATENCYTOP
depends on DEBUG_KERNEL
depends on STACKTRACE_SUPPORT
depends on PROC_FS
-   select FRAME_POINTER if !MIPS && !PPC && !S390 && !MICROBLAZE && !ARM 
&& !ARC && !X86
+   select FRAME_POINTER if MIPS || PPC || S390 || MICROBLAZE || ARM || ARC 
|| X86
select KALLSYMS
select KALLSYMS_ALL
select STACKTRACE
-- 
2.25.1



[PATCH] drivers: iio: adc: fix unmet dependency on OF

2021-03-27 Thread Julian Braha
When AD9467 is enabled, and OF is disabled,
Kbuild gives the following warning:

WARNING: unmet direct dependencies detected for ADI_AXI_ADC
 Depends on [n]: IIO [=y] && HAS_IOMEM [=y] && OF [=n]
 Selected by [y]:
 - AD9467 [=y] && IIO [=y] && SPI [=y]

This is because AD9467 selects ADI_AXI_ADC
without selecting or depending on OF,
despite ADI_AXI_ADC depending on OF.

Signed-off-by: Julian Braha 
---
 drivers/iio/adc/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index e0667c4b3c08..7606c9b1630e 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -248,7 +248,7 @@ config AD799X
 
 config AD9467
tristate "Analog Devices AD9467 High Speed ADC driver"
-   depends on SPI
+   depends on SPI && OF
select ADI_AXI_ADC
help
  Say yes here to build support for Analog Devices:
-- 
2.25.1



Re: [syzbot] UBSAN: shift-out-of-bounds in ___bpf_prog_run

2021-03-27 Thread syzbot
syzbot has found a reproducer for the following issue on:

HEAD commit:0f4498ce Merge tag 'for-5.12/dm-fixes-2' of git://git.kern..
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=16d734aad0
kernel config:  https://syzkaller.appspot.com/x/.config?x=d4e9addca54f3b44
dashboard link: https://syzkaller.appspot.com/bug?extid=bed360704c521841c85d
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=1424cd9ed0
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1085497cd0

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+bed360704c521841c...@syzkaller.appspotmail.com


UBSAN: shift-out-of-bounds in kernel/bpf/core.c:1421:2
shift exponent 248 is too large for 32-bit type 'unsigned int'
CPU: 1 PID: 8388 Comm: syz-executor895 Not tainted 5.12.0-rc4-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:79 [inline]
 dump_stack+0x141/0x1d7 lib/dump_stack.c:120
 ubsan_epilogue+0xb/0x5a lib/ubsan.c:148
 __ubsan_handle_shift_out_of_bounds.cold+0xb1/0x181 lib/ubsan.c:327
 ___bpf_prog_run.cold+0x20f/0x56c kernel/bpf/core.c:1421
 __bpf_prog_run480+0x99/0xe0 kernel/bpf/core.c:1739
 bpf_dispatcher_nop_func include/linux/bpf.h:659 [inline]
 __bpf_trace_run kernel/trace/bpf_trace.c:2091 [inline]
 bpf_trace_run2+0x12f/0x390 kernel/trace/bpf_trace.c:2128
 __bpf_trace_tlb_flush+0xbd/0x100 include/trace/events/tlb.h:38
 trace_tlb_flush+0xe0/0x1c0 include/trace/events/tlb.h:38
 switch_mm_irqs_off+0x48b/0x970 arch/x86/mm/tlb.c:563
 unuse_temporary_mm arch/x86/kernel/alternative.c:842 [inline]
 __text_poke+0x541/0x8c0 arch/x86/kernel/alternative.c:938
 text_poke_bp_batch+0x187/0x550 arch/x86/kernel/alternative.c:1190
 text_poke_flush arch/x86/kernel/alternative.c:1347 [inline]
 text_poke_flush arch/x86/kernel/alternative.c:1344 [inline]
 text_poke_finish+0x16/0x30 arch/x86/kernel/alternative.c:1354
 arch_jump_label_transform_apply+0x13/0x20 arch/x86/kernel/jump_label.c:126
 jump_label_update+0x1da/0x400 kernel/jump_label.c:825
 static_key_enable_cpuslocked+0x1b1/0x260 kernel/jump_label.c:177
 static_key_enable+0x16/0x20 kernel/jump_label.c:190
 tracepoint_add_func+0x707/0xa90 kernel/tracepoint.c:303
 tracepoint_probe_register_prio kernel/tracepoint.c:369 [inline]
 tracepoint_probe_register+0x9c/0xe0 kernel/tracepoint.c:389
 __bpf_probe_register kernel/trace/bpf_trace.c:2154 [inline]
 bpf_probe_register+0x15a/0x1c0 kernel/trace/bpf_trace.c:2159
 bpf_raw_tracepoint_open+0x34a/0x720 kernel/bpf/syscall.c:2878
 __do_sys_bpf+0x2586/0x4f40 kernel/bpf/syscall.c:4435
 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
 entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x43f009
Code: Unable to access opcode bytes at RIP 0x43efdf.
RSP: 002b:7ffc64740b68 EFLAGS: 0246 ORIG_RAX: 0141
RAX: ffda RBX: 00400488 RCX: 0043f009
RDX: 0010 RSI: 2080 RDI: 0011
RBP: 00402ff0 R08:  R09: 00400488
R10:  R11: 0246 R12: 00403080
R13:  R14: 004ac018 R15: 00400488




[PATCH] xtensa: fix uaccess-related livelock in do_page_fault

2021-03-27 Thread Max Filippov
If a uaccess (e.g. get_user()) triggers a fault and there's a
fault signal pending, the handler will return to the uaccess without
having performed a uaccess fault fixup, and so the CPU will immediately
execute the uaccess instruction again, whereupon it will livelock
bouncing between that instruction and the fault handler.

https://lore.kernel.org/lkml/20210121123140.GD48431@C02TD0UTHF1T.local/

Cc: sta...@vger.kernel.org
Reported-by: Mark Rutland 
Signed-off-by: Max Filippov 
---
 arch/xtensa/mm/fault.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/xtensa/mm/fault.c b/arch/xtensa/mm/fault.c
index 7666408ce12a..95a74890c7e9 100644
--- a/arch/xtensa/mm/fault.c
+++ b/arch/xtensa/mm/fault.c
@@ -112,8 +112,11 @@ void do_page_fault(struct pt_regs *regs)
 */
fault = handle_mm_fault(vma, address, flags, regs);
 
-   if (fault_signal_pending(fault, regs))
+   if (fault_signal_pending(fault, regs)) {
+   if (!user_mode(regs))
+   goto bad_page_fault;
return;
+   }
 
if (unlikely(fault & VM_FAULT_ERROR)) {
if (fault & VM_FAULT_OOM)
-- 
2.20.1



hppa64-linux-ld: net/ipv4/tcp_ipv4.o(.init.text+0x50): cannot reach unknown

2021-03-27 Thread kernel test robot
tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   0f4498cef9f5cd18d7c6639a2a902ec1edc5be4e
commit: e807b13cb3e3bcf0f602cb5ef66f7a1988d0e703 nft_set_pipapo: Generalise 
group size for buckets
date:   1 year ago
config: parisc-randconfig-s031-20210326 (attached as .config)
compiler: hppa64-linux-gcc (GCC) 9.3.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.3-277-gc089cd2d-dirty
# 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e807b13cb3e3bcf0f602cb5ef66f7a1988d0e703
git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout e807b13cb3e3bcf0f602cb5ef66f7a1988d0e703
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=parisc 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All errors (new ones prefixed by >>):

   init/main.o:(.init.text+0x744): relocation truncated to fit: 
R_PARISC_PCREL22F against symbol `get_option' defined in .text section in 
lib/cmdline.o
   hppa64-linux-ld: init/main.o(.init.text+0x874): cannot reach strlcpy
   init/main.o: in function `parse_early_param':
   (.init.text+0x874): additional relocation overflows omitted from the output
   hppa64-linux-ld: init/main.o(.init.text+0x8e0): cannot reach rest_init
   hppa64-linux-ld: init/main.o(.init.text+0xa4c): cannot reach strlen
   hppa64-linux-ld: init/main.o(.init.text+0xaf4): cannot reach strcpy
   hppa64-linux-ld: init/main.o(.init.text+0xb0c): cannot reach strcpy
   hppa64-linux-ld: init/main.o(.init.text+0xb40): cannot reach 
build_all_zonelists
   hppa64-linux-ld: init/main.o(.init.text+0xe84): cannot reach strlen
   hppa64-linux-ld: init/main.o(.init.text+0xecc): cannot reach profile_init
   hppa64-linux-ld: init/main.o(.init.text+0x1140): cannot reach 
wait_for_completion
   hppa64-linux-ld: init/main.o(.init.text+0x123c): cannot reach strlen
   hppa64-linux-ld: init/main.o(.init.text+0x12f4): cannot reach strcpy
   hppa64-linux-ld: init/main.o(.ref.text+0x1ac): cannot reach unknown
   hppa64-linux-ld: init/do_mounts.o(.init.text+0x128): cannot reach 
simple_strtol
   hppa64-linux-ld: init/do_mounts.o(.init.text+0x180): cannot reach 
simple_strtoul
   hppa64-linux-ld: init/do_mounts.o(.init.text+0x1d4): cannot reach strlcpy
   hppa64-linux-ld: init/do_mounts.o(.init.text+0x23c): cannot reach strstr
   hppa64-linux-ld: init/do_mounts.o(.init.text+0x370): cannot reach strcpy
   hppa64-linux-ld: init/do_mounts.o(.init.text+0x3d8): cannot reach strchr
   hppa64-linux-ld: init/do_mounts.o(.init.text+0x514): cannot reach strncpy
   hppa64-linux-ld: init/do_mounts.o(.init.text+0x67c): cannot reach strlen
   hppa64-linux-ld: init/do_mounts.o(.init.text+0x74c): cannot reach strlen
   hppa64-linux-ld: init/do_mounts.o(.init.text+0x864): cannot reach strncmp
   hppa64-linux-ld: init/do_mounts.o(.init.text+0x888): cannot reach strncmp
   hppa64-linux-ld: init/do_mounts.o(.init.text+0x8f4): cannot reach strncmp
   hppa64-linux-ld: arch/parisc/mm/init.o(.init.text+0x674): cannot reach memcmp
   hppa64-linux-ld: arch/parisc/mm/init.o(.init.text+0x694): cannot reach 
memparse
   hppa64-linux-ld: arch/parisc/mm/init.o(.ref.text+0x78): cannot reach unknown
   hppa64-linux-ld: arch/parisc/mm/init.o(.ref.text+0xa0): cannot reach unknown
   hppa64-linux-ld: arch/parisc/mm/init.o(.ref.text+0xc4): cannot reach unknown
   hppa64-linux-ld: arch/parisc/kernel/setup.o(.init.text+0x27c): cannot reach 
strlcpy
   hppa64-linux-ld: arch/parisc/kernel/setup.o(.init.text+0x298): cannot reach 
strcpy
   hppa64-linux-ld: arch/parisc/kernel/setup.o(.init.text+0x494): cannot reach 
memcmp
   hppa64-linux-ld: kernel/extable.o(.init.text+0x64): cannot reach sort_extable
   hppa64-linux-ld: kernel/printk/printk.o(.init.text+0x94): cannot reach strcpy
   hppa64-linux-ld: kernel/printk/printk.o(.init.text+0x1f8): cannot reach 
memparse
   hppa64-linux-ld: kernel/printk/printk.o(.init.text+0x2f0): cannot reach 
strcmp
   hppa64-linux-ld: kernel/printk/printk.o(.init.text+0x320): cannot reach 
strcmp
   hppa64-linux-ld: kernel/printk/printk.o(.init.text+0x3a0): cannot reach 
strcpy
   hppa64-linux-ld: kernel/printk/printk.o(.init.text+0x3cc): cannot reach 
strncpy
   hppa64-linux-ld: kernel/printk/printk.o(.init.text+0x3e8): cannot reach 
strchr
   hppa64-linux-ld: kernel/printk/printk.o(.init.text+0x444): cannot reach 
simple_strtoul
   hppa64-linux-ld: kernel/printk/printk.o(.init.text+0x774): cannot reach 
memcpy
   hppa64-linux-ld: kernel/printk/printk.o(.init.text+0x7b4): cannot reach 
preempt_schedule
   hppa64-linux-ld: 

[PATCH v3] crypto: mips: add poly1305-core.S to .gitignore

2021-03-27 Thread Ilya Lipnitskiy
poly1305-core.S is an auto-generated file, so it should be ignored.

Fixes: a11d055e7a64 ("crypto: mips/poly1305 - incorporate OpenSSL/CRYPTOGAMS 
optimized implementation")
Signed-off-by: Ilya Lipnitskiy 
Cc: Ard Biesheuvel 
---
 arch/mips/crypto/.gitignore | 2 ++
 1 file changed, 2 insertions(+)
 create mode 100644 arch/mips/crypto/.gitignore

diff --git a/arch/mips/crypto/.gitignore b/arch/mips/crypto/.gitignore
new file mode 100644
index ..0d47d4f21c6d
--- /dev/null
+++ b/arch/mips/crypto/.gitignore
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0-only
+poly1305-core.S
-- 
2.31.0



Re: [PATCH v25 09/10] fs/ntfs3: Add NTFS3 in fs/Kconfig and fs/Makefile

2021-03-27 Thread kernel test robot
Hi Konstantin,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on 931294922e65a23e1aad6398b9ae02df74044679]

url:
https://github.com/0day-ci/linux/commits/Konstantin-Komarov/NTFS-read-write-driver-GPL-implementation-by-Paragon-Software/20210328-054516
base:   931294922e65a23e1aad6398b9ae02df74044679
config: i386-allyesconfig (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 


cocci warnings: (new ones prefixed by >>)
>> fs/ntfs3/xattr.c:1037:8-9: WARNING: return of 0/1 in function 
>> 'ntfs_xattr_user_list' with return type bool
--
>> fs/ntfs3/super.c:93:17-23: Missing call to dput() at line 121.
--
>> fs/ntfs3/xattr.c:452:5-13: duplicated argument to && or ||
--
>> fs/ntfs3/fslog.c:38:8-14: WARNING use flexible-array member instead 
>> (https://www.kernel.org/doc/html/latest/process/deprecated.html#zero-length-and-one-element-arrays)
   fs/ntfs3/fslog.c:72:19-26: WARNING use flexible-array member instead 
(https://www.kernel.org/doc/html/latest/process/deprecated.html#zero-length-and-one-element-arrays)
   fs/ntfs3/fslog.c:89:8-17: WARNING use flexible-array member instead 
(https://www.kernel.org/doc/html/latest/process/deprecated.html#zero-length-and-one-element-arrays)
   fs/ntfs3/fslog.c:113:8-12: WARNING use flexible-array member instead 
(https://www.kernel.org/doc/html/latest/process/deprecated.html#zero-length-and-one-element-arrays)
   fs/ntfs3/fslog.c:160:8-17: WARNING use flexible-array member instead 
(https://www.kernel.org/doc/html/latest/process/deprecated.html#zero-length-and-one-element-arrays)

Please review and possibly fold the followup patch.

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip


[PATCH] fs/ntfs3: fix boolreturn.cocci warnings

2021-03-27 Thread kernel test robot
From: kernel test robot 

fs/ntfs3/xattr.c:1037:8-9: WARNING: return of 0/1 in function 
'ntfs_xattr_user_list' with return type bool

 Return statements in functions returning bool should use
 true/false instead of 1/0.
Generated by: scripts/coccinelle/misc/boolreturn.cocci

CC: Konstantin Komarov 
Reported-by: kernel test robot 
Signed-off-by: kernel test robot 
---

url:
https://github.com/0day-ci/linux/commits/Konstantin-Komarov/NTFS-read-write-driver-GPL-implementation-by-Paragon-Software/20210328-054516
base:   931294922e65a23e1aad6398b9ae02df74044679

 xattr.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/fs/ntfs3/xattr.c
+++ b/fs/ntfs3/xattr.c
@@ -1034,7 +1034,7 @@ out:
 
 static bool ntfs_xattr_user_list(struct dentry *dentry)
 {
-   return 1;
+   return true;
 }
 
 static const struct xattr_handler ntfs_xattr_handler = {


[PATCH] fs/ntfs3: fix d_find_alias.cocci warnings

2021-03-27 Thread kernel test robot
From: kernel test robot 

fs/ntfs3/super.c:93:17-23: Missing call to dput() at line 121.

 Make sure calls to d_find_alias() have a corresponding call to dput().
Generated by: scripts/coccinelle/api/d_find_alias.cocci

CC: Konstantin Komarov 
Reported-by: kernel test robot 
Signed-off-by: kernel test robot 
---

url:
https://github.com/0day-ci/linux/commits/Konstantin-Komarov/NTFS-read-write-driver-GPL-implementation-by-Paragon-Software/20210328-054516
base:   931294922e65a23e1aad6398b9ae02df74044679

Please take the patch only if it's a positive warning. Thanks!

 super.c |1 +
 1 file changed, 1 insertion(+)

--- a/fs/ntfs3/super.c
+++ b/fs/ntfs3/super.c
@@ -118,6 +118,7 @@ void ntfs_inode_printk(struct inode *ino
atomic_inc(_name_buf_cnt);
if (name != s_name_buf)
kfree(name);
+   dput(dentry);
 }
 #endif
 


Re: [PATCH bpf-next] bpf: trace jit code when enable BPF_JIT_ALWAYS_ON

2021-03-27 Thread Jianlin Lv
On Sat, Mar 27, 2021 at 11:19 PM Alexei Starovoitov
 wrote:
>
> On Sat, Mar 27, 2021 at 1:19 AM Jianlin Lv  wrote:
> >
> > > On Fri, Mar 26, 2021 at 5:40 AM Jianlin Lv  wrote:
> > > >
> > > > When CONFIG_BPF_JIT_ALWAYS_ON is enabled, the value of
> > > bpf_jit_enable
> > > > in /proc/sys is limited to SYSCTL_ONE. This is not convenient for 
> > > > debugging.
> > > > This patch modifies the value of extra2 (max) to 2 that support
> > > > developers to emit traces on kernel log.
> > > >
> > > > Signed-off-by: Jianlin Lv 
> > > > ---
> > > >  net/core/sysctl_net_core.c | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/net/core/sysctl_net_core.c b/net/core/sysctl_net_core.c
> > > > index d84c8a1b280e..aa16883ac445 100644
> > > > --- a/net/core/sysctl_net_core.c
> > > > +++ b/net/core/sysctl_net_core.c
> > > > @@ -386,7 +386,7 @@ static struct ctl_table net_core_table[] = {
> > > > .proc_handler   = proc_dointvec_minmax_bpf_enable,
> > > >  # ifdef CONFIG_BPF_JIT_ALWAYS_ON
> > > > .extra1 = SYSCTL_ONE,
> > > > -   .extra2 = SYSCTL_ONE,
> > > > +   .extra2 = ,
> > >
> > > "bpftool prog dump jited" is much better way to examine JITed dumps.
> > > I'd rather remove bpf_jit_enable=2 altogether.
> >
> > In my case, I introduced a bug when I made some adjustments to the arm64
> > jit macro A64_MOV(), which caused the SP register to be replaced by the
> > XZR register when building prologue, and the wrong value was stored in fp,
> > which triggered a crash.
> >
> > This bug is likely to cause the instruction to access the BPF stack in
> > jited prog to trigger a crash.
> > I tried to use bpftool to debug, but bpftool crashed when I executed the
> > "bpftool prog show" command.
> > The syslog shown that bpftool is loading and running some bpf prog.
> > because of the bug in the JIT compiler, the bpftool execution failed.
>
> Right 'bpftool prog show' command is loading a bpf iterator prog,
> but you didn't need to use it to dump JITed code.
> "bpftool prog dump jited name my_prog"
> would have dumped it even when JIT is all buggy.
>
> > bpf_jit_disasm saved me, it helped me dump the jited image:
> >
> > echo 2> /proc/sys/net/core/bpf_jit_enable
> > modprobe test_bpf test_name="SPILL_FILL"
> > ./bpf_jit_disasm -o
> >
> > So keeping bpf_jit_enable=2 is still very meaningful for developers who
> > try to modify the JIT compiler.
>
> sure and such JIT developers can compile the kernel
> without BPF_JIT_ALWAYS_ON just like you did.
> They can also insert printk, etc.
> bpf_jit_enable=2 was done long ago when there was no other way
> to see JITed code. Now we have proper apis.
> That =2 mode can and should be removed.

Thanks for your reply, I will prepare another patch to remove =2mode.

>
> > IMPORTANT NOTICE: The contents of this email and any attachments are 
> > confidential and may also be privileged. If you are not the intended 
> > recipient, please notify the sender immediately and do not disclose the 
> > contents to any other person, use it for any purpose, or store or copy the 
> > information in any medium. Thank you.
>
> please fix your email server/client/whatever. No patches will ever be
> accepted with
> such disclaimer.

Apologize for this.
Jianlin


[PATCH v2] crypto: mips: add poly1305-core.S to .gitignore

2021-03-27 Thread Ilya Lipnitskiy
poly1305-core.S is an auto-generated file, so it should be ignored.

Fixes: a11d055e7a64 ("crypto: mips/poly1305 - incorporate OpenSSL/CRYPTOGAMS 
optimized implementation")
Signed-off-by: Ilya Lipnitskiy 
Cc: Ard Biesheuvel 
---
 arch/mips/crypto/.gitignore | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 arch/mips/crypto/.gitignore

diff --git a/arch/mips/crypto/.gitignore b/arch/mips/crypto/.gitignore
new file mode 100644
index ..4882ba199071
--- /dev/null
+++ b/arch/mips/crypto/.gitignore
@@ -0,0 +1 @@
+poly1305-core.S
-- 
2.31.0



Re: [PATCH v4 2/4] riscv: cmpxchg.h: Merge macros

2021-03-27 Thread Guo Ren
Thx Arnd,

On Sun, Mar 28, 2021 at 5:25 AM Arnd Bergmann  wrote:
>
> On Sat, Mar 27, 2021 at 7:06 PM  wrote:
> >
> > From: Guo Ren 
> >
> > To reduce assembly codes, let's merge duplicate codes into one
> > (xchg_acquire, xchg_release, cmpxchg_release).
> >
> > Signed-off-by: Guo Ren 
>
> This is a nice cleanup, but I wonder if you can go even further by using
> the definitions from atomic-arch-fallback.h like arm64 and x86 do.
Ok, I'll separate it from the qspinlock patchset and try atomic-arch-fallback.h.

-- 
Best Regards
 Guo Ren

ML: https://lore.kernel.org/linux-csky/


Re: [PATCH v4 3/4] locking/qspinlock: Add ARCH_USE_QUEUED_SPINLOCKS_XCHG32

2021-03-27 Thread Guo Ren
On Sun, Mar 28, 2021 at 2:43 AM Waiman Long  wrote:
>
> On 3/27/21 2:06 PM, guo...@kernel.org wrote:
> > From: Guo Ren 
> >
> > Some architectures don't have sub-word swap atomic instruction,
> > they only have the full word's one.
> >
> > The sub-word swap only improve the performance when:
> > NR_CPUS < 16K
> >   *  0- 7: locked byte
> >   * 8: pending
> >   *  9-15: not used
> >   * 16-17: tail index
> >   * 18-31: tail cpu (+1)
> >
> > The 9-15 bits are wasted to use xchg16 in xchg_tail.
> >
> > Please let architecture select xchg16/xchg32 to implement
> > xchg_tail.
> >
> > Signed-off-by: Guo Ren 
> > Cc: Peter Zijlstra 
> > Cc: Will Deacon 
> > Cc: Ingo Molnar 
> > Cc: Waiman Long 
> > Cc: Arnd Bergmann 
> > Cc: Anup Patel 
> > ---
> >   kernel/Kconfig.locks   |  3 +++
> >   kernel/locking/qspinlock.c | 44 +-
> >   2 files changed, 27 insertions(+), 20 deletions(-)
> >
> > diff --git a/kernel/Kconfig.locks b/kernel/Kconfig.locks
> > index 3de8fd11873b..d02f1261f73f 100644
> > --- a/kernel/Kconfig.locks
> > +++ b/kernel/Kconfig.locks
> > @@ -239,6 +239,9 @@ config LOCK_SPIN_ON_OWNER
> >   config ARCH_USE_QUEUED_SPINLOCKS
> >   bool
> >
> > +config ARCH_USE_QUEUED_SPINLOCKS_XCHG32
> > + bool
> > +
> >   config QUEUED_SPINLOCKS
> >   def_bool y if ARCH_USE_QUEUED_SPINLOCKS
> >   depends on SMP
> > diff --git a/kernel/locking/qspinlock.c b/kernel/locking/qspinlock.c
> > index cbff6ba53d56..54de0632c6a8 100644
> > --- a/kernel/locking/qspinlock.c
> > +++ b/kernel/locking/qspinlock.c
> > @@ -163,26 +163,6 @@ static __always_inline void 
> > clear_pending_set_locked(struct qspinlock *lock)
> >   WRITE_ONCE(lock->locked_pending, _Q_LOCKED_VAL);
> >   }
> >
> > -/*
> > - * xchg_tail - Put in the new queue tail code word & retrieve previous one
> > - * @lock : Pointer to queued spinlock structure
> > - * @tail : The new queue tail code word
> > - * Return: The previous queue tail code word
> > - *
> > - * xchg(lock, tail), which heads an address dependency
> > - *
> > - * p,*,* -> n,*,* ; prev = xchg(lock, node)
> > - */
> > -static __always_inline u32 xchg_tail(struct qspinlock *lock, u32 tail)
> > -{
> > - /*
> > -  * We can use relaxed semantics since the caller ensures that the
> > -  * MCS node is properly initialized before updating the tail.
> > -  */
> > - return (u32)xchg_relaxed(>tail,
> > -  tail >> _Q_TAIL_OFFSET) << _Q_TAIL_OFFSET;
> > -}
> > -
> >   #else /* _Q_PENDING_BITS == 8 */
> >
> >   /**
> > @@ -206,6 +186,30 @@ static __always_inline void 
> > clear_pending_set_locked(struct qspinlock *lock)
> >   {
> >   atomic_add(-_Q_PENDING_VAL + _Q_LOCKED_VAL, >val);
> >   }
> > +#endif
> > +
> > +#if _Q_PENDING_BITS == 8 && 
> > !defined(CONFIG_ARCH_USE_QUEUED_SPINLOCKS_XCHG32)
> > +/*
> > + * xchg_tail - Put in the new queue tail code word & retrieve previous one
> > + * @lock : Pointer to queued spinlock structure
> > + * @tail : The new queue tail code word
> > + * Return: The previous queue tail code word
> > + *
> > + * xchg(lock, tail), which heads an address dependency
> > + *
> > + * p,*,* -> n,*,* ; prev = xchg(lock, node)
> > + */
> > +static __always_inline u32 xchg_tail(struct qspinlock *lock, u32 tail)
> > +{
> > + /*
> > +  * We can use relaxed semantics since the caller ensures that the
> > +  * MCS node is properly initialized before updating the tail.
> > +  */
> > + return (u32)xchg_relaxed(>tail,
> > +  tail >> _Q_TAIL_OFFSET) << _Q_TAIL_OFFSET;
> > +}
> > +
> > +#else
> >
> >   /**
> >* xchg_tail - Put in the new queue tail code word & retrieve previous one
>
> I don't have any problem adding a
> CONFIG_ARCH_USE_QUEUED_SPINLOCKS_XCHG32 config option to control that.
Thx

>
> One minor nit:
>
> #endif /* _Q_PENDING_BITS == 8 */
>
> You should probably remove the comment at the trailing end of the
> corresponding "#endif" as it is now wrong.
I'll fix it in next patch

-- 
Best Regards
 Guo Ren

ML: https://lore.kernel.org/linux-csky/


[PATCH] crypto: mips: add poly1305-core.S to .gitignore

2021-03-27 Thread Ilya Lipnitskiy
poly1305-core.S is an auto-generated file, so it should be ignored.

Signed-off-by: Ilya Lipnitskiy 
Cc: Ard Biesheuvel 
---
 arch/mips/crypto/.gitignore | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 arch/mips/crypto/.gitignore

diff --git a/arch/mips/crypto/.gitignore b/arch/mips/crypto/.gitignore
new file mode 100644
index ..4882ba199071
--- /dev/null
+++ b/arch/mips/crypto/.gitignore
@@ -0,0 +1 @@
+poly1305-core.S
-- 
2.31.0



Re: [PATCH v5 0/5] Add r8a77965 DRIF support

2021-03-27 Thread Laurent Pinchart
Hi Hans,

On Sat, Mar 27, 2021 at 11:05:01AM +0100, Hans Verkuil wrote:
> On 21/10/2020 23:43, Laurent Pinchart wrote:
> > On Wed, Oct 21, 2020 at 02:53:27PM +0100, Fabrizio Castro wrote:
> >> Dear All,
> >>
> >> this series is to add DRIF support for the r8a77965
> >> (a.k.a. R-Car M3-N). Version 5 fixes a warning reported
> >> by 'make dt_binding_check', as reported by Rob.
> > 
> > Patch 1/5 to 4/5 taken in my tree, I'll send a pull request to
> > linux-media when the merge window closes. I expect Geert to handle 5/5.
> 
> Patch 5 has been merged, but patches 1-4 aren't. I don't think there
> was a PR for it. For some reason these patches are delegated to me in
> patchwork. I've now delegated them to you for further processing.

I've just sent a pull request, for these and other miscellaneous
changes.

> >> Fabrizio Castro (5):
> >>   MAINTAINERS: Update MAINTAINERS for Renesas DRIF driver
> >>   media: dt-bindings: media: renesas,drif: Convert to json-schema
> >>   media: dt-bindings: media: renesas,drif: Add r8a77990 support
> >>   media: dt-bindings: media: renesas,drif: Add r8a77965 support
> >>   arm64: dts: r8a77965: Add DRIF support
> >>
> >>  .../bindings/media/renesas,drif.txt   | 177 ---
> >>  .../bindings/media/renesas,drif.yaml  | 279 ++
> >>  MAINTAINERS   |   4 +-
> >>  arch/arm64/boot/dts/renesas/r8a77965.dtsi | 120 
> >>  4 files changed, 401 insertions(+), 179 deletions(-)
> >>  delete mode 100644 
> >> Documentation/devicetree/bindings/media/renesas,drif.txt
> >>  create mode 100644 
> >> Documentation/devicetree/bindings/media/renesas,drif.yaml

-- 
Regards,

Laurent Pinchart


Re: [PATCH v1 3/8] software node: Show properties and their values in sysfs

2021-03-27 Thread kernel test robot
Hi Andy,

I love your patch! Yet something to improve:

[auto build test ERROR on driver-core/driver-core-testing]
[also build test ERROR on linuxtv-media/master linux/master linus/master 
v5.12-rc4 next-20210326]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Andy-Shevchenko/software-node-Free-resources-explicitly-when-swnode_register-fails/20210328-062322
base:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git 
ecdc996baf291b903342cc704f4086a88c361967
config: microblaze-randconfig-r016-20210328 (attached as .config)
compiler: microblaze-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://github.com/0day-ci/linux/commit/1d48129700f39fc70d26e5faee27e6fd7d8d5234
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Andy-Shevchenko/software-node-Free-resources-explicitly-when-swnode_register-fails/20210328-062322
git checkout 1d48129700f39fc70d26e5faee27e6fd7d8d5234
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=microblaze 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All errors (new ones prefixed by >>):

   In file included from include/linux/kobject.h:20,
from include/linux/energy_model.h:7,
from include/linux/device.h:16,
from drivers/base/swnode.c:9:
   drivers/base/swnode.c: In function 'swnode_register_properties':
>> include/linux/sysfs.h:55:8: error: 'struct kobj_attribute' has no member 
>> named 'key'
  55 |  (attr)->key = &__key;\
 |^~
   drivers/base/swnode.c:835:3: note: in expansion of macro 'sysfs_attr_init'
 835 |   sysfs_attr_init([n]);
 |   ^~~


vim +55 include/linux/sysfs.h

^1da177e4c3f41 Linus Torvalds2005-04-16  39  
35960258ed388c Eric W. Biederman 2010-02-12  40  /**
35960258ed388c Eric W. Biederman 2010-02-12  41   * sysfs_attr_init - 
initialize a dynamically allocated sysfs attribute
35960258ed388c Eric W. Biederman 2010-02-12  42   * @attr: struct attribute 
to initialize
35960258ed388c Eric W. Biederman 2010-02-12  43   *
35960258ed388c Eric W. Biederman 2010-02-12  44   * Initialize a 
dynamically allocated struct attribute so we can
35960258ed388c Eric W. Biederman 2010-02-12  45   * make lockdep happy.  
This is a new requirement for attributes
35960258ed388c Eric W. Biederman 2010-02-12  46   * and initially this is 
only needed when lockdep is enabled.
35960258ed388c Eric W. Biederman 2010-02-12  47   * Lockdep gives a nice 
error when your attribute is added to
35960258ed388c Eric W. Biederman 2010-02-12  48   * sysfs if you don't have 
this.
35960258ed388c Eric W. Biederman 2010-02-12  49   */
6992f5334995af Eric W. Biederman 2010-02-11  50  #ifdef CONFIG_DEBUG_LOCK_ALLOC
6992f5334995af Eric W. Biederman 2010-02-11  51  #define sysfs_attr_init(attr)  
\
6992f5334995af Eric W. Biederman 2010-02-11  52  do {   
\
6992f5334995af Eric W. Biederman 2010-02-11  53 static struct 
lock_class_key __key; \
6992f5334995af Eric W. Biederman 2010-02-11  54 
\
6992f5334995af Eric W. Biederman 2010-02-11 @55 (attr)->key = &__key;   
\
6992f5334995af Eric W. Biederman 2010-02-11  56  } while (0)
6992f5334995af Eric W. Biederman 2010-02-11  57  #else
6992f5334995af Eric W. Biederman 2010-02-11  58  #define sysfs_attr_init(attr) 
do {} while (0)
6992f5334995af Eric W. Biederman 2010-02-11  59  #endif
6992f5334995af Eric W. Biederman 2010-02-11  60  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip


Re: Testers wanted: Atom netbooks with x86_64 disabled by BIOS

2021-03-27 Thread Thomas Gleixner
On Sun, Mar 28 2021 at 00:25, Willy Tarreau wrote:
> On Sat, Mar 27, 2021 at 10:13:22PM +0100, Mateusz Jonczyk wrote:
> FWIW I tested on my ASUS 1025C which runs on an Atom N2600 forced to
> 32-bit. I had already tried in the past but wanted to give it a try
> again in case I'd have missed anything. Sadly it didn't work, I'm
> still getting the "requires an x86-64 CPU" message.
>
> Given these machines were really cheap, I've always suspected that they
> employ cheaper, low-grade CPUs, possibly having been subject to reduced
> tests where x86_64-specific parts were not even verified and might be
> defective. This may explain why they forcefully disable long mode there,
> but that's just speculation.

There are some of these '32bit only' CPUs out there in the wild which
actually support long mode. Some of them even do not have the long mode
CPUID bit fused out. But whether it works is a different story:

  - If the CPUID bit is on, then the chance is high, but it runs out of
spec (guarantee wise)

  - If it's off is still might work by some definition of work as they
might have fused off more or there are actual defects in some 64bit
only area which are irrelevant when in 32bit mode.

Even if it could work perfectly fine, the BIOS/SMM/ucode can prevent
switching to long mode.

It's a lost cause.

Thanks,

tglx


[GIT PULL] SCSI fixes for 5.12-rc4

2021-03-27 Thread James Bottomley
Seven fixes, all in drivers (qla2xxx, mkt3sas, qedi, target, ibmvscsi).
The most serious are the target pscsi oom and the qla2xxx revert which
can otherwise cause a use after free.

The patch is available here:

git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes

The short changelog is:

Bart Van Assche (1):
  scsi: Revert "qla2xxx: Make sure that aborted commands are freed"

Jia-Ju Bai (2):
  scsi: mpt3sas: Fix error return code of mpt3sas_base_attach()
  scsi: qedi: Fix error return code of qedi_alloc_global_queues()

Martin Wilck (2):
  scsi: target: pscsi: Clean up after failure in pscsi_map_sg()
  scsi: target: pscsi: Avoid OOM in pscsi_map_sg()

Tyrel Datwyler (2):
  scsi: ibmvfc: Make ibmvfc_wait_for_ops() MQ aware
  scsi: ibmvfc: Fix potential race in ibmvfc_wait_for_ops()

And the diffstat:

 drivers/scsi/ibmvscsi/ibmvfc.c  | 67 ++---
 drivers/scsi/mpt3sas/mpt3sas_base.c |  8 +++--
 drivers/scsi/qedi/qedi_main.c   |  1 +
 drivers/scsi/qla2xxx/qla_target.c   | 13 +++
 drivers/scsi/qla2xxx/tcm_qla2xxx.c  |  4 ---
 drivers/target/target_core_pscsi.c  |  9 -
 6 files changed, 74 insertions(+), 28 deletions(-)

With full diff below.

James

---

diff --git a/drivers/scsi/ibmvscsi/ibmvfc.c b/drivers/scsi/ibmvscsi/ibmvfc.c
index 6a92891ac488..bb64e3247a6c 100644
--- a/drivers/scsi/ibmvscsi/ibmvfc.c
+++ b/drivers/scsi/ibmvscsi/ibmvfc.c
@@ -2371,6 +2371,24 @@ static int ibmvfc_match_lun(struct ibmvfc_event *evt, 
void *device)
return 0;
 }
 
+/**
+ * ibmvfc_event_is_free - Check if event is free or not
+ * @evt:   ibmvfc event struct
+ *
+ * Returns:
+ * true / false
+ **/
+static bool ibmvfc_event_is_free(struct ibmvfc_event *evt)
+{
+   struct ibmvfc_event *loop_evt;
+
+   list_for_each_entry(loop_evt, >queue->free, queue_list)
+   if (loop_evt == evt)
+   return true;
+
+   return false;
+}
+
 /**
  * ibmvfc_wait_for_ops - Wait for ops to complete
  * @vhost: ibmvfc host struct
@@ -2385,35 +2403,58 @@ static int ibmvfc_wait_for_ops(struct ibmvfc_host 
*vhost, void *device,
 {
struct ibmvfc_event *evt;
DECLARE_COMPLETION_ONSTACK(comp);
-   int wait;
+   int wait, i, q_index, q_size;
unsigned long flags;
signed long timeout = IBMVFC_ABORT_WAIT_TIMEOUT * HZ;
+   struct ibmvfc_queue *queues;
 
ENTER;
+   if (vhost->mq_enabled && vhost->using_channels) {
+   queues = vhost->scsi_scrqs.scrqs;
+   q_size = vhost->scsi_scrqs.active_queues;
+   } else {
+   queues = >crq;
+   q_size = 1;
+   }
+
do {
wait = 0;
-   spin_lock_irqsave(>crq.l_lock, flags);
-   list_for_each_entry(evt, >crq.sent, queue_list) {
-   if (match(evt, device)) {
-   evt->eh_comp = 
-   wait++;
+   spin_lock_irqsave(vhost->host->host_lock, flags);
+   for (q_index = 0; q_index < q_size; q_index++) {
+   spin_lock([q_index].l_lock);
+   for (i = 0; i < queues[q_index].evt_pool.size; i++) {
+   evt = [q_index].evt_pool.events[i];
+   if (!ibmvfc_event_is_free(evt)) {
+   if (match(evt, device)) {
+   evt->eh_comp = 
+   wait++;
+   }
+   }
}
+   spin_unlock([q_index].l_lock);
}
-   spin_unlock_irqrestore(>crq.l_lock, flags);
+   spin_unlock_irqrestore(vhost->host->host_lock, flags);
 
if (wait) {
timeout = wait_for_completion_timeout(, timeout);
 
if (!timeout) {
wait = 0;
-   spin_lock_irqsave(>crq.l_lock, flags);
-   list_for_each_entry(evt, >crq.sent, 
queue_list) {
-   if (match(evt, device)) {
-   evt->eh_comp = NULL;
-   wait++;
+   spin_lock_irqsave(vhost->host->host_lock, 
flags);
+   for (q_index = 0; q_index < q_size; q_index++) {
+   spin_lock([q_index].l_lock);
+   for (i = 0; i < 
queues[q_index].evt_pool.size; i++) {
+   evt = 
[q_index].evt_pool.events[i];
+   if (!ibmvfc_event_is_free(evt)) 
{
+   if (match(evt, 

Re: Candidate Linux ABI for Intel AMX and hypothetical new related features

2021-03-27 Thread Thomas Gleixner
Andy,

On Fri, Mar 26 2021 at 16:18, Andy Lutomirski wrote:
> arch_prctl(ARCH_SET_XCR0, xcr0, lazy_states, sigsave_states,
> sigclear_states, 0);
>
> Sets xcr0.  All states are preallocated except that states in
> lazy_states may be unallocated in the kernel until used.  (Not
> supported at all in v1.  lazy_states & ~xcr0 != 0 is illegal.)  States
> in sigsave_states are saved in the signal frame.  States in
> sigclear_states are reset to the init state on signal delivery.
> States in sigsave_states are restored by sigreturn, and states not in
> sigsave_states are left alone by sigreturn.

I like the idea in principle.

> Optionally we come up with a new format for new features in the signal
> frame, since the current format is showing its age.  Taking 8kB for a
> signal with AMX is one thing.  Taking another 8kB for a nested signal
> if AMX is not in use is worse.

I don't think that we should make that optional to begin with. Sizing
sigaltstack is lottery as of today and making it more so does not help
at all.

> Optionally we make AVX-512 also default off, which fixes what is
> arguably a serious ABI break with AVX-512: lots of programs, following
> POSIX (!), seem to think that they know much much space to allocate
> for sigaltstack().   AVX-512 is too big.

I really wish we could do that. That AVX512 disaster is not trivial to
sort.

Let's focus on AMX first. That ship at least has not sailed yet, but if
it does without a proper resolution then it's going to sail deep south.
Maybe we end up with some ideas about the AVX512 issue as well that way.

The main problem I see is simply historical. Every other part of the
user stack space from libraries to applications tries to be "smart"
about utilizing the assumed best instruction set, feature extensions
which are detected when something is initialized. I can sing a song of
that because I was casually involved porting debian to an unsupported
architecture. Magic all over the place. Now add the whole pile of
proprietary software stacks, libraries on top of that picture and things
get completely out of control.

Why? Simply because user space has absolutely no concept about
orchestrating these things at all. That worked for a while by some
definition of works and this model is still proliferated today even by
players who should know better.

Even if you expected that some not so distant events and the experience
with fleet consistency would have stopped the 'performance first,
features first' chorus in some way, that's not what reality is.

Linux is not necessarily innocent. For years we just crammed features
into the kernel without thinking too hard about the big picture. But,
yes we realized the hard way that there is a problem and just adding yet
another magic 'make it work' hack for AMX is definitely the wrong
approach.

What are the possible problems when we make it a hard requirement for
AMX to be requested by an application/task in order to use it?

For the kernel itself. Not really any consequence I can think off
aside of unhappy campers in user space.

For user space this is disruptive and we have at least to come up with
some reasonable model how all involved components with different ideas
of how to best utilize a given CPU can be handled.

That starts at the very simple problem of feature enumeration. Up to now
CPUID is non-priviledged and a large amount of user space just takes
that as the ultimate reference. We can change that when CPUID faulting
in CPL3 is supported by the CPU which we can't depend on because it is
not architectural.

Though the little devil in my head tells me, that making AMX support
depend on the CPUID faulting capability might be not the worst thing.

Then we actually enforce CPUID faulting (finally) on CPUs which support
it, which would be a first step into the right direction simply because
then random library X has to go to the kernel and ask for it explicitely
or just shrug and use whatever the kernel is willing to hand out in
CPUID.

Now take that one step further. When the first part of some user space
application asks for it, then you can register that with the process and
make sane decisions for all other requesters which come after it, which
is an important step into the direction of having a common orchestration
for this.

Sure you can do that via XCR0 as well to some extent, but that CPUID
fault would solve a whole class of other problems which people who care
about feature consistency face today at least to some extent.

And contrary to XCR0, which is orthogonal and obviously still required
for the AMX (and hint AVX512) problem, CPUID faulting would just hand
out the feature bits which the kernel want's to hand out.

If the app, library or whatever still tries to use them, then they get
the #UD, #GP or whatever penalty is associated to that particular XCR0
disabled piece. It's not there, you tried, keep the pieces.

Making it solely depend on XCR0 and fault if not requested upfront is
bringing you into the 

Re: [PATCH 6/9] debugfs: Implement debugfs_create_str()

2021-03-27 Thread Steven Rostedt
On Sat, 27 Mar 2021 22:24:45 +
Al Viro  wrote:

> On Fri, Mar 26, 2021 at 11:33:58AM +0100, Peter Zijlstra wrote:
> 
> > +again:
> > +   rcu_read_lock();
> > +   str = rcu_dereference(*(char **)file->private_data);
> > +   len = strlen(str) + 1;
> > +
> > +   if (!copy || copy_len < len) {
> > +   rcu_read_unlock();
> > +   kfree(copy);
> > +   copy = kmalloc(len + 1, GFP_KERNEL);
> > +   if (!copy) {
> > +   debugfs_file_put(dentry);
> > +   return -ENOMEM;
> > +   }
> > +   copy_len = len;
> > +   goto again;
> > +   }
> > +
> > +   strncpy(copy, str, len);
> > +   copy[len] = '\n';
> > +   copy[len+1] = '\0';
> > +   rcu_read_unlock();  
> 
> *Ow*
> 
>   If the string can't change under you, what is RCU use about?
> And if it can, any use of string functions is asking for serious
> trouble; they are *not* guaranteed to be safe when any of the strings
> involved might be modified under them.

Just from looking at the above, RCU isn't protecting that the string
can change under you, but the pointer to file->private_data can.

str = rcu_dereference(*(char **)file->private_data);

That's just getting a pointer to the string. While under rcu, the value
of that string wont change nor will it be free. But file->private_data
might change, and it might free its old value, but will do so after a
RCU grace period (which is why the above has rcu_read_lock).

What the above looks like to me is a way to copy that string safely,
without worrying that it will be freed underneath you. But there's no
worry that it will change.

-- Steve


[GIT PULL] CIFS/SMB3 Fixes

2021-03-27 Thread Steve French
Please pull the following changes since commit
0d02ec6b3136c73c09e7859f0d0e4e2c4c07b49b:

  Linux 5.12-rc4 (2021-03-21 14:56:43 -0700)

are available in the Git repository at:

  git://git.samba.org/sfrench/cifs-2.6.git tags/5.12-rc4-smb3

for you to fetch changes up to cfc63fc8126a93cbf95379bc4cad79a7b15b6ece:

  smb3: fix cached file size problems in duplicate extents (reflink)
(2021-03-26 18:41:55 -0500)


5 cifs/smb3 fixes, 2 for stable, includes an important fix for
encryption and an ACL fix, as well as two fixes for possible data
corruptions (one for reflink and one for SMB1)

Test results: 
http://smb3-test-rhel-75.southcentralus.cloudapp.azure.com/#/builders/2/builds/543

Ronnie Sahlberg (1):
  cifs: revalidate mapping when we open files for SMB1 POSIX

Shyam Prasad N (2):
  cifs: Adjust key sizes and key generation routines for AES256 encryption
  cifs: Fix chmod with modefromsid when an older ACE already exists.

Steve French (1):
  smb3: fix cached file size problems in duplicate extents (reflink)

Vincent Whitchurch (1):
  cifs: Silently ignore unknown oplock break handle

 fs/cifs/cifsacl.c   |  3 +--
 fs/cifs/cifsglob.h  |  4 ++--
 fs/cifs/cifspdu.h   |  5 +
 fs/cifs/file.c  |  1 +
 fs/cifs/smb2glob.h  |  1 +
 fs/cifs/smb2misc.c  |  4 ++--
 fs/cifs/smb2ops.c   | 27 ---
 fs/cifs/smb2transport.c | 37 -
 8 files changed, 60 insertions(+), 22 deletions(-)

-- 
Thanks,

Steve


Re: [syzbot] KASAN: null-ptr-deref Read in filp_close (2)

2021-03-27 Thread Al Viro
On Fri, Mar 26, 2021 at 02:50:11PM +0100, Christian Brauner wrote:
> @@ -632,6 +632,7 @@ EXPORT_SYMBOL(close_fd); /* for ksys_close() */
>  static inline void __range_cloexec(struct files_struct *cur_fds,
>  unsigned int fd, unsigned int max_fd)
>  {
> + unsigned int cur_max;
>   struct fdtable *fdt;
>  
>   if (fd > max_fd)
> @@ -639,7 +640,12 @@ static inline void __range_cloexec(struct files_struct 
> *cur_fds,
>  
>   spin_lock(_fds->file_lock);
>   fdt = files_fdtable(cur_fds);
> - bitmap_set(fdt->close_on_exec, fd, max_fd - fd + 1);
> + /* make very sure we're using the correct maximum value */
> + cur_max = fdt->max_fds;
> + cur_max--;
> + cur_max = min(max_fd, cur_max);
> + if (fd <= cur_max)
> + bitmap_set(fdt->close_on_exec, fd, cur_max - fd + 1);
>   spin_unlock(_fds->file_lock);
>  }

Umm...  That's harder to follow than it ought to be.  What's the point of
having
max_fd = min(max_fd, cur_max);
done in the caller, anyway?  Note that in __range_close() you have to
compare with re-fetched ->max_fds (look at pick_file()), so...

BTW, I really wonder if the cost of jerking ->file_lock up and down
in that loop in __range_close() is negligible.  What values do we
typically get from callers and how sparse does descriptor table tend
to be for those?


[PATCH] USB: serial: iuu_phoenix: remove redundant variable 'error'

2021-03-27 Thread Colin King
From: Colin Ian King 

The variable error is initialized to 0 and is set to 1 this
value is never read as it is on an immediate return path. The
only read of error is to check it is 0 and this check is always
true at that point of the code. The variable is redundant and
can be removed.

Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King 
---
 drivers/usb/serial/iuu_phoenix.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/usb/serial/iuu_phoenix.c b/drivers/usb/serial/iuu_phoenix.c
index 093afd67a664..19753611e7b0 100644
--- a/drivers/usb/serial/iuu_phoenix.c
+++ b/drivers/usb/serial/iuu_phoenix.c
@@ -643,7 +643,6 @@ static void iuu_uart_read_callback(struct urb *urb)
struct iuu_private *priv = usb_get_serial_port_data(port);
unsigned long flags;
int status = urb->status;
-   int error = 0;
int len = 0;
unsigned char *data = urb->transfer_buffer;
priv->poll++;
@@ -660,12 +659,11 @@ static void iuu_uart_read_callback(struct urb *urb)
if (urb->actual_length > 1) {
dev_dbg(>dev, "%s - urb->actual_length = %i\n", __func__,
urb->actual_length);
-   error = 1;
return;
}
/* if len > 0 call readbuf */
 
-   if (len > 0 && error == 0) {
+   if (len > 0) {
dev_dbg(>dev, "%s - call read buf - len to read is %i\n",
__func__, len);
status = iuu_read_buf(port, len);
-- 
2.30.2



[PATCH 1/2] sched/debug: Don't disable IRQ when acquiring sched_debug_lock

2021-03-27 Thread Waiman Long
The sched_debug_lock was used only in print_cpu().  The
print_cpu() function has two callers - sched_debug_show() and
sysrq_sched_debug_show(). Both of them are invoked by user action
(sched_debug file and sysrq-t). As print_cpu() won't be called from
interrupt context at all, there is no point in disabling IRQ when
acquiring sched_debug_lock.

Besides, if the system has many cpus and the sched_debug_lock is somehow
busy (e.g. parallel sysrq-t), the system may hit a hard lockup panic, like

[ 7809.796262] Kernel panic - not syncing: Hard LOCKUP
[ 7809.796264] CPU: 13 PID: 79867 Comm: reproducer.sh Kdump: loaded Tainted: G  
I  - -  - 4.18.0-301.el8.x86_64 #1
[ 7809.796264] Hardware name: Dell Inc. PowerEdge R640/0W23H8, BIOS 1.4.9 
06/29/2018
[ 7809.796265] Call Trace:
[ 7809.796265]  
[ 7809.796266]  dump_stack+0x5c/0x80
[ 7809.796266]  panic+0xe7/0x2a9
[ 7809.796267]  nmi_panic.cold.9+0xc/0xc
[ 7809.796267]  watchdog_overflow_callback.cold.7+0x5c/0x70
[ 7809.796268]  __perf_event_overflow+0x52/0xf0
[ 7809.796268]  handle_pmi_common+0x204/0x2a0
[ 7809.796269]  ? __set_pte_vaddr+0x32/0x50
[ 7809.796269]  ? __native_set_fixmap+0x24/0x30
[ 7809.796270]  ? ghes_copy_tofrom_phys+0xd3/0x1c0
[ 7809.796271]  intel_pmu_handle_irq+0xbf/0x160
[ 7809.796271]  perf_event_nmi_handler+0x2d/0x50
[ 7809.796272]  nmi_handle+0x63/0x110
[ 7809.796272]  default_do_nmi+0x49/0x100
[ 7809.796273]  do_nmi+0x17e/0x1e0
[ 7809.796273]  end_repeat_nmi+0x16/0x6f
[ 7809.796274] RIP: 0010:native_queued_spin_lock_slowpath+0x5b/0x1d0
[ 7809.796275] Code: 6d f0 0f ba 2f 08 0f 92 c0 0f b6 c0 c1 e0 08 89 c2 8b 07 
30 e4 09 d0 a9 00 01 ff ff 75 47 85 c0 74 0e 8b 07 84 c0 74 08 f3 90 <8b> 07 84 
c0 75 f8 b8 01 00 00 00 66 89 07 c3 8b 37 81 fe 00 01 00
[ 7809.796276] RSP: 0018:aa54cd887df8 EFLAGS: 0002
[ 7809.796277] RAX: 0101 RBX: 0246 RCX: 
[ 7809.796278] RDX:  RSI:  RDI: 936b66d0
[ 7809.796278] RBP: 9301fb40 R08: 0004 R09: 004f
[ 7809.796279] R10:  R11: aa54cd887cc0 R12: 907fd0a29ec0
[ 7809.796280] R13:  R14: 926ab7c0 R15: 
[ 7809.796280]  ? native_queued_spin_lock_slowpath+0x5b/0x1d0
[ 7809.796281]  ? native_queued_spin_lock_slowpath+0x5b/0x1d0
[ 7809.796281]  
[ 7809.796282]  _raw_spin_lock_irqsave+0x32/0x40
[ 7809.796283]  print_cpu+0x261/0x7c0
[ 7809.796283]  sysrq_sched_debug_show+0x34/0x50
[ 7809.796284]  sysrq_handle_showstate+0xc/0x20
[ 7809.796284]  __handle_sysrq.cold.11+0x48/0xfb
[ 7809.796285]  write_sysrq_trigger+0x2b/0x30
[ 7809.796285]  proc_reg_write+0x39/0x60
[ 7809.796286]  vfs_write+0xa5/0x1a0
[ 7809.796286]  ksys_write+0x4f/0xb0
[ 7809.796287]  do_syscall_64+0x5b/0x1a0
[ 7809.796287]  entry_SYSCALL_64_after_hwframe+0x65/0xca
[ 7809.796288] RIP: 0033:0x7fabe4ceb648

It is not to disable IRQ for so long that a hard lockup panic is
triggered. Fix that by not disabling IRQ when taking sched_debug_lock.

Fixes: efe25c2c7b3a ("sched: Reinstate group names in /proc/sched_debug")
Signed-off-by: Waiman Long 
---
 kernel/sched/debug.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c
index 486f403a778b..c4ae8a0853a1 100644
--- a/kernel/sched/debug.c
+++ b/kernel/sched/debug.c
@@ -666,7 +666,6 @@ void print_dl_rq(struct seq_file *m, int cpu, struct dl_rq 
*dl_rq)
 static void print_cpu(struct seq_file *m, int cpu)
 {
struct rq *rq = cpu_rq(cpu);
-   unsigned long flags;
 
 #ifdef CONFIG_X86
{
@@ -717,13 +716,13 @@ do {  
\
}
 #undef P
 
-   spin_lock_irqsave(_debug_lock, flags);
+   spin_lock(_debug_lock);
print_cfs_stats(m, cpu);
print_rt_stats(m, cpu);
print_dl_stats(m, cpu);
 
print_rq(m, rq, cpu);
-   spin_unlock_irqrestore(_debug_lock, flags);
+   spin_unlock(_debug_lock);
SEQ_printf(m, "\n");
 }
 
-- 
2.18.1



[PATCH 2/2] sched/debug: Use sched_debug_lock to serialize use of cgroup_path[] only

2021-03-27 Thread Waiman Long
The purpose of sched_debug_lock is to serialize the use of the global
cgroup_path[] buffer in print_cpu(). The rests of the printf calls
don't need serialization from sched_debug_lock. The printing of sched
debug data to console can take quite a while, taking sched_debug_lock
at the print_cpu() level will unnecessarily block the progress of other
print_cpu() users. Fix that by holding sched_debug_lock only when using
cgroup_path[] via task_group_path().

Signed-off-by: Waiman Long 
---
 kernel/sched/debug.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c
index c4ae8a0853a1..87168d13714f 100644
--- a/kernel/sched/debug.c
+++ b/kernel/sched/debug.c
@@ -8,8 +8,6 @@
  */
 #include "sched.h"
 
-static DEFINE_SPINLOCK(sched_debug_lock);
-
 /*
  * This allows printing both to /proc/sched_debug and
  * to the console
@@ -470,6 +468,7 @@ static void print_cfs_group_stats(struct seq_file *m, int 
cpu, struct task_group
 #endif
 
 #ifdef CONFIG_CGROUP_SCHED
+static DEFINE_SPINLOCK(sched_debug_lock);
 static char group_path[PATH_MAX];
 
 static char *task_group_path(struct task_group *tg)
@@ -506,7 +505,9 @@ print_task(struct seq_file *m, struct rq *rq, struct 
task_struct *p)
SEQ_printf(m, " %d %d", task_node(p), task_numa_group_id(p));
 #endif
 #ifdef CONFIG_CGROUP_SCHED
+   spin_lock(_debug_lock);
SEQ_printf(m, " %s", task_group_path(task_group(p)));
+   spin_unlock(_debug_lock);
 #endif
 
SEQ_printf(m, "\n");
@@ -543,7 +544,9 @@ void print_cfs_rq(struct seq_file *m, int cpu, struct 
cfs_rq *cfs_rq)
 
 #ifdef CONFIG_FAIR_GROUP_SCHED
SEQ_printf(m, "\n");
+   spin_lock(_debug_lock);
SEQ_printf(m, "cfs_rq[%d]:%s\n", cpu, task_group_path(cfs_rq->tg));
+   spin_unlock(_debug_lock);
 #else
SEQ_printf(m, "\n");
SEQ_printf(m, "cfs_rq[%d]:\n", cpu);
@@ -614,7 +617,9 @@ void print_rt_rq(struct seq_file *m, int cpu, struct rt_rq 
*rt_rq)
 {
 #ifdef CONFIG_RT_GROUP_SCHED
SEQ_printf(m, "\n");
+   spin_lock(_debug_lock);
SEQ_printf(m, "rt_rq[%d]:%s\n", cpu, task_group_path(rt_rq->tg));
+   spin_unlock(_debug_lock);
 #else
SEQ_printf(m, "\n");
SEQ_printf(m, "rt_rq[%d]:\n", cpu);
@@ -716,13 +721,11 @@ do {  
\
}
 #undef P
 
-   spin_lock(_debug_lock);
print_cfs_stats(m, cpu);
print_rt_stats(m, cpu);
print_dl_stats(m, cpu);
 
print_rq(m, rq, cpu);
-   spin_unlock(_debug_lock);
SEQ_printf(m, "\n");
 }
 
-- 
2.18.1



Re: Testers wanted: Atom netbooks with x86_64 disabled by BIOS

2021-03-27 Thread Willy Tarreau
Hi,

On Sat, Mar 27, 2021 at 10:13:22PM +0100, Mateusz Jonczyk wrote:
> W dniu 27.03.2021 o 21:32, Mateusz Jonczyk pisze:
> > Hello,
> >
> > There are some netbooks with Intel Atom processors that have 64-bit
> > support disabled by BIOS. Theoretically, the processor supports 64-bit
> > operation, but BIOS allows only 32-bit code to run.
> >
> > I wonder whether the 64-bit mode is really disabled in the CPU or only
> > hidden in the CPUID flags. If the latter, the computer could be made to
> > run a 64-bit kernel.
> >
> > Similarly, there are some Pentium M processors that support PAE
> > (Physical Address Extensions), but do not show this in CPUID. They could
> > be made to run distributions that require PAE with the "forcepae" kernel
> > command line parameter.
> >
> > I would like to ask people with such netbooks to try to run a 64-bit kernel
> > with this patch applied.
> >
> > When a patched 64-bit kernel is run in `qemu-system-i386`, the virtual
> > machine restarts instantly. Without this patch in such a case a 64-bit
> > kernel hangs indefinitely (inside .Lno_longmode in head_64.S).
> 
> I have made two mistakes:
> - I left commented out code,
> - I have commented out lines with '#'. The code compiled though.
> 
> Attaching corrected patch, please excuse me.

FWIW I tested on my ASUS 1025C which runs on an Atom N2600 forced to
32-bit. I had already tried in the past but wanted to give it a try
again in case I'd have missed anything. Sadly it didn't work, I'm
still getting the "requires an x86-64 CPU" message.

Given these machines were really cheap, I've always suspected that they
employ cheaper, low-grade CPUs, possibly having been subject to reduced
tests where x86_64-specific parts were not even verified and might be
defective. This may explain why they forcefully disable long mode there,
but that's just speculation.

Cheers,
Willy


[PATCH] scsi: qedi: emove redundant assignment to variable err

2021-03-27 Thread Colin King
From: Colin Ian King 

variable err is assigned -ENOMEM followed by an error return path
via label err_udev that does not access the variable and returns
with the -ENOMEM error return code. The assignment to err is
redundant and can be removed.

Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King 
---
 drivers/scsi/qedi/qedi_main.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/scsi/qedi/qedi_main.c b/drivers/scsi/qedi/qedi_main.c
index 69c5b5ee2169..2455d1448a7e 100644
--- a/drivers/scsi/qedi/qedi_main.c
+++ b/drivers/scsi/qedi/qedi_main.c
@@ -276,10 +276,8 @@ static int qedi_alloc_uio_rings(struct qedi_ctx *qedi)
}
 
udev = kzalloc(sizeof(*udev), GFP_KERNEL);
-   if (!udev) {
-   rc = -ENOMEM;
+   if (!udev)
goto err_udev;
-   }
 
udev->uio_dev = -1;
 
-- 
2.30.2



Re: [PATCH v4 2/3] drm/encoder: Add macro drmm_plain_encoder_alloc()

2021-03-27 Thread Laurent Pinchart
Hi Paul,

Thank you for the patch.

On Sat, Mar 27, 2021 at 11:57:41AM +, Paul Cercueil wrote:
> This performs the same operation as drmm_encoder_alloc(), but
> only allocates and returns a struct drm_encoder instance.
> 
> v4: Rename macro drmm_plain_encoder_alloc() and move to
> . Since it's not "simple" anymore it
> will now take funcs/name arguments as well.
> 
> Signed-off-by: Paul Cercueil 

Reviewed-by: Laurent Pinchart 

> ---
>  include/drm/drm_encoder.h | 18 ++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/include/drm/drm_encoder.h b/include/drm/drm_encoder.h
> index 5bf78b5bcb2b..6e91a0280f31 100644
> --- a/include/drm/drm_encoder.h
> +++ b/include/drm/drm_encoder.h
> @@ -224,6 +224,24 @@ void *__drmm_encoder_alloc(struct drm_device *dev,
> offsetof(type, member), funcs, \
> encoder_type, name, ##__VA_ARGS__))
>  
> +/**
> + * drmm_plain_encoder_alloc - Allocate and initialize an encoder
> + * @dev: drm device
> + * @funcs: callbacks for this encoder (optional)
> + * @encoder_type: user visible type of the encoder
> + * @name: printf style format string for the encoder name, or NULL for 
> default name
> + *
> + * This is a simplified version of drmm_encoder_alloc(), which only allocates
> + * and returns a struct drm_encoder instance, with no subclassing.
> + *
> + * Returns:
> + * Pointer to the new drm_encoder struct, or ERR_PTR on failure.
> + */
> +#define drmm_plain_encoder_alloc(dev, funcs, encoder_type, name, ...) \
> + ((struct drm_encoder *) \
> +  __drmm_encoder_alloc(dev, sizeof(struct drm_encoder), \
> +   0, funcs, encoder_type, name, ##__VA_ARGS__))
> +
>  /**
>   * drm_encoder_index - find the index of a registered encoder
>   * @encoder: encoder to find index for

-- 
Regards,

Laurent Pinchart


Re: [PATCH] PCI: Remove pci_try_set_mwi

2021-03-27 Thread Heiner Kallweit
On 26.03.2021 22:26, Bjorn Helgaas wrote:
> [+cc Randy, Andrew (though I'm sure you have zero interest in this
> ancient question :))]
> 
> On Wed, Dec 09, 2020 at 09:31:21AM +0100, Heiner Kallweit wrote:
>> pci_set_mwi() and pci_try_set_mwi() do exactly the same, just that the
>> former one is declared as __must_check. However also some callers of
>> pci_set_mwi() have a comment that it's an optional feature. I don't
>> think there's much sense in this separation and the use of
>> __must_check. Therefore remove pci_try_set_mwi() and remove the
>> __must_check attribute from pci_set_mwi().
>> I don't expect either function to be used in new code anyway.
> 
> There's not much I like better than removing things.  But some
> significant thought went into adding pci_try_set_mwi() in the first
> place, so I need a little more convincing about why it's safe to
> remove it.
> 

Thanks for the link to the 13 yrs old discussion. Unfortunately it
doesn't mention any real argument for the __must_check, just:

"And one of the reasons for adding the __must_check annotation is to
weed out design errors."
And the very next response in the discussion calls this a "non-argument".
Plus not mentioning what the other reasons could be.

Currently we have three ancient drivers that bail out if the call fails.
Most callers of pci_set_mwi() use the return code only to emit an
error message, but they proceed normally. Majority of users calls
pci_try_set_mwi(). And as stated in the commit message I don't expect
any new usage of pci_set_mwi().

> The argument should cite the discussion about adding it.  I think one
> of the earliest conversations is here:
> https://lore.kernel.org/linux-ide/20070404213704.224128ec.randy.dun...@oracle.com/
> 
>> Signed-off-by: Heiner Kallweit 
>> ---
>> patch applies on top of pci/misc for v5.11
>> ---
>>  Documentation/PCI/pci.rst |  5 +
>>  drivers/ata/pata_cs5530.c |  2 +-
>>  drivers/ata/sata_mv.c |  2 +-
>>  drivers/dma/dw/pci.c  |  2 +-
>>  drivers/dma/hsu/pci.c |  2 +-
>>  drivers/ide/cs5530.c  |  2 +-
>>  drivers/mfd/intel-lpss-pci.c  |  2 +-
>>  drivers/net/ethernet/adaptec/starfire.c   |  2 +-
>>  drivers/net/ethernet/alacritech/slicoss.c |  2 +-
>>  drivers/net/ethernet/dec/tulip/tulip_core.c   |  5 +
>>  drivers/net/ethernet/sun/cassini.c|  4 ++--
>>  drivers/net/wireless/intersil/p54/p54pci.c|  2 +-
>>  .../intersil/prism54/islpci_hotplug.c |  3 +--
>>  .../wireless/realtek/rtl818x/rtl8180/dev.c|  2 +-
>>  drivers/pci/pci.c | 19 ---
>>  drivers/scsi/3w-9xxx.c|  4 ++--
>>  drivers/scsi/3w-sas.c |  4 ++--
>>  drivers/scsi/csiostor/csio_init.c |  2 +-
>>  drivers/scsi/lpfc/lpfc_init.c |  2 +-
>>  drivers/scsi/qla2xxx/qla_init.c   |  8 
>>  drivers/scsi/qla2xxx/qla_mr.c |  2 +-
>>  drivers/tty/serial/8250/8250_lpss.c   |  2 +-
>>  drivers/usb/chipidea/ci_hdrc_pci.c|  2 +-
>>  drivers/usb/gadget/udc/amd5536udc_pci.c   |  2 +-
>>  drivers/usb/gadget/udc/net2280.c  |  2 +-
>>  drivers/usb/gadget/udc/pch_udc.c  |  2 +-
>>  include/linux/pci.h   |  5 ++---
>>  27 files changed, 33 insertions(+), 60 deletions(-)
>>
>> diff --git a/Documentation/PCI/pci.rst b/Documentation/PCI/pci.rst
>> index 814b40f83..120362cc9 100644
>> --- a/Documentation/PCI/pci.rst
>> +++ b/Documentation/PCI/pci.rst
>> @@ -226,10 +226,7 @@ If the PCI device can use the PCI 
>> Memory-Write-Invalidate transaction,
>>  call pci_set_mwi().  This enables the PCI_COMMAND bit for Mem-Wr-Inval
>>  and also ensures that the cache line size register is set correctly.
>>  Check the return value of pci_set_mwi() as not all architectures
>> -or chip-sets may support Memory-Write-Invalidate.  Alternatively,
>> -if Mem-Wr-Inval would be nice to have but is not required, call
>> -pci_try_set_mwi() to have the system do its best effort at enabling
>> -Mem-Wr-Inval.
>> +or chip-sets may support Memory-Write-Invalidate.
>>  
>>  
>>  Request MMIO/IOP resources
>> diff --git a/drivers/ata/pata_cs5530.c b/drivers/ata/pata_cs5530.c
>> index ad75d02b6..8654b3ae1 100644
>> --- a/drivers/ata/pata_cs5530.c
>> +++ b/drivers/ata/pata_cs5530.c
>> @@ -214,7 +214,7 @@ static int cs5530_init_chip(void)
>>  }
>>  
>>  pci_set_master(cs5530_0);
>> -pci_try_set_mwi(cs5530_0);
>> +pci_set_mwi(cs5530_0);
>>  
>>  /*
>>   * Set PCI CacheLineSize to 16-bytes:
>> diff --git a/drivers/ata/sata_mv.c b/drivers/ata/sata_mv.c
>> index 664ef658a..ee37755ea 100644
>> --- a/drivers/ata/sata_mv.c
>> +++ b/drivers/ata/sata_mv.c
>> @@ -4432,7 +4432,7 @@ static int mv_pci_init_one(struct pci_dev *pdev,
>>  mv_print_info(host);
>>  

[PATCH] rtlwifi: remove redundant assignment to variable err

2021-03-27 Thread Colin King
From: Colin Ian King 

Variable err is assigned -ENODEV followed by an error return path
via label error_out that does not access the variable and returns
with the -ENODEV error return code. The assignment to err is
redundant and can be removed.

Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King 
---
 drivers/net/wireless/realtek/rtlwifi/usb.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/usb.c 
b/drivers/net/wireless/realtek/rtlwifi/usb.c
index 6c5e242b1bc5..37a9a03123f3 100644
--- a/drivers/net/wireless/realtek/rtlwifi/usb.c
+++ b/drivers/net/wireless/realtek/rtlwifi/usb.c
@@ -1070,7 +1070,6 @@ int rtl_usb_probe(struct usb_interface *intf,
err = ieee80211_register_hw(hw);
if (err) {
pr_err("Can't register mac80211 hw.\n");
-   err = -ENODEV;
goto error_out;
}
rtlpriv->mac80211.mac80211_registered = 1;
-- 
2.30.2



[PATCH v2 1/1] x86/tdx: Handle MWAIT, MONITOR and WBINVD

2021-03-27 Thread Kuppuswamy Sathyanarayanan
In non-root TDX guest mode, MWAIT, MONITOR and WBINVD instructions
are not supported. So handle #VE due to these instructions as no ops.

Signed-off-by: Kuppuswamy Sathyanarayanan 

Reviewed-by: Andi Kleen 
---

Changes since v1:
 * Added WARN() for MWAIT #VE exception.

Changes since previous series:
 * Suppressed MWAIT feature as per Andi's comment.
 * Added warning debug log for MWAIT #VE exception.

 arch/x86/kernel/tdx.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/arch/x86/kernel/tdx.c b/arch/x86/kernel/tdx.c
index e936b2f88bf6..3c6158a53c17 100644
--- a/arch/x86/kernel/tdx.c
+++ b/arch/x86/kernel/tdx.c
@@ -308,6 +308,9 @@ void __init tdx_early_init(void)
 
setup_force_cpu_cap(X86_FEATURE_TDX_GUEST);
 
+   /* MWAIT is not supported in TDX platform, so suppress it */
+   setup_clear_cpu_cap(X86_FEATURE_MWAIT);
+
tdg_get_info();
 
pv_ops.irq.safe_halt = tdg_safe_halt;
@@ -362,6 +365,26 @@ int tdg_handle_virtualization_exception(struct pt_regs 
*regs,
case EXIT_REASON_EPT_VIOLATION:
ve->instr_len = tdg_handle_mmio(regs, ve);
break;
+   /*
+* Per Guest-Host-Communication Interface (GHCI) for Intel Trust
+* Domain Extensions (Intel TDX) specification, sec 2.4,
+* some instructions that unconditionally cause #VE (such as WBINVD,
+* MONITOR, MWAIT) do not have corresponding TDCALL
+* [TDG.VP.VMCALL ] leaves, since the TD has been designed
+* with no deterministic way to confirm the result of those operations
+* performed by the host VMM.  In those cases, the goal is for the TD
+* #VE handler to increment the RIP appropriately based on the VE
+* information provided via TDCALL.
+*/
+   case EXIT_REASON_WBINVD:
+   pr_warn_once("WBINVD #VE Exception\n");
+   case EXIT_REASON_MONITOR_INSTRUCTION:
+   /* Handle as nops. */
+   break;
+   case EXIT_REASON_MWAIT_INSTRUCTION:
+   /* MWAIT is supressed, not supposed to reach here. */
+   WARN(1, "MWAIT unexpected #VE Exception\n");
+   return -EFAULT;
default:
pr_warn("Unexpected #VE: %d\n", ve->exit_reason);
return -EFAULT;
-- 
2.25.1



arch/arm64/include/asm/syscall_wrapper.h:76:25: warning: no previous prototype for '__arm64_sys_process_madvise'

2021-03-27 Thread kernel test robot
tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   0f4498cef9f5cd18d7c6639a2a902ec1edc5be4e
commit: ecb8ac8b1f146915aa6b96449b66dd48984caacc mm/madvise: introduce 
process_madvise() syscall: an external memory hinting API
date:   5 months ago
config: arm64-randconfig-r011-20210328 (attached as .config)
compiler: aarch64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ecb8ac8b1f146915aa6b96449b66dd48984caacc
git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout ecb8ac8b1f146915aa6b96449b66dd48984caacc
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=arm64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>):

 | ^~~
   kernel/sys_ni.c:254:1: note: in expansion of macro 'COND_SYSCALL_COMPAT'
 254 | COND_SYSCALL_COMPAT(recvmsg);
 | ^~~
   arch/arm64/include/asm/syscall_wrapper.h:76:25: warning: no previous 
prototype for '__arm64_sys_mremap' [-Wmissing-prototypes]
  76 |  asmlinkage long __weak __arm64_sys_##name(const struct pt_regs 
*regs) \
 | ^~~~
   kernel/sys_ni.c:259:1: note: in expansion of macro 'COND_SYSCALL'
 259 | COND_SYSCALL(mremap);
 | ^~~~
   arch/arm64/include/asm/syscall_wrapper.h:76:25: warning: no previous 
prototype for '__arm64_sys_add_key' [-Wmissing-prototypes]
  76 |  asmlinkage long __weak __arm64_sys_##name(const struct pt_regs 
*regs) \
 | ^~~~
   kernel/sys_ni.c:262:1: note: in expansion of macro 'COND_SYSCALL'
 262 | COND_SYSCALL(add_key);
 | ^~~~
   arch/arm64/include/asm/syscall_wrapper.h:76:25: warning: no previous 
prototype for '__arm64_sys_request_key' [-Wmissing-prototypes]
  76 |  asmlinkage long __weak __arm64_sys_##name(const struct pt_regs 
*regs) \
 | ^~~~
   kernel/sys_ni.c:263:1: note: in expansion of macro 'COND_SYSCALL'
 263 | COND_SYSCALL(request_key);
 | ^~~~
   arch/arm64/include/asm/syscall_wrapper.h:76:25: warning: no previous 
prototype for '__arm64_sys_keyctl' [-Wmissing-prototypes]
  76 |  asmlinkage long __weak __arm64_sys_##name(const struct pt_regs 
*regs) \
 | ^~~~
   kernel/sys_ni.c:264:1: note: in expansion of macro 'COND_SYSCALL'
 264 | COND_SYSCALL(keyctl);
 | ^~~~
   arch/arm64/include/asm/syscall_wrapper.h:41:25: warning: no previous 
prototype for '__arm64_compat_sys_keyctl' [-Wmissing-prototypes]
  41 |  asmlinkage long __weak __arm64_compat_sys_##name(const struct 
pt_regs *regs) \
 | ^~~
   kernel/sys_ni.c:265:1: note: in expansion of macro 'COND_SYSCALL_COMPAT'
 265 | COND_SYSCALL_COMPAT(keyctl);
 | ^~~
   arch/arm64/include/asm/syscall_wrapper.h:76:25: warning: no previous 
prototype for '__arm64_sys_fadvise64_64' [-Wmissing-prototypes]
  76 |  asmlinkage long __weak __arm64_sys_##name(const struct pt_regs 
*regs) \
 | ^~~~
   kernel/sys_ni.c:270:1: note: in expansion of macro 'COND_SYSCALL'
 270 | COND_SYSCALL(fadvise64_64);
 | ^~~~
   arch/arm64/include/asm/syscall_wrapper.h:76:25: warning: no previous 
prototype for '__arm64_sys_swapon' [-Wmissing-prototypes]
  76 |  asmlinkage long __weak __arm64_sys_##name(const struct pt_regs 
*regs) \
 | ^~~~
   kernel/sys_ni.c:273:1: note: in expansion of macro 'COND_SYSCALL'
 273 | COND_SYSCALL(swapon);
 | ^~~~
   arch/arm64/include/asm/syscall_wrapper.h:76:25: warning: no previous 
prototype for '__arm64_sys_swapoff' [-Wmissing-prototypes]
  76 |  asmlinkage long __weak __arm64_sys_##name(const struct pt_regs 
*regs) \
 | ^~~~
   kernel/sys_ni.c:274:1: note: in expansion of macro 'COND_SYSCALL'
 274 | COND_SYSCALL(swapoff);
 | ^~~~
   arch/arm64/include/asm/syscall_wrapper.h:76:25: warning: no previous 
prototype for '__arm64_sys_mprotect' [-Wmissing-prototypes]
  76 |  asmlinkage long __weak __arm64_sys_##name(const struct pt_regs 
*regs) \
 | ^~~~
   kernel/sys_ni.c:275:1: note: in expansion of macro 'COND_SYSCALL'
 275 | COND_SYSCALL(mprotect);
 | ^~~~
   

[PATCH] of/fdt: Improve error checking

2021-03-27 Thread Guenter Roeck
If an unaligned pointer is passed to of_fdt_unflatten_tree(),
populate_node() as called from unflatten_dt_nodes() will fail.
unflatten_dt_nodes() will return 0 and set *nodepp to NULL.
This is not expected to happen in __unflatten_device_tree(),
which then tries to write into the NULL pointer, causing a crash
on openrisc if CONFIG_OF_UNITTEST=y.

 ### dt-test ### start of unittest - you will see error messages
Unable to handle kernel NULL pointer dereference
 at virtual address 0x0064

Oops#: 
CPU #: 0
   PC: c03a25d4SR: 807fSP: c102dd50
GPR00:  GPR01: c102dd50 GPR02: c102dd78 GPR03: c1704004
GPR04:  GPR05: c102dc18 GPR06: c102ddc8 GPR07: c102dcf7
GPR08: 0001 GPR09: c03a25a0 GPR10: c102c000 GPR11: c16fd75c
GPR12: ffb7 GPR13:  GPR14: 0008 GPR15: 
GPR16: c16fd75c GPR17: 0064 GPR18: c1704004 GPR19: 0004
GPR20:  GPR21:  GPR22: c102ddc8 GPR23: 0018
GPR24: 0001 GPR25: 0010 GPR26: c16fd75c GPR27: 0008
GPR28: deadbeef GPR29:  GPR30: c0720128 GPR31: 0006
  RES: c16fd75c oGPR11: 
Process swapper (pid: 1, stackpage=c1028ba0)

Stack:
Call trace:
[<(ptrval)>] __unflatten_device_tree+0xe0/0x184
[<(ptrval)>] of_fdt_unflatten_tree+0x60/0x90
[<(ptrval)>] of_unittest+0xb4/0x3614
[<(ptrval)>] ? __kernfs_create_file+0x130/0x188
[<(ptrval)>] ? sysfs_add_file_mode_ns+0x13c/0x288
[<(ptrval)>] ? of_unittest+0x0/0x3614
[<(ptrval)>] ? lock_is_held_type+0x160/0x20c
[<(ptrval)>] ? of_unittest+0x0/0x3614
[<(ptrval)>] ? ignore_unknown_bootoption+0x0/0x24
[<(ptrval)>] do_one_initcall+0x98/0x340
[<(ptrval)>] ? parse_args+0x220/0x4e4
[<(ptrval)>] ? lock_is_held_type+0x160/0x20c
[<(ptrval)>] ? ignore_unknown_bootoption+0x0/0x24
[<(ptrval)>] ? rcu_read_lock_sched_held+0x34/0x88
[<(ptrval)>] kernel_init_freeable+0x1c0/0x240
[<(ptrval)>] ? ignore_unknown_bootoption+0x0/0x24
[<(ptrval)>] ? kernel_init+0x0/0x154
[<(ptrval)>] kernel_init+0x1c/0x154
[<(ptrval)>] ? calculate_sigpending+0x54/0x64
[<(ptrval)>] ret_from_fork+0x1c/0x150

This problem affects all architectures with a 4-byte memory alignment.
Since commit 79edff12060f ("scripts/dtc: Update to upstream version
v1.6.0-51-g183df9e9c2b9"), devicetree code in the Linux kernel mandates
an 8-byte memory alignment of devicetree pointers, but it does not take
into account that functions such as kmalloc() or kmemdup() may not return
accordingly aligned pointers.

To fix the immediate crash, check if *mynodes is NULL in
__unflatten_device_tree() before writing into it.

Also affected by this problem is the code calling of_fdt_unflatten_tree().
That code checks for errors using the content of the mynodes pointer,
which is not set by the devicetree code if the alignment problem is
observed. Result is that the callers of of_fdt_unflatten_tree() check
if an uninitialized pointer is set to NULL. Preinitialize that pointer
to avoid the problem.

With this code in place, devicetree code on openrisc (and any other
architecture with 4-byte memory alignment) will still not work properly,
but at least it won't crash anymore. The resulting log message is

 ### dt-test ### start of unittest - you will see error messages
 ### dt-test ### unittest_data_add: No tree to attach; not running tests

when trying to run devicetree unittests.

Fixes: 79edff12060f ("scripts/dtc: Update to upstream version 
v1.6.0-51-g183df9e9c2b9")
Signed-off-by: Guenter Roeck 
---
 drivers/of/fdt.c  | 2 +-
 drivers/of/overlay.c  | 2 +-
 drivers/of/unittest.c | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index dcc1dd96911a..ab95fdb4461d 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -415,7 +415,7 @@ void *__unflatten_device_tree(const void *blob,
pr_warn("End of tree marker overwritten: %08x\n",
be32_to_cpup(mem + size));
 
-   if (detached && mynodes) {
+   if (detached && mynodes && *mynodes) {
of_node_set_flag(*mynodes, OF_DETACHED);
pr_debug("unflattened tree is detached\n");
}
diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
index 50bbe0edf538..e12c643b6ba8 100644
--- a/drivers/of/overlay.c
+++ b/drivers/of/overlay.c
@@ -1017,7 +1017,7 @@ int of_overlay_fdt_apply(const void *overlay_fdt, u32 
overlay_fdt_size,
const void *new_fdt;
int ret;
u32 size;
-   struct device_node *overlay_root;
+   struct device_node *overlay_root = NULL;
 
*ovcs_id = 0;
ret = 0;
diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
index eb100627c186..5dc4d2378bfd 100644
--- a/drivers/of/unittest.c
+++ b/drivers/of/unittest.c
@@ -1408,7 +1408,7 @@ static void attach_node_and_children(struct device_node 
*np)
 static int __init unittest_data_add(void)
 {
void *unittest_data;
-   struct device_node *unittest_data_node, *np;
+   struct device_node *unittest_data_node = NULL, *np;
/*
 * 

[PATCH] mfd: timberdale: remove redundant assignment to variable err

2021-03-27 Thread Colin King
From: Colin Ian King 

Variable err is assigned -ENODEV followed by an error return path
via label err_mfd that does not access the variable and returns
with the -ENODEV error return code. The assignment to err is
redundant and can be removed.

Signed-off-by: Colin Ian King 
---
 drivers/mfd/timberdale.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/mfd/timberdale.c b/drivers/mfd/timberdale.c
index faecbca6dba3..0a9872ed722f 100644
--- a/drivers/mfd/timberdale.c
+++ b/drivers/mfd/timberdale.c
@@ -766,7 +766,6 @@ static int timb_probe(struct pci_dev *dev,
default:
dev_err(>dev, "Unknown IP setup: %d.%d.%d\n",
priv->fw.major, priv->fw.minor, ip_setup);
-   err = -ENODEV;
goto err_mfd;
}
 
-- 
2.30.2



Dearly Beloved In Christ

2021-03-27 Thread Mrs Daniella Kyle
Hi Dear,

Sorry to invade your privacy, I am Mrs Daniela Angelo Kyle the wife of
late Mr Angelo Kyle,my husband worked with Central Bank Of Philippines
for ten years before he died in the year 2012. When my late husband
was alive he deposited sum amount of Money with UBA Bank therein
Burkina Faso Ouagadougou.

Presently this money is still with the UBA Bank Burkina Faso
Ouagadougou,I am in a hospital in Philippines receiving treatment and
my doctor has confirmed to me that
i have just few days to live on earth due to my esophageal cancer.

Please i am choosing you to receive this money on my behalf,and use it
to help the less privilege. Contact me on my private email address if
interested.

Thanks
Sincerely Mrs Daniela Angelo Kyle


Re: [PATCH v1 1/1] kernel.h: Drop inclusion in bitmap.h

2021-03-27 Thread Andy Shevchenko
On Sun, Mar 28, 2021 at 12:23 AM Al Viro  wrote:
>
> On Fri, Mar 26, 2021 at 07:03:47PM +0200, Andy Shevchenko wrote:
> > The bitmap.h header is used in a lot of code around the kernel.
> > Besides that it includes kernel.h which sometimes makes a loop.
>
> How much of the kernel does *not* end up pulling kernel.h anyway,
> making all subsequent includes fast no-ops?
>
> Realistically, any C compiler is going to recognize the case when
> included file has contents of form
>
> #ifndef 
> #define  
> 
> #endif
>
> where  contain no exposed #else, #elif or #endif and
> remember that subsequent includes of that file should be ignored
> unless  becomes undefined.

The problem here is not in C compiler, but in many unneeded loops that
make header hell dependencies.
For example, how you may move bitmap_zalloc() from C-file to the
header? Currently it's impossible.
And bitmap.h here is only a tip of an iceberg.

kerne.h is a dump of everything that even has nothing in common at all.
We may still have it, but in my new code I prefer to include only the
headers that I want to use, without the bulk of unneeded kernel code.

> AFAICS, on e.g. allmodconfig amd64 build it's (at most - there
> might've been false positives) 131 files out of ~3; on
> defconfig it's 55 out of ~2300.  How much does your patch
> change that?

I'm not sure I understand what you mean here.

-- 
With Best Regards,
Andy Shevchenko


Re: [PATCH -next] drivers: net: CONFIG_ATH9K select LEDS_CLASS

2021-03-27 Thread Pavel Machek
On Fri 2021-03-26 16:13:51, Zhang Jianhua wrote:
> If CONFIG_ATH9K=y, the following errors will be seen while compiling
> gpio.c
> 
> drivers/net/wireless/ath/ath9k/gpio.o: In function `ath_deinit_leds':
> gpio.c:(.text+0x604): undefined reference to `led_classdev_unregister'
> gpio.c:(.text+0x604): relocation truncated to fit: R_AARCH64_CALL26
> against undefined symbol `led_classdev_unregister'
> drivers/net/wireless/ath/ath9k/gpio.o: In function `ath_init_leds':
> gpio.c:(.text+0x708): undefined reference to `led_classdev_register_ext'
> gpio.c:(.text+0x708): relocation truncated to fit: R_AARCH64_CALL26
> against undefined symbol `led_classdev_register_ext'
> 
> Reported-by: Hulk Robot 
> Signed-off-by: Zhang Jianhua 

a) please cc led lists with led issue.

b) probably does not work as LED_CLASS depends on NEW_LEDS...?

Best regards,
Pavel

-- 
http://www.livejournal.com/~pavelmachek


signature.asc
Description: PGP signature


[PATCH][next] mlxsw: spectrum_router: remove redundant initialization of variable force

2021-03-27 Thread Colin King
From: Colin Ian King 

The variable force is being initialized with a value that is
never read and it is being updated later with a new value. The
initialization is redundant and can be removed.

Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King 
---
 drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c 
b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
index 6ccaa194733b..ff240e3c29f7 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
@@ -5059,7 +5059,7 @@ mlxsw_sp_nexthop_obj_bucket_adj_update(struct mlxsw_sp 
*mlxsw_sp,
 {
u16 bucket_index = info->nh_res_bucket->bucket_index;
struct netlink_ext_ack *extack = info->extack;
-   bool force = info->nh_res_bucket->force;
+   bool force;
char ratr_pl_new[MLXSW_REG_RATR_LEN];
char ratr_pl[MLXSW_REG_RATR_LEN];
u32 adj_index;
-- 
2.30.2



Re: [PATCH] kconfig: nconf: stop endless search-up loops

2021-03-27 Thread Randy Dunlap
On 3/27/21 3:12 PM, Mihai Moldovan wrote:
> * On 3/27/21 4:58 PM, Randy Dunlap wrote:
>> On 3/27/21 5:01 AM, Mihai Moldovan wrote:
>>> +   if ((-1 == index) && (index == match_start))
>>
>> checkpatch doesn't complain about this (and I wonder how it's missed), but
>> kernel style is (mostly) "constant goes on right hand side of comparison",
>> so
>>  if ((index == -1) &&
> 
> I can naturally send a V2 with that swapped.
> 
> To my rationale: I made sure to use checkpatch, saw that it was accepted and
> even went for a quick git grep -- '-1 ==', which likewise returned enough
> results for me to call this consistent with the current code style.
> 
> Maybe those matches were just frowned-upon, but forgotten-to-be-critized
> examples of this pattern being used.

There is a test for it in checkpatch.pl but I also used checkpatch.pl
without it complaining, so I don't know what it takes to make the script
complain.

if ($lead !~ /(?:$Operators|\.)\s*$/ &&
$to !~ /^(?:Constant|[A-Z_][A-Z0-9_]*)$/ &&
WARN("CONSTANT_COMPARISON",
 "Comparisons should place the constant on the 
right side of the test\n" . $herecurr) &&

cheers.
-- 
~Randy



Re: [PATCH 6/9] debugfs: Implement debugfs_create_str()

2021-03-27 Thread Al Viro
On Fri, Mar 26, 2021 at 11:33:58AM +0100, Peter Zijlstra wrote:

> +again:
> + rcu_read_lock();
> + str = rcu_dereference(*(char **)file->private_data);
> + len = strlen(str) + 1;
> +
> + if (!copy || copy_len < len) {
> + rcu_read_unlock();
> + kfree(copy);
> + copy = kmalloc(len + 1, GFP_KERNEL);
> + if (!copy) {
> + debugfs_file_put(dentry);
> + return -ENOMEM;
> + }
> + copy_len = len;
> + goto again;
> + }
> +
> + strncpy(copy, str, len);
> + copy[len] = '\n';
> + copy[len+1] = '\0';
> + rcu_read_unlock();

*Ow*

If the string can't change under you, what is RCU use about?
And if it can, any use of string functions is asking for serious
trouble; they are *not* guaranteed to be safe when any of the strings
involved might be modified under them.


Re: [PATCH v3 2/6] PCI: brcmstb: Add control of EP voltage regulators

2021-03-27 Thread Jim Quinlan
On Fri, Mar 26, 2021 at 4:11 PM Bjorn Helgaas  wrote:
>
> On Fri, Mar 26, 2021 at 03:19:00PM -0400, Jim Quinlan wrote:
> > Control of EP regulators by the RC is needed because of the chicken-and-egg
>
> Can you expand "EP"?  Not sure if this refers to "endpoint" or
> something else.
Yes I meant "endpoint" -- I will expand it.
>
> If this refers to a device in a slot, I guess it isn't necessarily aWe only 
> support this feature for endpoint devices; it they hav
> PCIe *endpoint*; it could also be a switch upstream port.
True; to be precise I mean the device directly connected to the single RC port.
>
> > situation: although the regulator is "owned" by the EP and would be best
> > handled on its driver, the EP cannot be discovered and probed unless its
> > regulator is already turned on.
> >
> > Signed-off-by: Jim Quinlan 
> > ---
> >  drivers/pci/controller/pcie-brcmstb.c | 90 ++-
> >  1 file changed, 87 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/pci/controller/pcie-brcmstb.c 
> > b/drivers/pci/controller/pcie-brcmstb.c
> > index e330e6811f0b..b76ec7d9af32 100644
> > --- a/drivers/pci/controller/pcie-brcmstb.c
> > +++ b/drivers/pci/controller/pcie-brcmstb.c
> > @@ -24,6 +24,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -169,6 +170,7 @@
> >  #define SSC_STATUS_SSC_MASK  0x400
> >  #define SSC_STATUS_PLL_LOCK_MASK 0x800
> >  #define PCIE_BRCM_MAX_MEMC   3
> > +#define PCIE_BRCM_MAX_EP_REGULATORS  4
> >
> >  #define IDX_ADDR(pcie)   
> > (pcie->reg_offsets[EXT_CFG_INDEX])
> >  #define DATA_ADDR(pcie)  
> > (pcie->reg_offsets[EXT_CFG_DATA])
> > @@ -295,8 +297,27 @@ struct brcm_pcie {
> >   u32 hw_rev;
> >   void(*perst_set)(struct brcm_pcie *pcie, u32 val);
> >   void(*bridge_sw_init_set)(struct brcm_pcie *pcie, 
> > u32 val);
> > + struct regulator_bulk_data supplies[PCIE_BRCM_MAX_EP_REGULATORS];
> > + unsigned intnum_supplies;
> >  };
> >
> > +static int brcm_set_regulators(struct brcm_pcie *pcie, bool on)
> > +{
> > + struct device *dev = pcie->dev;
> > + int ret;
> > +
> > + if (!pcie->num_supplies)
> > + return 0;
> > + if (on)
> > + ret = regulator_bulk_enable(pcie->num_supplies, 
> > pcie->supplies);
> > + else
> > + ret = regulator_bulk_disable(pcie->num_supplies, 
> > pcie->supplies);
> > + if (ret)
> > + dev_err(dev, "failed to %s EP regulators\n",
> > + on ? "enable" : "disable");
> > + return ret;
> > +}
> > +
> >  /*
> >   * This is to convert the size of the inbound "BAR" region to the
> >   * non-linear values of PCIE_X_MISC_RC_BAR[123]_CONFIG_LO.SIZE
> > @@ -1141,16 +1162,63 @@ static void brcm_pcie_turn_off(struct brcm_pcie 
> > *pcie)
> >   pcie->bridge_sw_init_set(pcie, 1);
> >  }
> >
> > +static int brcm_pcie_get_regulators(struct brcm_pcie *pcie)
> > +{
> > + struct device_node *child, *parent = pcie->np;
> > + const unsigned int max_name_len = 64 + 4;
> > + struct property *pp;
> > +
> > + /* Look for regulator supply property in the EP device subnodes */
> > + for_each_available_child_of_node(parent, child) {
> > + /*
> > +  * Do a santiy test to ensure that this is an EP node
>
> s/santiy/sanity/
>
> > +  * (e.g. node name: "pci-ep@0,0").  The slot number
> > +  * should always be 0 as our controller only has a single
> > +  * port.
> > +  */
> > + const char *p = strstr(child->full_name, "@0");
> > +
> > + if (!p || (p[2] && p[2] != ','))
> > + continue;
> > +
> > + /* Now look for regulator supply properties */
> > + for_each_property_of_node(child, pp) {
> > + int i, n = strnlen(pp->name, max_name_len);
> > +
> > + if (n <= 7 || strncmp("-supply", >name[n - 7], 7))
> > + continue;
> > +
> > + /* Make sure this is not a duplicate */
> > + for (i = 0; i < pcie->num_supplies; i++)
> > + if (strncmp(pcie->supplies[i].supply,
> > + pp->name, max_name_len) == 0)
> > + continue;
> > +
> > + if (pcie->num_supplies < PCIE_BRCM_MAX_EP_REGULATORS)
> > + pcie->supplies[pcie->num_supplies++].supply = 
> > pp->name;
> > + else
> > + dev_warn(pcie->dev, "No room for EP supply 
> > %s\n",
> > +  pp->name);
> > + }
> > + }
> > + /*
> > +  * Get the regulators that the EP devices require.  We cannot use
> > +  * pcie->dev 

[PATCH v1 7/8] software node: Introduce SOFTWARE_NODE_REFERENCE() helper macro

2021-03-27 Thread Andy Shevchenko
This is useful to assign software node reference with arguments
in a common way. Moreover, we have already couple of users that
may be converted. And by the fact, one of them is moved right here
to use the helper.

Signed-off-by: Andy Shevchenko 
---
 drivers/base/test/property-entry-test.c | 11 ++-
 include/linux/property.h| 13 -
 2 files changed, 10 insertions(+), 14 deletions(-)

diff --git a/drivers/base/test/property-entry-test.c 
b/drivers/base/test/property-entry-test.c
index abe03315180f..c2e455d46ffd 100644
--- a/drivers/base/test/property-entry-test.c
+++ b/drivers/base/test/property-entry-test.c
@@ -370,15 +370,8 @@ static void pe_test_reference(struct kunit *test)
};
 
static const struct software_node_ref_args refs[] = {
-   {
-   .node = [0],
-   .nargs = 0,
-   },
-   {
-   .node = [1],
-   .nargs = 2,
-   .args = { 3, 4 },
-   },
+   SOFTWARE_NODE_REFERENCE([0]),
+   SOFTWARE_NODE_REFERENCE([1], 3, 4),
};
 
const struct property_entry entries[] = {
diff --git a/include/linux/property.h b/include/linux/property.h
index dd4687b56239..0d876316e61d 100644
--- a/include/linux/property.h
+++ b/include/linux/property.h
@@ -254,6 +254,13 @@ struct software_node_ref_args {
u64 args[NR_FWNODE_REFERENCE_ARGS];
 };
 
+#define SOFTWARE_NODE_REFERENCE(_ref_, ...)\
+(const struct software_node_ref_args) {\
+   .node = _ref_,  \
+   .nargs = ARRAY_SIZE(((u64[]){ 0, ##__VA_ARGS__ })) - 1, \
+   .args = { __VA_ARGS__ },\
+}
+
 /**
  * struct property_entry - "Built-in" device property representation.
  * @name: Name of the property.
@@ -362,11 +369,7 @@ struct property_entry {
.name = _name_, \
.length = sizeof(struct software_node_ref_args),\
.type = DEV_PROP_REF,   \
-   { .pointer = &(const struct software_node_ref_args) {   \
-   .node = _ref_,  \
-   .nargs = ARRAY_SIZE(((u64[]){ 0, ##__VA_ARGS__ })) - 1, \
-   .args = { __VA_ARGS__ },\
-   } },\
+   { .pointer = _NODE_REFERENCE(_ref_, ##__VA_ARGS__), }, \
 }
 
 struct property_entry *
-- 
2.30.2



[PATCH v1 5/8] software node: Imply kobj_to_swnode() to be no-op

2021-03-27 Thread Andy Shevchenko
Since we don't use structure field layout randomization
the manual shuffling can affect some macros, in particular
kobj_to_swnode(), which becomes a no-op when kobj member
is the first one in the struct swnode.

Bloat-o-meter statistics:

  add/remove: 0/0 grow/shrink: 2/10 up/down: 9/-100 (-91)
  Total: Before=7217, After=7126, chg -1.26%

Signed-off-by: Andy Shevchenko 
---
 drivers/base/swnode.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
index 22f81688af2c..ae53c48f84b1 100644
--- a/drivers/base/swnode.c
+++ b/drivers/base/swnode.c
@@ -13,10 +13,10 @@
 #include 
 
 struct swnode {
-   int id;
struct kobject kobj;
struct fwnode_handle fwnode;
const struct software_node *node;
+   int id;
 
/* properties in sysfs */
struct kobj_attribute *property_attrs;
-- 
2.30.2



[PATCH v1 3/8] software node: Show properties and their values in sysfs

2021-03-27 Thread Andy Shevchenko
It's very convenient to see what properties and their values
are currently being assigned in the registered software nodes.

Show properties and their values in sysfs.

Signed-off-by: Andy Shevchenko 
---
 drivers/base/swnode.c | 137 --
 1 file changed, 132 insertions(+), 5 deletions(-)

diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
index 19aa44bc2628..d7fe1a887d2d 100644
--- a/drivers/base/swnode.c
+++ b/drivers/base/swnode.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct swnode {
int id;
@@ -17,6 +18,10 @@ struct swnode {
struct fwnode_handle fwnode;
const struct software_node *node;
 
+   /* properties in sysfs */
+   struct kobj_attribute *property_attrs;
+   struct attribute_group property_group;
+
/* hierarchy */
struct ida child_ids;
struct list_head entry;
@@ -25,6 +30,7 @@ struct swnode {
 
unsigned int allocated:1;
unsigned int managed:1;
+   unsigned int properties:1;
 };
 
 static DEFINE_IDA(swnode_root_ids);
@@ -299,6 +305,18 @@ static int property_entry_copy_data(struct property_entry 
*dst,
return 0;
 }
 
+static int property_entries_count(const struct property_entry *properties)
+{
+   int n = 0;
+
+   if (properties) {
+   while (properties[n].name)
+   n++;
+   }
+
+   return n;
+}
+
 /**
  * property_entries_dup - duplicate array of properties
  * @properties: array of properties to copy
@@ -310,15 +328,13 @@ struct property_entry *
 property_entries_dup(const struct property_entry *properties)
 {
struct property_entry *p;
-   int i, n = 0;
+   int i, n;
int ret;
 
-   if (!properties)
+   n = property_entries_count(properties);
+   if (n == 0)
return NULL;
 
-   while (properties[n].name)
-   n++;
-
p = kcalloc(n + 1, sizeof(*p), GFP_KERNEL);
if (!p)
return ERR_PTR(-ENOMEM);
@@ -746,6 +762,108 @@ static void software_node_free(const struct software_node 
*node)
kfree(node);
 }
 
+static ssize_t
+swnode_property_show(struct kobject *kobj, struct kobj_attribute *attr, char 
*buf)
+{
+   struct swnode *swnode = kobj_to_swnode(kobj);
+   const struct property_entry *prop;
+   const void *pointer;
+   ssize_t len = 0;
+   int i;
+
+   prop = property_entry_get(swnode->node->properties, attr->attr.name);
+   if (!prop)
+   return -EINVAL;
+
+   /* We can't fail here, because it means boolean property */
+   pointer = property_get_pointer(prop);
+   if (!pointer)
+   return sysfs_emit(buf, "\n");
+
+   switch (prop->type) {
+   case DEV_PROP_U8:
+   for (i = 0; i < prop->length / sizeof(u8); i++)
+   len += sysfs_emit_at(buf, len, "%u,", ((u8 
*)pointer)[i]);
+   break;
+   case DEV_PROP_U16:
+   for (i = 0; i < prop->length / sizeof(u16); i++)
+   len += sysfs_emit_at(buf, len, "%u,", ((u16 
*)pointer)[i]);
+   break;
+   case DEV_PROP_U32:
+   for (i = 0; i < prop->length / sizeof(u32); i++)
+   len += sysfs_emit_at(buf, len, "%u,", ((u32 
*)pointer)[i]);
+   break;
+   case DEV_PROP_U64:
+   for (i = 0; i < prop->length / sizeof(u64); i++)
+   len += sysfs_emit_at(buf, len, "%llu,", ((u64 
*)pointer)[i]);
+   break;
+   case DEV_PROP_STRING:
+   for (i = 0; i < prop->length / sizeof(const char **); i++)
+   len += sysfs_emit_at(buf, len, "\"%s\",", ((const char 
**)pointer)[i]);
+   break;
+   default:
+   return -EINVAL;
+   }
+
+   sysfs_emit_at(buf, len ? len - 1 : 0, "\n");
+   return len;
+}
+
+static int swnode_register_properties(struct swnode *swnode)
+{
+   const struct property_entry *props = swnode->node->properties;
+   struct attribute **group_attrs;
+   struct kobj_attribute *attrs;
+   int n;
+   int ret;
+
+   n = property_entries_count(props);
+   if (n == 0)
+   return 0;
+
+   group_attrs = kcalloc(n + 1, sizeof(*group_attrs), GFP_KERNEL);
+   if (!group_attrs)
+   return -ENOMEM;
+
+   attrs = kcalloc(n, sizeof(*attrs), GFP_KERNEL);
+   if (!attrs) {
+   kfree(group_attrs);
+   return -ENOMEM;
+   }
+
+   while (n--) {
+   sysfs_attr_init([n]);
+   attrs[n].attr.mode = 0444;
+   attrs[n].attr.name = props[n].name;
+   attrs[n].show = swnode_property_show;
+   group_attrs[n] = [n].attr;
+   }
+
+   swnode->property_group.name = "properties";
+   swnode->property_group.attrs = group_attrs;
+
+   ret = sysfs_create_group(>kobj, >property_group);
+   

[PATCH v1 6/8] software node: Simplify swnode_register() a bit

2021-03-27 Thread Andy Shevchenko
By introducing two temporary variables simplify swnode_register() a bit.
No functional change intended.

Signed-off-by: Andy Shevchenko 
---
 drivers/base/swnode.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
index ae53c48f84b1..1e81aaf5f6a1 100644
--- a/drivers/base/swnode.c
+++ b/drivers/base/swnode.c
@@ -894,6 +894,8 @@ static struct fwnode_handle *
 swnode_register(const struct software_node *node, struct swnode *parent,
unsigned int allocated)
 {
+   struct ida *ids = parent ? >child_ids : _root_ids;
+   struct kobject *kobj_parent = parent ? >kobj : NULL;
struct swnode *swnode;
int ret;
 
@@ -901,8 +903,7 @@ swnode_register(const struct software_node *node, struct 
swnode *parent,
if (!swnode)
return ERR_PTR(-ENOMEM);
 
-   ret = ida_simple_get(parent ? >child_ids : _root_ids,
-0, 0, GFP_KERNEL);
+   ret = ida_simple_get(ids, 0, 0, GFP_KERNEL);
if (ret < 0) {
kfree(swnode);
return ERR_PTR(ret);
@@ -920,12 +921,10 @@ swnode_register(const struct software_node *node, struct 
swnode *parent,
 
if (node->name)
ret = kobject_init_and_add(>kobj, _node_type,
-  parent ? >kobj : NULL,
-  "%s", node->name);
+  kobj_parent, "%s", node->name);
else
ret = kobject_init_and_add(>kobj, _node_type,
-  parent ? >kobj : NULL,
-  "node%d", swnode->id);
+  kobj_parent, "node%d", swnode->id);
if (ret) {
kobject_put(>kobj);
return ERR_PTR(ret);
-- 
2.30.2



[PATCH v1 8/8] media: ipu3-cio2: Switch to use SOFTWARE_NODE_REFERENCE()

2021-03-27 Thread Andy Shevchenko
This is useful to assign software node reference with arguments
in a common way. Switch to use SOFTWARE_NODE_REFERENCE() here.

Signed-off-by: Andy Shevchenko 
---
 drivers/media/pci/intel/ipu3/cio2-bridge.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/pci/intel/ipu3/cio2-bridge.c 
b/drivers/media/pci/intel/ipu3/cio2-bridge.c
index c2199042d3db..e8511787c1e4 100644
--- a/drivers/media/pci/intel/ipu3/cio2-bridge.c
+++ b/drivers/media/pci/intel/ipu3/cio2-bridge.c
@@ -79,8 +79,8 @@ static void cio2_bridge_create_fwnode_properties(
 {
sensor->prop_names = prop_names;
 
-   sensor->local_ref[0].node = >swnodes[SWNODE_CIO2_ENDPOINT];
-   sensor->remote_ref[0].node = >swnodes[SWNODE_SENSOR_ENDPOINT];
+   sensor->local_ref[0] = 
SOFTWARE_NODE_REFERENCE(>swnodes[SWNODE_CIO2_ENDPOINT]);
+   sensor->remote_ref[0] = 
SOFTWARE_NODE_REFERENCE(>swnodes[SWNODE_SENSOR_ENDPOINT]);
 
sensor->dev_properties[0] = PROPERTY_ENTRY_U32(
sensor->prop_names.clock_frequency,
-- 
2.30.2



Re: [PATCH v4 22/22] x86/fpu/xstate: Introduce boot-parameters to control state component support

2021-03-27 Thread Thomas Gleixner
Len,

On Sat, Mar 27 2021 at 00:53, Len Brown wrote:
>> 3.3 RECOMMENDATIONS FOR SYSTEM SOFTWARE
>>
>> System software may disable use of Intel AMX by clearing XCR0[18:17],
>> by clearing CR4.OSXSAVE, or by setting
>> IA32_XFD[18]. It is recommended that system software initialize AMX
>> state (e.g., by executing TILERELEASE)
>> before doing so. This is because maintaining AMX state in a
>> non-initialized state may have negative power and
>> performance implications.
>
> I agree that the wording here about disabling AMX is ominous.

Which is what I pointed out 7 days ago already, but that got lost in the
ABI and command line noise... Thanks Andy for bringing it back!

> The hardware initializes with AMX disabled.
> The kernel probes AMX, enables it in XCR0, and keeps it enabled.
>
> Initially, XFD is "armed" for all tasks.
> When a task accesses AMX state, #NM fires, we allocate a context
> switch buffer, and we "disarm" XFD for that task.
> As we have that buffer in-hand for the lifetime of the task, we never
> "arm" XFD for that task again.
>
> XFD is context switched, and so the next time it is set, is when we
> are restoring some other task's state.
>
> n.b. I'm describing the Linux flow.  The VMM scenario is a little different.
>
>> Since you reviewed the patch set, I assume you are familiar with how
>> Linux manages XSTATE.  Linux does *not* eagerly load XSTATE on context
>> switch.  Instead, Linux loads XSTATE when the kernel needs it loaded
>> or before executing user code.  This means that the kernel can (and
>> does, and it's a performance win) execute kernel thread code and/or go
>> idle, *including long-term deep idle*, with user XSTATE loaded.
>
> Yes, this scenario is clear.
>
> There are several cases.
>
> 1. Since TMM registers are volatile, a routine using TMM that wants
> them to persist across a call must save them,
> and will TILERELEASE before invoking that call.  That is the
> calling convention,
> and I expect that if it is not followed, debugging (of tools) will
> occur until it is.
>
> The only way for a user program's XSTATE to be present during the
> kernel's call to idle
> is if it sleep via a system call when no other task wants to run
> on that CPU.
>
> Since system calls are calls, in this case, AMX INIT=1 during
> idle.

What is the guarantee for that? A calling convention?

That's uninteresting because that's only the recommended and desired
state and not the guaranteed state.

> All deep C-state are enabled, the idle CPU is able to contribute
> it's maximum turbo buget to its peers.
>
> 2. A correct program with live TMM registers takes an interrupt, and
> we enter the kernel AMX INIT=0.
> Yes, we will enter the syscall at the frequency of the app (like
> we always do).

That's about interrupts not syscalls and I assume this should be all
s/syscall/interrupt/ for the whole #2 including 2a

> Yes, turbo frequency may be limited by the activity of this
> processor and its peers (like it always is)
>
>2a. If we return to the same program, then depending on how long
> the syscall runs, we may execute
>  the program and the system call code at a frequency lower
> than we might if AMX INIT=1 at time of interrupt.

So the frequency effect is relevant for the duration of the interrupt
and the eventually appended soft interrupt, right?

The program state is uninteresting because even if the kernel would
do XSAVES, TILERELEASE on interrupt entry then it would restore the
state before returning and then the program would have the same
conditions as before the interrupt.

>2b. If we context switch to a task that has AMX INIT=1, then any
> AMX-imposed limits on turbo
>  are immediately gone.

Immediately on context switch? Definitely not.

  switch_to(prev, next)
XSAVES(prev)
eventually set XFD[18]

The point where AMX INIT=1 of 'next' becomes relevant is on return to
user space where XRSTORS happens. Up to that point AMX INIT=0 stays in
effect.

Now what guarantees that 'next' is returning to user space immediately?

Nothing.

If it's a user task this can be a wakeup for whatever which might cause
another wait depending on the callchain that task is in. It can be
preempted before reaching XRSTORS which is the point that matters to
flip the AMX INIT state back to 1.

It can be a kernel task or a chain of kernel tasks with arbitrary
runtime.

As a consequence the scheduler might migrate 'prev' from CPU_A to CPU_L
and what happens to that state on CPU_A? Does it magically move along
with 'prev' to CPU_L? I can't see how, but what do I know about magic.

So now the chain of kernel tasks finishes and there is nothing to do,
CPU_A goes idle with AMX INIT=0, which prevents the CPU from going deep,
drains power, can't contribute to the turbo state or whatever undesired
side effects that has.

You can get the same effect not only by device interrupts but also by
regular task migration, ptrace, breakpoints, any 

[PATCH v1 1/8] software node: Free resources explicitly when swnode_register() fails

2021-03-27 Thread Andy Shevchenko
Currently we have a slightly twisted logic in swnode_register().
It frees resources that it doesn't allocate on error path and
in once case it relies on the ->release() implementation.

Untwist the logic by freeing resources explicitly when swnode_register()
fails. Currently it happens only in fwnode_create_software_node().

Signed-off-by: Andy Shevchenko 
---
 drivers/base/swnode.c | 29 +
 1 file changed, 17 insertions(+), 12 deletions(-)

diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
index fa3719ef80e4..456f5fe58b58 100644
--- a/drivers/base/swnode.c
+++ b/drivers/base/swnode.c
@@ -767,22 +767,19 @@ swnode_register(const struct software_node *node, struct 
swnode *parent,
int ret;
 
swnode = kzalloc(sizeof(*swnode), GFP_KERNEL);
-   if (!swnode) {
-   ret = -ENOMEM;
-   goto out_err;
-   }
+   if (!swnode)
+   return ERR_PTR(-ENOMEM);
 
ret = ida_simple_get(parent ? >child_ids : _root_ids,
 0, 0, GFP_KERNEL);
if (ret < 0) {
kfree(swnode);
-   goto out_err;
+   return ERR_PTR(ret);
}
 
swnode->id = ret;
swnode->node = node;
swnode->parent = parent;
-   swnode->allocated = allocated;
swnode->kobj.kset = swnode_kset;
fwnode_init(>fwnode, _node_ops);
 
@@ -803,16 +800,17 @@ swnode_register(const struct software_node *node, struct 
swnode *parent,
return ERR_PTR(ret);
}
 
+   /*
+* Assign the flag only in the successful case, so
+* the above kobject_put() won't mess up with properties.
+*/
+   swnode->allocated = allocated;
+
if (parent)
list_add_tail(>entry, >children);
 
kobject_uevent(>kobj, KOBJ_ADD);
return >fwnode;
-
-out_err:
-   if (allocated)
-   property_entries_free(node->properties);
-   return ERR_PTR(ret);
 }
 
 /**
@@ -963,6 +961,7 @@ struct fwnode_handle *
 fwnode_create_software_node(const struct property_entry *properties,
const struct fwnode_handle *parent)
 {
+   struct fwnode_handle *fwnode;
struct software_node *node;
struct swnode *p = NULL;
int ret;
@@ -987,7 +986,13 @@ fwnode_create_software_node(const struct property_entry 
*properties,
 
node->parent = p ? p->node : NULL;
 
-   return swnode_register(node, p, 1);
+   fwnode = swnode_register(node, p, 1);
+   if (IS_ERR(fwnode)) {
+   property_entries_free(node->properties);
+   kfree(node);
+   }
+
+   return fwnode;
 }
 EXPORT_SYMBOL_GPL(fwnode_create_software_node);
 
-- 
2.30.2



[PATCH v1 4/8] software node: Deduplicate code in fwnode_create_software_node()

2021-03-27 Thread Andy Shevchenko
Deduplicate conditional and assignment in fwnode_create_software_node(),
i.e. parent is checked in two out of three cases and parent software node
is assigned by to_swnode() call.

Signed-off-by: Andy Shevchenko 
---
 drivers/base/swnode.c | 17 -
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
index d7fe1a887d2d..22f81688af2c 100644
--- a/drivers/base/swnode.c
+++ b/drivers/base/swnode.c
@@ -1100,15 +1100,14 @@ fwnode_create_software_node(const struct property_entry 
*properties,
 {
struct fwnode_handle *fwnode;
struct software_node *node;
-   struct swnode *p = NULL;
-
-   if (parent) {
-   if (IS_ERR(parent))
-   return ERR_CAST(parent);
-   if (!is_software_node(parent))
-   return ERR_PTR(-EINVAL);
-   p = to_swnode(parent);
-   }
+   struct swnode *p;
+
+   if (IS_ERR(parent))
+   return ERR_CAST(parent);
+
+   p = to_swnode(parent);
+   if (parent && !p)
+   return ERR_PTR(-EINVAL);
 
node = software_node_alloc(properties);
if (IS_ERR(node))
-- 
2.30.2



[PATCH v1 2/8] software node: Introduce software_node_alloc()/software_node_free()

2021-03-27 Thread Andy Shevchenko
Introduce software_node_alloc() and software_node_free() helpers.
This will help with code readability and maintenance.

Signed-off-by: Andy Shevchenko 
---
 drivers/base/swnode.c | 47 ++-
 1 file changed, 24 insertions(+), 23 deletions(-)

diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
index 456f5fe58b58..19aa44bc2628 100644
--- a/drivers/base/swnode.c
+++ b/drivers/base/swnode.c
@@ -720,19 +720,30 @@ software_node_find_by_name(const struct software_node 
*parent, const char *name)
 }
 EXPORT_SYMBOL_GPL(software_node_find_by_name);
 
-static int
-software_node_register_properties(struct software_node *node,
- const struct property_entry *properties)
+static struct software_node *software_node_alloc(const struct property_entry 
*properties)
 {
struct property_entry *props;
+   struct software_node *node;
 
props = property_entries_dup(properties);
if (IS_ERR(props))
-   return PTR_ERR(props);
+   return ERR_CAST(props);
+
+   node = kzalloc(sizeof(*node), GFP_KERNEL);
+   if (!node) {
+   property_entries_free(props);
+   return ERR_PTR(-ENOMEM);
+   }
 
node->properties = props;
 
-   return 0;
+   return node;
+}
+
+static void software_node_free(const struct software_node *node)
+{
+   property_entries_free(node->properties);
+   kfree(node);
 }
 
 static void software_node_release(struct kobject *kobj)
@@ -746,10 +757,9 @@ static void software_node_release(struct kobject *kobj)
ida_simple_remove(_root_ids, swnode->id);
}
 
-   if (swnode->allocated) {
-   property_entries_free(swnode->node->properties);
-   kfree(swnode->node);
-   }
+   if (swnode->allocated)
+   software_node_free(swnode->node);
+
ida_destroy(>child_ids);
kfree(swnode);
 }
@@ -964,7 +974,6 @@ fwnode_create_software_node(const struct property_entry 
*properties,
struct fwnode_handle *fwnode;
struct software_node *node;
struct swnode *p = NULL;
-   int ret;
 
if (parent) {
if (IS_ERR(parent))
@@ -974,23 +983,15 @@ fwnode_create_software_node(const struct property_entry 
*properties,
p = to_swnode(parent);
}
 
-   node = kzalloc(sizeof(*node), GFP_KERNEL);
-   if (!node)
-   return ERR_PTR(-ENOMEM);
-
-   ret = software_node_register_properties(node, properties);
-   if (ret) {
-   kfree(node);
-   return ERR_PTR(ret);
-   }
+   node = software_node_alloc(properties);
+   if (IS_ERR(node))
+   return ERR_CAST(node);
 
node->parent = p ? p->node : NULL;
 
fwnode = swnode_register(node, p, 1);
-   if (IS_ERR(fwnode)) {
-   property_entries_free(node->properties);
-   kfree(node);
-   }
+   if (IS_ERR(fwnode))
+   software_node_free(node);
 
return fwnode;
 }
-- 
2.30.2



Re: [PATCH 17/17] auxdisplay: ht16k33: Add segment display LED support

2021-03-27 Thread Pavel Machek
Hi!

> > > > > - err = ht16k33_brightness_set(priv, MAX_BRIGHTNESS);
> > > > > + of_property_read_u32(node, "color", );
> > > > > + seg->led.name = devm_kasprintf(dev, GFP_KERNEL,
> > > > > + DRIVER_NAME ":%s:" LED_FUNCTION_BACKLIGHT,
> > > > > + color < LED_COLOR_ID_MAX ? led_colors[color] : 
> > > > > "");
> >
> > And would prefer not to see driver_name as part of LED name.
> 
> OK. So what should I use instead? Or just leave the part before the
> first colon empty?

I'd suggest auxdisplay:...:backlight.

And we should start documenting this somewhere.

Best regards,
Pavel
-- 
http://www.livejournal.com/~pavelmachek


signature.asc
Description: PGP signature


Re: [PATCH v1 1/1] kernel.h: Drop inclusion in bitmap.h

2021-03-27 Thread Al Viro
On Fri, Mar 26, 2021 at 07:03:47PM +0200, Andy Shevchenko wrote:
> The bitmap.h header is used in a lot of code around the kernel.
> Besides that it includes kernel.h which sometimes makes a loop.

How much of the kernel does *not* end up pulling kernel.h anyway,
making all subsequent includes fast no-ops?

Realistically, any C compiler is going to recognize the case when
included file has contents of form

#ifndef 
#define  

#endif

where  contain no exposed #else, #elif or #endif and
remember that subsequent includes of that file should be ignored
unless  becomes undefined.

AFAICS, on e.g. allmodconfig amd64 build it's (at most - there
might've been false positives) 131 files out of ~3; on
defconfig it's 55 out of ~2300.  How much does your patch
change that?


Re: [PATCH] usb: gadget: aspeed: set port_dev dma mask

2021-03-27 Thread Tao Ren
On Fri, Mar 26, 2021 at 01:05:26PM +0100, Christoph Hellwig wrote:
> On Fri, Mar 26, 2021 at 12:03:03PM +, Robin Murphy wrote:
> > This might happen to work out, but is far from correct. Just wait until you 
> > try it on a platform where the USB controller is behind an IOMMU...
> >
> > It looks like something is more fundamentally wrong here - the device 
> > passed to DMA API calls must be the actual hardware device performing the 
> > DMA, which in USB-land I believe means the controller's sysdev.
> 
> The shiny new usb_intf_get_dma_device API provides the device to use.

Thanks Robin and Christoph for the feedback.

If I understand correctly, usb_intf_get_dma_device API is mainly for usb
host drivers? I just found usb_gadget_map_request_by_dev API: does it
make sense to replace usb_gadget_map_request with
usb_gadget_map_request_by_dev so we can pass the actual DMA-capable
hardware device (aspeed-vhub platform device) to the API?


Cheers,

Tao


fs/ntfs/aops.c:378:12: warning: stack frame size of 2288 bytes in function 'ntfs_readpage'

2021-03-27 Thread kernel test robot
tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   0f4498cef9f5cd18d7c6639a2a902ec1edc5be4e
commit: 4eeef098b43242ed145c83fba9989d586d707589 powerpc/44x: Remove 
STDBINUTILS kconfig option
date:   8 weeks ago
config: powerpc64-randconfig-r036-20210328 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 
d50fe9f0d6b9ee61df8830a67ea0a33c27a637e7)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# install powerpc64 cross compiling tool for clang build
# apt-get install binutils-powerpc64-linux-gnu
# 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4eeef098b43242ed145c83fba9989d586d707589
git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 4eeef098b43242ed145c83fba9989d586d707589
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross 
ARCH=powerpc64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>):

>> fs/ntfs/aops.c:378:12: warning: stack frame size of 2288 bytes in function 
>> 'ntfs_readpage' [-Wframe-larger-than=]
   static int ntfs_readpage(struct file *file, struct page *page)
  ^
   1 warning generated.
--
>> net/bluetooth/hci_core.c:2108:26: warning: result of comparison of constant 
>> 65536 with expression of type '__u16' (aka 'unsigned short') is always false 
>> [-Wtautological-constant-out-of-range-compare]
   if (!dev_num || dev_num > (PAGE_SIZE * 2) / sizeof(*dr))
   ^~~~
   include/linux/compiler.h:56:47: note: expanded from macro 'if'
   #define if(cond, ...) if ( __trace_if_var( !!(cond , ## __VA_ARGS__) ) )
  ~~~^~~~
   include/linux/compiler.h:58:86: note: expanded from macro '__trace_if_var'
   #define __trace_if_var(cond) (__builtin_constant_p(cond) ? (cond) : 
__trace_if_value(cond))
   
~^
   include/linux/compiler.h:69:3: note: expanded from macro '__trace_if_value'
   (cond) ?\
^~~~
>> net/bluetooth/hci_core.c:2108:26: warning: result of comparison of constant 
>> 65536 with expression of type '__u16' (aka 'unsigned short') is always false 
>> [-Wtautological-constant-out-of-range-compare]
   if (!dev_num || dev_num > (PAGE_SIZE * 2) / sizeof(*dr))
   ^~~~
   include/linux/compiler.h:56:47: note: expanded from macro 'if'
   #define if(cond, ...) if ( __trace_if_var( !!(cond , ## __VA_ARGS__) ) )
  ~~~^~~~
   include/linux/compiler.h:58:52: note: expanded from macro '__trace_if_var'
   #define __trace_if_var(cond) (__builtin_constant_p(cond) ? (cond) : 
__trace_if_value(cond))
  ^~~~
>> net/bluetooth/hci_core.c:2108:26: warning: result of comparison of constant 
>> 65536 with expression of type '__u16' (aka 'unsigned short') is always false 
>> [-Wtautological-constant-out-of-range-compare]
   if (!dev_num || dev_num > (PAGE_SIZE * 2) / sizeof(*dr))
   ^~~~
   include/linux/compiler.h:56:47: note: expanded from macro 'if'
   #define if(cond, ...) if ( __trace_if_var( !!(cond , ## __VA_ARGS__) ) )
  ~~~^~~~
   include/linux/compiler.h:58:61: note: expanded from macro '__trace_if_var'
   #define __trace_if_var(cond) (__builtin_constant_p(cond) ? (cond) : 
__trace_if_value(cond))
   ^~~~
   3 warnings generated.


vim +/ntfs_readpage +378 fs/ntfs/aops.c

^1da177e4c3f41 Linus Torvalds 2005-04-16  359  
^1da177e4c3f41 Linus Torvalds 2005-04-16  360  /**
^1da177e4c3f41 Linus Torvalds 2005-04-16  361   * ntfs_readpage - fill a 
@page of a @file with data from the device
^1da177e4c3f41 Linus Torvalds 2005-04-16  362   * @file:open file to 
which the page @page belongs or NULL
^1da177e4c3f41 Linus Torvalds 2005-04-16  363   * @page:page cache page 
to fill with data
^1da177e4c3f41 Linus Torvalds 2005-04-16  364   *
^1da177e4c3f41 Linus Torvalds 2005-04-16  365   * For non-resident 
attributes, ntfs_readpage() fills the @page of the open
^1da177e4c3f41 Linus Torvalds 2005-04-16  366   * file @file by calling the 
ntfs version of the generic block_read_full_page()
^1da177e4c3f41 Linus 

Re: [PATCH] kconfig: nconf: stop endless search-up loops

2021-03-27 Thread Mihai Moldovan
* On 3/27/21 4:58 PM, Randy Dunlap wrote:
> On 3/27/21 5:01 AM, Mihai Moldovan wrote:
>> +if ((-1 == index) && (index == match_start))
> 
> checkpatch doesn't complain about this (and I wonder how it's missed), but
> kernel style is (mostly) "constant goes on right hand side of comparison",
> so
>   if ((index == -1) &&

I can naturally send a V2 with that swapped.

To my rationale: I made sure to use checkpatch, saw that it was accepted and
even went for a quick git grep -- '-1 ==', which likewise returned enough
results for me to call this consistent with the current code style.

Maybe those matches were just frowned-upon, but forgotten-to-be-critized
examples of this pattern being used.



Mihai




OpenPGP_signature
Description: OpenPGP digital signature


Re: [PATCH] userfaultfd/shmem: fix MCOPY_ATOMIC_CONTNUE error handling + accounting

2021-03-27 Thread Peter Xu
Axel,

On Thu, Mar 25, 2021 at 04:10:27PM -0700, Axel Rasmussen wrote:
> Previously, in the error path, we unconditionally removed the page from
> the page cache. But in the continue case, we didn't add it - it was
> already there because the page is used by a second (non-UFFD-registered)
> mapping. So, in that case, it's incorrect to remove it as the other
> mapping may still use it normally.
> 
> For this error handling failure, trivially exercise it in the
> userfaultfd selftest, to detect this kind of bug in the future.
> 
> Also, we previously were unconditionally calling shmem_inode_acct_block.
> In the continue case, however, this is incorrect, because we would have
> already accounted for the RAM usage when the page was originally
> allocated (since at this point it's already in the page cache). So,
> doing it in the continue case causes us to double-count.
> 
> Fixes: 00da60b9d0a0 ("userfaultfd: support minor fault handling for shmem")
> Signed-off-by: Axel Rasmussen 
> ---
>  mm/shmem.c   | 15 ++-
>  tools/testing/selftests/vm/userfaultfd.c | 12 
>  2 files changed, 22 insertions(+), 5 deletions(-)
> 
> diff --git a/mm/shmem.c b/mm/shmem.c
> index d2e0e81b7d2e..5ac8ea737004 100644
> --- a/mm/shmem.c
> +++ b/mm/shmem.c
> @@ -2379,9 +2379,11 @@ int shmem_mcopy_atomic_pte(struct mm_struct *dst_mm, 
> pmd_t *dst_pmd,
>   int ret;
>   pgoff_t offset, max_off;
>  
> - ret = -ENOMEM;
> - if (!shmem_inode_acct_block(inode, 1))

IMHO a better change here is to only touch this line into:

if (!is_continue && !shmem_inode_acct_block(inode, 1))

Then you don't need to touch any other line, also you can drop line [1] below
too as a side benefit.

> - goto out;
> + if (!is_continue) {
> + ret = -ENOMEM;
> + if (!shmem_inode_acct_block(inode, 1))
> + goto out;
> + }
>  
>   if (is_continue) {
>   ret = -EFAULT;
> @@ -2389,6 +2391,7 @@ int shmem_mcopy_atomic_pte(struct mm_struct *dst_mm, 
> pmd_t *dst_pmd,
>   if (!page)
>   goto out_unacct_blocks;
>   } else if (!*pagep) {
> + ret = -ENOMEM;

[1]

>   page = shmem_alloc_page(gfp, info, pgoff);
>   if (!page)
>   goto out_unacct_blocks;
> @@ -2486,12 +2489,14 @@ int shmem_mcopy_atomic_pte(struct mm_struct *dst_mm, 
> pmd_t *dst_pmd,
>  out_release_unlock:
>   pte_unmap_unlock(dst_pte, ptl);
>   ClearPageDirty(page);

Should this be conditional too?  IIUC this will clear dirty for the page cache
even if it was dirty.  I'm not sure whether it'll cause data loss.

> - delete_from_page_cache(page);
> + if (!is_continue)
> + delete_from_page_cache(page);
>  out_release:
>   unlock_page(page);
>   put_page(page);
>  out_unacct_blocks:
> - shmem_inode_unacct_blocks(inode, 1);
> + if (!is_continue)
> + shmem_inode_unacct_blocks(inode, 1);
>   goto out;
>  }

Besides the error handling, I looked at the function again and I have another
two thoughts:

1. IMHO in shmem_mcopy_atomic_pte() we should also conditionally call
   pte_mkwrite() just like the hugetlb code too, so as to keep W bit clear when
   !VM_SHARED.

2. I see even more "if (!is_continue)" here.. I'm thinking whether we can
   simply jump to pte installation "if (is_continue)" instead, because
   uffdio-continue shoiuld really be a lightweight operation.

   E.g., most of the things at the middle of the function is not relevant to
   uffd-continue.  To be explicit:

ret = -EFAULT;
offset = linear_page_index(dst_vma, dst_addr);
max_off = DIV_ROUND_UP(i_size_read(inode), PAGE_SIZE);
if (unlikely(offset >= max_off))
goto out_release;

   These chunk can be put into !is_continue too, then if you see you're
   bypassing mostly everything.  Then error handling of uffdio-continue would
   be simple too, since it could only fail if either page cache not exist, or
   pte changed.  Nothing else could happen.

For above point (1), I even start to doubt whether we should conditionally
grant the write bit for normal uffdio_copy case only if both WRITE|SHARED set
for the vma flags. E.g., shmem_mcopy_atomic_pte() of a normal uffdio-copy will
fill in the page cache into pte, however what if this mapping is privately
mapped?  IMHO we can't apply write bit otherwise the process will be writting
to the page cache directly.

However I think that question will be irrelevant to this patch.

Thanks,

-- 
Peter Xu



Re: [PATCH v8 1/3] lib: zstd: Add kernel-specific API

2021-03-27 Thread Oleksandr Natalenko
Hello.

On Sat, Mar 27, 2021 at 05:48:01PM +0800, kernel test robot wrote:
> >> ERROR: modpost: "ZSTD_maxCLevel" [fs/f2fs/f2fs.ko] undefined!

Since f2fs can be built as a module, the following correction seems to
be needed:

```
diff --git a/lib/zstd/compress/zstd_compress.c 
b/lib/zstd/compress/zstd_compress.c
index 9c998052a0e5..584c92c51169 100644
--- a/lib/zstd/compress/zstd_compress.c
+++ b/lib/zstd/compress/zstd_compress.c
@@ -4860,6 +4860,7 @@ size_t ZSTD_endStream(ZSTD_CStream* zcs, ZSTD_outBuffer* 
output)
 
 #define ZSTD_MAX_CLEVEL 22
 int ZSTD_maxCLevel(void) { return ZSTD_MAX_CLEVEL; }
+EXPORT_SYMBOL(ZSTD_maxCLevel);
 int ZSTD_minCLevel(void) { return (int)-ZSTD_TARGETLENGTH_MAX; }
 
 static const ZSTD_compressionParameters 
ZSTD_defaultCParameters[4][ZSTD_MAX_CLEVEL+1] = {
```

Not sure if the same should be done for `ZSTD_minCLevel()` since I don't
see it being used anywhere else.

-- 
  Oleksandr Natalenko (post-factum)


Re: [v9,5/7] PCI: mediatek-gen3: Add MSI support

2021-03-27 Thread Marc Zyngier
On Sat, 27 Mar 2021 20:29:04 +,
Pali Rohár  wrote:
> 
> On Saturday 27 March 2021 19:44:30 Marc Zyngier wrote:
> > On Sat, 27 Mar 2021 19:28:37 +,
> > Pali Rohár  wrote:
> > > 
> > > On Wednesday 24 March 2021 11:05:08 Jianjun Wang wrote:
> > > > +static void mtk_pcie_msi_handler(struct mtk_pcie_port *port, int 
> > > > set_idx)
> > > > +{
> > > > +   struct mtk_msi_set *msi_set = >msi_sets[set_idx];
> > > > +   unsigned long msi_enable, msi_status;
> > > > +   unsigned int virq;
> > > > +   irq_hw_number_t bit, hwirq;
> > > > +
> > > > +   msi_enable = readl_relaxed(msi_set->base + 
> > > > PCIE_MSI_SET_ENABLE_OFFSET);
> > > > +
> > > > +   do {
> > > > +   msi_status = readl_relaxed(msi_set->base +
> > > > +  PCIE_MSI_SET_STATUS_OFFSET);
> > > > +   msi_status &= msi_enable;
> > > > +   if (!msi_status)
> > > > +   break;
> > > > +
> > > > +   for_each_set_bit(bit, _status, 
> > > > PCIE_MSI_IRQS_PER_SET) {
> > > > +   hwirq = bit + set_idx * PCIE_MSI_IRQS_PER_SET;
> > > > +   virq = 
> > > > irq_find_mapping(port->msi_bottom_domain, hwirq);
> > > > +   generic_handle_irq(virq);
> > > > +   }
> > > > +   } while (true);
> > > 
> > > Hello!
> > > 
> > > Just a question, cannot this while-loop cause block of processing other
> > > interrupts?
> > 
> > This is a level interrupt. You don't have much choice but to handle it
> > immediately, although an alternative would be to mask it and deal with
> > it in a thread. And since Linux doesn't deal with interrupt priority,
> > a screaming interrupt is never a good thing.
> 
> I see. Something like "interrupt priority" (which does not exist?) would
> be needed to handle it.

Interrupt priorities definitely exist, but Linux doesn't use
them. Furthermore, This wouldn't be relevant here as you get a bunch
of MSI multiplexed onto a single one. Where would you apply the
priority?

> 
> > > I have done tests with different HW (aardvark) but with same while(true)
> > > loop logic. One XHCI PCIe controller was sending MSI interrupts too fast
> > > and interrupt handler with this while(true) logic was in infinite loop.
> > > During one IRQ it was calling infinite many times generic_handle_irq()
> > > as HW was feeding new and new MSI hwirq into status register.
> > 
> > Define "too fast".
> 
> Fast - next interrupt comes prior checking if while(true)-loop should stop.

That's definitely not something you can easily fix at the interrupt
handling level. You need to prevent this from happening. That's
usually the result of a misprogramming or a HW bug.

> > If something in the system is able to program the
> > XHCI device in such a way that it causes a screaming interrupt, that's
> > the place to look for problems, and probably not in the interrupt
> > handling itself, which does what it is supposed to do.
> > 
> > > But this is different HW, so it can have different behavior and does not
> > > have to cause above issue.
> > > 
> > > I have just spotted same code pattern for processing MSI interrupts...
> > 
> > This is a common pattern that you will find in pretty much any
> > interrupt handling/demuxing, and is done this way when the cost of
> > taking the exception is high compared to that of handling it.
> 
> And would not help if while(true)-loop is replaced by loop with upper
> limit of iterations? Or just call only one iteration?

That wouldn't change much: you would still have the interrupt being
pending, and it would fire again at the earliest opportunity.

At best, the root interrupt controller is able to present you with
another interrupt before forcing you to deal with the one you have
ignored again. But you cannot rely on that either.

And to be honest, other interrupts are only a part of the problem you
are describing. With a screaming interrupt, you can't execute
userspace. This is as bad as it gets.

M.

-- 
Without deviation from the norm, progress is not possible.


[PATCH] tty: fix memory leak in vc_deallocate

2021-03-27 Thread Pavel Skripkin
syzbot reported memory leak in tty/vt.
The problem was in VT_DISALLOCATE ioctl cmd.
After allocating unimap with PIO_UNIMAP it wasn't
freed via VT_DISALLOCATE, but vc_cons[currcons].d was
zeroed.

Signed-off-by: Pavel Skripkin 
Reported-by: syzbot+bcc922b19ccc64240...@syzkaller.appspotmail.com
---
 drivers/tty/vt/vt.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 284b07224c55..0cc360da5426 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -1381,6 +1381,7 @@ struct vc_data *vc_deallocate(unsigned int currcons)
atomic_notifier_call_chain(_notifier_list, VT_DEALLOCATE, 
);
vcs_remove_sysfs(currcons);
visual_deinit(vc);
+   con_free_unimap(vc);
put_pid(vc->vt_pid);
vc_uniscr_set(vc, NULL);
kfree(vc->vc_screenbuf);
-- 
2.30.2



[PATCH v25 01/10] fs/ntfs3: Add headers and misc files

2021-03-27 Thread Konstantin Komarov
This adds headers and misc files

Signed-off-by: Konstantin Komarov 
---
 fs/ntfs3/debug.h   |   64 +++
 fs/ntfs3/ntfs.h| 1237 
 fs/ntfs3/ntfs_fs.h | 1087 ++
 fs/ntfs3/upcase.c  |  105 
 4 files changed, 2493 insertions(+)
 create mode 100644 fs/ntfs3/debug.h
 create mode 100644 fs/ntfs3/ntfs.h
 create mode 100644 fs/ntfs3/ntfs_fs.h
 create mode 100644 fs/ntfs3/upcase.c

diff --git a/fs/ntfs3/debug.h b/fs/ntfs3/debug.h
new file mode 100644
index 0..dfaa4c79d
--- /dev/null
+++ b/fs/ntfs3/debug.h
@@ -0,0 +1,64 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ *
+ * Copyright (C) 2019-2021 Paragon Software GmbH, All rights reserved.
+ *
+ * useful functions for debuging
+ */
+
+// clang-format off
+#ifndef Add2Ptr
+#define Add2Ptr(P, I)  ((void *)((u8 *)(P) + (I)))
+#define PtrOffset(B, O)((size_t)((size_t)(O) - (size_t)(B)))
+#endif
+
+#define QuadAlign(n)   (((n) + 7u) & (~7u))
+#define IsQuadAligned(n)   (!((size_t)(n)&7u))
+#define Quad2Align(n)  (((n) + 15u) & (~15u))
+#define IsQuad2Aligned(n)  (!((size_t)(n)&15u))
+#define Quad4Align(n)  (((n) + 31u) & (~31u))
+#define IsSizeTAligned(n)  (!((size_t)(n) & (sizeof(size_t) - 1)))
+#define DwordAlign(n)  (((n) + 3u) & (~3u))
+#define IsDwordAligned(n)  (!((size_t)(n)&3u))
+#define WordAlign(n)   (((n) + 1u) & (~1u))
+#define IsWordAligned(n)   (!((size_t)(n)&1u))
+
+#ifdef CONFIG_PRINTK
+__printf(2, 3)
+void ntfs_printk(const struct super_block *sb, const char *fmt, ...);
+__printf(2, 3)
+void ntfs_inode_printk(struct inode *inode, const char *fmt, ...);
+#else
+static inline __printf(2, 3)
+void ntfs_printk(const struct super_block *sb, const char *fmt, ...)
+{
+}
+
+static inline __printf(2, 3)
+void ntfs_inode_printk(struct inode *inode, const char *fmt, ...)
+{
+}
+#endif
+
+/*
+ * Logging macros ( thanks Joe Perches  for implementation )
+ */
+
+#define ntfs_err(sb, fmt, ...)  ntfs_printk(sb, KERN_ERR fmt, ##__VA_ARGS__)
+#define ntfs_warn(sb, fmt, ...) ntfs_printk(sb, KERN_WARNING fmt, 
##__VA_ARGS__)
+#define ntfs_info(sb, fmt, ...) ntfs_printk(sb, KERN_INFO fmt, ##__VA_ARGS__)
+#define ntfs_notice(sb, fmt, ...)  
\
+   ntfs_printk(sb, KERN_NOTICE fmt, ##__VA_ARGS__)
+
+#define ntfs_inode_err(inode, fmt, ...)
\
+   ntfs_inode_printk(inode, KERN_ERR fmt, ##__VA_ARGS__)
+#define ntfs_inode_warn(inode, fmt, ...)   
\
+   ntfs_inode_printk(inode, KERN_WARNING fmt, ##__VA_ARGS__)
+
+#define ntfs_malloc(s) kmalloc(s, GFP_NOFS)
+#define ntfs_zalloc(s) kzalloc(s, GFP_NOFS)
+#define ntfs_vmalloc(s)kvmalloc(s, GFP_KERNEL)
+#define ntfs_free(p)   kfree(p)
+#define ntfs_vfree(p)  kvfree(p)
+#define ntfs_memdup(src, len)  kmemdup(src, len, GFP_NOFS)
+// clang-format on
diff --git a/fs/ntfs3/ntfs.h b/fs/ntfs3/ntfs.h
new file mode 100644
index 0..d3d3d93a1
--- /dev/null
+++ b/fs/ntfs3/ntfs.h
@@ -0,0 +1,1237 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ *
+ * Copyright (C) 2019-2021 Paragon Software GmbH, All rights reserved.
+ *
+ * on-disk ntfs structs
+ */
+
+// clang-format off
+
+/* TODO:
+ * - Check 4K mft record and 512 bytes cluster
+ */
+
+/*
+ * Activate this define to use binary search in indexes
+ */
+#define NTFS3_INDEX_BINARY_SEARCH
+
+/*
+ * Check each run for marked clusters
+ */
+#define NTFS3_CHECK_FREE_CLST
+
+#define NTFS_NAME_LEN 255
+
+/*
+ * ntfs.sys used 500 maximum links
+ * on-disk struct allows up to 0x
+ */
+#define NTFS_LINK_MAX 0x400
+//#define NTFS_LINK_MAX 0x
+
+/*
+ * Activate to use 64 bit clusters instead of 32 bits in ntfs.sys
+ * Logical and virtual cluster number
+ * If needed, may be redefined to use 64 bit value
+ */
+//#define CONFIG_NTFS3_64BIT_CLUSTER
+
+#define NTFS_LZNT_MAX_CLUSTER  4096
+#define NTFS_LZNT_CUNIT4
+#define NTFS_LZNT_CLUSTERS (1uhigh) << 32);
+#else
+   return le32_to_cpu(ref->low);
+#endif
+}
+
+struct NTFS_BOOT {
+   u8 jump_code[3];// 0x00: Jump to boot code
+   u8 system_id[8];// 0x03: System ID, equals "NTFS"
+
+   // NOTE: this member is not aligned(!)
+   // bytes_per_sector[0] must be 0
+   // bytes_per_sector[1] must be multiplied by 256
+   u8 bytes_per_sector[2]; // 0x0B: Bytes per sector
+
+   u8 sectors_per_clusters;// 0x0D: Sectors per cluster
+   u8 unused1[7];
+   u8 media_type;  // 0x15: Media type (0xF8 - harddisk)
+   u8 unused2[2];
+   __le16 sct_per_track;   // 0x18: number of sectors per track
+   __le16 heads;   // 0x1A: number of heads per cylinder
+   __le32 hidden_sectors;  // 0x1C: number of 'hidden' sectors
+   u8 unused3[4];
+   u8 bios_drive_num;  // 

[PATCH v25 05/10] fs/ntfs3: Add attrib operations

2021-03-27 Thread Konstantin Komarov
This adds attrib operations

Signed-off-by: Konstantin Komarov 
---
 fs/ntfs3/attrib.c   | 2083 +++
 fs/ntfs3/attrlist.c |  456 ++
 fs/ntfs3/xattr.c| 1050 ++
 3 files changed, 3589 insertions(+)
 create mode 100644 fs/ntfs3/attrib.c
 create mode 100644 fs/ntfs3/attrlist.c
 create mode 100644 fs/ntfs3/xattr.c

diff --git a/fs/ntfs3/attrib.c b/fs/ntfs3/attrib.c
new file mode 100644
index 0..188c8b280
--- /dev/null
+++ b/fs/ntfs3/attrib.c
@@ -0,0 +1,2083 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ *
+ * Copyright (C) 2019-2021 Paragon Software GmbH, All rights reserved.
+ *
+ * TODO: merge attr_set_size/attr_data_get_block/attr_allocate_frame?
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "debug.h"
+#include "ntfs.h"
+#include "ntfs_fs.h"
+
+/*
+ * You can set external NTFS_MIN_LOG2_OF_CLUMP/NTFS_MAX_LOG2_OF_CLUMP to manage
+ * preallocate algorithm
+ */
+#ifndef NTFS_MIN_LOG2_OF_CLUMP
+#define NTFS_MIN_LOG2_OF_CLUMP 16
+#endif
+
+#ifndef NTFS_MAX_LOG2_OF_CLUMP
+#define NTFS_MAX_LOG2_OF_CLUMP 26
+#endif
+
+// 16M
+#define NTFS_CLUMP_MIN (1 << (NTFS_MIN_LOG2_OF_CLUMP + 8))
+// 16G
+#define NTFS_CLUMP_MAX (1ull << (NTFS_MAX_LOG2_OF_CLUMP + 8))
+
+/*
+ * get_pre_allocated
+ *
+ */
+static inline u64 get_pre_allocated(u64 size)
+{
+   u32 clump;
+   u8 align_shift;
+   u64 ret;
+
+   if (size <= NTFS_CLUMP_MIN) {
+   clump = 1 << NTFS_MIN_LOG2_OF_CLUMP;
+   align_shift = NTFS_MIN_LOG2_OF_CLUMP;
+   } else if (size >= NTFS_CLUMP_MAX) {
+   clump = 1 << NTFS_MAX_LOG2_OF_CLUMP;
+   align_shift = NTFS_MAX_LOG2_OF_CLUMP;
+   } else {
+   align_shift = NTFS_MIN_LOG2_OF_CLUMP - 1 +
+ __ffs(size >> (8 + NTFS_MIN_LOG2_OF_CLUMP));
+   clump = 1u << align_shift;
+   }
+
+   ret = (((size + clump - 1) >> align_shift)) << align_shift;
+
+   return ret;
+}
+
+/*
+ * attr_must_be_resident
+ *
+ * returns true if attribute must be resident
+ */
+static inline bool attr_must_be_resident(struct ntfs_sb_info *sbi,
+enum ATTR_TYPE type)
+{
+   const struct ATTR_DEF_ENTRY *de;
+
+   switch (type) {
+   case ATTR_STD:
+   case ATTR_NAME:
+   case ATTR_ID:
+   case ATTR_LABEL:
+   case ATTR_VOL_INFO:
+   case ATTR_ROOT:
+   case ATTR_EA_INFO:
+   return true;
+   default:
+   de = ntfs_query_def(sbi, type);
+   if (de && (de->flags & NTFS_ATTR_MUST_BE_RESIDENT))
+   return true;
+   return false;
+   }
+}
+
+/*
+ * attr_load_runs
+ *
+ * load all runs stored in 'attr'
+ */
+int attr_load_runs(struct ATTRIB *attr, struct ntfs_inode *ni,
+  struct runs_tree *run, const CLST *vcn)
+{
+   int err;
+   CLST svcn = le64_to_cpu(attr->nres.svcn);
+   CLST evcn = le64_to_cpu(attr->nres.evcn);
+   u32 asize;
+   u16 run_off;
+
+   if (svcn >= evcn + 1 || run_is_mapped_full(run, svcn, evcn))
+   return 0;
+
+   if (vcn && (evcn < *vcn || *vcn < svcn))
+   return -EINVAL;
+
+   asize = le32_to_cpu(attr->size);
+   run_off = le16_to_cpu(attr->nres.run_off);
+   err = run_unpack_ex(run, ni->mi.sbi, ni->mi.rno, svcn, evcn,
+   vcn ? *vcn : svcn, Add2Ptr(attr, run_off),
+   asize - run_off);
+   if (err < 0)
+   return err;
+
+   return 0;
+}
+
+/*
+ * int run_deallocate_ex
+ *
+ * Deallocate clusters
+ */
+static int run_deallocate_ex(struct ntfs_sb_info *sbi, struct runs_tree *run,
+CLST vcn, CLST len, CLST *done, bool trim)
+{
+   int err = 0;
+   CLST vcn_next, vcn0 = vcn, lcn, clen, dn = 0;
+   size_t idx;
+
+   if (!len)
+   goto out;
+
+   if (!run_lookup_entry(run, vcn, , , )) {
+failed:
+   run_truncate(run, vcn0);
+   err = -EINVAL;
+   goto out;
+   }
+
+   for (;;) {
+   if (clen > len)
+   clen = len;
+
+   if (!clen) {
+   err = -EINVAL;
+   goto out;
+   }
+
+   if (lcn != SPARSE_LCN) {
+   mark_as_free_ex(sbi, lcn, clen, trim);
+   dn += clen;
+   }
+
+   len -= clen;
+   if (!len)
+   break;
+
+   vcn_next = vcn + clen;
+   if (!run_get_entry(run, ++idx, , , ) ||
+   vcn != vcn_next) {
+   // save memory - don't load entire run
+   goto failed;
+   }
+   }
+
+out:
+   if (done)
+   *done += dn;
+
+   return err;
+}
+
+/*
+ * attr_allocate_clusters
+ *
+ * find 

[PATCH v25 06/10] fs/ntfs3: Add compression

2021-03-27 Thread Konstantin Komarov
This patch adds different types of NTFS-applicable compressions:
- lznt
- lzx
- xpress
Latter two (lzx, xpress) implement Windows Compact OS feature and
were taken from ntfs-3g system comression plugin authored by Eric Biggers
(https://github.com/ebiggers/ntfs-3g-system-compression)
which were ported to ntfs3 and adapted to Linux Kernel environment.

Signed-off-by: Konstantin Komarov 
---
 fs/ntfs3/lib/decompress_common.c | 332 +++
 fs/ntfs3/lib/decompress_common.h | 352 
 fs/ntfs3/lib/lib.h   |  26 ++
 fs/ntfs3/lib/lzx_decompress.c| 683 +++
 fs/ntfs3/lib/xpress_decompress.c | 155 +++
 fs/ntfs3/lznt.c  | 452 
 6 files changed, 2000 insertions(+)
 create mode 100644 fs/ntfs3/lib/decompress_common.c
 create mode 100644 fs/ntfs3/lib/decompress_common.h
 create mode 100644 fs/ntfs3/lib/lib.h
 create mode 100644 fs/ntfs3/lib/lzx_decompress.c
 create mode 100644 fs/ntfs3/lib/xpress_decompress.c
 create mode 100644 fs/ntfs3/lznt.c

diff --git a/fs/ntfs3/lib/decompress_common.c b/fs/ntfs3/lib/decompress_common.c
new file mode 100644
index 0..83c9e93ae
--- /dev/null
+++ b/fs/ntfs3/lib/decompress_common.c
@@ -0,0 +1,332 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * decompress_common.c - Code shared by the XPRESS and LZX decompressors
+ *
+ * Copyright (C) 2015 Eric Biggers
+ *
+ * This program is free software: you can redistribute it and/or modify it 
under
+ * the terms of the GNU General Public License as published by the Free 
Software
+ * Foundation, either version 2 of the License, or (at your option) any later
+ * version.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or 
FITNESS
+ * FOR A PARTICULAR PURPOSE.  See the GNU General Public License for more
+ * details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include "decompress_common.h"
+
+/*
+ * make_huffman_decode_table() -
+ *
+ * Build a decoding table for a canonical prefix code, or "Huffman code".
+ *
+ * This is an internal function, not part of the library API!
+ *
+ * This takes as input the length of the codeword for each symbol in the
+ * alphabet and produces as output a table that can be used for fast
+ * decoding of prefix-encoded symbols using read_huffsym().
+ *
+ * Strictly speaking, a canonical prefix code might not be a Huffman
+ * code.  But this algorithm will work either way; and in fact, since
+ * Huffman codes are defined in terms of symbol frequencies, there is no
+ * way for the decompressor to know whether the code is a true Huffman
+ * code or not until all symbols have been decoded.
+ *
+ * Because the prefix code is assumed to be "canonical", it can be
+ * reconstructed directly from the codeword lengths.  A prefix code is
+ * canonical if and only if a longer codeword never lexicographically
+ * precedes a shorter codeword, and the lexicographic ordering of
+ * codewords of the same length is the same as the lexicographic ordering
+ * of the corresponding symbols.  Consequently, we can sort the symbols
+ * primarily by codeword length and secondarily by symbol value, then
+ * reconstruct the prefix code by generating codewords lexicographically
+ * in that order.
+ *
+ * This function does not, however, generate the prefix code explicitly.
+ * Instead, it directly builds a table for decoding symbols using the
+ * code.  The basic idea is this: given the next 'max_codeword_len' bits
+ * in the input, we can look up the decoded symbol by indexing a table
+ * containing 2**max_codeword_len entries.  A codeword with length
+ * 'max_codeword_len' will have exactly one entry in this table, whereas
+ * a codeword shorter than 'max_codeword_len' will have multiple entries
+ * in this table.  Precisely, a codeword of length n will be represented
+ * by 2**(max_codeword_len - n) entries in this table.  The 0-based index
+ * of each such entry will contain the corresponding codeword as a prefix
+ * when zero-padded on the left to 'max_codeword_len' binary digits.
+ *
+ * That's the basic idea, but we implement two optimizations regarding
+ * the format of the decode table itself:
+ *
+ * - For many compression formats, the maximum codeword length is too
+ *   long for it to be efficient to build the full decoding table
+ *   whenever a new prefix code is used.  Instead, we can build the table
+ *   using only 2**table_bits entries, where 'table_bits' is some number
+ *   less than or equal to 'max_codeword_len'.  Then, only codewords of
+ *   length 'table_bits' and shorter can be directly looked up.  For
+ *   longer codewords, the direct lookup instead produces the root of a
+ *   binary tree.  Using this tree, the decoder can do traditional
+ *   bit-by-bit decoding of the remainder of 

[PATCH v25 09/10] fs/ntfs3: Add NTFS3 in fs/Kconfig and fs/Makefile

2021-03-27 Thread Konstantin Komarov
This adds NTFS3 in fs/Kconfig and fs/Makefile

Signed-off-by: Konstantin Komarov 
---
 fs/Kconfig  | 1 +
 fs/Makefile | 1 +
 2 files changed, 2 insertions(+)

diff --git a/fs/Kconfig b/fs/Kconfig
index 9e7e47933..1bf7b82d5 100644
--- a/fs/Kconfig
+++ b/fs/Kconfig
@@ -146,6 +146,7 @@ menu "DOS/FAT/EXFAT/NT Filesystems"
 source "fs/fat/Kconfig"
 source "fs/exfat/Kconfig"
 source "fs/ntfs/Kconfig"
+source "fs/ntfs3/Kconfig"
 
 endmenu
 endif # BLOCK
diff --git a/fs/Makefile b/fs/Makefile
index 542a77374..8f199ba5b 100644
--- a/fs/Makefile
+++ b/fs/Makefile
@@ -101,6 +101,7 @@ obj-$(CONFIG_CIFS)  += cifs/
 obj-$(CONFIG_SMB_SERVER)   += cifsd/
 obj-$(CONFIG_HPFS_FS)  += hpfs/
 obj-$(CONFIG_NTFS_FS)  += ntfs/
+obj-$(CONFIG_NTFS3_FS) += ntfs3/
 obj-$(CONFIG_UFS_FS)   += ufs/
 obj-$(CONFIG_EFS_FS)   += efs/
 obj-$(CONFIG_JFFS2_FS) += jffs2/
-- 
2.25.4



[PATCH v25 10/10] fs/ntfs3: Add MAINTAINERS

2021-03-27 Thread Konstantin Komarov
This adds MAINTAINERS

Signed-off-by: Konstantin Komarov 
---
 MAINTAINERS | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 67b104202..832f7d4d0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12875,6 +12875,13 @@ T: git 
git://git.kernel.org/pub/scm/linux/kernel/git/aia21/ntfs.git
 F: Documentation/filesystems/ntfs.rst
 F: fs/ntfs/
 
+NTFS3 FILESYSTEM
+M: Konstantin Komarov 
+S: Supported
+W: http://www.paragon-software.com/
+F: Documentation/filesystems/ntfs3.rst
+F: fs/ntfs3/
+
 NUBUS SUBSYSTEM
 M: Finn Thain 
 L: linux-m...@lists.linux-m68k.org
-- 
2.25.4



[PATCH v25 08/10] fs/ntfs3: Add Kconfig, Makefile and doc

2021-03-27 Thread Konstantin Komarov
This adds Kconfig, Makefile and doc

Signed-off-by: Konstantin Komarov 
---
 Documentation/filesystems/ntfs3.rst | 107 
 fs/ntfs3/Kconfig|  46 
 fs/ntfs3/Makefile   |  34 +
 3 files changed, 187 insertions(+)
 create mode 100644 Documentation/filesystems/ntfs3.rst
 create mode 100644 fs/ntfs3/Kconfig
 create mode 100644 fs/ntfs3/Makefile

diff --git a/Documentation/filesystems/ntfs3.rst 
b/Documentation/filesystems/ntfs3.rst
new file mode 100644
index 0..fb2906736
--- /dev/null
+++ b/Documentation/filesystems/ntfs3.rst
@@ -0,0 +1,107 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=
+NTFS3
+=
+
+
+Summary and Features
+
+
+NTFS3 is fully functional NTFS Read-Write driver. The driver works with
+NTFS versions up to 3.1, normal/compressed/sparse files
+and journal replaying. File system type to use on mount is 'ntfs3'.
+
+- This driver implements NTFS read/write support for normal, sparse and
+  compressed files.
+- Supports native journal replaying;
+- Supports extended attributes
+   Predefined extended attributes:
+   - 'system.ntfs_security' gets/sets security
+   descriptor (SECURITY_DESCRIPTOR_RELATIVE)
+   - 'system.ntfs_attrib' gets/sets ntfs file/dir attributes.
+   Note: applied to empty files, this allows to switch type between
+   sparse(0x200), compressed(0x800) and normal;
+- Supports NFS export of mounted NTFS volumes.
+
+Mount Options
+=
+
+The list below describes mount options supported by NTFS3 driver in addition to
+generic ones.
+
+===
+
+nls=name   This option informs the driver how to interpret path
+   strings and translate them to Unicode and back. If
+   this option is not set, the default codepage will be
+   used (CONFIG_NLS_DEFAULT).
+   Examples:
+   'nls=utf8'
+
+uid=
+gid=
+umask= Controls the default permissions for files/directories 
created
+   after the NTFS volume is mounted.
+
+fmask=
+dmask= Instead of specifying umask which applies both to
+   files and directories, fmask applies only to files and
+   dmask only to directories.
+
+nohidden   Files with the Windows-specific HIDDEN 
(FILE_ATTRIBUTE_HIDDEN)
+   attribute will not be shown under Linux.
+
+sys_immutable  Files with the Windows-specific SYSTEM
+   (FILE_ATTRIBUTE_SYSTEM) attribute will be marked as 
system
+   immutable files.
+
+discardEnable support of the TRIM command for improved 
performance
+   on delete operations, which is recommended for use with 
the
+   solid-state drives (SSD).
+
+force  Forces the driver to mount partitions even if 'dirty' 
flag
+   (volume dirty) is set. Not recommended for use.
+
+sparse Create new files as "sparse".
+
+showmeta   Use this parameter to show all meta-files (System 
Files) on
+   a mounted NTFS partition.
+   By default, all meta-files are hidden.
+
+prealloc   Preallocate space for files excessively when file size 
is
+   increasing on writes. Decreases fragmentation in case of
+   parallel write operations to different files.
+
+no_acs_rules   "No access rules" mount option sets access rights for
+   files/folders to 777 and owner/group to root. This mount
+   option absorbs all other permissions:
+   - permissions change for files/folders will be reported
+   as successful, but they will remain 777;
+   - owner/group change will be reported as successful, but
+   they will stay as root
+
+aclSupport POSIX ACLs (Access Control Lists). Effective if
+   supported by Kernel. Not to be confused with NTFS ACLs.
+   The option specified as acl enables support for POSIX 
ACLs.
+
+noatimeAll files and directories will not update their 
last access
+   time attribute if a partition is mounted with this 
parameter.
+   This option can speed up file system operation.
+
+===
+
+ToDo list
+=
+
+- Full journaling support (currently journal replaying is supported) over JBD.
+
+
+References
+==
+https://www.paragon-software.com/home/ntfs-linux-professional/
+   

[PATCH v25 07/10] fs/ntfs3: Add NTFS journal

2021-03-27 Thread Konstantin Komarov
This adds NTFS journal

Signed-off-by: Konstantin Komarov 
---
 fs/ntfs3/fslog.c | 5208 ++
 1 file changed, 5208 insertions(+)
 create mode 100644 fs/ntfs3/fslog.c

diff --git a/fs/ntfs3/fslog.c b/fs/ntfs3/fslog.c
new file mode 100644
index 0..fc287a500
--- /dev/null
+++ b/fs/ntfs3/fslog.c
@@ -0,0 +1,5208 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ *
+ * Copyright (C) 2019-2021 Paragon Software GmbH, All rights reserved.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "debug.h"
+#include "ntfs.h"
+#include "ntfs_fs.h"
+
+/*
+ * LOG FILE structs
+ */
+
+// clang-format off
+
+#define MaxLogFileSize 0x1ull
+#define DefaultLogPageSize 4096
+#define MinLogRecordPages  0x30
+
+struct RESTART_HDR {
+   struct NTFS_RECORD_HEADER rhdr; // 'RSTR'
+   __le32 sys_page_size; // 0x10: Page size of the system which 
initialized the log
+   __le32 page_size; // 0x14: Log page size used for this log file
+   __le16 ra_off;// 0x18:
+   __le16 minor_ver; // 0x1A:
+   __le16 major_ver; // 0x1C:
+   __le16 fixups[1];
+};
+
+#define LFS_NO_CLIENT 0x
+#define LFS_NO_CLIENT_LE cpu_to_le16(0x)
+
+struct CLIENT_REC {
+   __le64 oldest_lsn;
+   __le64 restart_lsn; // 0x08:
+   __le16 prev_client; // 0x10:
+   __le16 next_client; // 0x12:
+   __le16 seq_num; // 0x14:
+   u8 align[6];// 0x16
+   __le32 name_bytes;  // 0x1C: in bytes
+   __le16 name[32];// 0x20: name of client
+};
+
+static_assert(sizeof(struct CLIENT_REC) == 0x60);
+
+/* Two copies of these will exist at the beginning of the log file */
+struct RESTART_AREA {
+   __le64 current_lsn;// 0x00: Current logical end of log file
+   __le16 log_clients;// 0x08: Maximum number of clients
+   __le16 client_idx[2];  // 0x0A: free/use index into the client record 
arrays
+   __le16 flags;  // 0x0E: See RESTART_SINGLE_PAGE_IO
+   __le32 seq_num_bits;   // 0x10: the number of bits in sequence number.
+   __le16 ra_len; // 0x14:
+   __le16 client_off; // 0x16:
+   __le64 l_size; // 0x18: Usable log file size.
+   __le32 last_lsn_data_len; // 0x20:
+   __le16 rec_hdr_len;// 0x24: log page data offset
+   __le16 data_off;   // 0x26: log page data length
+   __le32 open_log_count; // 0x28:
+   __le32 align[5];   // 0x2C:
+   struct CLIENT_REC clients[1]; // 0x40:
+};
+
+struct LOG_REC_HDR {
+   __le16 redo_op;  // 0x00:  NTFS_LOG_OPERATION
+   __le16 undo_op;  // 0x02:  NTFS_LOG_OPERATION
+   __le16 redo_off; // 0x04:  Offset to Redo record
+   __le16 redo_len; // 0x06:  Redo length
+   __le16 undo_off; // 0x08:  Offset to Undo record
+   __le16 undo_len; // 0x0A:  Undo length
+   __le16 target_attr;  // 0x0C:
+   __le16 lcns_follow;  // 0x0E:
+   __le16 record_off;   // 0x10:
+   __le16 attr_off; // 0x12:
+   __le16 cluster_off;  // 0x14:
+   __le16 reserved; // 0x16:
+   __le64 target_vcn;   // 0x18:
+   __le64 page_lcns[1]; // 0x20:
+};
+
+static_assert(sizeof(struct LOG_REC_HDR) == 0x28);
+
+#define RESTART_ENTRY_ALLOCATED0x
+#define RESTART_ENTRY_ALLOCATED_LE cpu_to_le32(0x)
+
+struct RESTART_TABLE {
+   __le16 size;   // 0x00:  In bytes
+   __le16 used;   // 0x02: entries
+   __le16 total;  // 0x04: entries
+   __le16 res[3]; // 0x06:
+   __le32 free_goal;  // 0x0C:
+   __le32 first_free; // 0x10
+   __le32 last_free;  // 0x14
+
+};
+
+static_assert(sizeof(struct RESTART_TABLE) == 0x18);
+
+struct ATTR_NAME_ENTRY {
+   __le16 off; // offset in the Open attribute Table
+   __le16 name_bytes;
+   __le16 name[1];
+};
+
+struct OPEN_ATTR_ENRTY {
+   __le32 next;// 0x00: RESTART_ENTRY_ALLOCATED if allocated
+   __le32 bytes_per_index; // 0x04:
+   enum ATTR_TYPE type;// 0x08:
+   u8 is_dirty_pages;  // 0x0C:
+   u8 is_attr_name;// 0x0B: Faked field to manage 'ptr'
+   u8 name_len;// 0x0C: Faked field to manage 'ptr'
+   u8 res;
+   struct MFT_REF ref; // 0x10: File Reference of file containing attribute
+   __le64 open_record_lsn; // 0x18:
+   void *ptr;  // 0x20:
+};
+
+/* 32 bit version of 'struct OPEN_ATTR_ENRTY' */
+struct OPEN_ATTR_ENRTY_32 {
+   __le32 next;// 0x00: RESTART_ENTRY_ALLOCATED if allocated
+   __le32 ptr; // 0x04:
+   struct MFT_REF ref; // 0x08:
+   __le64 open_record_lsn; // 0x10:
+   u8 is_dirty_pages;  // 0x18:
+   u8 is_attr_name;// 0x19
+   u8 res1[2];
+   enum ATTR_TYPE type;// 0x1C:
+   u8 name_len;// 0x20:  in wchar
+   u8 res2[3];
+   __le32 AttributeName;   // 0x24:
+   

[PATCH v25 03/10] fs/ntfs3: Add bitmap

2021-03-27 Thread Konstantin Komarov
This adds bitmap

Signed-off-by: Konstantin Komarov 
---
 fs/ntfs3/bitfunc.c |  135 
 fs/ntfs3/bitmap.c  | 1519 
 2 files changed, 1654 insertions(+)
 create mode 100644 fs/ntfs3/bitfunc.c
 create mode 100644 fs/ntfs3/bitmap.c

diff --git a/fs/ntfs3/bitfunc.c b/fs/ntfs3/bitfunc.c
new file mode 100644
index 0..2de5faef2
--- /dev/null
+++ b/fs/ntfs3/bitfunc.c
@@ -0,0 +1,135 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ *
+ * Copyright (C) 2019-2021 Paragon Software GmbH, All rights reserved.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+
+#include "debug.h"
+#include "ntfs.h"
+#include "ntfs_fs.h"
+
+#define BITS_IN_SIZE_T (sizeof(size_t) * 8)
+
+/*
+ * fill_mask[i] - first i bits are '1' , i = 0,1,2,3,4,5,6,7,8
+ * fill_mask[i] = 0xFF >> (8-i)
+ */
+static const u8 fill_mask[] = { 0x00, 0x01, 0x03, 0x07, 0x0F,
+   0x1F, 0x3F, 0x7F, 0xFF };
+
+/*
+ * zero_mask[i] - first i bits are '0' , i = 0,1,2,3,4,5,6,7,8
+ * zero_mask[i] = 0xFF << i
+ */
+static const u8 zero_mask[] = { 0xFF, 0xFE, 0xFC, 0xF8, 0xF0,
+   0xE0, 0xC0, 0x80, 0x00 };
+
+/*
+ * are_bits_clear
+ *
+ * Returns true if all bits [bit, bit+nbits) are zeros "0"
+ */
+bool are_bits_clear(const ulong *lmap, size_t bit, size_t nbits)
+{
+   size_t pos = bit & 7;
+   const u8 *map = (u8 *)lmap + (bit >> 3);
+
+   if (pos) {
+   if (8 - pos >= nbits)
+   return !nbits || !(*map & fill_mask[pos + nbits] &
+  zero_mask[pos]);
+
+   if (*map++ & zero_mask[pos])
+   return false;
+   nbits -= 8 - pos;
+   }
+
+   pos = ((size_t)map) & (sizeof(size_t) - 1);
+   if (pos) {
+   pos = sizeof(size_t) - pos;
+   if (nbits >= pos * 8) {
+   for (nbits -= pos * 8; pos; pos--, map++) {
+   if (*map)
+   return false;
+   }
+   }
+   }
+
+   for (pos = nbits / BITS_IN_SIZE_T; pos; pos--, map += sizeof(size_t)) {
+   if (*((size_t *)map))
+   return false;
+   }
+
+   for (pos = (nbits % BITS_IN_SIZE_T) >> 3; pos; pos--, map++) {
+   if (*map)
+   return false;
+   }
+
+   pos = nbits & 7;
+   if (pos && (*map & fill_mask[pos]))
+   return false;
+
+   // All bits are zero
+   return true;
+}
+
+/*
+ * are_bits_set
+ *
+ * Returns true if all bits [bit, bit+nbits) are ones "1"
+ */
+bool are_bits_set(const ulong *lmap, size_t bit, size_t nbits)
+{
+   u8 mask;
+   size_t pos = bit & 7;
+   const u8 *map = (u8 *)lmap + (bit >> 3);
+
+   if (pos) {
+   if (8 - pos >= nbits) {
+   mask = fill_mask[pos + nbits] & zero_mask[pos];
+   return !nbits || (*map & mask) == mask;
+   }
+
+   mask = zero_mask[pos];
+   if ((*map++ & mask) != mask)
+   return false;
+   nbits -= 8 - pos;
+   }
+
+   pos = ((size_t)map) & (sizeof(size_t) - 1);
+   if (pos) {
+   pos = sizeof(size_t) - pos;
+   if (nbits >= pos * 8) {
+   for (nbits -= pos * 8; pos; pos--, map++) {
+   if (*map != 0xFF)
+   return false;
+   }
+   }
+   }
+
+   for (pos = nbits / BITS_IN_SIZE_T; pos; pos--, map += sizeof(size_t)) {
+   if (*((size_t *)map) != MINUS_ONE_T)
+   return false;
+   }
+
+   for (pos = (nbits % BITS_IN_SIZE_T) >> 3; pos; pos--, map++) {
+   if (*map != 0xFF)
+   return false;
+   }
+
+   pos = nbits & 7;
+   if (pos) {
+   u8 mask = fill_mask[pos];
+
+   if ((*map & mask) != mask)
+   return false;
+   }
+
+   // All bits are ones
+   return true;
+}
diff --git a/fs/ntfs3/bitmap.c b/fs/ntfs3/bitmap.c
new file mode 100644
index 0..32aab0031
--- /dev/null
+++ b/fs/ntfs3/bitmap.c
@@ -0,0 +1,1519 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ *
+ * Copyright (C) 2019-2021 Paragon Software GmbH, All rights reserved.
+ *
+ * This code builds two trees of free clusters extents.
+ * Trees are sorted by start of extent and by length of extent.
+ * NTFS_MAX_WND_EXTENTS defines the maximum number of elements in trees.
+ * In extreme case code reads on-disk bitmap to find free clusters
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "debug.h"
+#include "ntfs.h"
+#include "ntfs_fs.h"
+
+/*
+ * Maximum number of extents in tree.
+ */
+#define NTFS_MAX_WND_EXTENTS (32u * 1024u)
+
+struct rb_node_key {
+   struct rb_node node;
+   size_t key;

[PATCH v25 00/10] NTFS read-write driver GPL implementation by Paragon Software

2021-03-27 Thread Konstantin Komarov
This patch adds NTFS Read-Write driver to fs/ntfs3.

Having decades of expertise in commercial file systems development and huge
test coverage, we at Paragon Software GmbH want to make our contribution to
the Open Source Community by providing implementation of NTFS Read-Write
driver for the Linux Kernel.

This is fully functional NTFS Read-Write driver. Current version works with
NTFS(including v3.1) and normal/compressed/sparse files and supports journal 
replaying.

We plan to support this version after the codebase once merged, and add new
features and fix bugs. For example, full journaling support over JBD will be
added in later updates.

v2:
 - patch splitted to chunks (file-wise)
 - build issues fixed
 - sparse and checkpatch.pl errors fixed
 - NULL pointer dereference on mkfs.ntfs-formatted volume mount fixed
 - cosmetics + code cleanup

v3:
 - added acl, noatime, no_acs_rules, prealloc mount options
 - added fiemap support
 - fixed encodings support
 - removed typedefs
 - adapted Kernel-way logging mechanisms
 - fixed typos and corner-case issues

v4:
 - atomic_open() refactored
 - code style updated
 - bugfixes

v5:
- nls/nls_alt mount options added
- Unicode conversion fixes
- Improved very fragmented files operations
- logging cosmetics

v6:
- Security Descriptors processing changed
  added system.ntfs_security xattr to set
  SD
- atomic_open() optimized
- cosmetics

v7:
- Security Descriptors validity checks added (by Mark Harmstone)
- atomic_open() fixed for the compressed file creation with directio
  case
- remount support
- temporarily removed readahead usage
- cosmetics

v8:
- Compressed files operations fixed

v9:
- Further cosmetics applied as suggested
by Joe Perches

v10:
- operations with compressed/sparse files on very fragmented volumes improved
- reduced memory consumption for above cases

v11:
- further compressed files optimizations: reads/writes are now skipping 
bufferization
- journal wipe to the initial state optimized (bufferization is also skipped)
- optimized run storage (re-packing cluster metainformation)
- fixes based on Matthew Wilcox feedback to the v10
- compressed/sparse/normal could be set for empty files with 
'system.ntfs_attrib' xattr

v12:
- nls_alt mount option removed after discussion with Pali Rohar
- fixed ni_repack()
- fixed resident files transition to non-resident when size increasing

v13:
- nested_lock fix (lockdep)
- out-of-bounds read fix (KASAN warning)
- resident->nonresident transition fixed for compressed files
- load_nls() missed fix applied
- some sparse utility warnings fixes

v14:
- support for additional compression types (we've adapted WIMLIB's
  implementation, authored by Eric Biggers, into ntfs3)

v15:
- kernel test robot warnings fixed
- lzx/xpress compression license headers updated

v16:
- lzx/xpress moved to initial ntfs-3g plugin code
- mutexes instead of a global spinlock for compresions
- FALLOC_FL_PUNCH_HOLE and FALLOC_FL_COLLAPSE_RANGE implemented
- CONFIG_NTFS3_FS_POSIX_ACL added

v17:
- FALLOC_FL_COLLAPSE_RANGE fixed
- fixes for Mattew Wilcox's and Andy Lavr's concerns

v18:
- ntfs_alloc macro splitted into two ntfs_malloc + ntfs_zalloc
- attrlist.c: always use ntfs_cmp_names instead of memcmp; compare entry names
  only for entry with vcn == 0
- dir.c: remove unconditional ni_lock in ntfs_readdir
- fslog.c: corrected error case behavior
- index.c: refactored due to modification of ntfs_cmp_names; use rw_semaphore
  for read/write access to alloc_run and bitmap_run while ntfs_readdir
- run.c: separated big/little endian code in functions
- upcase.c: improved ntfs_cmp_names, thanks to Kari Argillander for idea
  and 'bothcase' implementation

v19:
- fixed directory bitmap for 2MB cluster size
- fixed rw_semaphore init for directories

v20:
- fixed issue with incorrect hidden/system attribute setting on
  root subdirectories
- use kvmalloc instead of kmalloc for runs array
- fixed index behavior on volumes with cluster size more than 4k
- current build info is added into module info instead of printing on insmod

v21:
- fixes for clang CFI checks
- fixed sb->s_maxbytes for 32bit clusters
- user.DOSATTRIB is no more intercepted by ntfs3
- corrected xattr limits;  is used
- corrected CONFIG_NTFS3_64BIT_CLUSTER usage
- info about current build is added into module info and printing
on insmod (by Andy Lavr's request)
note: v21 is applicable for 'linux-next' not older than 2021.01.28

v22:
- ntfs_cmp_names() fixed
- raise warning if 'nls->uni2char' fails
- hot fix free clusters code optimized
- use clang-format 11.0 instead of 10.0 to format code

v23:
- corrections for Kernel Test Robot warnings
- kmem_cache_create() utilized to allocate memory in bitmap.c
- cosmetics and comments thru the code

v24:
- BIO_MAX_PAGES -> BIO_MAX_VECS (fix for build issue of v23 vs linux-next)
- minor optimization for LogFile: do not fill it with -1, if it's already there
- index.c: removed 'inline' in definition of hdr_find_split() and 

Re: [PATCH] MIPS: ralink: mt7621: add memory detection support

2021-03-27 Thread Ilya Lipnitskiy
On Sat, Mar 27, 2021 at 2:06 PM Thomas Bogendoerfer
 wrote:
>
> On Sat, Mar 27, 2021 at 09:35:43AM -0700, Ilya Lipnitskiy wrote:
> > On Sat, Mar 27, 2021 at 2:46 AM Thomas Bogendoerfer
> >  wrote:
> > >
> > > On Thu, Mar 25, 2021 at 07:45:23PM -0700, Ilya Lipnitskiy wrote:
> > > > On Thu, Mar 25, 2021 at 3:01 AM Thomas Bogendoerfer
> > > >  wrote:
> > > > >
> > > > > On Tue, Mar 16, 2021 at 10:59:02PM -0700, Ilya Lipnitskiy wrote:
> > > > > > From: Chuanhong Guo 
> > > > > >
> > > > > > mt7621 has the following memory map:
> > > > > > 0x0-0x1c00: lower 448m memory
> > > > > > 0x1c00-0x200: peripheral registers
> > > > > > 0x2000-0x240: higher 64m memory
> > > > > >
> > > > > > detect_memory_region in arch/mips/kernel/setup.c only adds the first
> > > > > > memory region and isn't suitable for 512m memory detection because
> > > > > > it may accidentally read the memory area for peripheral registers.
> > > > > >
> > > > > > This commit adds memory detection capability for mt7621:
> > > > > >   1. Add the highmem area when 512m is detected.
> > > > > >   2. Guard memcmp from accessing peripheral registers:
> > > > > >  This only happens when a user decided to change kernel load 
> > > > > > address
> > > > > >  to 256m or higher address. Since this is a quite unusual case, 
> > > > > > we
> > > > > >  just skip 512m testing and return 256m as memory size.
> > > > > >
> > > > > > [...]
> > > > >
> > > > > I get
> > > > >
> > > > > WARNING: modpost: vmlinux.o(.text+0x132c): Section mismatch in 
> > > > > reference from the function prom_soc_init() to the function 
> > > > > .init.text:mt7621_memory_detect()
> > > > > The function prom_soc_init() references
> > > > > the function __init mt7621_memory_detect().
> > > > > This is often because prom_soc_init lacks a __init
> > > > > annotation or the annotation of mt7621_memory_detect is wrong.
> > > > >
> > > > > Can you please fix this ?
> > > > Thanks, I will fix it. Having trouble reproducing the error, but I
> > > > clearly see the issue. Are you building on a MIPS target or
> > > > cross-compiling (I'm cross-compiling and no errors).
> > >
> > > I'm cross compiling, I can provide you the .config, if you want.
> > Yeah, that would help. I spent quite a bit of time trying to reproduce
> > - tried different options with GCC 8 and GCC 10 to no avail. Maybe you
> > are using clang?
>
> no, but an older gcc (gcc version 6.1.1 20160621 (Red Hat Cross 6.1.1-2) 
> (GCC)).
> config is attached.
Thanks, disabling CONFIG_LD_DEAD_CODE_DATA_ELIMINATION reproduced it
even with GCC 10. Fixed in
https://lore.kernel.org/linux-arm-kernel/20210327053840.471155-1-ilya.lipnits...@gmail.com/

- Ilya


Re: [PATCH] mm: add page_owner_stack=off to make stack collection optional

2021-03-27 Thread Sergei Trofimovich
On Sun, 21 Mar 2021 21:25:01 +
Sergei Trofimovich  wrote:

> On some architectures (like ia64) stack walking is slow
> and currently requires memory allocation. This causes stack
> collection for page_owner=on to fall into recursion.
> 
> This patch implements a page_owner_stack=off to allow page stats
> collection.

More user friendly alternative would be to have a GFP_ flag similar
to __GFP_NOLOCKDEP which would allow us to skip the recursion.
I'll prepare alternative patch.

> Signed-off-by: Sergei Trofimovich 
> ---
>  .../admin-guide/kernel-parameters.txt |  6 +
>  mm/Kconfig.debug  |  3 ++-
>  mm/page_owner.c   | 23 +--
>  3 files changed, 24 insertions(+), 8 deletions(-)
> 
> diff --git a/Documentation/admin-guide/kernel-parameters.txt 
> b/Documentation/admin-guide/kernel-parameters.txt
> index 04545725f187..3e710c4ab4df 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -3518,6 +3518,12 @@
>   we can turn it on.
>   on: enable the feature
>  
> + page_owner_stack= [KNL] Boot-time parameter option disabling stack
> + collection of page allocation. Has effect only if
> + "page_owner=on" is set. Useful for cases when stack
> + collection is too slow or not feasible.
> + off: disable the feature
> +
>   page_poison=[KNL] Boot-time parameter changing the state of
>   poisoning on the buddy allocator, available with
>   CONFIG_PAGE_POISONING=y.
> diff --git a/mm/Kconfig.debug b/mm/Kconfig.debug
> index 1e73717802f8..c1ecaf066c93 100644
> --- a/mm/Kconfig.debug
> +++ b/mm/Kconfig.debug
> @@ -57,7 +57,8 @@ config PAGE_OWNER
> help to find bare alloc_page(s) leaks. Even if you include this
> feature on your build, it is disabled in default. You should pass
> "page_owner=on" to boot parameter in order to enable it. Eats
> -   a fair amount of memory if enabled. See tools/vm/page_owner_sort.c
> +   a fair amount of memory if enabled. Call chain tracking can be
> +   disabled with "page_owner_stack=off". See tools/vm/page_owner_sort.c
> for user-space helper.
>  
> If unsure, say N.
> diff --git a/mm/page_owner.c b/mm/page_owner.c
> index d15c7c4994f5..2cc1113fa28d 100644
> --- a/mm/page_owner.c
> +++ b/mm/page_owner.c
> @@ -31,6 +31,7 @@ struct page_owner {
>  };
>  
>  static bool page_owner_enabled = false;
> +static bool page_owner_stack_enabled = true;
>  DEFINE_STATIC_KEY_FALSE(page_owner_inited);
>  
>  static depot_stack_handle_t dummy_handle;
> @@ -41,21 +42,26 @@ static void init_early_allocated_pages(void);
>  
>  static int __init early_page_owner_param(char *buf)
>  {
> - if (!buf)
> - return -EINVAL;
> -
> - if (strcmp(buf, "on") == 0)
> - page_owner_enabled = true;
> -
> - return 0;
> + return kstrtobool(buf, _owner_enabled);
>  }
>  early_param("page_owner", early_page_owner_param);
>  
> +static int __init early_page_owner_stack_param(char *buf)
> +{
> + return kstrtobool(buf, _owner_stack_enabled);
> +}
> +early_param("page_owner_stack", early_page_owner_stack_param);
> +
>  static bool need_page_owner(void)
>  {
>   return page_owner_enabled;
>  }
>  
> +static bool need_page_owner_stack(void)
> +{
> + return page_owner_stack_enabled;
> +}
> +
>  static __always_inline depot_stack_handle_t create_dummy_stack(void)
>  {
>   unsigned long entries[4];
> @@ -122,6 +128,9 @@ static noinline depot_stack_handle_t save_stack(gfp_t 
> flags)
>   depot_stack_handle_t handle;
>   unsigned int nr_entries;
>  
> + if (!need_page_owner_stack())
> + return failure_handle;
> +
>   nr_entries = stack_trace_save(entries, ARRAY_SIZE(entries), 2);
>  
>   /*
> -- 
> 2.31.0
> 


-- 

  Sergei


Re: [PATCH v1 1/1] kernel.h: Drop inclusion in bitmap.h

2021-03-27 Thread Yury Norov
On Fri, Mar 26, 2021 at 07:03:47PM +0200, Andy Shevchenko wrote:
> The bitmap.h header is used in a lot of code around the kernel.
> Besides that it includes kernel.h which sometimes makes a loop.
> 
> Break the loop by introducing align.h, including it in kernel.h
> and bitmap.h followed by replacing kernel.h with limits.h.
> 
> Signed-off-by: Andy Shevchenko 

Can you give an example of such dependency?

Nevertheless,

Acked-by: Yury Norov 

> ---
>  include/linux/align.h  | 15 +++
>  include/linux/bitmap.h |  3 ++-
>  include/linux/kernel.h |  9 +
>  3 files changed, 18 insertions(+), 9 deletions(-)
>  create mode 100644 include/linux/align.h
> 
> diff --git a/include/linux/align.h b/include/linux/align.h
> new file mode 100644
> index ..2b4acec7b95a
> --- /dev/null
> +++ b/include/linux/align.h
> @@ -0,0 +1,15 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _LINUX_ALIGN_H
> +#define _LINUX_ALIGN_H
> +
> +#include 
> +
> +/* @a is a power of 2 value */
> +#define ALIGN(x, a)  __ALIGN_KERNEL((x), (a))
> +#define ALIGN_DOWN(x, a) __ALIGN_KERNEL((x) - ((a) - 1), (a))
> +#define __ALIGN_MASK(x, mask)__ALIGN_KERNEL_MASK((x), (mask))
> +#define PTR_ALIGN(p, a)  ((typeof(p))ALIGN((unsigned long)(p), 
> (a)))
> +#define PTR_ALIGN_DOWN(p, a) ((typeof(p))ALIGN_DOWN((unsigned long)(p), (a)))
> +#define IS_ALIGNED(x, a) (((x) & ((typeof(x))(a) - 1)) == 0)
> +
> +#endif   /* _LINUX_ALIGN_H */
> diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h
> index 70a932470b2d..6cbcd9d9edd2 100644
> --- a/include/linux/bitmap.h
> +++ b/include/linux/bitmap.h
> @@ -4,10 +4,11 @@
>  
>  #ifndef __ASSEMBLY__
>  
> +#include 
>  #include 
>  #include 
> +#include 
>  #include 
> -#include 
>  
>  /*
>   * bitmaps provide bit arrays that consume one or more unsigned
> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> index 5b7ed6dc99ac..09035ac67d4b 100644
> --- a/include/linux/kernel.h
> +++ b/include/linux/kernel.h
> @@ -3,6 +3,7 @@
>  #define _LINUX_KERNEL_H
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -30,14 +31,6 @@
>   */
>  #define REPEAT_BYTE(x)   ((~0ul / 0xff) * (x))
>  
> -/* @a is a power of 2 value */
> -#define ALIGN(x, a)  __ALIGN_KERNEL((x), (a))
> -#define ALIGN_DOWN(x, a) __ALIGN_KERNEL((x) - ((a) - 1), (a))
> -#define __ALIGN_MASK(x, mask)__ALIGN_KERNEL_MASK((x), (mask))
> -#define PTR_ALIGN(p, a)  ((typeof(p))ALIGN((unsigned long)(p), 
> (a)))
> -#define PTR_ALIGN_DOWN(p, a) ((typeof(p))ALIGN_DOWN((unsigned long)(p), (a)))
> -#define IS_ALIGNED(x, a) (((x) & ((typeof(x))(a) - 1)) == 0)
> -
>  /* generic data direction definitions */
>  #define READ 0
>  #define WRITE1
> -- 
> 2.30.2


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

2021-03-27 Thread Stephen Rothwell
Hi Sedat,

On Sat, 27 Mar 2021 12:50:55 +0100 Sedat Dilek  wrote:
>
> I wonder why Stephen's fixup-patch was not carried in recent
> Linux-next releases.

It is part of the tip tree merge commit.  So it is not an explicit
commit on its own, but the needed change is there.

> Wild speculation - no random-config with x86(-64) plus CONFIG_BPF_JIT=y?

I detected it with an X86_64 allmodconfig build (which I do all day).

-- 
Cheers,
Stephen Rothwell


pgpMYBHj2tdCv.pgp
Description: OpenPGP digital signature


Re: [PATCH v4 2/4] riscv: cmpxchg.h: Merge macros

2021-03-27 Thread Arnd Bergmann
On Sat, Mar 27, 2021 at 7:06 PM  wrote:
>
> From: Guo Ren 
>
> To reduce assembly codes, let's merge duplicate codes into one
> (xchg_acquire, xchg_release, cmpxchg_release).
>
> Signed-off-by: Guo Ren 

This is a nice cleanup, but I wonder if you can go even further by using
the definitions from atomic-arch-fallback.h like arm64 and x86 do.

Arnd


[PATCH] sata_mv: add IRQ checks

2021-03-27 Thread Sergey Shtylyov
The function mv_platform_probe() neglects to check the results of the
calls to platform_get_irq() and irq_of_parse_and_map() and blithely
passes them to ata_host_activate() -- while the latter only checks
for IRQ0 (treating it as a polling mode indicattion) and passes the
negative values to devm_request_irq() causing it to fail as it takes
unsigned values for the IRQ #...

Add to mv_platform_probe() the proper IRQ checks to pass the positive IRQ
#s to ata_host_activate(), propagate upstream the negative error codes,
and override the IRQ0 with -EINVAL (as we don't want the polling mode).

Fixes: f351b2d638c3 ("sata_mv: Support SoC controllers")
Signed-off-by: Sergey Shtylyov 

---
 drivers/ata/sata_mv.c |4 
 1 file changed, 4 insertions(+)

Index: linux-block/drivers/ata/sata_mv.c
===
--- linux-block.orig/drivers/ata/sata_mv.c
+++ linux-block/drivers/ata/sata_mv.c
@@ -4097,6 +4097,10 @@ static int mv_platform_probe(struct plat
n_ports = mv_platform_data->n_ports;
irq = platform_get_irq(pdev, 0);
}
+   if (irq < 0)
+   return irq;
+   if (!irq)
+   return -EINVAL;
 
host = ata_host_alloc_pinfo(>dev, ppi, n_ports);
hpriv = devm_kzalloc(>dev, sizeof(*hpriv), GFP_KERNEL);


RE: [PATCH v2] eeprom/optoe: driver to read/write SFP/QSFP/CMIS EEPROMS

2021-03-27 Thread Don Bollinger
> > What I have works.  Your consumers get quirk handling, mine don't need
it.
> > No compromise.
> 
> Hi Don
> 
> All this discussion is now a mute point. GregKH has spoken.

Ack.  I actually checked in with Greg a couple of days ago and got that
answer.  I just thought the discussion was going in an interesting direction
and didn't want to end it yet.  Response below is in the same vein.

> 
> But i'm sure there are some on the side lines, eating popcorn, maybe
> learning from the discussion.

Honestly not sure what they are learning from the discussion.  I think what
I learned is not what you think you taught me.

> 
> Would you think it is O.K. to add a KAPI which works for 3 1/2" SCSI
disks, but
> not 2", because you only make machines with 3 1/2" bays?

No.  Not sure how the analogy works.  QSFP is a larger form factor than SFP,
and the EEPROM layout changed at the same time, but optoe and my community
had no problem accommodating both.  CMIS changed the EEPROM layout again,
but it was easily accommodated.

> 
> This is an extreme, absurd example, but hopefully you get the point. We
> don't design KAPIs with the intention to only work for a subset of
devices. It
> needs to work with as many devices as possible, even if the first
> implementation below the KAPI is limited to just a subset.

Let me run with your example...  Suppose I used those 3 1/2" SCSI disks to
build storage servers.  Let's call them RAID devices.  Innovation follows, I
figure out how to make these devices hot swappable, hot backup, massively
parallel...  Innovation follows and I evolve this into a distributed
architecture with redundant data, encrypted, compressed, distributed across
servers and data centers.  Massively parallel, synchronized, access to the
data anywhere in the world, at bandwidth limited only by the size of your
network pipe.  Let's call it RIDSS (Redundant, Independent, Distributed
Storage Servers).  And I can use 2" disks.  Or non-spinning storage.

My fancy technology thinks the storage is dumb.  I present a
track/sector/length and I get back the bits.  Just for grins, let's say I
can also query the device for a list of bad blocks (sectors, whatever).

Recently, with the addition of 2" devices, YOU figured out that you can
stuff several disks into a small space, and manage them with software and
call it RAID.  You build a nice abstraction for storage, which contains
individual disks, and handles parallelism, redundancy, hot swap.  Very cool,
works well, a genuine innovation.

I've been using Linux for RIDSS for years, I get the memo that my linux
driver to access these SCSI devices should be in the upstream kernel.
Oddly, there are no drivers in the kernel that I can just present
track/sector/length and get back the bits.  So, I offer mine.  The answer is
no, that is a RAID device, you need to access the device through RAID data
structures and APIs.

Sorry, no, that is not a RAID device.  That is a storage device.  You use it
for RAID storage, I use it for RIDSS storage.  We need a layered
architecture with raw data access at the bottom (we both need the same
track/sector/length access).  Beyond that, your RAID stack, while brilliant,
has virtually nothing to do with my RIDSS stack.  They sound superficially
similar, but the technology and architecture are wildly different.  The RAID
stack is unnecessary for my RIDSS architecture, and requires widespread
changes to my software that yield no benefit.

So, no, I don't get your point.  I think there is value in a simple layered
architecture, where access to the module EEPROM is independent of the
consumer of that access.  You can access it for kernel networking, which is
useful, innovative, valuable.  I can access it for TOR switches which do not
use kernel networking but are nonetheless useful, innovative, valuable.
Your decision to reject optoe means the TOR community has to maintain this
simple bit of kernel code outside the mainline tree.  The judges have ruled,
case closed.

> 
> Anyway, i'm gratefull you have looked at the new ethtool netlink KAPI. It
will
> be better for your contributions. And i hope you can make use of it in the

Thanks for the acknowledgement.  

> future. But i think this discussion about optoe in mainline is over.

This discussion is indeed over if you say it is.  I'll be moving on :-(.

> 
>  Andrew

Don



Re: Testers wanted: Atom netbooks with x86_64 disabled by BIOS

2021-03-27 Thread Mateusz Jończyk
W dniu 27.03.2021 o 21:32, Mateusz Jończyk pisze:
> Hello,
>
> There are some netbooks with Intel Atom processors that have 64-bit
> support disabled by BIOS. Theoretically, the processor supports 64-bit
> operation, but BIOS allows only 32-bit code to run.
>
> I wonder whether the 64-bit mode is really disabled in the CPU or only
> hidden in the CPUID flags. If the latter, the computer could be made to
> run a 64-bit kernel.
>
> Similarly, there are some Pentium M processors that support PAE
> (Physical Address Extensions), but do not show this in CPUID. They could
> be made to run distributions that require PAE with the "forcepae" kernel
> command line parameter.
>
> I would like to ask people with such netbooks to try to run a 64-bit kernel
> with this patch applied.
>
> When a patched 64-bit kernel is run in `qemu-system-i386`, the virtual
> machine restarts instantly. Without this patch in such a case a 64-bit
> kernel hangs indefinitely (inside .Lno_longmode in head_64.S).

I have made two mistakes:
- I left commented out code,
- I have commented out lines with '#'. The code compiled though.

Attaching corrected patch, please excuse me.

Greetings,
Mateusz

Signed-off-by: Mateusz Jończyk 

---
 arch/x86/boot/compressed/head_64.S | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/x86/boot/compressed/head_64.S 
b/arch/x86/boot/compressed/head_64.S
index e94874f4bbc1..a9f0415da7c2 100644
--- a/arch/x86/boot/compressed/head_64.S
+++ b/arch/x86/boot/compressed/head_64.S
@@ -111,8 +111,6 @@ SYM_FUNC_START(startup_32)
lealrva(boot_stack_end)(%ebp), %esp
 
callverify_cpu
-   testl   %eax, %eax
-   jnz .Lno_longmode
 
 /*
  * Compute the delta between where we were compiled to run at
-- 
2.25.1



Re: [PATCH] MIPS: ralink: mt7621: add memory detection support

2021-03-27 Thread Thomas Bogendoerfer
On Sat, Mar 27, 2021 at 09:35:43AM -0700, Ilya Lipnitskiy wrote:
> On Sat, Mar 27, 2021 at 2:46 AM Thomas Bogendoerfer
>  wrote:
> >
> > On Thu, Mar 25, 2021 at 07:45:23PM -0700, Ilya Lipnitskiy wrote:
> > > On Thu, Mar 25, 2021 at 3:01 AM Thomas Bogendoerfer
> > >  wrote:
> > > >
> > > > On Tue, Mar 16, 2021 at 10:59:02PM -0700, Ilya Lipnitskiy wrote:
> > > > > From: Chuanhong Guo 
> > > > >
> > > > > mt7621 has the following memory map:
> > > > > 0x0-0x1c00: lower 448m memory
> > > > > 0x1c00-0x200: peripheral registers
> > > > > 0x2000-0x240: higher 64m memory
> > > > >
> > > > > detect_memory_region in arch/mips/kernel/setup.c only adds the first
> > > > > memory region and isn't suitable for 512m memory detection because
> > > > > it may accidentally read the memory area for peripheral registers.
> > > > >
> > > > > This commit adds memory detection capability for mt7621:
> > > > >   1. Add the highmem area when 512m is detected.
> > > > >   2. Guard memcmp from accessing peripheral registers:
> > > > >  This only happens when a user decided to change kernel load 
> > > > > address
> > > > >  to 256m or higher address. Since this is a quite unusual case, we
> > > > >  just skip 512m testing and return 256m as memory size.
> > > > >
> > > > > [...]
> > > >
> > > > I get
> > > >
> > > > WARNING: modpost: vmlinux.o(.text+0x132c): Section mismatch in 
> > > > reference from the function prom_soc_init() to the function 
> > > > .init.text:mt7621_memory_detect()
> > > > The function prom_soc_init() references
> > > > the function __init mt7621_memory_detect().
> > > > This is often because prom_soc_init lacks a __init
> > > > annotation or the annotation of mt7621_memory_detect is wrong.
> > > >
> > > > Can you please fix this ?
> > > Thanks, I will fix it. Having trouble reproducing the error, but I
> > > clearly see the issue. Are you building on a MIPS target or
> > > cross-compiling (I'm cross-compiling and no errors).
> >
> > I'm cross compiling, I can provide you the .config, if you want.
> Yeah, that would help. I spent quite a bit of time trying to reproduce
> - tried different options with GCC 8 and GCC 10 to no avail. Maybe you
> are using clang?

no, but an older gcc (gcc version 6.1.1 20160621 (Red Hat Cross 6.1.1-2) (GCC)).
config is attached.

Thomas.


-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.[ RFC1925, 2.3 ]


ralink-config.gz
Description: application/gzip


Re: [PATCH v3] cpu/hotplug: wait for cpuset_hotplug_work to finish on cpu onlining

2021-03-27 Thread Thomas Gleixner
Alexey,

On Wed, Mar 17 2021 at 00:36, Alexey Klimov wrote:
> When a CPU offlined and onlined via device_offline() and device_online()
> the userspace gets uevent notification. If, after receiving "online" uevent,
> userspace executes sched_setaffinity() on some task trying to move it
> to a recently onlined CPU, then it sometimes fails with -EINVAL. Userspace
> needs to wait around 5..30 ms before sched_setaffinity() will succeed for
> recently onlined CPU after receiving uevent.
>
> Cpusets used in guarantee_online_cpus() are updated using workqueue from
> cpuset_update_active_cpus() which in its turn is called from cpu hotplug 
> callback
> sched_cpu_activate() hence it may not be observable by sched_setaffinity() if
> it is called immediately after uevent.

And because cpusets are using a workqueue just to deal with their
backwards lock order we need to cure the symptom in the CPU hotplug
code, right?

> Out of line uevent can be avoided if we will ensure that cpuset_hotplug_work
> has run to completion using cpuset_wait_for_hotplug() after onlining the
> cpu in cpu_device_up() and in cpuhp_smt_enable().

It can also be avoided by fixing the root cause which is _NOT_ in the
CPU hotplug code at all.

The fundamental assumption of CPU hotplug is that if the state machine
reaches a given state, which might have user space visible effects or
even just kernel visible effects, the overall state of the system has to
be consistent.

cpusets violate this assumption. And they do so since 2013 due to commit
3a5a6d0c2b03("cpuset: don't nest cgroup_mutex inside get_online_cpus()").

If that cannot be fixed in cgroups/cpusets with out rewriting the whole
cpusets/cgroups muck, then this want's to be explained and justified in the
changelog.

Looking at the changelog of 3a5a6d0c2b03 it's entirely clear that this
is non trivial because that changelog clearly states that the lock order
is a design decision and that design decision required that workqueue
workaround

See? Now we suddenly have a proper root cause and not just a description
of the symptom with some hidden hint about workqueues. And we have an
argument why fixing the root cause is close to impossible.

>  int cpu_device_up(struct device *dev)
>  {
> - return cpu_up(dev->id, CPUHP_ONLINE);
> + int err;
> +
> + err = cpu_up(dev->id, CPUHP_ONLINE);
> + /*
> +  * Wait for cpuset updates to cpumasks to finish.  Later on this path
> +  * may generate uevents whose consumers rely on the updates.
> +  */
> + if (!err)
> + cpuset_wait_for_hotplug();

No. Quite some people wasted^Wspent a considerable amount of time to get
the hotplug trainwreck cleaned up and we are not sprinkling random
workarounds all over the place again.

>  int cpuhp_smt_disable(enum cpuhp_smt_control ctrlval)
>  {
> - int cpu, ret = 0;
> + cpumask_var_t mask;
> + int cpu, ret;
>  
> + if (!zalloc_cpumask_var(, GFP_KERNEL))
> + return -ENOMEM;
> +
> + ret = 0;
>   cpu_maps_update_begin();
>   for_each_online_cpu(cpu) {
>   if (topology_is_primary_thread(cpu))
> @@ -2093,31 +2109,42 @@ int cpuhp_smt_disable(enum cpuhp_smt_control ctrlval)
>   ret = cpu_down_maps_locked(cpu, CPUHP_OFFLINE);
>   if (ret)
>   break;
> - /*
> -  * As this needs to hold the cpu maps lock it's impossible
> -  * to call device_offline() because that ends up calling
> -  * cpu_down() which takes cpu maps lock. cpu maps lock
> -  * needs to be held as this might race against in kernel
> -  * abusers of the hotplug machinery (thermal management).
> -  *
> -  * So nothing would update device:offline state. That would
> -  * leave the sysfs entry stale and prevent onlining after
> -  * smt control has been changed to 'off' again. This is
> -  * called under the sysfs hotplug lock, so it is properly
> -  * serialized against the regular offline usage.
> -  */
> - cpuhp_offline_cpu_device(cpu);
> +
> + cpumask_set_cpu(cpu, mask);
>   }
>   if (!ret)
>   cpu_smt_control = ctrlval;
>   cpu_maps_update_done();
> +
> + /*
> +  * When the cpu maps lock was taken above it was impossible
> +  * to call device_offline() because that ends up calling
> +  * cpu_down() which takes cpu maps lock. cpu maps lock
> +  * needed to be held as this might race against in-kernel
> +  * abusers of the hotplug machinery (thermal management).
> +  *
> +  * So nothing would update device:offline state. That would
> +  * leave the sysfs entry stale and prevent onlining after
> +  * smt control has been changed to 'off' again. This is
> +  * called under the sysfs hotplug lock, so it is properly
> +  * serialized against the regular offline usage.
> +  */
> 

Re: [PATCH 0/2] HID: Add support for Surface Aggregator Module HID transport

2021-03-27 Thread Maximilian Luz

On 3/10/21 11:53 PM, Maximilian Luz wrote:

This series adds support for the Surface System Aggregator Module (SSAM)
HID transport subsystem.

The SSAM is an embedded controller, found on 5th- and later generation
Microsoft Surface devices. On some of these devices (specifically
Surface Laptops 1, 2, and 3, as well as Surface Book 3), built-in input
devices are connected via the SSAM. These devices communicate (mostly)
via normal HID reports, so adding support for them is (mostly) just a
matter of implementing an HID transport driver.

SSAM actually has two different HID interfaces: One (legacy) interface
used on Surface Laptops 1 and 2, and a newer interface for the rest. The
newer interface allows for multiple HID devices to be addressed and is
implemented in the first patch. The older interface only allows a single
HID device to be connected and, furthermore, only allows a single output
report, specifically one for the caps lock LED. This is implemented in
the second patch.

See the commit messages of the respective patches for more details.

Regards,
Max

Note: This patch depends on the

 platform/surface: Add Surface Aggregator device registry

series. More specifically patch

 platform/surface: Set up Surface Aggregator device registry

The full series has been merged into the for-next branch of the
platform-drivers-x86 tree [1]. The commit in question can be found at
[2].

[1]: 
https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/log/?h=for-next
[2]: 
https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/commit/?h=for-next=fc622b3d36e6d91330fb21506b9ad1e3206a4dde

Maximilian Luz (2):
   HID: Add support for Surface Aggregator Module HID transport
   HID: surface-hid: Add support for legacy keyboard interface

  MAINTAINERS|   7 +
  drivers/hid/Kconfig|   2 +
  drivers/hid/Makefile   |   2 +
  drivers/hid/surface-hid/Kconfig|  42 +++
  drivers/hid/surface-hid/Makefile   |   7 +
  drivers/hid/surface-hid/surface_hid.c  | 253 +
  drivers/hid/surface-hid/surface_hid_core.c | 272 +++
  drivers/hid/surface-hid/surface_hid_core.h |  77 ++
  drivers/hid/surface-hid/surface_kbd.c  | 300 +
  9 files changed, 962 insertions(+)
  create mode 100644 drivers/hid/surface-hid/Kconfig
  create mode 100644 drivers/hid/surface-hid/Makefile
  create mode 100644 drivers/hid/surface-hid/surface_hid.c
  create mode 100644 drivers/hid/surface-hid/surface_hid_core.c
  create mode 100644 drivers/hid/surface-hid/surface_hid_core.h
  create mode 100644 drivers/hid/surface-hid/surface_kbd.c



Hi, is there any status update on this?

Regards,
Max


Re: [PATCH 0/2] power: supply: Add battery and AC drivers for Surface devices

2021-03-27 Thread Maximilian Luz

On 3/9/21 1:05 AM, Maximilian Luz wrote:

This series provides battery and AC drivers for Microsoft Surface
devices, where this information is provided via an embedded controller
(the Surface System Aggregator Module, SSAM) instead of the usual ACPI
interface.

Specifically, 7th generation Surface devices, i.e. Surface Pro 7,
Surface Book 3, Surface Laptop 3, as well as the Surface Laptop Go use
this new interface.

Note: This series depends on the

 platform/surface: Add Surface Aggregator device registry

series. More specifically patch

 platform/surface: Set up Surface Aggregator device registry

The full series has been merged into the for-next branch of the
platform-drivers-x86 tree [1]. The commit in question can be found at
[2].

[1]: 
https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/log/?h=for-next
[2]: 
https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/commit/?h=for-next=fc622b3d36e6d91330fb21506b9ad1e3206a4dde

Maximilian Luz (2):
   power: supply: Add battery driver for Surface Aggregator Module
   power: supply: Add AC driver for Surface Aggregator Module

  MAINTAINERS|   8 +
  drivers/power/supply/Kconfig   |  32 +
  drivers/power/supply/Makefile  |   2 +
  drivers/power/supply/surface_battery.c | 901 +
  drivers/power/supply/surface_charger.c | 296 
  5 files changed, 1239 insertions(+)
  create mode 100644 drivers/power/supply/surface_battery.c
  create mode 100644 drivers/power/supply/surface_charger.c



Hi, is there any status update on this?

Regards,
Max


Testers wanted: Atom netbooks with x86_64 disabled by BIOS

2021-03-27 Thread Mateusz Jończyk
Hello,

There are some netbooks with Intel Atom processors that have 64-bit
support disabled by BIOS. Theoretically, the processor supports 64-bit
operation, but BIOS allows only 32-bit code to run.

I wonder whether the 64-bit mode is really disabled in the CPU or only
hidden in the CPUID flags. If the latter, the computer could be made to
run a 64-bit kernel.

Similarly, there are some Pentium M processors that support PAE
(Physical Address Extensions), but do not show this in CPUID. They could
be made to run distributions that require PAE with the "forcepae" kernel
command line parameter.

I would like to ask people with such netbooks to try to run a 64-bit kernel
with this patch applied.

When a patched 64-bit kernel is run in `qemu-system-i386`, the virtual
machine restarts instantly. Without this patch in such a case a 64-bit
kernel hangs indefinitely (inside .Lno_longmode in head_64.S).


CC: Thomas Gleixner 
CC: Ingo Molnar 
CC: Borislav Petkov 
CC: 

Signed-off-by: Mateusz Jończyk 

---
 arch/x86/boot/compressed/head_64.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/boot/compressed/head_64.S 
b/arch/x86/boot/compressed/head_64.S
index e94874f4bbc1..23c376d0b221 100644
--- a/arch/x86/boot/compressed/head_64.S
+++ b/arch/x86/boot/compressed/head_64.S
@@ -112,7 +112,7 @@ SYM_FUNC_START(startup_32)
 
callverify_cpu
testl   %eax, %eax
-   jnz .Lno_longmode
+   #jnz.Lno_longmode
 
 /*
  * Compute the delta between where we were compiled to run at
-- 
2.25.1



arch/arm64/kernel/proton-pack.c:558:13: warning: no previous prototype for 'spectre_v4_patch_fw_mitigation_enable'

2021-03-27 Thread kernel test robot
tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   0f4498cef9f5cd18d7c6639a2a902ec1edc5be4e
commit: c28762070ca651fe7a981b8f31d972c9b7d2c386 arm64: Rewrite Spectre-v4 
mitigation code
date:   6 months ago
config: arm64-randconfig-r011-20210328 (attached as .config)
compiler: aarch64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c28762070ca651fe7a981b8f31d972c9b7d2c386
git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout c28762070ca651fe7a981b8f31d972c9b7d2c386
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=arm64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>):

   arch/arm64/kernel/proton-pack.c: In function 
'spectre_v2_enable_fw_mitigation':
   arch/arm64/kernel/proton-pack.c:288:2: error: implicit declaration of 
function 'install_bp_hardening_cb' [-Werror=implicit-function-declaration]
 288 |  install_bp_hardening_cb(cb);
 |  ^~~
   arch/arm64/kernel/proton-pack.c: At top level:
>> arch/arm64/kernel/proton-pack.c:558:13: warning: no previous prototype for 
>> 'spectre_v4_patch_fw_mitigation_enable' [-Wmissing-prototypes]
 558 | void __init spectre_v4_patch_fw_mitigation_enable(struct alt_instr 
*alt,
 | ^
>> arch/arm64/kernel/proton-pack.c:578:13: warning: no previous prototype for 
>> 'spectre_v4_patch_fw_mitigation_conduit' [-Wmissing-prototypes]
 578 | void __init spectre_v4_patch_fw_mitigation_conduit(struct alt_instr 
*alt,
 | ^~
   cc1: some warnings being treated as errors


vim +/spectre_v4_patch_fw_mitigation_enable +558 arch/arm64/kernel/proton-pack.c

   553  
   554  /*
   555   * Patch a branch over the Spectre-v4 mitigation code with a NOP so that
   556   * we fallthrough and check whether firmware needs to be called on this 
CPU.
   557   */
 > 558  void __init spectre_v4_patch_fw_mitigation_enable(struct alt_instr *alt,
   559__le32 *origptr,
   560__le32 *updptr, int 
nr_inst)
   561  {
   562  BUG_ON(nr_inst != 1); /* Branch -> NOP */
   563  
   564  if (spectre_v4_mitigations_off())
   565  return;
   566  
   567  if (cpus_have_final_cap(ARM64_SSBS))
   568  return;
   569  
   570  if (spectre_v4_mitigations_dynamic())
   571  *updptr = cpu_to_le32(aarch64_insn_gen_nop());
   572  }
   573  
   574  /*
   575   * Patch a NOP in the Spectre-v4 mitigation code with an SMC/HVC 
instruction
   576   * to call into firmware to adjust the mitigation state.
   577   */
 > 578  void __init spectre_v4_patch_fw_mitigation_conduit(struct alt_instr 
 > *alt,
   579 __le32 *origptr,
   580 __le32 *updptr, int 
nr_inst)
   581  {
   582  u32 insn;
   583  
   584  BUG_ON(nr_inst != 1); /* NOP -> HVC/SMC */
   585  
   586  switch (arm_smccc_1_1_get_conduit()) {
   587  case SMCCC_CONDUIT_HVC:
   588  insn = aarch64_insn_get_hvc_value();
   589  break;
   590  case SMCCC_CONDUIT_SMC:
   591  insn = aarch64_insn_get_smc_value();
   592  break;
   593  default:
   594  return;
   595  }
   596  
   597  *updptr = cpu_to_le32(insn);
   598  }
   599  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip


[PATCH] spi: dt-bindings: nvidia,tegra210-quad: Use documented compatible "jedec,spi-nor" in example

2021-03-27 Thread Rob Herring
The 'spi-nor' compatible used in the example is not documented. Use the
documented 'jedec,spi-nor' compatible instead.

Cc: Mark Brown 
Cc: Thierry Reding 
Cc: Jonathan Hunter 
Cc: linux-...@vger.kernel.org
Cc: linux-te...@vger.kernel.org
Signed-off-by: Rob Herring 
---
 Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml 
b/Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml
index 35a8045b2c70..53627c6e2ae3 100644
--- a/Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml
+++ b/Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml
@@ -106,7 +106,7 @@ examples:
 dma-names = "rx", "tx";
 
 flash@0 {
-compatible = "spi-nor";
+compatible = "jedec,spi-nor";
 reg = <0>;
 spi-max-frequency = <10400>;
 spi-tx-bus-width = <2>;
-- 
2.27.0



  1   2   3   4   5   >