* [PATCH 2/6] staging: vc04_services: remove odd vchiq_debugfs_top() wrapper
From: Greg Kroah-Hartman @ 2018-06-01 11:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180601111004.1670-1-gregkh@linuxfoundation.org>
vchiq_debugfs_top() is only a wrapper around a pointer to a dentry, so
just use the dentry directly instead, making it a static variable
instead of part of a static structure.
This also removes the pointless BUG_ON() when checking that dentry as no
one should ever care if debugfs is working or not, and the kernel should
really not panic over something as trivial as that.
Suggested-by: Eric Anholt <eric@anholt.net>
Cc: Stefan Wahren <stefan.wahren@i2se.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Keerthi Reddy <keerthigd4990@gmail.com>
Cc: linux-rpi-kernel at lists.infradead.org
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
.../interface/vchiq_arm/vchiq_debugfs.c | 24 +++++++------------
1 file changed, 8 insertions(+), 16 deletions(-)
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_debugfs.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_debugfs.c
index 103fec955e2c..8b46256a97fc 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_debugfs.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_debugfs.c
@@ -53,9 +53,6 @@
/* Top-level debug info */
struct vchiq_debugfs_info {
- /* Global 'vchiq' debugfs entry used by all instances */
- struct dentry *vchiq_cfg_dir;
-
/* one entry per client process */
struct dentry *clients;
@@ -65,6 +62,9 @@ struct vchiq_debugfs_info {
static struct vchiq_debugfs_info debugfs_info;
+/* Global 'vchiq' debugfs entry used by all instances */
+struct dentry *vchiq_dbg_dir;
+
/* Log category debugfs entries */
struct vchiq_debugfs_log_entry {
const char *name;
@@ -82,7 +82,6 @@ static struct vchiq_debugfs_log_entry vchiq_debugfs_log_entries[] = {
static int n_log_entries = ARRAY_SIZE(vchiq_debugfs_log_entries);
static struct dentry *vchiq_clients_top(void);
-static struct dentry *vchiq_debugfs_top(void);
static int debugfs_log_show(struct seq_file *f, void *offset)
{
@@ -163,7 +162,7 @@ static void vchiq_debugfs_create_log_entries(struct dentry *top)
struct dentry *dir;
size_t i;
- dir = debugfs_create_dir("log", vchiq_debugfs_top());
+ dir = debugfs_create_dir("log", vchiq_dbg_dir);
debugfs_info.log_categories = dir;
for (i = 0; i < n_log_entries; i++) {
@@ -286,17 +285,16 @@ void vchiq_debugfs_remove_instance(VCHIQ_INSTANCE_T instance)
void vchiq_debugfs_init(void)
{
- debugfs_info.vchiq_cfg_dir = debugfs_create_dir("vchiq", NULL);
- debugfs_info.clients = debugfs_create_dir("clients",
- vchiq_debugfs_top());
+ vchiq_dbg_dir = debugfs_create_dir("vchiq", NULL);
+ debugfs_info.clients = debugfs_create_dir("clients", vchiq_dbg_dir);
- vchiq_debugfs_create_log_entries(vchiq_debugfs_top());
+ vchiq_debugfs_create_log_entries(vchiq_dbg_dir);
}
/* remove all the debugfs entries */
void vchiq_debugfs_deinit(void)
{
- debugfs_remove_recursive(vchiq_debugfs_top());
+ debugfs_remove_recursive(vchiq_dbg_dir);
}
static struct dentry *vchiq_clients_top(void)
@@ -304,12 +302,6 @@ static struct dentry *vchiq_clients_top(void)
return debugfs_info.clients;
}
-static struct dentry *vchiq_debugfs_top(void)
-{
- BUG_ON(debugfs_info.vchiq_cfg_dir == NULL);
- return debugfs_info.vchiq_cfg_dir;
-}
-
#else /* CONFIG_DEBUG_FS */
void vchiq_debugfs_init(void)
--
2.17.1
^ permalink raw reply related
* [PATCH 1/6] staging: vc04_services: no need to check debugfs return values
From: Greg Kroah-Hartman @ 2018-06-01 11:09 UTC (permalink / raw)
To: linux-arm-kernel
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Clean up the vchiq_arm code by not caring about the value of debugfs
calls. This ends up removing a number of lines of code that are not
needed.
Cc: Eric Anholt <eric@anholt.net>
Cc: Stefan Wahren <stefan.wahren@i2se.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Keerthi Reddy <keerthigd4990@gmail.com>
Cc: linux-rpi-kernel at lists.infradead.org
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
.../interface/vchiq_arm/vchiq_arm.c | 13 +---
.../interface/vchiq_arm/vchiq_debugfs.c | 72 +++----------------
.../interface/vchiq_arm/vchiq_debugfs.h | 4 +-
3 files changed, 15 insertions(+), 74 deletions(-)
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
index aaa264f3b598..bc05c69383b8 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
@@ -2018,7 +2018,6 @@ vchiq_open(struct inode *inode, struct file *file)
vchiq_log_info(vchiq_arm_log_level, "vchiq_open");
switch (dev) {
case VCHIQ_MINOR: {
- int ret;
VCHIQ_STATE_T *state = vchiq_get_state();
VCHIQ_INSTANCE_T instance;
@@ -2035,11 +2034,7 @@ vchiq_open(struct inode *inode, struct file *file)
instance->state = state;
instance->pid = current->tgid;
- ret = vchiq_debugfs_add_instance(instance);
- if (ret != 0) {
- kfree(instance);
- return ret;
- }
+ vchiq_debugfs_add_instance(instance);
sema_init(&instance->insert_event, 0);
sema_init(&instance->remove_event, 0);
@@ -3630,9 +3625,7 @@ static int vchiq_probe(struct platform_device *pdev)
goto failed_device_create;
/* create debugfs entries */
- err = vchiq_debugfs_init();
- if (err != 0)
- goto failed_debugfs_init;
+ vchiq_debugfs_init();
vchiq_log_info(vchiq_arm_log_level,
"vchiq: initialised - version %d (min %d), device %d.%d",
@@ -3645,8 +3638,6 @@ static int vchiq_probe(struct platform_device *pdev)
return 0;
-failed_debugfs_init:
- device_destroy(vchiq_class, vchiq_devid);
failed_device_create:
class_destroy(vchiq_class);
failed_class_create:
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_debugfs.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_debugfs.c
index 766b4fe5f32c..103fec955e2c 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_debugfs.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_debugfs.c
@@ -158,15 +158,12 @@ static const struct file_operations debugfs_log_fops = {
};
/* create an entry under <debugfs>/vchiq/log for each log category */
-static int vchiq_debugfs_create_log_entries(struct dentry *top)
+static void vchiq_debugfs_create_log_entries(struct dentry *top)
{
struct dentry *dir;
size_t i;
- int ret = 0;
dir = debugfs_create_dir("log", vchiq_debugfs_top());
- if (!dir)
- return -ENOMEM;
debugfs_info.log_categories = dir;
for (i = 0; i < n_log_entries; i++) {
@@ -177,14 +174,8 @@ static int vchiq_debugfs_create_log_entries(struct dentry *top)
debugfs_info.log_categories,
levp,
&debugfs_log_fops);
- if (!dir) {
- ret = -ENOMEM;
- break;
- }
-
vchiq_debugfs_log_entries[i].dir = dir;
}
- return ret;
}
static int debugfs_usecount_show(struct seq_file *f, void *offset)
@@ -268,43 +259,22 @@ static const struct file_operations debugfs_trace_fops = {
};
/* add an instance (process) to the debugfs entries */
-int vchiq_debugfs_add_instance(VCHIQ_INSTANCE_T instance)
+void vchiq_debugfs_add_instance(VCHIQ_INSTANCE_T instance)
{
char pidstr[16];
- struct dentry *top, *use_count, *trace;
+ struct dentry *top;
struct dentry *clients = vchiq_clients_top();
snprintf(pidstr, sizeof(pidstr), "%d",
vchiq_instance_get_pid(instance));
top = debugfs_create_dir(pidstr, clients);
- if (!top)
- goto fail_top;
-
- use_count = debugfs_create_file("use_count",
- 0444, top,
- instance,
- &debugfs_usecount_fops);
- if (!use_count)
- goto fail_use_count;
-
- trace = debugfs_create_file("trace",
- 0644, top,
- instance,
- &debugfs_trace_fops);
- if (!trace)
- goto fail_trace;
-
- vchiq_instance_get_debugfs_node(instance)->dentry = top;
- return 0;
+ debugfs_create_file("use_count", 0444, top, instance,
+ &debugfs_usecount_fops);
+ debugfs_create_file("trace", 0644, top, instance, &debugfs_trace_fops);
-fail_trace:
- debugfs_remove(use_count);
-fail_use_count:
- debugfs_remove(top);
-fail_top:
- return -ENOMEM;
+ vchiq_instance_get_debugfs_node(instance)->dentry = top;
}
void vchiq_debugfs_remove_instance(VCHIQ_INSTANCE_T instance)
@@ -314,31 +284,13 @@ void vchiq_debugfs_remove_instance(VCHIQ_INSTANCE_T instance)
debugfs_remove_recursive(node->dentry);
}
-int vchiq_debugfs_init(void)
+void vchiq_debugfs_init(void)
{
- BUG_ON(debugfs_info.vchiq_cfg_dir != NULL);
-
debugfs_info.vchiq_cfg_dir = debugfs_create_dir("vchiq", NULL);
- if (debugfs_info.vchiq_cfg_dir == NULL)
- goto fail;
-
debugfs_info.clients = debugfs_create_dir("clients",
vchiq_debugfs_top());
- if (!debugfs_info.clients)
- goto fail;
- if (vchiq_debugfs_create_log_entries(vchiq_debugfs_top()) != 0)
- goto fail;
-
- return 0;
-
-fail:
- vchiq_debugfs_deinit();
- vchiq_log_error(vchiq_arm_log_level,
- "%s: failed to create debugfs directory",
- __func__);
-
- return -ENOMEM;
+ vchiq_debugfs_create_log_entries(vchiq_debugfs_top());
}
/* remove all the debugfs entries */
@@ -360,18 +312,16 @@ static struct dentry *vchiq_debugfs_top(void)
#else /* CONFIG_DEBUG_FS */
-int vchiq_debugfs_init(void)
+void vchiq_debugfs_init(void)
{
- return 0;
}
void vchiq_debugfs_deinit(void)
{
}
-int vchiq_debugfs_add_instance(VCHIQ_INSTANCE_T instance)
+void vchiq_debugfs_add_instance(VCHIQ_INSTANCE_T instance)
{
- return 0;
}
void vchiq_debugfs_remove_instance(VCHIQ_INSTANCE_T instance)
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_debugfs.h b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_debugfs.h
index 1d95e3d70621..3af6397ada19 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_debugfs.h
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_debugfs.h
@@ -40,11 +40,11 @@ typedef struct vchiq_debugfs_node_struct {
struct dentry *dentry;
} VCHIQ_DEBUGFS_NODE_T;
-int vchiq_debugfs_init(void);
+void vchiq_debugfs_init(void);
void vchiq_debugfs_deinit(void);
-int vchiq_debugfs_add_instance(VCHIQ_INSTANCE_T instance);
+void vchiq_debugfs_add_instance(VCHIQ_INSTANCE_T instance);
void vchiq_debugfs_remove_instance(VCHIQ_INSTANCE_T instance);
--
2.17.1
^ permalink raw reply related
* [PATCH 04/13] staging: vc04_services: no need to check debugfs return values
From: Greg Kroah-Hartman @ 2018-06-01 11:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <874lioorbj.fsf@anholt.net>
On Wed, May 30, 2018 at 12:51:12PM -0700, Eric Anholt wrote:
> Greg Kroah-Hartman <gregkh@linuxfoundation.org> writes:
>
> > When calling debugfs functions, there is no need to ever check the
> > return value. The function can work or not, but the code logic should
> > never do something different based on this.
> >
> > Clean up the vchiq_arm code by not caring about the value of debugfs
> > calls. This ends up removing a number of lines of code that are not
> > needed.
> >
> > Cc: Eric Anholt <eric@anholt.net>
> > Cc: Stefan Wahren <stefan.wahren@i2se.com>
> > Cc: Kees Cook <keescook@chromium.org>
> > Cc: Dan Carpenter <dan.carpenter@oracle.com>
> > Cc: Arnd Bergmann <arnd@arndb.de>
> > Cc: Keerthi Reddy <keerthigd4990@gmail.com>
> > Cc: linux-rpi-kernel at lists.infradead.org
> > Cc: linux-arm-kernel at lists.infradead.org
> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > ---
> > .../interface/vchiq_arm/vchiq_arm.c | 13 +---
> > .../interface/vchiq_arm/vchiq_debugfs.c | 72 +++----------------
> > .../interface/vchiq_arm/vchiq_debugfs.h | 4 +-
> > 3 files changed, 15 insertions(+), 74 deletions(-)
> >
>
> > diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_debugfs.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_debugfs.c
> > index 766b4fe5f32c..103fec955e2c 100644
> > --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_debugfs.c
> > +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_debugfs.c
>
> > @@ -314,31 +284,13 @@ void vchiq_debugfs_remove_instance(VCHIQ_INSTANCE_T instance)
> > debugfs_remove_recursive(node->dentry);
> > }
> >
> > -int vchiq_debugfs_init(void)
> > +void vchiq_debugfs_init(void)
> > {
> > - BUG_ON(debugfs_info.vchiq_cfg_dir != NULL);
> > -
> > debugfs_info.vchiq_cfg_dir = debugfs_create_dir("vchiq", NULL);
> > - if (debugfs_info.vchiq_cfg_dir == NULL)
> > - goto fail;
> > -
>
> I think now that we allow successful probe with this value NULL, module
> remove could vchiq_debugfs_deinit() -> vchiq_debugfs_top() -> BUG_ON().
> I think the right solution would be to just drop that BUG_ON(). With
> that change (and probably just garbage-collecting that function), this
> will be enthusiastically:
>
> Reviewed-by: Eric Anholt <eric@anholt.net>
Much better idea, I just did that and will send out the patch series
now. The end result is nicer:
3 files changed, 42 insertions(+), 140 deletions(-)
thanks for the suggestion.
greg k-h
^ permalink raw reply
* [PATCH] coresight: Fix check in coresight_tmc_etr_buf_insert_barrier_packet
From: Suzuki K Poulose @ 2018-06-01 11:08 UTC (permalink / raw)
To: linux-arm-kernel
We request for "CORESIGHT_BARRIER_PKT_SIZE" length and we should
be happy when we get that size.
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
Mathieu,
Please could you pull this patch, if you are happy with it ?
This fixes a problem in the ETR buf series, which I just
noticed while testing the part2 of the series.
Suzuki
---
drivers/hwtracing/coresight/coresight-tmc-etr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c b/drivers/hwtracing/coresight/coresight-tmc-etr.c
index e2bcef3..c736250 100644
--- a/drivers/hwtracing/coresight/coresight-tmc-etr.c
+++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c
@@ -862,7 +862,7 @@ tmc_etr_buf_insert_barrier_packet(struct etr_buf *etr_buf, u64 offset)
len = tmc_etr_buf_get_data(etr_buf, offset,
CORESIGHT_BARRIER_PKT_SIZE, &bufp);
- if (WARN_ON(len <= CORESIGHT_BARRIER_PKT_SIZE))
+ if (WARN_ON(len < CORESIGHT_BARRIER_PKT_SIZE))
return -EINVAL;
coresight_insert_barrier_packet(bufp);
return offset + CORESIGHT_BARRIER_PKT_SIZE;
--
2.7.4
^ permalink raw reply related
* [PATCH 0/4] lib/vsprintf: Remove atomic-unsafe support for printk format %pCr
From: Andy Shevchenko @ 2018-06-01 11:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+55aFxHHSRnDbbNGq6SwNAwEt0EhX15n_pNqon3MzGYJgMJmA@mail.gmail.com>
On Fri, Jun 1, 2018 at 2:00 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Fri, Jun 1, 2018 at 4:29 AM Geert Uytterhoeven
> <geert+renesas@glider.be> wrote:
>>
>> This patch series:
>> - Changes all existing users of "%pCr" to print the result of
>> clk_get_rate() directly, which is safe as they all do this in task
>> context only,
>> - Removes support for the "%pCr" printk format.
>
> Looks good to me.
>
> What tree will this go through? The normal printk one? Just checking
> that this doesn't end up falling through the cracks because nobody
> knows who would take it...
We discussed few month before with Petr that he would take care of the
patches against vsprintf.c.
I think this is the case here.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH 0/4] lib/vsprintf: Remove atomic-unsafe support for printk format %pCr
From: Linus Torvalds @ 2018-06-01 11:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527845302-12159-1-git-send-email-geert+renesas@glider.be>
On Fri, Jun 1, 2018 at 4:29 AM Geert Uytterhoeven
<geert+renesas@glider.be> wrote:
>
> This patch series:
> - Changes all existing users of "%pCr" to print the result of
> clk_get_rate() directly, which is safe as they all do this in task
> context only,
> - Removes support for the "%pCr" printk format.
Looks good to me.
What tree will this go through? The normal printk one? Just checking
that this doesn't end up falling through the cracks because nobody
knows who would take it...
Linus
^ permalink raw reply
* [PATCH v2] ARM: avoid Cortex-A9 livelock on tight dmb loops
From: Russell King @ 2018-06-01 11:00 UTC (permalink / raw)
To: linux-arm-kernel
Executing loops such as:
while (1)
cpu_relax();
with interrupts disabled results in a livelock of the entire system,
as other CPUs are prevented making progress. This is most noticable
as a failure of crashdump kexec, which stops just after issuing:
Loading crashdump kernel...
to the system console. Two other locations of these loops within the
ARM code have been identified and fixed up.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
v2: use wfe() instead of cpu_do_idle
arch/arm/include/asm/barrier.h | 2 ++
arch/arm/kernel/machine_kexec.c | 5 ++++-
arch/arm/kernel/smp.c | 4 +++-
arch/arm/mach-omap2/prm_common.c | 4 +++-
4 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/arm/include/asm/barrier.h b/arch/arm/include/asm/barrier.h
index 69772e742a0a..83ae97c049d9 100644
--- a/arch/arm/include/asm/barrier.h
+++ b/arch/arm/include/asm/barrier.h
@@ -11,6 +11,8 @@
#define sev() __asm__ __volatile__ ("sev" : : : "memory")
#define wfe() __asm__ __volatile__ ("wfe" : : : "memory")
#define wfi() __asm__ __volatile__ ("wfi" : : : "memory")
+#else
+#define wfe() do { } while (0)
#endif
#if __LINUX_ARM_ARCH__ >= 7
diff --git a/arch/arm/kernel/machine_kexec.c b/arch/arm/kernel/machine_kexec.c
index dd2eb5f76b9f..76300f3813e8 100644
--- a/arch/arm/kernel/machine_kexec.c
+++ b/arch/arm/kernel/machine_kexec.c
@@ -91,8 +91,11 @@ void machine_crash_nonpanic_core(void *unused)
set_cpu_online(smp_processor_id(), false);
atomic_dec(&waiting_for_crash_ipi);
- while (1)
+
+ while (1) {
cpu_relax();
+ wfe();
+ }
}
void crash_smp_send_stop(void)
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index 9ec9a366ef44..a39fe6ab89a2 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -570,8 +570,10 @@ static void ipi_cpu_stop(unsigned int cpu)
local_fiq_disable();
local_irq_disable();
- while (1)
+ while (1) {
cpu_relax();
+ wfe();
+ }
}
static DEFINE_PER_CPU(struct completion *, cpu_completion);
diff --git a/arch/arm/mach-omap2/prm_common.c b/arch/arm/mach-omap2/prm_common.c
index 021b5a8b9c0a..bb15a9eec05c 100644
--- a/arch/arm/mach-omap2/prm_common.c
+++ b/arch/arm/mach-omap2/prm_common.c
@@ -522,8 +522,10 @@ void omap_prm_reset_system(void)
prm_ll_data->reset_system();
- while (1)
+ while (1) {
cpu_relax();
+ wfe();
+ }
}
/**
--
2.7.4
^ permalink raw reply related
* [PATCH v3] PCI: mediatek: Add system pm support for MT2712
From: Andy Shevchenko @ 2018-06-01 10:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527850145.28160.6.camel@mhfsdcap03>
On Fri, Jun 1, 2018 at 1:49 PM, Honghui Zhang
<honghui.zhang@mediatek.com> wrote:
> On Fri, 2018-06-01 at 13:17 +0300, Andy Shevchenko wrote:
>> On Fri, Jun 1, 2018 at 6:04 AM, <honghui.zhang@mediatek.com> wrote:
>> > From: Honghui Zhang <honghui.zhang@mediatek.com>
>>
>> > +#ifdef CONFIG_PM_SLEEP
>> > +static int mtk_pcie_suspend_noirq(struct device *dev)
>>
>> __maybe_unused
>>
>
> Hi, Andy, thanks for your review.
> Bjorn had point this out that at:
> https://www.spinics.net/lists/arm-kernel/msg656774.html
Nice, one more maintainer with strong opinion here.
Arnd, that's what I mentioned as a split in opinions earlier.
Any new developer or even existing contributor would be now really
confusing since maintainers asked for two different approaches on the
same matter.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH v3] PCI: mediatek: Add system pm support for MT2712
From: Honghui Zhang @ 2018-06-01 10:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHp75VeBTmC=3nJ-t+OO9bp0mzJuTYsGBwi8fokT16bu2nE9RA@mail.gmail.com>
On Fri, 2018-06-01 at 13:17 +0300, Andy Shevchenko wrote:
> On Fri, Jun 1, 2018 at 6:04 AM, <honghui.zhang@mediatek.com> wrote:
> > From: Honghui Zhang <honghui.zhang@mediatek.com>
>
> > +#ifdef CONFIG_PM_SLEEP
> > +static int mtk_pcie_suspend_noirq(struct device *dev)
>
> __maybe_unused
>
Hi, Andy, thanks for your review.
Bjorn had point this out that at:
https://www.spinics.net/lists/arm-kernel/msg656774.html
So __maybe_unused is not really needed.
thanks
^ permalink raw reply
* [PATCH v2 21/40] iommu/arm-smmu-v3: Add support for Substream IDs
From: Jean-Philippe Brucker @ 2018-06-01 10:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <BLUPR0201MB1505AA55707BE2E13392FFAFA5630@BLUPR0201MB1505.namprd02.prod.outlook.com>
On 31/05/18 12:01, Bharat Kumar Gogada wrote:
>> static void arm_smmu_sync_cd(void *cookie, int ssid, bool leaf) {
>> + struct arm_smmu_cmdq_ent cmd = {
>> + .opcode = CMDQ_OP_CFGI_CD_ALL,
>
> Hi Jean, here CMDQ_OP_CFGI_CD opcode 0x5.
Woops, nice catch!
I pushed fixes for all comments so far to branch sva/current
Thanks,
Jean
^ permalink raw reply
* [PATCH 06/18] arm64: move sve_user_{enable, disable} to <asm/fpsimd.h>
From: Dave Martin @ 2018-06-01 10:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180601102913.ougz2vshzzttvuaj@lakrids.cambridge.arm.com>
On Fri, Jun 01, 2018 at 11:29:13AM +0100, Mark Rutland wrote:
> On Wed, May 16, 2018 at 10:01:32AM +0100, Dave Martin wrote:
> > On Tue, May 15, 2018 at 05:33:52PM +0100, Mark Rutland wrote:
> > > On Tue, May 15, 2018 at 01:19:26PM +0100, Dave Martin wrote:
> > > > On Tue, May 15, 2018 at 11:39:36AM +0100, Mark Rutland wrote:
> > > > > Earlier I'd put BUILD_BUG() in the body for the !CONFIG_ARM64_SVE case,
> > > > > to catch that kind of thing -- I could restore that.
> > > >
> > > > IIUC:
> > > >
> > > > if (0) {
> > > > BUILD_BUG_ON(1);
> > > > }
> > > >
> > > > can still fire, in which case it's futile checking for CONFIG_ARM64_SVE
> > > > in most of the SVE support code.
> > >
> > > We already rely on BUILD_BUG() not firing in paths that can be trivially
> > > optimized away. e.g. in the cmpxchg code.
> >
> > Fair enough. I had been unsure on this point.
> >
> > If you want to put a BUILD_BUG_ON(!IS_ENABLED(CONFIG_ARM64_SVE)) in
> > sve_user_enable() and build with CONFIG_ARM64_SVE=n to check it works,
> > then I'd be fine with that.
> >
> > This doesn't capture the runtime part of the condition, but it's better
> > than nothing.
>
> For the moment, I've kept the stubs, but placed a BUILD_BUG() in each,
> as per the above rationale.
>
> We generally do that rather than than BUILD_BUG_ON(!IS_ENABLED(...)) in
> a common definition, and it's more in keeping with the other stubs in
> <asm/fpsimd.h>.
OK, fine by me.
> > > > > > > diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
> > > > > > > index 088940387a4d..79a81c7d85c6 100644
> > > > > > > --- a/arch/arm64/kernel/fpsimd.c
> > > > > > > +++ b/arch/arm64/kernel/fpsimd.c
> > > > > > > @@ -159,7 +159,6 @@ static void sve_free(struct task_struct *task)
> > > > > > > __sve_free(task);
> > > > > > > }
> > > > > > >
> > > > > > > -
> > > > > >
> > > > > > Hmmm, Ack. Check for conflicts with the KVM FPSIMD rework [1] (though
> > > > > > trivial).
> > > > >
> > > > > I'll assume that Ack stands regardless. :)
> > > >
> > > > Actually, I was just commenting on the deleted blank line...
> > >
> > > Ah. I've restored that now.
> >
> > I meant Ack to the deletion. It looks like the blank line was
> > spuriously introduced in the first place. But it doesn't hugely matter
> > either way.
>
> Ok. I've dropped that for now to minimize the potential for conflicts,
> but we can clean this up later.
No big deal either way.
Cheers
---Dave
^ permalink raw reply
* [PATCH 06/18] arm64: move sve_user_{enable, disable} to <asm/fpsimd.h>
From: Mark Rutland @ 2018-06-01 10:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180516090121.GQ7753@e103592.cambridge.arm.com>
On Wed, May 16, 2018 at 10:01:32AM +0100, Dave Martin wrote:
> On Tue, May 15, 2018 at 05:33:52PM +0100, Mark Rutland wrote:
> > On Tue, May 15, 2018 at 01:19:26PM +0100, Dave Martin wrote:
> > > On Tue, May 15, 2018 at 11:39:36AM +0100, Mark Rutland wrote:
> > > > Earlier I'd put BUILD_BUG() in the body for the !CONFIG_ARM64_SVE case,
> > > > to catch that kind of thing -- I could restore that.
> > >
> > > IIUC:
> > >
> > > if (0) {
> > > BUILD_BUG_ON(1);
> > > }
> > >
> > > can still fire, in which case it's futile checking for CONFIG_ARM64_SVE
> > > in most of the SVE support code.
> >
> > We already rely on BUILD_BUG() not firing in paths that can be trivially
> > optimized away. e.g. in the cmpxchg code.
>
> Fair enough. I had been unsure on this point.
>
> If you want to put a BUILD_BUG_ON(!IS_ENABLED(CONFIG_ARM64_SVE)) in
> sve_user_enable() and build with CONFIG_ARM64_SVE=n to check it works,
> then I'd be fine with that.
>
> This doesn't capture the runtime part of the condition, but it's better
> than nothing.
For the moment, I've kept the stubs, but placed a BUILD_BUG() in each,
as per the above rationale.
We generally do that rather than than BUILD_BUG_ON(!IS_ENABLED(...)) in
a common definition, and it's more in keeping with the other stubs in
<asm/fpsimd.h>.
> > > > > > diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
> > > > > > index 088940387a4d..79a81c7d85c6 100644
> > > > > > --- a/arch/arm64/kernel/fpsimd.c
> > > > > > +++ b/arch/arm64/kernel/fpsimd.c
> > > > > > @@ -159,7 +159,6 @@ static void sve_free(struct task_struct *task)
> > > > > > __sve_free(task);
> > > > > > }
> > > > > >
> > > > > > -
> > > > >
> > > > > Hmmm, Ack. Check for conflicts with the KVM FPSIMD rework [1] (though
> > > > > trivial).
> > > >
> > > > I'll assume that Ack stands regardless. :)
> > >
> > > Actually, I was just commenting on the deleted blank line...
> >
> > Ah. I've restored that now.
>
> I meant Ack to the deletion. It looks like the blank line was
> spuriously introduced in the first place. But it doesn't hugely matter
> either way.
Ok. I've dropped that for now to minimize the potential for conflicts,
but we can clean this up later.
Thanks,
Mark.
^ permalink raw reply
* [PATCH v3 2/8] dt-bindings: media: Document data-enable-active property
From: Sakari Ailus @ 2018-06-01 10:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527606359-19261-3-git-send-email-jacopo+renesas@jmondi.org>
Hi Jacopo,
Thanks for the patch.
On Tue, May 29, 2018 at 05:05:53PM +0200, Jacopo Mondi wrote:
> Add 'data-enable-active' property to endpoint node properties list.
>
> The property allows to specify the polarity of the data-enable signal, which
> when in active state determinates when data lanes have to sampled for valid
> pixel data.
Lanes or lines? I understand this is forthe parallel interface.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> ---
> v3:
> - new patch
> ---
> Documentation/devicetree/bindings/media/video-interfaces.txt | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt b/Documentation/devicetree/bindings/media/video-interfaces.txt
> index 258b8df..9839d26 100644
> --- a/Documentation/devicetree/bindings/media/video-interfaces.txt
> +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt
> @@ -109,6 +109,8 @@ Optional endpoint properties
> Note, that if HSYNC and VSYNC polarities are not specified, embedded
> synchronization may be required, where supported.
> - data-active: similar to HSYNC and VSYNC, specifies data line polarity.
> +- data-enable-active: similar to HSYNC and VSYNC, specifies the data enable
> + signal polarity.
> - field-even-active: field signal level during the even field data transmission.
> - pclk-sample: sample data on rising (1) or falling (0) edge of the pixel clock
> signal.
--
Sakari Ailus
sakari.ailus at linux.intel.com
^ permalink raw reply
* [RFC] dmaengine: Add metadat_ops for dma_async_tx_descriptor
From: Peter Ujfalusi @ 2018-06-01 10:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <32208a9c-2b15-d345-1432-f1e387531f9b@ti.com>
If the DMA supports per descriptor metadata it can implement the attach,
get_ptr/set_len callbacks.
Client drivers must only use either attach or get_ptr/set_len to avoid
miss configuration.
Wrappers are also added for the metadata_ops:
dmaengine_desc_attach_metadata()
dmaengine_desc_get_metadata_ptr()
dmaengine_desc_set_metadata_len()
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
Hi,
since attachments are bouncing back, I send the patch separately
Regards,
Peter
include/linux/dmaengine.h | 50 +++++++++++++++++++++++++++++++++++++++
1 file changed, 50 insertions(+)
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 51fbb861e84b..ac42ace36aa3 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -491,6 +491,18 @@ struct dmaengine_unmap_data {
dma_addr_t addr[0];
};
+struct dma_async_tx_descriptor;
+
+struct dma_descriptor_metadata_ops {
+ int (*attach)(struct dma_async_tx_descriptor *desc, void *data,
+ size_t len);
+
+ void *(*get_ptr)(struct dma_async_tx_descriptor *desc,
+ size_t *payload_len, size_t *max_len);
+ int (*set_len)(struct dma_async_tx_descriptor *desc,
+ size_t payload_len);
+};
+
/**
* struct dma_async_tx_descriptor - async transaction descriptor
* ---dma generic offload fields---
@@ -520,6 +532,7 @@ struct dma_async_tx_descriptor {
dma_async_tx_callback_result callback_result;
void *callback_param;
struct dmaengine_unmap_data *unmap;
+ struct dma_descriptor_metadata_ops *metadata_ops;
#ifdef CONFIG_ASYNC_TX_ENABLE_CHANNEL_SWITCH
struct dma_async_tx_descriptor *next;
struct dma_async_tx_descriptor *parent;
@@ -932,6 +945,43 @@ static inline struct dma_async_tx_descriptor *dmaengine_prep_dma_memcpy(
len, flags);
}
+static inline int dmaengine_desc_attach_metadata(
+ struct dma_async_tx_descriptor *desc, void *data, size_t len)
+{
+ if (!desc)
+ return 0;
+
+ if (!desc->metadata_ops || !desc->metadata_ops->attach)
+ return -ENOTSUPP;
+
+ return desc->metadata_ops->attach(desc, data, len);
+}
+
+static inline void *dmaengine_desc_get_metadata_ptr(
+ struct dma_async_tx_descriptor *desc, size_t *payload_len,
+ size_t *max_len)
+{
+ if (!desc)
+ return NULL;
+
+ if (!desc->metadata_ops || !desc->metadata_ops->get_ptr)
+ return ERR_PTR(-ENOTSUPP);
+
+ return desc->metadata_ops->get_ptr(desc, payload_len, max_len);
+}
+
+static inline int dmaengine_desc_set_metadata_len(
+ struct dma_async_tx_descriptor *desc, size_t payload_len)
+{
+ if (!desc)
+ return 0;
+
+ if (!desc->metadata_ops || !desc->metadata_ops->set_len)
+ return -ENOTSUPP;
+
+ return desc->metadata_ops->set_len(desc, payload_len);
+}
+
/**
* dmaengine_terminate_all() - Terminate all active DMA transfers
* @chan: The channel for which to terminate the transfers
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply related
* [RFC 2/6] dmaengine: xilinx_dma: Pass AXI4-Stream control words to netdev dma client
From: Peter Ujfalusi @ 2018-06-01 10:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <DM6PR02MB43612FF66323449C7D2B4FDCC76C0@DM6PR02MB4361.namprd02.prod.outlook.com>
Hi Radhey,
On 2018-05-30 20:29, Radhey Shyam Pandey wrote:
>> In couple of days I can update the metadata patches I have atm and send
>> as RFC.
>>
>> Is there anything from your side I should take into account when doing that?
> I think a generic interface to attach/share metadata buffer b/w client and the
> dmaengine driver is good enough. Is metadata patchset (early version)
> available in TI external repos?
I don't have it in public repository, but now that the TRM is public I
can start preparing things for upstream.
I have attached the patch I ended up with, but I need to add the
documentation part.
Since the 'metadata' is part of the DMA descriptor itself I thought that
it might be better to reflect that -> the metadata_ops is part of the
dma_async_tx_descriptor struct.
DMA drivers can initialize it when it is supported by the channel or
setup. In my case it is optional, many peripherals did not use it at all.
I have two modes to deal with the metadata:
1. attach mode
Client drivers are giving a buffer and a size to the DMA driver and in
case of TX the data is copied to the descriptor's metadata part. In case
of RX when the transfer is completed the DMA driver will copy the data
from the DMA descriptor to the client provided buffer.
Here we need one memcpy for each descriptor.
2. pointer mode
If we have high throughput peripheral, the per descriptor memcpy can be
an obstacle for performance.
TX: The client dmaengine_desc_get_metadata_ptr() to get the pointer to
the metadata section of the descriptor, it will receive back the max
size and the currently used size (important for RX). This is done before
issue_pending().
The client can update the metadata directly and when it is done calls
the dmaengine_desc_set_metadata_len() to tell the DMA driver the size of
the metadata it has configured.
RX: in the DMA callback the client calls
dmaengine_desc_get_metadata_ptr() to get the pointer and the size of the
metadata we have received and can process the information w/o memcpy.
I think it might be better to rename these from metadata to client_data
or something. It is part of the DMA descriptor, passed along with the
DMA descriptor, but it is owned by the client driver.
- P?ter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-dmaengine-Add-metadat_ops-for-dma_async_tx_descripto.patch
Type: text/x-patch
Size: 3092 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180601/d3c18cb2/attachment-0001.bin>
^ permalink raw reply
* [PATCH v3] PCI: mediatek: Add system pm support for MT2712
From: Andy Shevchenko @ 2018-06-01 10:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527822270-30280-1-git-send-email-honghui.zhang@mediatek.com>
On Fri, Jun 1, 2018 at 6:04 AM, <honghui.zhang@mediatek.com> wrote:
> From: Honghui Zhang <honghui.zhang@mediatek.com>
> +#ifdef CONFIG_PM_SLEEP
> +static int mtk_pcie_suspend_noirq(struct device *dev)
__maybe_unused
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH v6 2/2] arm64: signal: Report signal frame size to userspace via auxv
From: Dave Martin @ 2018-06-01 10:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527847814-22829-1-git-send-email-Dave.Martin@arm.com>
Stateful CPU architecture extensions may require the signal frame
to grow to a size that exceeds the arch's MINSIGSTKSZ #define.
However, changing this #define is an ABI break.
To allow userspace the option of determining the signal frame size
in a more forwards-compatible way, this patch adds a new auxv entry
tagged with AT_MINSIGSTKSZ, which provides the maximum signal frame
size that the process can observe during its lifetime.
If AT_MINSIGSTKSZ is absent from the aux vector, the caller can
assume that the MINSIGSTKSZ #define is sufficient. This allows for
a consistent interface with older kernels that do not provide
AT_MINSIGSTKSZ.
The idea is that libc could expose this via sysconf() or some
similar mechanism.
There is deliberately no AT_SIGSTKSZ. The kernel knows nothing
about userspace's own stack overheads and should not pretend to
know.
For arm64:
The primary motivation for this interface is the Scalable Vector
Extension, which can require at least 4KB or so of extra space
in the signal frame for the largest hardware implementations.
To determine the correct value, a "Christmas tree" mode (via the
add_all argument) is added to setup_sigframe_layout(), to simulate
addition of all possible records to the signal frame at maximum
possible size.
If this procedure goes wrong somehow, resulting in a stupidly large
frame layout and hence failure of sigframe_alloc() to allocate a
record to the frame, then this is indicative of a kernel bug. In
this case, we WARN() and no attempt is made to populate
AT_MINSIGSTKSZ for userspace.
For arm64 SVE:
The SVE context block in the signal frame needs to be considered
too when computing the maximum possible signal frame size.
Because the size of this block depends on the vector length, this
patch computes the size based not on the thread's current vector
length but instead on the maximum possible vector length: this
determines the maximum size of SVE context block that can be
observed in any signal frame for the lifetime of the process.
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Alex Benn?e <alex.bennee@linaro.org>
---
Changes since v5:
Requested by Will Deacon:
* Fill the hole left by a missing AT_MINSIGSTKSZ with AT_IGNORE
(due to concerns about how a short auxv may affect the FDPIC
loader and PR_SET_MM related stuff.
---
arch/arm64/include/asm/elf.h | 13 +++++++++
arch/arm64/include/asm/processor.h | 5 ++++
arch/arm64/include/uapi/asm/auxvec.h | 3 ++-
arch/arm64/kernel/cpufeature.c | 1 +
arch/arm64/kernel/signal.c | 52 +++++++++++++++++++++++++++++++-----
5 files changed, 66 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
index fac1c4d..433b955 100644
--- a/arch/arm64/include/asm/elf.h
+++ b/arch/arm64/include/asm/elf.h
@@ -121,6 +121,9 @@
#ifndef __ASSEMBLY__
+#include <linux/bug.h>
+#include <asm/processor.h> /* for signal_minsigstksz, used by ARCH_DLINFO */
+
typedef unsigned long elf_greg_t;
#define ELF_NGREG (sizeof(struct user_pt_regs) / sizeof(elf_greg_t))
@@ -148,6 +151,16 @@ typedef struct user_fpsimd_state elf_fpregset_t;
do { \
NEW_AUX_ENT(AT_SYSINFO_EHDR, \
(elf_addr_t)current->mm->context.vdso); \
+ \
+ /* \
+ * Should always be nonzero unless there's a kernel bug. \
+ * If we haven't determined a sensible value to give to \
+ * userspace, omit the entry: \
+ */ \
+ if (likely(signal_minsigstksz)) \
+ NEW_AUX_ENT(AT_MINSIGSTKSZ, signal_minsigstksz); \
+ else \
+ NEW_AUX_ENT(AT_IGNORE, 0); \
} while (0)
#define ARCH_HAS_SETUP_ADDITIONAL_PAGES
diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h
index 7675989..65ab83e 100644
--- a/arch/arm64/include/asm/processor.h
+++ b/arch/arm64/include/asm/processor.h
@@ -35,6 +35,8 @@
#ifdef __KERNEL__
#include <linux/build_bug.h>
+#include <linux/cache.h>
+#include <linux/init.h>
#include <linux/stddef.h>
#include <linux/string.h>
@@ -244,6 +246,9 @@ void cpu_enable_pan(const struct arm64_cpu_capabilities *__unused);
void cpu_enable_cache_maint_trap(const struct arm64_cpu_capabilities *__unused);
void cpu_clear_disr(const struct arm64_cpu_capabilities *__unused);
+extern unsigned long __ro_after_init signal_minsigstksz; /* sigframe size */
+extern void __init minsigstksz_setup(void);
+
/* Userspace interface for PR_SVE_{SET,GET}_VL prctl()s: */
#define SVE_SET_VL(arg) sve_set_current_vl(arg)
#define SVE_GET_VL() sve_get_current_vl()
diff --git a/arch/arm64/include/uapi/asm/auxvec.h b/arch/arm64/include/uapi/asm/auxvec.h
index ec0a86d..743c0b8 100644
--- a/arch/arm64/include/uapi/asm/auxvec.h
+++ b/arch/arm64/include/uapi/asm/auxvec.h
@@ -19,7 +19,8 @@
/* vDSO location */
#define AT_SYSINFO_EHDR 33
+#define AT_MINSIGSTKSZ 51 /* stack needed for signal delivery */
-#define AT_VECTOR_SIZE_ARCH 1 /* entries in ARCH_DLINFO */
+#define AT_VECTOR_SIZE_ARCH 2 /* entries in ARCH_DLINFO */
#endif
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 9d1b06d..0e0b53d 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -1619,6 +1619,7 @@ void __init setup_cpu_features(void)
pr_info("emulated: Privileged Access Never (PAN) using TTBR0_EL1 switching\n");
sve_setup();
+ minsigstksz_setup();
/* Advertise that we have computed the system capabilities */
set_sys_caps_initialised();
diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
index 154b7d3..e7da5db 100644
--- a/arch/arm64/kernel/signal.c
+++ b/arch/arm64/kernel/signal.c
@@ -17,6 +17,7 @@
* along with this program. If not, see <http://www.gnu.org/licenses/>.
*/
+#include <linux/cache.h>
#include <linux/compat.h>
#include <linux/errno.h>
#include <linux/kernel.h>
@@ -570,8 +571,15 @@ asmlinkage long sys_rt_sigreturn(struct pt_regs *regs)
return 0;
}
-/* Determine the layout of optional records in the signal frame */
-static int setup_sigframe_layout(struct rt_sigframe_user_layout *user)
+/*
+ * Determine the layout of optional records in the signal frame
+ *
+ * add_all: if true, lays out the biggest possible signal frame for
+ * this task; otherwise, generates a layout for the current state
+ * of the task.
+ */
+static int setup_sigframe_layout(struct rt_sigframe_user_layout *user,
+ bool add_all)
{
int err;
@@ -581,7 +589,7 @@ static int setup_sigframe_layout(struct rt_sigframe_user_layout *user)
return err;
/* fault information, if valid */
- if (current->thread.fault_code) {
+ if (add_all || current->thread.fault_code) {
err = sigframe_alloc(user, &user->esr_offset,
sizeof(struct esr_context));
if (err)
@@ -591,8 +599,14 @@ static int setup_sigframe_layout(struct rt_sigframe_user_layout *user)
if (system_supports_sve()) {
unsigned int vq = 0;
- if (test_thread_flag(TIF_SVE))
- vq = sve_vq_from_vl(current->thread.sve_vl);
+ if (add_all || test_thread_flag(TIF_SVE)) {
+ int vl = sve_max_vl;
+
+ if (!add_all)
+ vl = current->thread.sve_vl;
+
+ vq = sve_vq_from_vl(vl);
+ }
err = sigframe_alloc(user, &user->sve_offset,
SVE_SIG_CONTEXT_SIZE(vq));
@@ -603,7 +617,6 @@ static int setup_sigframe_layout(struct rt_sigframe_user_layout *user)
return sigframe_alloc_end(user);
}
-
static int setup_sigframe(struct rt_sigframe_user_layout *user,
struct pt_regs *regs, sigset_t *set)
{
@@ -701,7 +714,7 @@ static int get_sigframe(struct rt_sigframe_user_layout *user,
int err;
init_user_layout(user);
- err = setup_sigframe_layout(user);
+ err = setup_sigframe_layout(user, false);
if (err)
return err;
@@ -936,3 +949,28 @@ asmlinkage void do_notify_resume(struct pt_regs *regs,
thread_flags = READ_ONCE(current_thread_info()->flags);
} while (thread_flags & _TIF_WORK_MASK);
}
+
+unsigned long __ro_after_init signal_minsigstksz;
+
+/*
+ * Determine the stack space required for guaranteed signal devliery.
+ * This function is used to populate AT_MINSIGSTKSZ at process startup.
+ * cpufeatures setup is assumed to be complete.
+ */
+void __init minsigstksz_setup(void)
+{
+ struct rt_sigframe_user_layout user;
+
+ init_user_layout(&user);
+
+ /*
+ * If this fails, SIGFRAME_MAXSZ needs to be enlarged. It won't
+ * be big enough, but it's our best guess:
+ */
+ if (WARN_ON(setup_sigframe_layout(&user, true)))
+ return;
+
+ signal_minsigstksz = sigframe_size(&user) +
+ round_up(sizeof(struct frame_record), 16) +
+ 16; /* max alignment padding */
+}
--
2.1.4
^ permalink raw reply related
* [PATCH v6 1/2] arm64/sve: Thin out initialisation sanity-checks for sve_max_vl
From: Dave Martin @ 2018-06-01 10:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527847814-22829-1-git-send-email-Dave.Martin@arm.com>
Now that the kernel SVE support is reasonably mature, it is
excessive to default sve_max_vl to the invalid value -1 and then
sprinkle WARN_ON()s around the place to make sure it has been
initialised before use. The cpufeatures code already runs pretty
early, and will ensure sve_max_vl gets initialised.
This patch initialises sve_max_vl to something sane that will be
supported by every SVE implementation, and removes most of the
sanity checks.
The checks in find_supported_vector_length() are retained for now.
If anything goes horribly wrong, we are likely to trip a check here
sooner or later.
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
---
arch/arm64/kernel/fpsimd.c | 17 ++++-------------
arch/arm64/kernel/ptrace.c | 3 ---
2 files changed, 4 insertions(+), 16 deletions(-)
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index 87a3536..f9ec640 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -129,7 +129,7 @@ static int sve_default_vl = -1;
#ifdef CONFIG_ARM64_SVE
/* Maximum supported vector length across all CPUs (initially poisoned) */
-int __ro_after_init sve_max_vl = -1;
+int __ro_after_init sve_max_vl = SVE_VL_MIN;
/* Set of available vector lengths, as vq_to_bit(vq): */
static __ro_after_init DECLARE_BITMAP(sve_vq_map, SVE_VQ_MAX);
static void __percpu *efi_sve_state;
@@ -360,22 +360,13 @@ static int sve_proc_do_default_vl(struct ctl_table *table, int write,
return ret;
/* Writing -1 has the special meaning "set to max": */
- if (vl == -1) {
- /* Fail safe if sve_max_vl wasn't initialised */
- if (WARN_ON(!sve_vl_valid(sve_max_vl)))
- vl = SVE_VL_MIN;
- else
- vl = sve_max_vl;
-
- goto chosen;
- }
+ if (vl == -1)
+ vl = sve_max_vl;
if (!sve_vl_valid(vl))
return -EINVAL;
- vl = find_supported_vector_length(vl);
-chosen:
- sve_default_vl = vl;
+ sve_default_vl = find_supported_vector_length(vl);
return 0;
}
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index 7ff81fe..577deb0 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -766,9 +766,6 @@ static void sve_init_header_from_task(struct user_sve_header *header,
vq = sve_vq_from_vl(header->vl);
header->max_vl = sve_max_vl;
- if (WARN_ON(!sve_vl_valid(sve_max_vl)))
- header->max_vl = header->vl;
-
header->size = SVE_PT_SIZE(vq, header->flags);
header->max_size = SVE_PT_SIZE(sve_vq_from_vl(header->max_vl),
SVE_PT_REGS_SVE);
--
2.1.4
^ permalink raw reply related
* [PATCH v6 0/2] arm64: signal: Report signal frame size to userspace via auxv
From: Dave Martin @ 2018-06-01 10:10 UTC (permalink / raw)
To: linux-arm-kernel
This series adds support for telling userspace the size of the signal
frame via a new AT_MINSIGSTKSZ entry in the aux vector.
This is an update to [1]. An omitted AT_MINSIGSTKSZ is now replaced
with an AT_IGNORE entry instead of being collapsed out of the auxv
entirely.
See individual patches for the delta.
[1] [PATCH v5 0/2] arm64: signal: Report signal frame size to userspace via auxv
http://lists.infradead.org/pipermail/linux-arm-kernel/2018-May/580974.html
Dave Martin (2):
arm64/sve: Thin out initialisation sanity-checks for sve_max_vl
arm64: signal: Report signal frame size to userspace via auxv
arch/arm64/include/asm/elf.h | 13 +++++++++
arch/arm64/include/asm/processor.h | 5 ++++
arch/arm64/include/uapi/asm/auxvec.h | 3 ++-
arch/arm64/kernel/cpufeature.c | 1 +
arch/arm64/kernel/fpsimd.c | 17 +++---------
arch/arm64/kernel/ptrace.c | 3 ---
arch/arm64/kernel/signal.c | 52 +++++++++++++++++++++++++++++++-----
7 files changed, 70 insertions(+), 24 deletions(-)
--
2.1.4
^ permalink raw reply
* [PATCH v1 1/2] ACPI / APEI: Add SEI notification type support for ARMv8
From: gengdongjiu @ 2018-06-01 10:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180531105252.it67drvnsfz62pqa@lakrids.cambridge.arm.com>
Hi Mark,
Thanks for the comments.
On 2018/5/31 18:52, Mark Rutland wrote:
> On Thu, May 31, 2018 at 08:41:45PM +0800, Dongjiu Geng wrote:
>> +#ifdef CONFIG_ACPI_APEI_SEI
>> +static LIST_HEAD(ghes_sei);
>> +
>> +/*
>> + * Return 0 only if one of the SEI error sources successfully reported an error
>> + * record sent from the firmware.
>> + */
>> +int ghes_notify_sei(void)
>> +{
>> + struct ghes *ghes;
>> + int ret = -ENOENT;
>> +
>> + rcu_read_lock();
>> + list_for_each_entry_rcu(ghes, &ghes_sei, list) {
>> + if (!ghes_proc(ghes))
>> + ret = 0;
>> + }
>> + rcu_read_unlock();
>> + return ret;
>> +}
>> +
>> +static void ghes_sei_add(struct ghes *ghes)
>> +{
>> + mutex_lock(&ghes_list_mutex);
>> + list_add_rcu(&ghes->list, &ghes_sei);
>> + mutex_unlock(&ghes_list_mutex);
>> +}
>> +
>> +static void ghes_sei_remove(struct ghes *ghes)
>> +{
>> + mutex_lock(&ghes_list_mutex);
>> + list_del_rcu(&ghes->list);
>> + mutex_unlock(&ghes_list_mutex);
>> + synchronize_rcu();
>> +}
>> +#else /* CONFIG_ACPI_APEI_SEI */
>> +static inline void ghes_sei_add(struct ghes *ghes) { }
>> +static inline void ghes_sei_remove(struct ghes *ghes) { }
>> +#endif /* CONFIG_ACPI_APEI_SEI */
>> +
>> #ifdef CONFIG_HAVE_ACPI_APEI_NMI
>> /*
>
>> index 8feb0c8..9ba59e2 100644
>> --- a/include/acpi/ghes.h
>> +++ b/include/acpi/ghes.h
>> @@ -120,5 +120,6 @@ static inline void *acpi_hest_get_next(struct acpi_hest_generic_data *gdata)
>> section = acpi_hest_get_next(section))
>>
>> int ghes_notify_sea(void);
>> +int ghes_notify_sei(void);
>
> It would be nice to have a stub definition when !CONFIG_ACPI_APEI_SEI,
> e.g.
>
> #ifdef CONFIG_ACPI_APEI_SEI
> int ghes_notify_sei(void);
> #else
> static in int ghes_notify_sei(void) { return -ENOENT; }
> #endif
>
> ... as callers could simply call this without additional checks.
>
> As a cleanup, similar would be nice for ghes_notify_sea() with
> CONFIG_ACPI_APEI_SEA.
I think your suggestion is better, I will do the cleanup include the ghes_notify_sea().
thanks again.
>
> Thanks,
> Mark.
>
> .
>
^ permalink raw reply
* [PATCH 4/4] arm64/mm: migrate swapper_pg_dir and tramp_pg_dir
From: Robin Murphy @ 2018-06-01 9:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180601080918.11918-1-yaojun8558363@gmail.com>
On 01/06/18 09:09, Jun Yao wrote:
> Migrate swapper_pg_dir and tramp_pg_dir. And their virtual addresses
> do not correlate with kernel's address.
I think this might break software PAN, which IIRC depends on the
reserved TTBR0 PGD being physically adjacent to the live swapper PGD for
the trickery in __uaccess_ttbr0_{en,dis}able() to work.
Robin.
> Signed-off-by: Jun Yao <yaojun8558363@gmail.com>
> ---
> arch/arm64/mm/mmu.c | 70 +++++++++++++++++++++++++++------------------
> 1 file changed, 42 insertions(+), 28 deletions(-)
>
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index 26ba3e70a91c..5baae59479d8 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -57,6 +57,9 @@ EXPORT_SYMBOL(kimage_voffset);
>
> phys_addr_t __pa_swapper_pg_dir;
> pgd_t *new_swapper_pg_dir = swapper_pg_dir;
> +#ifdef CONFIG_UNMAP_KERNEL_AT_EL0
> +pgd_t *new_tramp_pg_dir;
> +#endif
>
> /*
> * Empty_zero_page is a special page that is used for zero-initialized data
> @@ -80,19 +83,14 @@ pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
> }
> EXPORT_SYMBOL(phys_mem_access_prot);
>
> -static phys_addr_t __init early_pgtable_alloc(void)
> +static void __init clear_page_phys(phys_addr_t phys)
> {
> - phys_addr_t phys;
> - void *ptr;
> -
> - phys = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
> -
> /*
> * The FIX_{PGD,PUD,PMD} slots may be in active use, but the FIX_PTE
> * slot will be free, so we can (ab)use the FIX_PTE slot to initialise
> * any level of table.
> */
> - ptr = pte_set_fixmap(phys);
> + void *ptr = pte_set_fixmap(phys);
>
> memset(ptr, 0, PAGE_SIZE);
>
> @@ -101,6 +99,14 @@ static phys_addr_t __init early_pgtable_alloc(void)
> * table walker
> */
> pte_clear_fixmap();
> +}
> +
> +static phys_addr_t __init early_pgtable_alloc(void)
> +{
> + phys_addr_t phys;
> +
> + phys = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
> + clear_page_phys(phys);
>
> return phys;
> }
> @@ -554,6 +560,10 @@ static int __init map_entry_trampoline(void)
> __create_pgd_mapping(tramp_pg_dir, pa_start, TRAMP_VALIAS, PAGE_SIZE,
> prot, pgd_pgtable_alloc, 0);
>
> + memcpy(new_tramp_pg_dir, tramp_pg_dir, PGD_SIZE);
> + memblock_free(__pa_symbol(tramp_pg_dir),
> + __pa_symbol(swapper_pg_dir) - __pa_symbol(tramp_pg_dir));
> +
> /* Map both the text and data into the kernel page table */
> __set_fixmap(FIX_ENTRY_TRAMP_TEXT, pa_start, prot);
> if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) {
> @@ -631,36 +641,40 @@ static void __init map_kernel(pgd_t *pgdp)
> */
> void __init paging_init(void)
> {
> - phys_addr_t pgd_phys = early_pgtable_alloc();
> - pgd_t *pgdp = pgd_set_fixmap(pgd_phys);
> + phys_addr_t pgd_phys;
> + pgd_t *pgdp;
> +
> +#ifdef CONFIG_UNMAP_KERNEL_AT_EL0
> + phys_addr_t mem_size;
> + phys_addr_t p;
>
> - __pa_swapper_pg_dir = __pa_symbol(swapper_pg_dir);
> + mem_size = __pa_symbol(swapper_pg_dir) + PAGE_SIZE
> + - __pa_symbol(tramp_pg_dir);
> + pgd_phys = memblock_alloc(mem_size, PAGE_SIZE);
> +
> + for (p = pgd_phys; p < pgd_phys + mem_size; p += PAGE_SIZE)
> + clear_page_phys(p);
> +
> + new_tramp_pg_dir = __va(pgd_phys);
> + __pa_swapper_pg_dir = pgd_phys + PAGE_SIZE;
> +#else
> + pgd_phys = early_pgtable_alloc();
> + __pa_swapper_pg_dir = pgd_phys;
> +#endif
> + new_swapper_pg_dir = __va(__pa_swapper_pg_dir);
> +
> + pgdp = pgd_set_fixmap(__pa_swapper_pg_dir);
>
> map_kernel(pgdp);
> map_mem(pgdp);
>
> - /*
> - * We want to reuse the original swapper_pg_dir so we don't have to
> - * communicate the new address to non-coherent secondaries in
> - * secondary_entry, and so cpu_switch_mm can generate the address with
> - * adrp+add rather than a load from some global variable.
> - *
> - * To do this we need to go via a temporary pgd.
> - */
> - cpu_replace_ttbr1(pgd_phys);
> - memcpy(swapper_pg_dir, pgdp, PGD_SIZE);
> cpu_replace_ttbr1(__pa_swapper_pg_dir);
> + init_mm.pgd = new_swapper_pg_dir;
>
> pgd_clear_fixmap();
> - memblock_free(pgd_phys, PAGE_SIZE);
>
> - /*
> - * We only reuse the PGD from the swapper_pg_dir, not the pud + pmd
> - * allocated with it.
> - */
> - memblock_free(__pa_symbol(swapper_pg_dir) + PAGE_SIZE,
> - __pa_symbol(swapper_pg_end) - __pa_symbol(swapper_pg_dir)
> - - PAGE_SIZE);
> + memblock_free(__pa_symbol(swapper_pg_dir),
> + __pa_symbol(swapper_pg_end) - __pa_symbol(swapper_pg_dir));
> }
>
> /*
>
^ permalink raw reply
* [PATCH] KVM: arm64: VHE: Migrate _elx sysreg accessors to msr_s/mrs_s
From: Mark Rutland @ 2018-06-01 9:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527603647-24787-1-git-send-email-Dave.Martin@arm.com>
Hi,
On Tue, May 29, 2018 at 03:20:47PM +0100, Dave Martin wrote:
> Currently, the {read,write}_sysreg_el*() accessors for accessing
> particular ELs' sysregs in the presence of VHE rely on some local
> hacks and define their system register encodings in a way that is
> inconsistent with the core definitions in <asm/sysreg.h>.
>
> As a result, it is necessary to add duplicate definitions for any
> system register that already needs a definition in sysreg.h for
> other reasons.
>
> This is a bit of a maintenance headache, and the reasons for the
> _el*() accessors working the way they do is a bit historical.
>
> This patch gets rid of the shadow sysreg definitions in
> <asm/kvm_hyp.h>, converts the _el*() accessors to use the core
> msr_s/mrs_s interface, and converts all call sites to use the
> standard sysreg #define names (i.e., upper case, with SYS_ prefix).
Nice!
[...]
> static inline unsigned long vcpu_read_elr_el1(const struct kvm_vcpu *vcpu)
> {
> if (vcpu->arch.sysregs_loaded_on_cpu)
> - return read_sysreg_el1(elr);
> + return read_sysreg_el1(SYS_ELR);
Could we have the macro implicitly handle the SYS_ prefix?
A further bit of cleanup that I'd like to do is make {read,write}_sysreg() use
{mrs,msr}_s, implicitly handling the SYS_ prefix, so that we can kill off
{read,write}_sysreg_s(), and always use a {read,write}_sysreg().
A minor pain point is that we'd have to convert callers to pass the sysreg name
in upper-case, but that conversion can be scripted fairly easily.
e.g. for the above, read_sysreg() would take ELR_EL1, and read_sysreg_el1()
would take ELR.
Thanks,
Mark.
^ permalink raw reply
* [PATCH 0/4] arm64/mm: migrate swapper_pg_dir
From: Robin Murphy @ 2018-06-01 9:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180601080819.11712-1-yaojun8558363@gmail.com>
On 01/06/18 09:08, Jun Yao wrote:
> Currently, The offset between swapper_pg_dir and _text is
> fixed. When attackers know the address of _text(no KASLR or
> breaking KASLR), they can caculate the address of
> swapper_pg_dir. Then KSMA(Kernel Space Mirroring Attack) can
> be applied.
>
> The principle of KSMA is to insert a carefully constructed PGD
> entry into the translation table. The type of this entry is
Out of interest, how does that part work? AFAICS, modifying a PGD entry
involves writing to kernel memory, which would mean the implication of
KSMA is "userspace can gain write permission to kernel memory by writing
to kernel memory" - that doesn't sound like an attack in itself, more
just a convenience for ease of exploiting whatever successful attack got
you in there in the first place.
That's not to say that it isn't still worth mitigating, I'm just
questioning the given rationale here.
Robin.
> block, which maps the kernel text and its access permissions
> bits are 01. The user process can then modify kernel text
> directly through this mapping.
>
> To protect against KSMA, these patches migrate swapper_pg_dir
> to new place, which is dynamically allocated. Since it is
> allocated during the kernel boot process and the address is
> relatively fixed, further randomization may be required.
>
> Jun Yao (4):
> arm64/mm: pass swapper_pg_dir as an argument to __enable_mmu()
> arm64/mm: introduce variable to save new swapper_pg_dir address
> arm64/mm: make tramp_pg_dir and swapper_pg_dir adjacent
> arm64/mm: migrate swapper_pg_dir and tramp_pg_dir
>
> arch/arm64/include/asm/mmu_context.h | 6 +--
> arch/arm64/include/asm/pgtable.h | 2 +
> arch/arm64/kernel/cpufeature.c | 2 +-
> arch/arm64/kernel/entry.S | 4 +-
> arch/arm64/kernel/head.S | 10 ++--
> arch/arm64/kernel/hibernate.c | 2 +-
> arch/arm64/kernel/sleep.S | 2 +
> arch/arm64/kernel/vmlinux.lds.S | 9 ++--
> arch/arm64/mm/kasan_init.c | 6 +--
> arch/arm64/mm/mmu.c | 75 +++++++++++++++++-----------
> 10 files changed, 71 insertions(+), 47 deletions(-)
>
^ permalink raw reply
* [PATCH 2/4] thermal: bcm2835: Stop using printk format %pCr
From: Stefan Wahren @ 2018-06-01 9:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527845302-12159-3-git-send-email-geert+renesas@glider.be>
Am 01.06.2018 um 11:28 schrieb Geert Uytterhoeven:
> Printk format "%pCr" will be removed soon, as clk_get_rate() must not be
> called in atomic context.
>
> Replace it by printing the variable that already holds the clock rate.
> Note that calling clk_get_rate() is safe here, as the code runs in task
> context.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
Thanks
^ permalink raw reply
* [PATCH 4/4] lib/vsprintf: Remove atomic-unsafe support for %pCr
From: Geert Uytterhoeven @ 2018-06-01 9:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527845302-12159-1-git-send-email-geert+renesas@glider.be>
"%pCr" formats the current rate of a clock, and calls clk_get_rate().
The latter obtains a mutex, hence it must not be called from atomic
context.
Remove support for this rarely-used format, as vsprintf() (and e.g.
printk()) must be callable from any context.
Any remaining out-of-tree users will start seeing the clock's name
printed instead of its rate.
Reported-by: Jia-Ju Bai <baijiaju1990@gmail.com>
Fixes: 900cca2944254edd ("lib/vsprintf: add %pC{,n,r} format specifiers for clocks")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Documentation/core-api/printk-formats.rst | 3 +--
lib/vsprintf.c | 3 ---
2 files changed, 1 insertion(+), 5 deletions(-)
diff --git a/Documentation/core-api/printk-formats.rst b/Documentation/core-api/printk-formats.rst
index eb30efdd2e789616..25dc591cb1108790 100644
--- a/Documentation/core-api/printk-formats.rst
+++ b/Documentation/core-api/printk-formats.rst
@@ -419,11 +419,10 @@ struct clk
%pC pll1
%pCn pll1
- %pCr 1560000000
For printing struct clk structures. %pC and %pCn print the name
(Common Clock Framework) or address (legacy clock framework) of the
-structure; %pCr prints the current clock rate.
+structure.
Passed by reference.
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 247a7e0bf24f6f74..a48aaa79d352313a 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -1469,9 +1469,6 @@ char *clock(char *buf, char *end, struct clk *clk, struct printf_spec spec,
return string(buf, end, NULL, spec);
switch (fmt[1]) {
- case 'r':
- return number(buf, end, clk_get_rate(clk), spec);
-
case 'n':
default:
#ifdef CONFIG_COMMON_CLK
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox