[PATCH V5 2/4] coresight: adding path for STM device

2016-04-06 Thread Chunyan Zhang 
From: Mathieu Poirier 

>From a core framework point of view an STM device is a source that is
treated the same way as any other tracers.  Unlike tracers though STM
devices are not associated with a CPU.  As such it doesn't make sense
to associate the path from an STM device to its sink with a per-cpu
variable as it is done for tracers.

This patch simply adds another global variable to keep STM paths and the
processing in coresight_enable/disable() is updated to deal with STM
devices properly.

Signed-off-by: Mathieu Poirier 
Signed-off-by: Chunyan Zhang 
---
 drivers/hwtracing/coresight/coresight.c | 106 
 1 file changed, 82 insertions(+), 24 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight.c 
b/drivers/hwtracing/coresight/coresight.c
index 2ea5961..6c80663 100644
--- a/drivers/hwtracing/coresight/coresight.c
+++ b/drivers/hwtracing/coresight/coresight.c
@@ -43,7 +43,15 @@ struct coresight_node {
  * When operating Coresight drivers from the sysFS interface, only a single
  * path can exist from a tracer (associated to a CPU) to a sink.
  */
-static DEFINE_PER_CPU(struct list_head *, sysfs_path);
+static DEFINE_PER_CPU(struct list_head *, tracer_path);
+
+/*
+ * As of this writing only a single STM can be found in CS topologies.  Since
+ * there is no way to know if we'll ever see more and what kind of
+ * configuration they will enact, for the time being only define a single path
+ * for STM.
+ */
+static struct list_head *stm_path;
 
 static int coresight_id_match(struct device *dev, void *data)
 {
@@ -432,18 +440,45 @@ void coresight_release_path(struct list_head *path)
path = NULL;
 }
 
+/** coresight_validate_source - make sure a source has the right credentials
+ *  @csdev:the device structure for a source.
+ *  @function: the function this was called from.
+ *
+ * Assumes the coresight_mutex is held.
+ */
+static int coresight_validate_source(struct coresight_device *csdev,
+const char *function)
+{
+   u32 type, subtype;
+
+   type = csdev->type;
+   subtype = csdev->subtype.source_subtype;
+
+   if (type != CORESIGHT_DEV_TYPE_SOURCE) {
+   dev_err(>dev, "wrong device type in %s\n", function);
+   return -EINVAL;
+   }
+
+   if (subtype != CORESIGHT_DEV_SUBTYPE_SOURCE_PROC &&
+   subtype != CORESIGHT_DEV_SUBTYPE_SOURCE_SOFTWARE) {
+   dev_err(>dev, "wrong device subtype in %s\n", function);
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
 int coresight_enable(struct coresight_device *csdev)
 {
-   int ret = 0;
-   int cpu;
+   int cpu, ret = 0;
struct list_head *path;
 
mutex_lock(_mutex);
-   if (csdev->type != CORESIGHT_DEV_TYPE_SOURCE) {
-   ret = -EINVAL;
-   dev_err(>dev, "wrong device type in %s\n", __func__);
+
+   ret = coresight_validate_source(csdev, __func__);
+   if (ret)
goto out;
-   }
+
if (csdev->enable)
goto out;
 
@@ -461,15 +496,25 @@ int coresight_enable(struct coresight_device *csdev)
if (ret)
goto err_source;
 
-   /*
-* When working from sysFS it is important to keep track
-* of the paths that were created so that they can be
-* undone in 'coresight_disable()'.  Since there can only
-* be a single session per tracer (when working from sysFS)
-* a per-cpu variable will do just fine.
-*/
-   cpu = source_ops(csdev)->cpu_id(csdev);
-   per_cpu(sysfs_path, cpu) = path;
+   switch (csdev->subtype.source_subtype) {
+   case CORESIGHT_DEV_SUBTYPE_SOURCE_PROC:
+   /*
+* When working from sysFS it is important to keep track
+* of the paths that were created so that they can be
+* undone in 'coresight_disable()'.  Since there can only
+* be a single session per tracer (when working from sysFS)
+* a per-cpu variable will do just fine.
+*/
+   cpu = source_ops(csdev)->cpu_id(csdev);
+   per_cpu(tracer_path, cpu) = path;
+   break;
+   case CORESIGHT_DEV_SUBTYPE_SOURCE_SOFTWARE:
+   stm_path = path;
+   break;
+   default:
+   /* We can't be here */
+   break;
+   }
 
 out:
mutex_unlock(_mutex);
@@ -486,23 +531,36 @@ EXPORT_SYMBOL_GPL(coresight_enable);
 
 void coresight_disable(struct coresight_device *csdev)
 {
-   int cpu;
-   struct list_head *path;
+   int cpu, ret;
+   struct list_head *path = NULL;
 
mutex_lock(_mutex);
-   if (csdev->type != CORESIGHT_DEV_TYPE_SOURCE) {
-   dev_err(>dev, "wrong device type in %s\n", __func__);
+
+   ret = coresight_validate_source(csdev,

[PATCH V5 1/4] stm class: Support devices that override software assigned masters

2016-04-06 Thread Chunyan Zhang 
From: Alexander Shishkin 

Some STM devices adjust software assigned master numbers depending on
the trace source and its runtime state and whatnot. This patch adds
a sysfs attribute to inform the trace-side software that master numbers
assigned to software sources will not match those in the STP stream,
so that, for example, master/channel allocation policy can be adjusted
accordingly.

Signed-off-by: Alexander Shishkin 
---
 Documentation/ABI/testing/sysfs-class-stm | 10 ++
 drivers/hwtracing/stm/core.c  | 15 +++
 include/linux/stm.h   |  3 +++
 3 files changed, 28 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-class-stm 
b/Documentation/ABI/testing/sysfs-class-stm
index c9aa4f3..77ed3da 100644
--- a/Documentation/ABI/testing/sysfs-class-stm
+++ b/Documentation/ABI/testing/sysfs-class-stm
@@ -12,3 +12,13 @@ KernelVersion:   4.3
 Contact:   Alexander Shishkin 
 Description:
Shows the number of channels per master on this STM device.
+
+What:  /sys/class/stm//hw_override
+Date:  March 2016
+KernelVersion: 4.7
+Contact:   Alexander Shishkin 
+Description:
+   Reads as 0 if master numbers in the STP stream produced by
+   this stm device will match the master numbers assigned by
+   the software or 1 if the stm hardware overrides software
+   assigned masters.
diff --git a/drivers/hwtracing/stm/core.c b/drivers/hwtracing/stm/core.c
index de80d45..9387f8c 100644
--- a/drivers/hwtracing/stm/core.c
+++ b/drivers/hwtracing/stm/core.c
@@ -67,9 +67,24 @@ static ssize_t channels_show(struct device *dev,
 
 static DEVICE_ATTR_RO(channels);
 
+static ssize_t hw_override_show(struct device *dev,
+   struct device_attribute *attr,
+   char *buf)
+{
+   struct stm_device *stm = to_stm_device(dev);
+   int ret;
+
+   ret = sprintf(buf, "%u\n", stm->data->hw_override);
+
+   return ret;
+}
+
+static DEVICE_ATTR_RO(hw_override);
+
 static struct attribute *stm_attrs[] = {
_attr_masters.attr,
_attr_channels.attr,
+   _attr_hw_override.attr,
NULL,
 };
 
diff --git a/include/linux/stm.h b/include/linux/stm.h
index 1a79ed8..8369d8a 100644
--- a/include/linux/stm.h
+++ b/include/linux/stm.h
@@ -50,6 +50,8 @@ struct stm_device;
  * @sw_end:last STP master available to software
  * @sw_nchannels:  number of STP channels per master
  * @sw_mmiosz: size of one channel's IO space, for mmap, optional
+ * @hw_override:   masters in the STP stream will not match the ones
+ * assigned by software, but are up to the STM hardware
  * @packet:callback that sends an STP packet
  * @mmio_addr: mmap callback, optional
  * @link:  called when a new stm_source gets linked to us, optional
@@ -85,6 +87,7 @@ struct stm_data {
unsigned intsw_end;
unsigned intsw_nchannels;
unsigned intsw_mmiosz;
+   unsigned inthw_override;
ssize_t (*packet)(struct stm_data *, unsigned int,
  unsigned int, unsigned int,
  unsigned int, unsigned int,
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V5 3/4] coresight-stm: Bindings for System Trace Macrocell

2016-04-06 Thread Chunyan Zhang 
From: Mathieu Poirier 

The System Trace Macrocell (STM) is an IP block falling under the
CoreSight umbrella.  It's main purpose it so expose stimulus channels
to any system component for the purpose of information logging.

Bindings for this IP block adds a couple of items to the current
mandatory definition for CoreSight components.

Signed-off-by: Mathieu Poirier 
Acked-by: Rob Herring 
Signed-off-by: Chunyan Zhang 
---
 .../devicetree/bindings/arm/coresight.txt  | 28 ++
 1 file changed, 28 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/coresight.txt 
b/Documentation/devicetree/bindings/arm/coresight.txt
index 62938eb..93147c0c 100644
--- a/Documentation/devicetree/bindings/arm/coresight.txt
+++ b/Documentation/devicetree/bindings/arm/coresight.txt
@@ -19,6 +19,7 @@ its hardware characteristcs.
- "arm,coresight-etm3x", "arm,primecell";
- "arm,coresight-etm4x", "arm,primecell";
- "qcom,coresight-replicator1x", "arm,primecell";
+   - "arm,coresight-stm", "arm,primecell"; [1]
 
* reg: physical base address and length of the register
  set(s) of the component.
@@ -36,6 +37,14 @@ its hardware characteristcs.
  layout using the generic DT graph presentation found in
  "bindings/graph.txt".
 
+* Additional required properties for System Trace Macrocells (STM):
+   * reg: along with the physical base address and length of the register
+ set as described above, another entry is required to describe the
+ mapping of the extended stimulus port area.
+
+   * reg-names: the only acceptable values are "stm-base" and
+ "stm-stimulus-base", each corresponding to the areas defined in "reg".
+
 * Required properties for devices that don't show up on the AMBA bus, such as
   non-configurable replicators:
 
@@ -202,3 +211,22 @@ Example:
};
};
};
+
+4. STM
+   stm@2010 {
+   compatible = "arm,coresight-stm", "arm,primecell";
+   reg = <0 0x2010 0 0x1000>,
+ <0 0x2800 0 0x18>;
+   reg-names = "stm-base", "stm-stimulus-base";
+
+   clocks = <_smc50mhz>;
+   clock-names = "apb_pclk";
+   port {
+   stm_out_port: endpoint {
+   remote-endpoint = <_funnel_in_port2>;
+   };
+   };
+   };
+
+[1]. There is currently two version of STM: STM32 and STM500.  Both
+have the same HW interface and as such don't need an explicit binding name.
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V5 4/4] coresight-stm: adding driver for CoreSight STM component

2016-04-06 Thread Chunyan Zhang 
From: Pratik Patel 

This driver adds support for the STM CoreSight IP block, allowing any
system compoment (HW or SW) to log and aggregate messages via a
single entity.

The CoreSight STM exposes an application defined number of channels
called stimulus port.  Configuration is done using entries in sysfs
and channels made available to userspace via configfs.

Signed-off-by: Pratik Patel 
Signed-off-by: Mathieu Poirier 
Reviewed-by: Michael Williams 
Signed-off-by: Chunyan Zhang 
---
 .../ABI/testing/sysfs-bus-coresight-devices-stm|  53 ++
 Documentation/trace/coresight.txt  |  37 +-
 drivers/hwtracing/coresight/Kconfig|  11 +
 drivers/hwtracing/coresight/Makefile   |   1 +
 drivers/hwtracing/coresight/coresight-stm.c| 918 +
 include/linux/coresight-stm.h  |   6 +
 include/uapi/linux/coresight-stm.h |  21 +
 7 files changed, 1045 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
 create mode 100644 drivers/hwtracing/coresight/coresight-stm.c
 create mode 100644 include/linux/coresight-stm.h
 create mode 100644 include/uapi/linux/coresight-stm.h

diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-stm 
b/Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
new file mode 100644
index 000..1dffabe
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
@@ -0,0 +1,53 @@
+What:  /sys/bus/coresight/devices/.stm/enable_source
+Date:  April 2016
+KernelVersion: 4.7
+Contact:   Mathieu Poirier 
+Description:   (RW) Enable/disable tracing on this specific trace macrocell.
+   Enabling the trace macrocell implies it has been configured
+   properly and a sink has been identified for it.  The path
+   of coresight components linking the source to the sink is
+   configured and managed automatically by the coresight framework.
+
+What:  /sys/bus/coresight/devices/.stm/hwevent_enable
+Date:  April 2016
+KernelVersion: 4.7
+Contact:   Mathieu Poirier 
+Description:   (RW) Provides access to the HW event enable register, used in
+   conjunction with HW event bank select register.
+
+What:  /sys/bus/coresight/devices/.stm/hwevent_select
+Date:  April 2016
+KernelVersion: 4.7
+Contact:   Mathieu Poirier 
+Description:   (RW) Gives access to the HW event block select register
+   (STMHEBSR) in order to configure up to 256 channels.  Used in
+   conjunction with "hwevent_enable" register as described above.
+
+What:  /sys/bus/coresight/devices/.stm/port_enable
+Date:  April 2016
+KernelVersion: 4.7
+Contact:   Mathieu Poirier 
+Description:   (RW) Provides access to the stimulus port enable register
+   (STMSPER).  Used in conjunction with "port_select" described
+   below.
+
+What:  /sys/bus/coresight/devices/.stm/port_select
+Date:  April 2016
+KernelVersion: 4.7
+Contact:   Mathieu Poirier 
+Description:   (RW) Used to determine which bank of stimulus port bit in
+   register STMSPER (see above) apply to.
+
+What:  /sys/bus/coresight/devices/.stm/status
+Date:  April 2016
+KernelVersion: 4.7
+Contact:   Mathieu Poirier 
+Description:   (R) List various control and status registers.  The specific
+   layout and content is driver specific.
+
+What:  /sys/bus/coresight/devices/.stm/traceid
+Date:  April 2016
+KernelVersion: 4.7
+Contact:   Mathieu Poirier 
+Description:   (RW) Holds the trace ID that will appear in the trace stream
+   coming from this trace entity.
diff --git a/Documentation/trace/coresight.txt 
b/Documentation/trace/coresight.txt
index 0a5c329..a33c88c 100644
--- a/Documentation/trace/coresight.txt
+++ b/Documentation/trace/coresight.txt
@@ -190,8 +190,8 @@ expected to be accessed and controlled using those entries.
 Last but not least, "struct module *owner" is expected to be set to reflect
 the information carried in "THIS_MODULE".
 
-How to use
---
+How to use the tracer modules
+-
 
 Before trace collection can start, a coresight sink needs to be identify.
 There is no limit on the amount of sinks (nor sources) that can be enabled at
@@ -297,3 +297,36 @@ InfoTracing enabled
 Instruction 135708310x8026B584  E28DD00Cfalse   ADD
  sp,sp,#0xc
 Instruction 0   0x8026B588  E8BD8000

[PATCH V5 0/4] Introduce CoreSight STM support

2016-04-06 Thread Chunyan Zhang 
This patchset adds support for the CoreSight STM IP block.

Changes from V4:
 - Rebased the whole patch set onto [4] (v4.6-rc1).
 - Made a few minor modifications according to the code changes since v4.5.
 - Replaced the original 1/4 with a new patch the Alex provided.
 - Another new patch 2/4 in this set is for storing path from CS-STM to sink.
 - Addressed comments from V4.
 - Removed coresight_simple_func() from CS-STM driver, used the common 
definition instead.
 - Modified STM tracer-id from an arbitrary value 0x20 to 0x1.
 - Replaced module_amba_driver() with builtin_amba_driver() according to [5].
 - Used driver->suppress_bind_attr to prevent CS-STM being unbound from the 
driver.
 - Updated the kernel version (4.7) and month in 
sysfs-bus-coresight-devices-stm.
 - Replaced 'mshared' with 'hw_override' in CS-STM driver.
 - Initialized sw_start and sw_end with 1.
 - Returned a size of '1' after processing FLAG packets.
 - Removed pre-compile option 'CONFIG_64BIT' for the packet size of 8.
 - Added Michael Williams's Reviewed-by in 4/4.

Changes from V3:
 - Removed ioctl get_options interface from the generic STM code and CoreSight 
STM driver.
 - Removed 'write_max' from the structure 'stm_drvdata', and changed 
'write_64bit' to 'write_bytes'.
 - Revised stm_fundamental_data_size() to return the fundamental data size 
instead of 0/1.
 - Removed stm_remove() from the driver.
 - Revised the return value of ::packet() callback function according to [2].
 - Modified stm_send() to send one STP packet at a time.
 - Added comments to invariant/guaranteed CoreSight STM transaction mode.

Changes from V2:
 - Changed to return -EFAULT if failed on the command STP_GET_OPTIONS.
 - Used Alex's patch [1] instead of the last 2/6.
 - Removed the while loop from stm_send(), since the packet size passed
   to it isn't larger than 4 bytes on 32-bit system and 8 bytes on
   64-bit system.
 - Removed stm_send_64bit(), since the process of packets on 64-bit
   CS-STM should be basically the same with on 32-bit system, except the 
   maximum length of writing STM at a time.
 - Removed the support of writing 64-bit to CoreSight STM buffer at a time
   on 32-bit ARM architecture according to an ARM engineer suggestion.  As
   he said that the STM might receive a 64-bit write, or might receive a
   pair of 32-bit writes to the two addressed words in either order.
   So 64-bit write isn't guaranteed to work on the ARM 32-bit architecture.

Changes from v1:
 - Added a definition of coresight_simple_func() in CS-STM driver to
   avoid the kbuild test robot error for the time being.  This
   modification will be removed when merging the code in which the
   coresight_simple_func() has been moved to the header file.
 - Calculate the channel number according to the channel memory space size.


Thanks,
Chunyan

[1] https://lkml.org/lkml/2016/2/4/652
[2] https://lkml.org/lkml/2016/2/12/397
[3] https://lkml.org/lkml/2015/12/22/348
[4] https://git.linaro.org/kernel/coresight.git/shortlog/refs/heads/next
[5] http://www.spinics.net/lists/kernel/msg2187320.html

Alexander Shishkin (1):
  stm class: Support devices that override software assigned masters

Mathieu Poirier (2):
  coresight: adding path for STM device
  coresight-stm: Bindings for System Trace Macrocell

Pratik Patel (1):
  coresight-stm: adding driver for CoreSight STM component

 .../ABI/testing/sysfs-bus-coresight-devices-stm|  53 ++
 Documentation/ABI/testing/sysfs-class-stm  |  10 +
 .../devicetree/bindings/arm/coresight.txt  |  28 +
 Documentation/trace/coresight.txt  |  37 +-
 drivers/hwtracing/coresight/Kconfig|  11 +
 drivers/hwtracing/coresight/Makefile   |   1 +
 drivers/hwtracing/coresight/coresight-stm.c| 918 +
 drivers/hwtracing/coresight/coresight.c| 106 ++-
 drivers/hwtracing/stm/core.c   |  15 +
 include/linux/coresight-stm.h  |   6 +
 include/linux/stm.h|   3 +
 include/uapi/linux/coresight-stm.h |  21 +
 12 files changed, 1183 insertions(+), 26 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
 create mode 100644 drivers/hwtracing/coresight/coresight-stm.c
 create mode 100644 include/linux/coresight-stm.h
 create mode 100644 include/uapi/linux/coresight-stm.h

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] Documentation: clk: update file names containing referenced structures

2016-04-06 Thread Andi Shyti 
Commit 'b09d6d991' removes include/linux/clk-private.h and
re-arranges the clock related structures contained in it in
different files. The documentation has not been updated
accordingly, thus it wasn't anymore consistent.

Place the structures referenced by Documentation/clk.txt in the
correct files and update their contents to the latest status.

Signed-off-by: Andi Shyti 
---
 Documentation/clk.txt | 44 +++-
 1 file changed, 23 insertions(+), 21 deletions(-)

diff --git a/Documentation/clk.txt b/Documentation/clk.txt
index 5c4bc4d..4c106fd 100644
--- a/Documentation/clk.txt
+++ b/Documentation/clk.txt
@@ -38,17 +38,18 @@ clock interface.
Part 2 - common data structures and api
 
 Below is the common struct clk definition from
-include/linux/clk-private.h, modified for brevity:
-
-   struct clk {
-   const char  *name;
-   const struct clk_ops*ops;
-   struct clk_hw   *hw;
-   char**parent_names;
-   struct clk  **parents;
-   struct clk  *parent;
-   struct hlist_head   children;
-   struct hlist_node   child_node;
+include/linux/clk.c, modified for brevity:
+
+   struct clk_core {
+   const char  *name;
+   const struct clk_ops*ops;
+   struct clk_hw   *hw;
+   struct module   *owner;
+   struct clk_core *parent;
+   const char  **parent_names;
+   struct clk_core **parents;
+   u8  num_parents;
+   u8  new_parent_index;
...
};
 
@@ -58,35 +59,36 @@ struct clk.  That api is documented in include/linux/clk.h.
 
 Platforms and devices utilizing the common struct clk use the struct
 clk_ops pointer in struct clk to perform the hardware-specific parts of
-the operations defined in clk.h:
+the operations defined in clk-provider.h:
 
struct clk_ops {
int (*prepare)(struct clk_hw *hw);
void(*unprepare)(struct clk_hw *hw);
+   int (*is_prepared)(struct clk_hw *hw);
+   void(*unprepare_unused)(struct clk_hw *hw);
int (*enable)(struct clk_hw *hw);
void(*disable)(struct clk_hw *hw);
int (*is_enabled)(struct clk_hw *hw);
+   void(*disable_unused)(struct clk_hw *hw);
unsigned long   (*recalc_rate)(struct clk_hw *hw,
unsigned long parent_rate);
-   long(*round_rate)(struct clk_hw *hw,
-   unsigned long rate,
+   long(*round_rate)(struct clk_hw *hw, unsigned long 
rate,
unsigned long *parent_rate);
int (*determine_rate)(struct clk_hw *hw,
  struct clk_rate_request *req);
int (*set_parent)(struct clk_hw *hw, u8 index);
u8  (*get_parent)(struct clk_hw *hw);
-   int (*set_rate)(struct clk_hw *hw,
-   unsigned long rate,
+   int (*set_rate)(struct clk_hw *hw, unsigned long 
rate,
unsigned long parent_rate);
int (*set_rate_and_parent)(struct clk_hw *hw,
unsigned long rate,
-   unsigned long parent_rate,
-   u8 index);
+   unsigned long parent_rate, u8 
index);
unsigned long   (*recalc_accuracy)(struct clk_hw *hw,
-   unsigned long parent_accuracy);
+  unsigned long 
parent_accuracy);
+   int (*get_phase)(struct clk_hw *hw);
+   int (*set_phase)(struct clk_hw *hw, int degrees);
void(*init)(struct clk_hw *hw);
-   int (*debug_init)(struct clk_hw *hw,
- struct dentry *dentry);
+   int (*debug_init)(struct clk_hw *hw, struct dentry 
*dentry);
};
 
Part 3 - hardware clk implementations
-- 
2.8.0.rc3

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Prefer kASLR over Hibernation

2016-04-06 Thread Ingo Molnar 

* Rafael J. Wysocki  wrote:

> [...]
> 
> One of the weak points is the final jump, because it has to be done to the 
> physical location of the image kernel's entry point even though the virtual 
> addresses of it may differ between the boot and the image kernels.  The seed 
> is 
> not needed for that, only the physical address of the entry point.  The boot 
> kernel doesn't have it today, though, because the virtual address of that is 
> passed in the image header. That should not be too difficult to change, 
> however.

I didn't realize we jumped to the image kernel as well - I (wrongly) assumed we 
kept the bootup kernel. That should indeed make hibernation mostly 
kASLR-invariant.

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Prefer kASLR over Hibernation

2016-04-06 Thread Ingo Molnar 

* Kees Cook  wrote:

> >> I don't think this is a good idea, as it turns off emergency hibernation 
> >> of 
> >> laptops - many desktop distros support it by default.
> >
> > Right, I forgot about this one.
> 
> When I last checked Ubuntu doesn't enable hibernation by default any more: 
> https://help.ubuntu.com/16.04/ubuntu-help/power-hibernate.html
> 
> And it seems like Fedora either doesn't either, or has a lot of people
> for whom it doesn't work:
> https://bugzilla.redhat.com/show_bug.cgi?id=1206936
> https://bugzilla.redhat.com/show_bug.cgi?id=1224151
> http://blog.kriptonium.com/2015/12/fedora-23-hibernate.html

Ok, that's a relatively recent development, I distinctly remember my laptop 
being 
hibernated in such a fashion fairly recently.

That makes it easier to hack around the kASLR incompatibility by making 
hibernation less useful. Personally I think that conceptually user space 
persistency (CRIU et al) is superior to kernel level hibernation - but
user-space save/restore is nowhere near as complete as kernel hibernation,
so it's still somewhat sad that it doesn't work ...

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Prefer kASLR over Hibernation

2016-04-06 Thread Paul Bolle 
On wo, 2016-04-06 at 15:16 -0700, Kees Cook wrote:
> And it seems like Fedora either doesn't either, or has a lot of people
> for whom it doesn't work:
> https://bugzilla.redhat.com/show_bug.cgi?id=1206936
> https://bugzilla.redhat.com/show_bug.cgi?id=1224151
> http://blog.kriptonium.com/2015/12/fedora-23-hibernate.html

Which are all variations on a theme: add "resume=$SWAP" to your kernel
commandline, aren't they?

(No idea why that's needed since Fedora 22, but it cost me quite a bit
of head scratching to find out.)

Once that parameter was set hibernate functioned again on the few
laptops I, well, manage that run Fedora 22.

Thanks,


Paul Bolle 
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Prefer kASLR over Hibernation

2016-04-06 Thread Kees Cook 
On Wed, Apr 6, 2016 at 3:04 PM, Rafael J. Wysocki  wrote:
> On Wed, Apr 6, 2016 at 11:56 PM, Ingo Molnar  wrote:
>>
>> * Rafael J. Wysocki  wrote:
>>
>>> On Wed, Apr 6, 2016 at 9:44 PM, Kees Cook  wrote:
>>> > When building with both CONFIG_HIBERNATION and CONFIG_RANDOMIZE_BASE,
>>> > one or the other must be chosen at boot-time. Until now, hibernation
>>> > was selected when no choice was made on the command line.
>>> >
>>> > To make the security benefits of kASLR more widely available to end
>>> > users (since the use of hibernation is becoming more rare and kASLR,
>>> > already available on x86, will be available on arm64 and MIPS soon),
>>> > this changes the default to preferring kASLR over hibernation. Users
>>> > wanting hibernation can turn off kASLR by adding "nokaslr" to the kernel
>>> > command line.
>>> >
>>> > Suggested-by: Linus Torvalds 
>>> > Signed-off-by: Kees Cook 
>>>
>>> Acked-by: Rafael J. Wysocki 
>>>
>>> Or do you want me to apply it?
>>
>> I don't think this is a good idea, as it turns off emergency hibernation of
>> laptops - many desktop distros support it by default.
>
> Right, I forgot about this one.

When I last checked Ubuntu doesn't enable hibernation by default any more:
https://help.ubuntu.com/16.04/ubuntu-help/power-hibernate.html

And it seems like Fedora either doesn't either, or has a lot of people
for whom it doesn't work:
https://bugzilla.redhat.com/show_bug.cgi?id=1206936
https://bugzilla.redhat.com/show_bug.cgi?id=1224151
http://blog.kriptonium.com/2015/12/fedora-23-hibernate.html

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2] memory_hotplug: introduce config and command line options to set the default onlining policy

2016-04-06 Thread David Rientjes 
On Wed, 6 Apr 2016, Andrew Morton wrote:

> > This patchset continues the work I started with:
> > 
> > commit 31bc3858ea3ebcc3157b3f5f0e624c5962f5a7a6
> > Author: Vitaly Kuznetsov 
> > Date:   Tue Mar 15 14:56:48 2016 -0700
> > 
> > memory-hotplug: add automatic onlining policy for the newly added memory
> > 
> > Initially I was going to stop there and bring the policy setting logic to
> > userspace. I met two issues on this way:
> > 
> > 1) It is possible to have memory hotplugged at boot (e.g. with QEMU). These
> >blocks stay offlined if we turn the onlining policy on by userspace.
> > 
> > 2) My attempt to bring this policy setting to systemd failed, systemd
> >maintainers suggest to change the default in kernel or ... to use 
> > tmpfiles.d
> >to alter the policy (which looks like a hack to me): 
> >https://github.com/systemd/systemd/pull/2938
> 
> That discussion really didn't come to a conclusion and I don't
> understand why you consider Lennert's "recommended way" to be a hack?
> 
> > Here I suggest to add a config option to set the default value for the 
> > policy
> > and a kernel command line parameter to make the override.
> 
> But the patchset looks pretty reasonable regardless of the above.
> 

I don't understand why initscripts simply cannot crawl sysfs memory blocks 
and online them for the same behavior.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Prefer kASLR over Hibernation

2016-04-06 Thread Rafael J. Wysocki 
On Wed, Apr 6, 2016 at 11:56 PM, Ingo Molnar  wrote:
>
> * Rafael J. Wysocki  wrote:
>
>> On Wed, Apr 6, 2016 at 9:44 PM, Kees Cook  wrote:
>> > When building with both CONFIG_HIBERNATION and CONFIG_RANDOMIZE_BASE,
>> > one or the other must be chosen at boot-time. Until now, hibernation
>> > was selected when no choice was made on the command line.
>> >
>> > To make the security benefits of kASLR more widely available to end
>> > users (since the use of hibernation is becoming more rare and kASLR,
>> > already available on x86, will be available on arm64 and MIPS soon),
>> > this changes the default to preferring kASLR over hibernation. Users
>> > wanting hibernation can turn off kASLR by adding "nokaslr" to the kernel
>> > command line.
>> >
>> > Suggested-by: Linus Torvalds 
>> > Signed-off-by: Kees Cook 
>>
>> Acked-by: Rafael J. Wysocki 
>>
>> Or do you want me to apply it?
>
> I don't think this is a good idea, as it turns off emergency hibernation of
> laptops - many desktop distros support it by default.

Right, I forgot about this one.

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Prefer kASLR over Hibernation

2016-04-06 Thread Ingo Molnar 

* Rafael J. Wysocki  wrote:

> On Wed, Apr 6, 2016 at 9:44 PM, Kees Cook  wrote:
> > When building with both CONFIG_HIBERNATION and CONFIG_RANDOMIZE_BASE,
> > one or the other must be chosen at boot-time. Until now, hibernation
> > was selected when no choice was made on the command line.
> >
> > To make the security benefits of kASLR more widely available to end
> > users (since the use of hibernation is becoming more rare and kASLR,
> > already available on x86, will be available on arm64 and MIPS soon),
> > this changes the default to preferring kASLR over hibernation. Users
> > wanting hibernation can turn off kASLR by adding "nokaslr" to the kernel
> > command line.
> >
> > Suggested-by: Linus Torvalds 
> > Signed-off-by: Kees Cook 
> 
> Acked-by: Rafael J. Wysocki 
> 
> Or do you want me to apply it?

I don't think this is a good idea, as it turns off emergency hibernation of 
laptops - many desktop distros support it by default.

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Prefer kASLR over Hibernation

2016-04-06 Thread Ingo Molnar 

* Ingo Molnar  wrote:

> 
> * Kees Cook  wrote:
> 
> > On Wed, Apr 6, 2016 at 1:56 PM, Linus Torvalds
> >  wrote:
> > > On Wed, Apr 6, 2016 at 1:17 PM, Pavel Machek  wrote:
> > >>
> > >> Why is kASLR incompatible with hibernation? We can hibernate have
> > >> 4.3 kernel resume hibernation image of 4.2 kernel (on x86-64, and I
> > >> have patches for x86). Resuming kernel with different randomization
> > >> does not look that much different...
> > >
> > > Oh, I'd absolutely prefer to just allow kaslr together with
> > > hibernation if it actually works.
> > >
> > > Could the people who piped up to say that they actually use
> > > hibernation just try passing in the "kaslr" command line option on
> > > their machine, and see if it works for them? We could just remove the
> > > "no kaslr with hibername" code - or at least limit it to 32-bit for
> > > now..
> > >
> > > Because that would be lovely.
> > 
> > This is where our original investigation of having them coexist ended:
> > https://lkml.org/lkml/2014/6/15/180
> > 
> > To quote Rafael Wysocki:
> > > We're jumping from the boot kernel into the image kernel.  The virtual 
> > > address
> > > comes from the image kernel, but the boot kernel has to use it.  The only 
> > > way
> > > we can ensure that we'll jump to the right place is to pass the physical 
> > > address
> > > in the header (otherwise we de facto assume that the virtual address of 
> > > the
> > > target page frame will be the same in both the boot and the image 
> > > kernels).
> > >
> > > The missing piece is that the code in swsusp_arch_resume() sets up 
> > > temporary
> > > page tables to ensure that they won't be overwritten while copying the 
> > > last
> > > remaining image kernel pages to the right page frames (those page tables
> > > have to be stored in page frames that are free from the kernel image 
> > > perspective).
> > >
> > > But if the kernel address space is randomized, set_up_temporary_mappings()
> > > really should duplicate the existing layout instead of creating a new one 
> > > from
> > > scratch.  Otherwise, virtual addresses before set_up_temporary_mappings() 
> > > may
> > > be different from the ones after it.
> 
> So as I suggested it in the previous mail, the right solution would be to 
> pass in 
> the randomization seed via a new kasl_seed=xyz boot option, and thus have the 
> same 
> addresses as prior hibernation.
> 
> That should make hibernation work as-is, with very little effort.
> 
> Two details I can think of:
> 
> 1) the new option has to be hidden from /proc/cmdline, due to:
> 
>   triton:~/tip> ll /proc/cmdline
>   -r--r--r-- 1 root root 0 Apr  6 23:45 /proc/cmdline
> 
> 2)
> 
> another detail is that the new boot option has to be checked in 
> choose_kernel_location(), to make sure it's done at the right point during 
> bootup. 
> That's a good place to remove it from the boot options string as well.

... and I missed the biggest complication: to solve the chicken and egg problem 
with software_resume() running very late during bootup, software_resume() 
should 
probably kexec() the original kernel image, this time with the kaslr seed set 
in 
the boot parameters.

So it's two bootups...

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Prefer kASLR over Hibernation

2016-04-06 Thread Rafael J. Wysocki 
On Wed, Apr 6, 2016 at 9:44 PM, Kees Cook  wrote:
> When building with both CONFIG_HIBERNATION and CONFIG_RANDOMIZE_BASE,
> one or the other must be chosen at boot-time. Until now, hibernation
> was selected when no choice was made on the command line.
>
> To make the security benefits of kASLR more widely available to end
> users (since the use of hibernation is becoming more rare and kASLR,
> already available on x86, will be available on arm64 and MIPS soon),
> this changes the default to preferring kASLR over hibernation. Users
> wanting hibernation can turn off kASLR by adding "nokaslr" to the kernel
> command line.
>
> Suggested-by: Linus Torvalds 
> Signed-off-by: Kees Cook 

Acked-by: Rafael J. Wysocki 

Or do you want me to apply it?
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Prefer kASLR over Hibernation

2016-04-06 Thread Ingo Molnar 

* Kees Cook  wrote:

> On Wed, Apr 6, 2016 at 1:56 PM, Linus Torvalds
>  wrote:
> > On Wed, Apr 6, 2016 at 1:17 PM, Pavel Machek  wrote:
> >>
> >> Why is kASLR incompatible with hibernation? We can hibernate have
> >> 4.3 kernel resume hibernation image of 4.2 kernel (on x86-64, and I
> >> have patches for x86). Resuming kernel with different randomization
> >> does not look that much different...
> >
> > Oh, I'd absolutely prefer to just allow kaslr together with
> > hibernation if it actually works.
> >
> > Could the people who piped up to say that they actually use
> > hibernation just try passing in the "kaslr" command line option on
> > their machine, and see if it works for them? We could just remove the
> > "no kaslr with hibername" code - or at least limit it to 32-bit for
> > now..
> >
> > Because that would be lovely.
> 
> This is where our original investigation of having them coexist ended:
> https://lkml.org/lkml/2014/6/15/180
> 
> To quote Rafael Wysocki:
> > We're jumping from the boot kernel into the image kernel.  The virtual 
> > address
> > comes from the image kernel, but the boot kernel has to use it.  The only 
> > way
> > we can ensure that we'll jump to the right place is to pass the physical 
> > address
> > in the header (otherwise we de facto assume that the virtual address of the
> > target page frame will be the same in both the boot and the image kernels).
> >
> > The missing piece is that the code in swsusp_arch_resume() sets up temporary
> > page tables to ensure that they won't be overwritten while copying the last
> > remaining image kernel pages to the right page frames (those page tables
> > have to be stored in page frames that are free from the kernel image 
> > perspective).
> >
> > But if the kernel address space is randomized, set_up_temporary_mappings()
> > really should duplicate the existing layout instead of creating a new one 
> > from
> > scratch.  Otherwise, virtual addresses before set_up_temporary_mappings() 
> > may
> > be different from the ones after it.

So as I suggested it in the previous mail, the right solution would be to pass 
in 
the randomization seed via a new kasl_seed=xyz boot option, and thus have the 
same 
addresses as prior hibernation.

That should make hibernation work as-is, with very little effort.

Two details I can think of:

1) the new option has to be hidden from /proc/cmdline, due to:

  triton:~/tip> ll /proc/cmdline
  -r--r--r-- 1 root root 0 Apr  6 23:45 /proc/cmdline

2)

another detail is that the new boot option has to be checked in 
choose_kernel_location(), to make sure it's done at the right point during 
bootup. 
That's a good place to remove it from the boot options string as well.

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/7] cpufreq: remove redundant CPUFREQ_INCOMPATIBLE notifier event

2016-04-06 Thread Rafael J. Wysocki 
On Wed, Apr 6, 2016 at 11:29 PM, Saravana Kannan  wrote:
> On 04/06/2016 02:21 PM, Rafael J. Wysocki wrote:
>>
>> On Wed, Apr 6, 2016 at 10:30 PM, Saravana Kannan 
>> wrote:
>>>
>>> On 09/09/2015 05:53 PM, Rafael J. Wysocki wrote:


[cut]

>>
>> Well, nobody was using that event.
>>
>
> True, but that's more of a bug in drivers/thermal/cpu-cooling.c and
> drivers/acpi/processor_thermal.c. We should revert this patch and fix those
> drivers. Does that seem acceptable to you?

I'd rather see a patch series adding the event back along with some
users.  One user at least.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/7] cpufreq: remove redundant CPUFREQ_INCOMPATIBLE notifier event

2016-04-06 Thread Saravana Kannan 

On 04/06/2016 02:21 PM, Rafael J. Wysocki wrote:

On Wed, Apr 6, 2016 at 10:30 PM, Saravana Kannan  wrote:

On 09/09/2015 05:53 PM, Rafael J. Wysocki wrote:


Hi,

On Thu, Sep 10, 2015 at 2:39 AM, Viresh Kumar 
wrote:


On 10-09-15, 01:26, Rafael J. Wysocki wrote:


On Monday, August 03, 2015 08:36:14 AM Viresh Kumar wrote:


What's being done from CPUFREQ_INCOMPATIBLE, can also be done with
CPUFREQ_ADJUST. There is nothing special with CPUFREQ_INCOMPATIBLE
notifier.



The above part of the changelog is a disaster to me. :-(

It not only doesn't explain what really goes on, but it's actively
confusing.

What really happens is that the core sends CPUFREQ_INCOMPATIBLE
notifications
unconditionally right after sending the CPUFREQ_ADJUST ones, so the
former is
just redundant and it's more efficient to merge the two into one.



Undoubtedly this looks far better :)

But, isn't this series already applied some time back ?



Right, never mind.  For some reason that patch was left in the "New"
state.

The code is OK.




I guess I didn't notice this change when it was sent out.

The comment that was deleted in this patch clearly states why the
INCOMPATIBLE notifier is needed. Some client might want to boost the CPU min
freq for performance or other reasons, but thermal might want to limit it.
So, by having thermal register for INCOMPATIBLE notifiers to enforce the
limits, we provide a way to guarantee it gets the final say.

The real fix should have been to change drivers/thermal/cpu_cooling.c to use
CPUFREQ_INCOMPATIBLE instead of CPUFREQ_ADJUST.

Is there something I'm missing? If not, can we please revert this patch?


Well, nobody was using that event.



True, but that's more of a bug in drivers/thermal/cpu-cooling.c and 
drivers/acpi/processor_thermal.c. We should revert this patch and fix 
those drivers. Does that seem acceptable to you?


-Saravana


--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Prefer kASLR over Hibernation

2016-04-06 Thread Kees Cook 
On Wed, Apr 6, 2016 at 1:56 PM, Linus Torvalds
 wrote:
> On Wed, Apr 6, 2016 at 1:17 PM, Pavel Machek  wrote:
>>
>> Why is kASLR incompatible with hibernation? We can hibernate have
>> 4.3 kernel resume hibernation image of 4.2 kernel (on x86-64, and I
>> have patches for x86). Resuming kernel with different randomization
>> does not look that much different...
>
> Oh, I'd absolutely prefer to just allow kaslr together with
> hibernation if it actually works.
>
> Could the people who piped up to say that they actually use
> hibernation just try passing in the "kaslr" command line option on
> their machine, and see if it works for them? We could just remove the
> "no kaslr with hibername" code - or at least limit it to 32-bit for
> now..
>
> Because that would be lovely.

This is where our original investigation of having them coexist ended:
https://lkml.org/lkml/2014/6/15/180

To quote Rafael Wysocki:
> We're jumping from the boot kernel into the image kernel.  The virtual address
> comes from the image kernel, but the boot kernel has to use it.  The only way
> we can ensure that we'll jump to the right place is to pass the physical 
> address
> in the header (otherwise we de facto assume that the virtual address of the
> target page frame will be the same in both the boot and the image kernels).
>
> The missing piece is that the code in swsusp_arch_resume() sets up temporary
> page tables to ensure that they won't be overwritten while copying the last
> remaining image kernel pages to the right page frames (those page tables
> have to be stored in page frames that are free from the kernel image 
> perspective).
>
> But if the kernel address space is randomized, set_up_temporary_mappings()
> really should duplicate the existing layout instead of creating a new one from
> scratch.  Otherwise, virtual addresses before set_up_temporary_mappings() may
> be different from the ones after it.

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Prefer kASLR over Hibernation

2016-04-06 Thread Linus Torvalds 
On Wed, Apr 6, 2016 at 1:17 PM, Pavel Machek  wrote:
>
> Why is kASLR incompatible with hibernation? We can hibernate have
> 4.3 kernel resume hibernation image of 4.2 kernel (on x86-64, and I
> have patches for x86). Resuming kernel with different randomization
> does not look that much different...

Oh, I'd absolutely prefer to just allow kaslr together with
hibernation if it actually works.

Could the people who piped up to say that they actually use
hibernation just try passing in the "kaslr" command line option on
their machine, and see if it works for them? We could just remove the
"no kaslr with hibername" code - or at least limit it to 32-bit for
now..

Because that would be lovely.

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Prefer kASLR over Hibernation

2016-04-06 Thread Pavel Machek 
Hi!

> When building with both CONFIG_HIBERNATION and CONFIG_RANDOMIZE_BASE,
> one or the other must be chosen at boot-time. Until now, hibernation
> was selected when no choice was made on the command line.
> 
> To make the security benefits of kASLR more widely available to end
> users (since the use of hibernation is becoming more rare and kASLR,
> already available on x86, will be available on arm64 and MIPS soon),
> this changes the default to preferring kASLR over hibernation. Users
> wanting hibernation can turn off kASLR by adding "nokaslr" to the kernel
> command line.

I must say I don't exactly like this patch.

Why is kASLR incompatible with hibernation? We can hibernate have 
4.3 kernel resume hibernation image of 4.2 kernel (on x86-64, and I
have patches for x86). Resuming kernel with different randomization
does not look that much different...

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2] memory_hotplug: introduce config and command line options to set the default onlining policy

2016-04-06 Thread Andrew Morton 
On Wed,  6 Apr 2016 15:45:10 +0200 Vitaly Kuznetsov  wrote:

> This patchset continues the work I started with:
> 
> commit 31bc3858ea3ebcc3157b3f5f0e624c5962f5a7a6
> Author: Vitaly Kuznetsov 
> Date:   Tue Mar 15 14:56:48 2016 -0700
> 
> memory-hotplug: add automatic onlining policy for the newly added memory
> 
> Initially I was going to stop there and bring the policy setting logic to
> userspace. I met two issues on this way:
> 
> 1) It is possible to have memory hotplugged at boot (e.g. with QEMU). These
>blocks stay offlined if we turn the onlining policy on by userspace.
> 
> 2) My attempt to bring this policy setting to systemd failed, systemd
>maintainers suggest to change the default in kernel or ... to use 
> tmpfiles.d
>to alter the policy (which looks like a hack to me): 
>https://github.com/systemd/systemd/pull/2938

That discussion really didn't come to a conclusion and I don't
understand why you consider Lennert's "recommended way" to be a hack?

> Here I suggest to add a config option to set the default value for the policy
> and a kernel command line parameter to make the override.

But the patchset looks pretty reasonable regardless of the above.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] iio: core: Add devm_ APIs for iio_channel_{get,release}

2016-04-06 Thread Laxman Dewangan 

Hi Daniel,


On Wednesday 06 April 2016 07:19 PM, Daniel Baluta wrote:

On Wed, Apr 6, 2016 at 1:31 PM, Laxman Dewangan  wrote:

Some of kernel driver uses the IIO framework to get the sensor
value via ADC or IIO HW driver. The client driver get iio channel
by iio_channel_get() and release it by calling iio_channel_release().

Add resource managed version (devm_*) of these APIs so that if client
calls the devm_iio_channel_get() then it need not to release it explicitly,
it can be done by managed device framework when driver get un-binded.

This reduces the code in error path and also need of .remove callback in
some cases.


Please provide at least one example of code that uses this API.


Most of client for this APIs are in other subsystem.
When I was working on the patch
[PATCH 2/2] thermal: generic-adc: Add ADC based thermal sensor driver

if I have devm_iio_channel_get() then I can get .remove callback at all.

I did not use this new APIs in my patch because they are in different 
subsystem.




--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC v5 7/7] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported

2016-04-06 Thread Alex Williamson 
On Tue,  5 Apr 2016 21:46:44 +0800
Yongji Xie  wrote:

> This patch enables mmapping MSI-X tables if
> hardware supports interrupt remapping which
> can ensure that a given pci device can only
> shoot the MSIs assigned for it.
> 
> Signed-off-by: Yongji Xie 
> ---
>  drivers/vfio/pci/vfio_pci.c |9 +++--
>  drivers/vfio/pci/vfio_pci_private.h |1 +
>  drivers/vfio/pci/vfio_pci_rdwr.c|2 +-
>  3 files changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
> index c60d790..ef02896 100644
> --- a/drivers/vfio/pci/vfio_pci.c
> +++ b/drivers/vfio/pci/vfio_pci.c
> @@ -201,6 +201,10 @@ static int vfio_pci_enable(struct vfio_pci_device *vdev)
>   } else
>   vdev->msix_bar = 0xFF;
>  
> + if (iommu_capable(pdev->dev.bus, IOMMU_CAP_INTR_REMAP) ||

This doesn't address the issue I raised earlier where ARM SMMU sets
this capability, but doesn't really provide per vector isolation.  ARM
either needs to be fixed or we need to consider the whole capability
tainted for this application and standardize around the bus flags.
It's not very desirable to have two different ways to test this anyway.

> + pdev->bus->bus_flags | PCI_BUS_FLAGS_MSI_REMAP)

Perhaps some sort of wrapper for testing these flags would help avoid
this kind of coding error (| vs &)

> + vdev->msi_remap = true;
> +
>   if (!vfio_vga_disabled() && vfio_pci_is_vga(pdev))
>   vdev->has_vga = true;
>  
> @@ -635,7 +639,8 @@ static long vfio_pci_ioctl(void *device_data,
>VFIO_REGION_INFO_FLAG_WRITE;
>   if (vdev->bar_mmap_supported[info.index]) {
>   info.flags |= VFIO_REGION_INFO_FLAG_MMAP;
> - if (info.index == vdev->msix_bar) {
> + if (info.index == vdev->msix_bar &&
> + !vdev->msi_remap) {
>   ret = msix_sparse_mmap_cap(vdev, );
>   if (ret)
>   return ret;
> @@ -1067,7 +1072,7 @@ static int vfio_pci_mmap(void *device_data, struct 
> vm_area_struct *vma)
>   if (req_start + req_len > phys_len)
>   return -EINVAL;
>  
> - if (index == vdev->msix_bar) {
> + if (index == vdev->msix_bar && !vdev->msi_remap) {
>   /*
>* Disallow mmaps overlapping the MSI-X table; users don't
>* get to touch this directly.  We could find somewhere
> diff --git a/drivers/vfio/pci/vfio_pci_private.h 
> b/drivers/vfio/pci/vfio_pci_private.h
> index 0ea4c62..4f20963 100644
> --- a/drivers/vfio/pci/vfio_pci_private.h
> +++ b/drivers/vfio/pci/vfio_pci_private.h
> @@ -78,6 +78,7 @@ struct vfio_pci_device {
>   int irq_type;
>   int num_regions;
>   struct vfio_pci_region  *region;
> + boolmsi_remap;
>   u8  msi_qmax;
>   u8  msix_bar;
>   u16 msix_size;
> diff --git a/drivers/vfio/pci/vfio_pci_rdwr.c 
> b/drivers/vfio/pci/vfio_pci_rdwr.c
> index 5ffd1d9..606ee3c 100644
> --- a/drivers/vfio/pci/vfio_pci_rdwr.c
> +++ b/drivers/vfio/pci/vfio_pci_rdwr.c
> @@ -164,7 +164,7 @@ ssize_t vfio_pci_bar_rw(struct vfio_pci_device *vdev, 
> char __user *buf,
>   } else
>   io = vdev->barmap[bar];
>  
> - if (bar == vdev->msix_bar) {
> + if (bar == vdev->msix_bar && !vdev->msi_remap) {
>   x_start = vdev->msix_offset;
>   x_end = vdev->msix_offset + vdev->msix_size;
>   }

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] memory_hotplug: introduce CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE

2016-04-06 Thread Vitaly Kuznetsov 
Introduce config option to set the default value for memory hotplug
onlining policy (/sys/devices/system/memory/auto_online_blocks). The
reason one would want to turn this option on are to have early onlining
for hotpluggable memory available at boot and to not require any userspace
actions to make memory hotplug work.

Signed-off-by: Vitaly Kuznetsov 
---
 Documentation/memory-hotplug.txt |  9 +
 mm/Kconfig   | 16 
 mm/memory_hotplug.c  |  4 
 3 files changed, 25 insertions(+), 4 deletions(-)

diff --git a/Documentation/memory-hotplug.txt b/Documentation/memory-hotplug.txt
index 443f4b4..0d7cb95 100644
--- a/Documentation/memory-hotplug.txt
+++ b/Documentation/memory-hotplug.txt
@@ -261,10 +261,11 @@ it according to the policy which can be read from 
"auto_online_blocks" file:
 
 % cat /sys/devices/system/memory/auto_online_blocks
 
-The default is "offline" which means the newly added memory is not in a
-ready-to-use state and you have to "online" the newly added memory blocks
-manually. Automatic onlining can be requested by writing "online" to
-"auto_online_blocks" file:
+The default depends on the CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE kernel config
+option. If it is disabled the default is "offline" which means the newly added
+memory is not in a ready-to-use state and you have to "online" the newly added
+memory blocks manually. Automatic onlining can be requested by writing "online"
+to "auto_online_blocks" file:
 
 % echo online > /sys/devices/system/memory/auto_online_blocks
 
diff --git a/mm/Kconfig b/mm/Kconfig
index 989f8f3..4c7dd6e 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -192,6 +192,22 @@ config MEMORY_HOTPLUG_SPARSE
def_bool y
depends on SPARSEMEM && MEMORY_HOTPLUG
 
+config MEMORY_HOTPLUG_DEFAULT_ONLINE
+bool "Online the newly added memory blocks by default"
+default n
+depends on MEMORY_HOTPLUG
+help
+ This option changes the default policy setting for memory hotplug
+ onlining policy (/sys/devices/system/memory/auto_online_blocks) which
+ determines what happens to the newly added memory regions. Policy
+ setting can always be changed in runtime.
+ See Documentation/memory-hotplug.txt for more information.
+
+ Say Y here if you want all hot-plugged memory blocks to appear in
+ 'online' state by default.
+ Say N here if you want the default policy to keep all hot-plugged
+ memory blocks in 'offline' state.
+
 config MEMORY_HOTREMOVE
bool "Allow for memory hot remove"
select MEMORY_ISOLATION
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index aa34431..072e0a1 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -78,7 +78,11 @@ static struct {
 #define memhp_lock_acquire()  lock_map_acquire(_hotplug.dep_map)
 #define memhp_lock_release()  lock_map_release(_hotplug.dep_map)
 
+#ifndef CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE
 bool memhp_auto_online;
+#else
+bool memhp_auto_online = true;
+#endif
 EXPORT_SYMBOL_GPL(memhp_auto_online);
 
 void get_online_mems(void)
-- 
2.5.5

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/2] memory_hotplug: introduce config and command line options to set the default onlining policy

2016-04-06 Thread Vitaly Kuznetsov 
This patchset continues the work I started with:

commit 31bc3858ea3ebcc3157b3f5f0e624c5962f5a7a6
Author: Vitaly Kuznetsov 
Date:   Tue Mar 15 14:56:48 2016 -0700

memory-hotplug: add automatic onlining policy for the newly added memory

Initially I was going to stop there and bring the policy setting logic to
userspace. I met two issues on this way:

1) It is possible to have memory hotplugged at boot (e.g. with QEMU). These
   blocks stay offlined if we turn the onlining policy on by userspace.

2) My attempt to bring this policy setting to systemd failed, systemd
   maintainers suggest to change the default in kernel or ... to use tmpfiles.d
   to alter the policy (which looks like a hack to me): 
   https://github.com/systemd/systemd/pull/2938

Here I suggest to add a config option to set the default value for the policy
and a kernel command line parameter to make the override.

Vitaly Kuznetsov (2):
  memory_hotplug: introduce CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE
  memory_hotplug: introduce memhp_default_state= command line parameter

 Documentation/kernel-parameters.txt |  8 
 Documentation/memory-hotplug.txt|  9 +
 mm/Kconfig  | 16 
 mm/memory_hotplug.c | 15 +++
 4 files changed, 44 insertions(+), 4 deletions(-)

-- 
2.5.5

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC6 PATCH v6 00/21] ILP32 for ARM64

2016-04-06 Thread Yury Norov 
Hi Geert,

On Wed, Apr 06, 2016 at 08:51:50AM +0200, Geert Uytterhoeven wrote:
> Hi Yuri,
> 
> On Wed, Apr 6, 2016 at 12:08 AM, Yury Norov  wrote:
> > This version is rebased on kernel v4.6-rc2, and has fixes in signal 
> > subsystem.
> > It works with updated glibc [1] (though very draft), and tested with LTP.
> >
> > It was tested on QEMU and ThunderX machines. No major difference found.
> > This is RFC because ILP32 is not tested in big-endian mode.
> >
> >  v3: https://lkml.org/lkml/2014/9/3/704
> >  v4: https://lkml.org/lkml/2015/4/13/691
> >  v5: https://lkml.org/lkml/2015/9/29/911
> >
> >  v6:
> >  - time_t, __kenel_off_t and other types turned to be 32-bit
> >for compatibility reasons (after v5 discussion);
> 
> Reading this sparked my interest, so I went to the links above...

Great! I'll add you to CC than.

> 
> What makes you think these "applications that can’t readily be migrated to 
> LP64
> because they were written assuming an ILP32 data model, and that will never
> become suitable for a LP64 data model and will remain locked into ILP32
> operating environments" are more likely to be fixed for y2038 later, than for
> LP64 now?
> 

It was written by Philipp, not me:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-April/337350.html

I'm not the author of this, and I don't think so. Maybe just because I
didn't see all that legacy nightmare, as Philipp does...

Chris Tyler shares relatively common point of view in his video from
Linaro Connect:
https://www.youtube.com/watch?v=QsVLsw_LrJ0

Briefly, we need it (mostly) for compatibility and (then) for performance.
Maybe Prasun can share more details and examples.

> We're already closer to the (future) y2038 than to the (past) introduction of
> LP64...
> 

This is not about Y2038 at all. In fact, current version doesn't fix
Y2038 problem, as we decided finally.

After v4 and v5, it was spread discussion about what ilp32 should do,
and what not. Finally we decided to be not like aarch32, and not like
lp64, and don't fix any issues specifically, but be standard compat
format, as much as possible. So, any improvements and fixes applied
to generic compat will be applied to ilp32 with minimal efforts.

> These unfixable legacy applications have been spreading through x32 to
> the shiny new arm64 server architecture (does ppc64el also have an ILP32 mode,
> or is it planned)?

I don't think this is the question you really don't know the answer.
Almost everywhere shiny arm64 comes with old and ugly aarch32 IP core.
If no, like ThunderX, people really worry about that. And for me,
configurable option in kernel sources is better tradeoff than billions
transistors in every chip on market. So Cavium here is more
future-oriented than many others...

The other example is ACPI. We have nice and cute device tree, don't we?
Does it make sense to vendors?

> Lots of resources are spent on maintaining the status quo,
> instead of on fixing the real problems.
> 

I think, compatibility is one of real problems. Aarch32 is hardware
solution, and ilp32 is software one.

Yury.

> Gr{oetje,eeting}s,
> 
> Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/3] iio: core: Add devm_ APIs for iio_channel_{get,release}_all

2016-04-06 Thread Laxman Dewangan 
Some of kernel driver uses the IIO framework to get the sensor
value via ADC or IIO HW driver. The client driver get iio channel
by iio_channel_get_all() and release it by calling
iio_channel_release_all().

Add resource managed version (devm_*) of these APIs so that if client
calls the devm_iio_channel_get_all() then it need not to release it
explicitly, it can be done by managed device framework when driver
get un-binded.

This reduces the code in error path and also need of .remove callback in
some cases.

Signed-off-by: Laxman Dewangan 
---
 drivers/iio/inkern.c | 36 
 include/linux/iio/consumer.h | 26 ++
 2 files changed, 62 insertions(+)

diff --git a/drivers/iio/inkern.c b/drivers/iio/inkern.c
index 18e623f..8c1abfe 100644
--- a/drivers/iio/inkern.c
+++ b/drivers/iio/inkern.c
@@ -489,6 +489,42 @@ void iio_channel_release_all(struct iio_channel *channels)
 }
 EXPORT_SYMBOL_GPL(iio_channel_release_all);
 
+static void devm_iio_channel_free_all(struct device *dev, void *res)
+{
+   struct iio_channel *channels = *(struct iio_channel **)res;
+
+   iio_channel_release_all(channels);
+}
+
+struct iio_channel *devm_iio_channel_get_all(struct device *dev)
+{
+   struct iio_channel **ptr, *channels;
+
+   ptr = devres_alloc(devm_iio_channel_free_all, sizeof(*ptr), GFP_KERNEL);
+   if (!ptr)
+   return ERR_PTR(-ENOMEM);
+
+   channels = iio_channel_get_all(dev);
+   if (IS_ERR(channels)) {
+   devres_free(ptr);
+   return channels;
+   }
+
+   *ptr = channels;
+   devres_add(dev, ptr);
+
+   return channels;
+}
+EXPORT_SYMBOL_GPL(devm_iio_channel_get_all);
+
+void devm_iio_channel_release_all(struct device *dev,
+ struct iio_channel *channels)
+{
+   WARN_ON(devres_release(dev, devm_iio_channel_free_all,
+  devm_iio_channel_match, channels));
+}
+EXPORT_SYMBOL_GPL(devm_iio_channel_release_all);
+
 static int iio_channel_read(struct iio_channel *chan, int *val, int *val2,
enum iio_chan_info_enum info)
 {
diff --git a/include/linux/iio/consumer.h b/include/linux/iio/consumer.h
index e1e033d..3d672f7 100644
--- a/include/linux/iio/consumer.h
+++ b/include/linux/iio/consumer.h
@@ -92,6 +92,32 @@ struct iio_channel *iio_channel_get_all(struct device *dev);
  */
 void iio_channel_release_all(struct iio_channel *chan);
 
+/**
+ * devm_iio_channel_get_all() - Resource managed version of
+ * iio_channel_get_all().
+ * @dev: Pointer to consumer device.
+ *
+ * Returns a pointer to negative errno if it is not able to get the iio channel
+ * otherwise returns an array of iio_channel structures terminated with one 
with
+ * null iio_dev pointer.
+ *
+ * This function is used by fairly generic consumers to get all the
+ * channels registered as having this consumer.
+ *
+ * The allocated iio channels are automatically released when the device is
+ * unbounded.
+ */
+struct iio_channel *devm_iio_channel_get_all(struct device *dev);
+
+/**
+ * devm_iio_channel_release_all() - Resource managed version of
+ * iio_channel_release_all().
+ * @dev:   Pointer to consumer device for which resource
+ * is allocared.
+ * @chan:  Array channel to be released.
+ */
+void devm_iio_channel_release_all(struct device *dev, struct iio_channel 
*chan);
+
 struct iio_cb_buffer;
 /**
  * iio_channel_get_all_cb() - register callback for triggered capture
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/3] iio: Add resource managed APIs devm_iio_channel_{get,release) in devres

2016-04-06 Thread Laxman Dewangan 
Add following APIs in the list of managed resources of IIO:
devm_iio_channel_get()
devm_iio_channel_get_all()
devm_iio_channel_release()
devm_iio_channel_release_all()

Signed-off-by: Laxman Dewangan 
---
 Documentation/driver-model/devres.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/driver-model/devres.txt 
b/Documentation/driver-model/devres.txt
index 73b98df..bdc2dfb 100644
--- a/Documentation/driver-model/devres.txt
+++ b/Documentation/driver-model/devres.txt
@@ -267,6 +267,10 @@ IIO
   devm_iio_kfifo_free()
   devm_iio_trigger_alloc()
   devm_iio_trigger_free()
+  devm_iio_channel_get()
+  devm_iio_channel_release()
+  devm_iio_channel_get_all()
+  devm_iio_channel_release_all()
 
 IO region
   devm_release_mem_region()
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: kexec: fix crashkernel= handling

2016-04-06 Thread Dave Young 
On 04/01/16 at 02:25pm, Russell King - ARM Linux wrote:

[snip]

> Well, if we want to remove it, we then need to sort out a method of
> specifying a limit on the address - where platforms physical memory
> bridges the 4GB CPU-accessible limit, the crashkernel region must be
> allocated below that so that it is boot-time accessible.
> 
> Some patches also have boot-time only aliases of RAM, with the normal
> alias above 4GB (eg, TI Keystone2) where the running view of RAM is
> at 0x8, but it has a non-coherent boot alias at 0x8000.
> 
> I've patches which resolve some of the issues there, and making that
> change would make this patch dependent on those changes.  So, I
> recommend that this patch remains as-is for the time being, and this
> issue is addressed in a later patch after the Keystone2 idmap_to_phys()
> patches, similar to:
> 
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index 0a12fcf1aff6..74781e6d4e87 100644
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -962,7 +962,6 @@ late_initcall(init_machine_late);
>   * zImage relocating below the reserved region.
>   */
>  #define CRASH_ALIGN  (128 << 20)
> -#define CRASH_ADDR_MAX   (PHYS_OFFSET + (512 << 20))
>  
>  static inline unsigned long long get_total_mem(void)
>  {
> @@ -992,7 +991,8 @@ static void __init reserve_crashkernel(void)
>   return;
>  
>   if (crash_base <= 0) {
> - crash_base = memblock_find_in_range(CRASH_ALIGN, CRASH_ADDR_MAX,
> + unsigned long long crash_max = idmap_to_phys((u32)~0);
> + crash_base = memblock_find_in_range(CRASH_ALIGN, crash_max,
>   crash_size, CRASH_ALIGN);
>   if (!crash_base) {
>   pr_err("crashkernel reservation failed - No suitable 
> area found.\n");
> 
> Right now, I don't want to tie this facility to TI Keystone2 support
> as what this patch is doing is something that the ARM kexec support
> should have been doing since it was first introduced, so folk may
> want to backport this change to stable trees.

Is it possible for PHYS_OFFSET + (512 << 20) be larger than 4G assume that 
phys_addr_t is 32bit, if so it can be trunked to a small value then
the max will be wrong?

Otherwise I think use it temprarily is fine.

Thanks
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC6 PATCH v6 00/21] ILP32 for ARM64

2016-04-06 Thread Geert Uytterhoeven 
Hi Yuri,

On Wed, Apr 6, 2016 at 12:08 AM, Yury Norov  wrote:
> This version is rebased on kernel v4.6-rc2, and has fixes in signal subsystem.
> It works with updated glibc [1] (though very draft), and tested with LTP.
>
> It was tested on QEMU and ThunderX machines. No major difference found.
> This is RFC because ILP32 is not tested in big-endian mode.
>
>  v3: https://lkml.org/lkml/2014/9/3/704
>  v4: https://lkml.org/lkml/2015/4/13/691
>  v5: https://lkml.org/lkml/2015/9/29/911
>
>  v6:
>  - time_t, __kenel_off_t and other types turned to be 32-bit
>for compatibility reasons (after v5 discussion);

Reading this sparked my interest, so I went to the links above...

What makes you think these "applications that can’t readily be migrated to LP64
because they were written assuming an ILP32 data model, and that will never
become suitable for a LP64 data model and will remain locked into ILP32
operating environments" are more likely to be fixed for y2038 later, than for
LP64 now?

We're already closer to the (future) y2038 than to the (past) introduction of
LP64...

These unfixable legacy applications have been spreading through x32 to
the shiny new arm64 server architecture (does ppc64el also have an ILP32 mode,
or is it planned)? Lots of resources are spent on maintaining the status quo,
instead of on fixing the real problems.

Gr{oetje,eeting}s,

Geert

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

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html