* Re: [PATCH v4 1/3] leds: Introduce userspace leds driver
From: Jacek Anaszewski @ 2016-11-09 8:44 UTC (permalink / raw)
To: Pavel Machek
Cc: David Lechner, Richard Purdie, linux-kernel, linux-leds,
Marcel Holtmann, Hans de Goede
In-Reply-To: <20161109070514.GA18969@amd>
Hi,
On 11/09/2016 08:05 AM, Pavel Machek wrote:
> Hi!
>
>>> +struct uleds_device {
>>> + struct uleds_user_dev user_dev;
>>> + struct led_classdev led_cdev;
>>> + struct mutex mutex;
>>> + enum uleds_state state;
>>> + wait_queue_head_t waitq;
>>> + unsigned char brightness;
>>
>> I've just noticed that this is wrong, since LED subsystem
>> brightness type is enum led_brightness, i.e. int.
>> LED_FULL (255) value is a legacy enum value that can be overridden
>> by max_brightness property.
>>
>> Please submit a fix so that I could merge it with the original
>> patch before sending it upstream.
>
> Actually... perhaps you want to wait with merging the userspace driver
> till the locking is solved in the LED subsystem? Maybe I'm wrong, but
> I have feeling that userspace driver will have unusual requirements
> w.r.t. locking, and that it would be good to have that solved,
> first...
If you think about locking between led_set_brightness() and
led_update_brightness() then we have no ready solution for that.
Do you have any?
If not then we have to live with that until one is devised.
After adding the locking in brightness_show the risk of races will be
only in case of concurrent calls to led_set_brightness() and
led_update_brightness() from kernel, whereas currently there are no
such use cases.
--
Best regards,
Jacek Anaszewski
^ permalink raw reply
* Re: [PATCH] ACPI / gpio: avoid warning for gpio hogging code
From: Linus Walleij @ 2016-11-09 8:44 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Alexandre Courbot, Mika Westerberg, Rafael J. Wysocki,
Dmitry Torokhov, Wei Yongjun, Christophe Ricard,
linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20161108134035.1764500-1-arnd@arndb.de>
On Tue, Nov 8, 2016 at 2:40 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> The newly added acpi_gpiochip_scan_gpios function produces a few harmless
> warnings:
>
> drivers/gpio/gpiolib-acpi.c: In function ‘acpi_gpiochip_add’:
> drivers/gpio/gpiolib-acpi.c:925:7: error: ‘dflags’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
> drivers/gpio/gpiolib-acpi.c:925:9: error: ‘lflags’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
>
> The problem is that he compiler cannot know that a negative return value
> from fwnode_property_read_u32_array() or acpi_gpiochip_pin_to_gpio_offset()
> implies that the IS_ERR(gpio_desc) is true, as the value could in theory
> be below -MAX_ERRNO.
>
> The function already initializes its output values to zero, and moving
> that intialization a little higher up ensures that we can never have
> uninitialized data in the caller.
>
> Fixes: c80f1ba75df2 ("ACPI / gpio: Add hogging support")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Patch applied with Mika's ACK.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v7 4/6] VT-d: No need to set irq affinity for posted format IRTE
From: Wu, Feng @ 2016-11-09 8:44 UTC (permalink / raw)
To: Jan Beulich
Cc: Tian, Kevin, Wu, Feng, george.dunlap@eu.citrix.com,
andrew.cooper3@citrix.com, dario.faggioli@citrix.com,
xen-devel@lists.xen.org
In-Reply-To: <58219388020000780011CF8E@prv-mh.provo.novell.com>
>
> > 2. if previous p is 1 and it is in remapped mode, we can only set it to
> > remapped mode in _this_ function, setting it to posted mode is in
> > another function: pi_update_irte().
>
> Which may be part of the problem: Why are there two functions?
>
I think the reason is that pi_update_irte() was introduced when we first
enabled VT-d PI, and this patch handles some cases which need to be
done in msi_msg_to_remap_entry(). But I think your suggestion here
is good, I am thinking of calling msi_msg_to_remap_entry() (Need to add
new parameter to this function) in pi_update_irte().
Thanks,
Feng
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* [linux-next:master 5015/5173] include/drm/drmP.h:178:2: note: in expansion of macro '_DRM_PRINTK'
From: kbuild test robot @ 2016-11-09 8:46 UTC (permalink / raw)
To: Sudip Mukherjee; +Cc: kbuild-all, Andrew Morton, Linux Memory Management List
[-- Attachment #1: Type: text/plain, Size: 14792 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
head: 6b9ac964c292bfc0f8e948392ec1914e40abae63
commit: ae751ceb4237be6781b205ab196ef887a2836cf2 [5015/5173] m32r: add simple dma
config: m32r-allmodconfig (attached as .config)
compiler: m32r-linux-gcc (GCC) 6.2.0
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout ae751ceb4237be6781b205ab196ef887a2836cf2
# save the attached .config to linux build tree
make.cross ARCH=m32r
All warnings (new ones prefixed by >>):
In file included from include/linux/printk.h:6:0,
from include/linux/kernel.h:13,
from include/linux/list.h:8,
from include/linux/kobject.h:20,
from include/linux/device.h:17,
from include/linux/i2c.h:30,
from include/drm/drm_crtc.h:28,
from include/drm/drm_atomic.h:31,
from drivers/gpu/drm/vc4/vc4_crtc.c:34:
drivers/gpu/drm/vc4/vc4_crtc.c: In function 'vc4_crtc_dump_regs':
include/linux/kern_levels.h:4:18: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'long unsigned int' [-Wformat=]
#define KERN_SOH "\001" /* ASCII Start Of Header */
^
include/linux/kern_levels.h:13:19: note: in expansion of macro 'KERN_SOH'
#define KERN_INFO KERN_SOH "6" /* informational */
^~~~~~~~
include/drm/drmP.h:173:16: note: in expansion of macro 'KERN_INFO'
printk##once(KERN_##level "[" DRM_NAME "] " fmt, \
^~~~~
>> include/drm/drmP.h:178:2: note: in expansion of macro '_DRM_PRINTK'
_DRM_PRINTK(, INFO, fmt, ##__VA_ARGS__)
^~~~~~~~~~~
drivers/gpu/drm/vc4/vc4_crtc.c:118:3: note: in expansion of macro 'DRM_INFO'
DRM_INFO("0x%04x (%s): 0x%08x\n",
^~~~~~~~
drivers/gpu/drm/vc4/vc4_crtc.c: In function 'vc4_crtc_debugfs_regs':
drivers/gpu/drm/vc4/vc4_crtc.c:145:36: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'long unsigned int' [-Wformat=]
seq_printf(m, "%s (0x%04x): 0x%08x\n",
^
--
In file included from include/linux/printk.h:6:0,
from include/linux/kernel.h:13,
from include/linux/list.h:8,
from include/linux/kobject.h:20,
from include/linux/device.h:17,
from include/linux/i2c.h:30,
from include/drm/drm_crtc.h:28,
from include/drm/drm_atomic_helper.h:31,
from drivers/gpu/drm/vc4/vc4_dpi.c:24:
drivers/gpu/drm/vc4/vc4_dpi.c: In function 'vc4_dpi_dump_regs':
include/linux/kern_levels.h:4:18: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'long unsigned int' [-Wformat=]
#define KERN_SOH "\001" /* ASCII Start Of Header */
^
include/linux/kern_levels.h:13:19: note: in expansion of macro 'KERN_SOH'
#define KERN_INFO KERN_SOH "6" /* informational */
^~~~~~~~
include/drm/drmP.h:173:16: note: in expansion of macro 'KERN_INFO'
printk##once(KERN_##level "[" DRM_NAME "] " fmt, \
^~~~~
>> include/drm/drmP.h:178:2: note: in expansion of macro '_DRM_PRINTK'
_DRM_PRINTK(, INFO, fmt, ##__VA_ARGS__)
^~~~~~~~~~~
drivers/gpu/drm/vc4/vc4_dpi.c:152:3: note: in expansion of macro 'DRM_INFO'
DRM_INFO("0x%04x (%s): 0x%08x\n",
^~~~~~~~
drivers/gpu/drm/vc4/vc4_dpi.c: In function 'vc4_dpi_debugfs_regs':
drivers/gpu/drm/vc4/vc4_dpi.c:171:36: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'long unsigned int' [-Wformat=]
seq_printf(m, "%s (0x%04x): 0x%08x\n",
^
drivers/gpu/drm/vc4/vc4_dpi.c: In function 'vc4_dpi_bind':
drivers/gpu/drm/vc4/vc4_dpi.c:422:36: warning: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'long unsigned int' [-Wformat=]
dev_err(dev, "Port returned 0x%08x for ID instead of 0x%08x\n",
^
--
drivers/gpu/drm/vc4/vc4_hdmi.c: In function 'vc4_hdmi_debugfs_regs':
drivers/gpu/drm/vc4/vc4_hdmi.c:133:36: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'long unsigned int' [-Wformat=]
seq_printf(m, "%s (0x%04x): 0x%08x\n",
^
drivers/gpu/drm/vc4/vc4_hdmi.c:139:36: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'long unsigned int' [-Wformat=]
seq_printf(m, "%s (0x%04x): 0x%08x\n",
^
In file included from include/linux/printk.h:6:0,
from include/linux/kernel.h:13,
from include/linux/list.h:8,
from include/linux/kobject.h:20,
from include/linux/device.h:17,
from include/linux/i2c.h:30,
from include/drm/drm_crtc.h:28,
from include/drm/drm_atomic_helper.h:31,
from drivers/gpu/drm/vc4/vc4_hdmi.c:28:
drivers/gpu/drm/vc4/vc4_hdmi.c: In function 'vc4_hdmi_dump_regs':
include/linux/kern_levels.h:4:18: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'long unsigned int' [-Wformat=]
#define KERN_SOH "\001" /* ASCII Start Of Header */
^
include/linux/kern_levels.h:13:19: note: in expansion of macro 'KERN_SOH'
#define KERN_INFO KERN_SOH "6" /* informational */
^~~~~~~~
include/drm/drmP.h:173:16: note: in expansion of macro 'KERN_INFO'
printk##once(KERN_##level "[" DRM_NAME "] " fmt, \
^~~~~
>> include/drm/drmP.h:178:2: note: in expansion of macro '_DRM_PRINTK'
_DRM_PRINTK(, INFO, fmt, ##__VA_ARGS__)
^~~~~~~~~~~
drivers/gpu/drm/vc4/vc4_hdmi.c:154:3: note: in expansion of macro 'DRM_INFO'
DRM_INFO("0x%04x (%s): 0x%08x\n",
^~~~~~~~
include/linux/kern_levels.h:4:18: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'long unsigned int' [-Wformat=]
#define KERN_SOH "\001" /* ASCII Start Of Header */
^
include/linux/kern_levels.h:13:19: note: in expansion of macro 'KERN_SOH'
#define KERN_INFO KERN_SOH "6" /* informational */
^~~~~~~~
include/drm/drmP.h:173:16: note: in expansion of macro 'KERN_INFO'
printk##once(KERN_##level "[" DRM_NAME "] " fmt, \
^~~~~
>> include/drm/drmP.h:178:2: note: in expansion of macro '_DRM_PRINTK'
_DRM_PRINTK(, INFO, fmt, ##__VA_ARGS__)
^~~~~~~~~~~
drivers/gpu/drm/vc4/vc4_hdmi.c:159:3: note: in expansion of macro 'DRM_INFO'
DRM_INFO("0x%04x (%s): 0x%08x\n",
^~~~~~~~
--
In file included from include/linux/printk.h:6:0,
from include/linux/kernel.h:13,
from include/linux/list.h:8,
from include/linux/agp_backend.h:33,
from include/drm/drmP.h:35,
from drivers/gpu/drm/vc4/vc4_drv.h:9,
from drivers/gpu/drm/vc4/vc4_hvs.c:26:
drivers/gpu/drm/vc4/vc4_hvs.c: In function 'vc4_hvs_dump_state':
include/linux/kern_levels.h:4:18: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'long unsigned int' [-Wformat=]
#define KERN_SOH "\001" /* ASCII Start Of Header */
^
include/linux/kern_levels.h:13:19: note: in expansion of macro 'KERN_SOH'
#define KERN_INFO KERN_SOH "6" /* informational */
^~~~~~~~
include/drm/drmP.h:173:16: note: in expansion of macro 'KERN_INFO'
printk##once(KERN_##level "[" DRM_NAME "] " fmt, \
^~~~~
>> include/drm/drmP.h:178:2: note: in expansion of macro '_DRM_PRINTK'
_DRM_PRINTK(, INFO, fmt, ##__VA_ARGS__)
^~~~~~~~~~~
drivers/gpu/drm/vc4/vc4_hvs.c:69:3: note: in expansion of macro 'DRM_INFO'
DRM_INFO("0x%04x (%s): 0x%08x\n",
^~~~~~~~
include/linux/kern_levels.h:4:18: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'long unsigned int' [-Wformat=]
#define KERN_SOH "\001" /* ASCII Start Of Header */
^
include/linux/kern_levels.h:13:19: note: in expansion of macro 'KERN_SOH'
#define KERN_INFO KERN_SOH "6" /* informational */
^~~~~~~~
include/drm/drmP.h:173:16: note: in expansion of macro 'KERN_INFO'
printk##once(KERN_##level "[" DRM_NAME "] " fmt, \
^~~~~
>> include/drm/drmP.h:178:2: note: in expansion of macro '_DRM_PRINTK'
_DRM_PRINTK(, INFO, fmt, ##__VA_ARGS__)
^~~~~~~~~~~
drivers/gpu/drm/vc4/vc4_hvs.c:76:3: note: in expansion of macro 'DRM_INFO'
DRM_INFO("0x%08x (%s): 0x%08x 0x%08x 0x%08x 0x%08x\n",
^~~~~~~~
include/linux/kern_levels.h:4:18: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'long unsigned int' [-Wformat=]
#define KERN_SOH "\001" /* ASCII Start Of Header */
^
include/linux/kern_levels.h:13:19: note: in expansion of macro 'KERN_SOH'
#define KERN_INFO KERN_SOH "6" /* informational */
^~~~~~~~
include/drm/drmP.h:173:16: note: in expansion of macro 'KERN_INFO'
printk##once(KERN_##level "[" DRM_NAME "] " fmt, \
^~~~~
>> include/drm/drmP.h:178:2: note: in expansion of macro '_DRM_PRINTK'
_DRM_PRINTK(, INFO, fmt, ##__VA_ARGS__)
^~~~~~~~~~~
drivers/gpu/drm/vc4/vc4_hvs.c:76:3: note: in expansion of macro 'DRM_INFO'
DRM_INFO("0x%08x (%s): 0x%08x 0x%08x 0x%08x 0x%08x\n",
^~~~~~~~
include/linux/kern_levels.h:4:18: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'long unsigned int' [-Wformat=]
#define KERN_SOH "\001" /* ASCII Start Of Header */
^
include/linux/kern_levels.h:13:19: note: in expansion of macro 'KERN_SOH'
#define KERN_INFO KERN_SOH "6" /* informational */
^~~~~~~~
include/drm/drmP.h:173:16: note: in expansion of macro 'KERN_INFO'
printk##once(KERN_##level "[" DRM_NAME "] " fmt, \
^~~~~
>> include/drm/drmP.h:178:2: note: in expansion of macro '_DRM_PRINTK'
_DRM_PRINTK(, INFO, fmt, ##__VA_ARGS__)
^~~~~~~~~~~
drivers/gpu/drm/vc4/vc4_hvs.c:76:3: note: in expansion of macro 'DRM_INFO'
DRM_INFO("0x%08x (%s): 0x%08x 0x%08x 0x%08x 0x%08x\n",
^~~~~~~~
include/linux/kern_levels.h:4:18: warning: format '%x' expects argument of type 'unsigned int', but argument 7 has type 'long unsigned int' [-Wformat=]
#define KERN_SOH "\001" /* ASCII Start Of Header */
^
include/linux/kern_levels.h:13:19: note: in expansion of macro 'KERN_SOH'
#define KERN_INFO KERN_SOH "6" /* informational */
^~~~~~~~
include/drm/drmP.h:173:16: note: in expansion of macro 'KERN_INFO'
printk##once(KERN_##level "[" DRM_NAME "] " fmt, \
^~~~~
>> include/drm/drmP.h:178:2: note: in expansion of macro '_DRM_PRINTK'
_DRM_PRINTK(, INFO, fmt, ##__VA_ARGS__)
^~~~~~~~~~~
drivers/gpu/drm/vc4/vc4_hvs.c:76:3: note: in expansion of macro 'DRM_INFO'
DRM_INFO("0x%08x (%s): 0x%08x 0x%08x 0x%08x 0x%08x\n",
^~~~~~~~
drivers/gpu/drm/vc4/vc4_hvs.c: In function 'vc4_hvs_debugfs_regs':
drivers/gpu/drm/vc4/vc4_hvs.c:94:36: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'long unsigned int' [-Wformat=]
seq_printf(m, "%s (0x%04x): 0x%08x\n",
^
--
In file included from include/linux/printk.h:305:0,
from include/linux/kernel.h:13,
from include/linux/list.h:8,
from include/linux/module.h:9,
from drivers/media/platform/pxa_camera.c:15:
drivers/media/platform/pxa_camera.c: In function 'pxa_camera_eof':
>> drivers/media/platform/pxa_camera.c:1170:3: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'long unsigned int' [-Wformat=]
"Camera interrupt status 0x%x\n",
^
include/linux/dynamic_debug.h:134:39: note: in definition of macro 'dynamic_dev_dbg'
__dynamic_dev_dbg(&descriptor, dev, fmt, \
^~~
>> drivers/media/platform/pxa_camera.c:1169:2: note: in expansion of macro 'dev_dbg'
dev_dbg(pcdev_to_dev(pcdev),
^~~~~~~
vim +/_DRM_PRINTK +178 include/drm/drmP.h
^1da177e drivers/char/drm/drmP.h Linus Torvalds 2005-04-16 167 /***********************************************************************/
^1da177e drivers/char/drm/drmP.h Linus Torvalds 2005-04-16 168 /** \name Macros to make printk easier */
^1da177e drivers/char/drm/drmP.h Linus Torvalds 2005-04-16 169 /*@{*/
^1da177e drivers/char/drm/drmP.h Linus Torvalds 2005-04-16 170
30b0da8d include/drm/drmP.h Dave Gordon 2016-08-18 171 #define _DRM_PRINTK(once, level, fmt, ...) \
30b0da8d include/drm/drmP.h Dave Gordon 2016-08-18 172 do { \
30b0da8d include/drm/drmP.h Dave Gordon 2016-08-18 @173 printk##once(KERN_##level "[" DRM_NAME "] " fmt, \
30b0da8d include/drm/drmP.h Dave Gordon 2016-08-18 174 ##__VA_ARGS__); \
30b0da8d include/drm/drmP.h Dave Gordon 2016-08-18 175 } while (0)
30b0da8d include/drm/drmP.h Dave Gordon 2016-08-18 176
30b0da8d include/drm/drmP.h Dave Gordon 2016-08-18 177 #define DRM_INFO(fmt, ...) \
30b0da8d include/drm/drmP.h Dave Gordon 2016-08-18 @178 _DRM_PRINTK(, INFO, fmt, ##__VA_ARGS__)
30b0da8d include/drm/drmP.h Dave Gordon 2016-08-18 179 #define DRM_NOTE(fmt, ...) \
30b0da8d include/drm/drmP.h Dave Gordon 2016-08-18 180 _DRM_PRINTK(, NOTICE, fmt, ##__VA_ARGS__)
30b0da8d include/drm/drmP.h Dave Gordon 2016-08-18 181 #define DRM_WARN(fmt, ...) \
:::::: The code at line 178 was first introduced by commit
:::::: 30b0da8d556e65ff935a56cd82c05ba0516d3e4a drm: extra printk() wrapper macros
:::::: TO: Dave Gordon <david.s.gordon@intel.com>
:::::: CC: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 39709 bytes --]
^ permalink raw reply
* [PATCH] arm64: dts: marvell: add unique identifiers for Armada A8k SPI controllers
From: Gregory CLEMENT @ 2016-11-09 8:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161108174851.2cd8efb4@free-electrons.com>
Hi Marcin,
On mar., nov. 08 2016, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> On Tue, 8 Nov 2016 17:31:32 +0100, Marcin Wojtas wrote:
>> Enabling SPI controllers, which are attached to different busses
>> inside an SoC, may result in overlapping enumeration and cause
>> sysfs registration failure. Example log after enabling two
>> controllers on Armada 8040 SoC with same identifiers:
>>
>> [ 3.740415] sysfs: cannot create duplicate filename
>> '/class/spi_master/spi0'
>> [ 3.747510] ------------[ cut here ]------------
>> [ 3.752145] WARNING: at fs/sysfs/dir.c:31
>> [...]
>> [ 4.002299] orion_spi: probe of f4700600.spi failed with error -17
>>
>> spi-orion driver offers dedicated DT property ('cell-index'), that
>> allow setting unique identifiers. Recently added support for CP110-slave
>> HW block introduced two new SPI controllers' nodes with same ID as
>> ones from CP110-master.
>>
>> This commit fixes the issue by assigning different 'cell-index' values
>> for CP110-slave SPI controllers.
>>
>> Fixes: 4eef78a0091b ("arm64: dts: marvell: add description for the slave
>> CP110 in Armada 8K")
>> Signed-off-by: Marcin Wojtas <mw@semihalf.com>
>
> It's sad that we need to hardcode those indexes in the Device Tree
> (which by no means are a description of the HW by the way), but that's
> what the SPI framework expects I believe. Therefore:
>
> Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Applied on mvebu/fixes with acked-by from Thomas.
In the same time I also applied "arm64: dts: marvell: fix clocksource
for CP110 slave SPI0" which didn't find his way to mainline yet.
Thanks,
Gregory
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH] arm64: dts: marvell: add unique identifiers for Armada A8k SPI controllers
From: Gregory CLEMENT @ 2016-11-09 8:47 UTC (permalink / raw)
To: Marcin Wojtas
Cc: Thomas Petazzoni, linux-kernel, linux-arm-kernel,
sebastian.hesselbarth, andrew, jason, will.deacon, robh+dt,
mark.rutland, nadavh, alior, jaz, tn
In-Reply-To: <20161108174851.2cd8efb4@free-electrons.com>
Hi Marcin,
On mar., nov. 08 2016, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> On Tue, 8 Nov 2016 17:31:32 +0100, Marcin Wojtas wrote:
>> Enabling SPI controllers, which are attached to different busses
>> inside an SoC, may result in overlapping enumeration and cause
>> sysfs registration failure. Example log after enabling two
>> controllers on Armada 8040 SoC with same identifiers:
>>
>> [ 3.740415] sysfs: cannot create duplicate filename
>> '/class/spi_master/spi0'
>> [ 3.747510] ------------[ cut here ]------------
>> [ 3.752145] WARNING: at fs/sysfs/dir.c:31
>> [...]
>> [ 4.002299] orion_spi: probe of f4700600.spi failed with error -17
>>
>> spi-orion driver offers dedicated DT property ('cell-index'), that
>> allow setting unique identifiers. Recently added support for CP110-slave
>> HW block introduced two new SPI controllers' nodes with same ID as
>> ones from CP110-master.
>>
>> This commit fixes the issue by assigning different 'cell-index' values
>> for CP110-slave SPI controllers.
>>
>> Fixes: 4eef78a0091b ("arm64: dts: marvell: add description for the slave
>> CP110 in Armada 8K")
>> Signed-off-by: Marcin Wojtas <mw@semihalf.com>
>
> It's sad that we need to hardcode those indexes in the Device Tree
> (which by no means are a description of the HW by the way), but that's
> what the SPI framework expects I believe. Therefore:
>
> Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Applied on mvebu/fixes with acked-by from Thomas.
In the same time I also applied "arm64: dts: marvell: fix clocksource
for CP110 slave SPI0" which didn't find his way to mainline yet.
Thanks,
Gregory
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH 01/14] crypto: caam - fix AEAD givenc descriptors
From: Horia Geantă @ 2016-11-09 8:46 UTC (permalink / raw)
To: Herbert Xu; +Cc: David S. Miller, linux-crypto, Alex Porosanu
In-Reply-To: <1478681184-9442-1-git-send-email-horia.geanta@nxp.com>
From: Alex Porosanu <alexandru.porosanu@nxp.com>
The AEAD givenc descriptor relies on moving the IV through the
output FIFO and then back to the CTX2 for authentication. The
SEQ FIFO STORE could be scheduled before the data can be
read from OFIFO, especially since the SEQ FIFO LOAD needs
to wait for the SEQ FIFO LOAD SKIP to finish first. The
SKIP takes more time when the input is SG than when it's
a contiguous buffer. If the SEQ FIFO LOAD is not scheduled
before the STORE, the DECO will hang waiting for data
to be available in the OFIFO so it can be transferred to C2.
In order to overcome this, first force transfer of IV to C2
by starting the "cryptlen" transfer first and then starting to
store data from OFIFO to the output buffer.
Fixes: 1acebad3d8db8 ("crypto: caam - faster aead implementation")
Cc: <stable@vger.kernel.org> # 3.2+
Signed-off-by: Alex Porosanu <alexandru.porosanu@nxp.com>
Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
---
drivers/crypto/caam/caamalg.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/caam/caamalg.c b/drivers/crypto/caam/caamalg.c
index 8de85dfb1b04..5317d8cad44d 100644
--- a/drivers/crypto/caam/caamalg.c
+++ b/drivers/crypto/caam/caamalg.c
@@ -736,7 +736,9 @@ static int aead_set_sh_desc(struct crypto_aead *aead)
/* Will read cryptlen */
append_math_add(desc, VARSEQINLEN, SEQINLEN, REG0, CAAM_CMD_SZ);
- aead_append_src_dst(desc, FIFOLD_TYPE_MSG1OUT2);
+ append_seq_fifo_load(desc, 0, FIFOLD_CLASS_BOTH | KEY_VLF |
+ FIFOLD_TYPE_MSG1OUT2 | FIFOLD_TYPE_LASTBOTH);
+ append_seq_fifo_store(desc, 0, FIFOST_TYPE_MESSAGE_DATA | KEY_VLF);
/* Write ICV */
append_seq_store(desc, ctx->authsize, LDST_CLASS_2_CCB |
--
2.4.4
^ permalink raw reply related
* [PATCH 04/14] crypto: caam - fix sparse warnings
From: Horia Geantă @ 2016-11-09 8:46 UTC (permalink / raw)
To: Herbert Xu; +Cc: David S. Miller, linux-crypto
In-Reply-To: <1478681184-9442-1-git-send-email-horia.geanta@nxp.com>
Fix the following sparse warning (note that endianness issues
are not not addressed in current patch):
drivers/crypto/caam/ctrl.c:388:24: warning: incorrect type in argument 1 (different address spaces)
drivers/crypto/caam/ctrl.c:388:24: expected void [noderef] <asn:2>*reg
drivers/crypto/caam/ctrl.c:388:24: got unsigned int *<noident>
drivers/crypto/caam/ctrl.c:390:24: warning: incorrect type in argument 1 (different address spaces)
drivers/crypto/caam/ctrl.c:390:24: expected void [noderef] <asn:2>*reg
drivers/crypto/caam/ctrl.c:390:24: got unsigned int *<noident>
drivers/crypto/caam/ctrl.c:548:24: warning: incorrect type in assignment (different address spaces)
drivers/crypto/caam/ctrl.c:548:24: expected struct caam_ctrl [noderef] <asn:2>*ctrl
drivers/crypto/caam/ctrl.c:548:24: got struct caam_ctrl *<noident>
drivers/crypto/caam/ctrl.c:550:30: warning: cast removes address space of expression
drivers/crypto/caam/ctrl.c:549:26: warning: incorrect type in assignment (different address spaces)
drivers/crypto/caam/ctrl.c:549:26: expected struct caam_assurance [noderef] <asn:2>*assure
drivers/crypto/caam/ctrl.c:549:26: got struct caam_assurance *<noident>
drivers/crypto/caam/ctrl.c:554:28: warning: cast removes address space of expression
drivers/crypto/caam/ctrl.c:553:24: warning: incorrect type in assignment (different address spaces)
drivers/crypto/caam/ctrl.c:553:24: expected struct caam_deco [noderef] <asn:2>*deco
drivers/crypto/caam/ctrl.c:553:24: got struct caam_deco *<noident>
drivers/crypto/caam/ctrl.c:634:48: warning: cast removes address space of expression
drivers/crypto/caam/ctrl.c:633:44: warning: incorrect type in assignment (different address spaces)
drivers/crypto/caam/ctrl.c:633:44: expected struct caam_job_ring [noderef] <asn:2>*<noident>
drivers/crypto/caam/ctrl.c:633:44: got struct caam_job_ring *<noident>
drivers/crypto/caam/ctrl.c:648:34: warning: cast removes address space of expression
drivers/crypto/caam/ctrl.c:647:30: warning: incorrect type in assignment (different address spaces)
drivers/crypto/caam/ctrl.c:647:30: expected struct caam_queue_if [noderef] <asn:2>*qi
drivers/crypto/caam/ctrl.c:647:30: got struct caam_queue_if *<noident>
drivers/crypto/caam/ctrl.c:806:37: warning: incorrect type in assignment (different address spaces)
drivers/crypto/caam/ctrl.c:806:37: expected void *data
drivers/crypto/caam/ctrl.c:806:37: got unsigned int [noderef] <asn:2>*
drivers/crypto/caam/ctrl.c:814:38: warning: incorrect type in assignment (different address spaces)
drivers/crypto/caam/ctrl.c:814:38: expected void *data
drivers/crypto/caam/ctrl.c:814:38: got unsigned int [noderef] <asn:2>*
drivers/crypto/caam/ctrl.c:822:38: warning: incorrect type in assignment (different address spaces)
drivers/crypto/caam/ctrl.c:822:38: expected void *data
drivers/crypto/caam/ctrl.c:822:38: got unsigned int [noderef] <asn:2>*
drivers/crypto/caam/jr.c:492:23: warning: incorrect type in assignment (different address spaces)
drivers/crypto/caam/jr.c:492:23: expected struct caam_job_ring [noderef] <asn:2>*rregs
drivers/crypto/caam/jr.c:492:23: got struct caam_job_ring *<noident>
drivers/crypto/caam/caampkc.c:398:35: warning: Using plain integer as NULL pointer
drivers/crypto/caam/caampkc.c:444:35: warning: Using plain integer as NULL pointer
Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
---
drivers/crypto/caam/caampkc.c | 4 ++--
drivers/crypto/caam/ctrl.c | 40 +++++++++++++++++-----------------------
drivers/crypto/caam/jr.c | 2 +-
3 files changed, 20 insertions(+), 26 deletions(-)
diff --git a/drivers/crypto/caam/caampkc.c b/drivers/crypto/caam/caampkc.c
index 851015e652b8..32100c4851dd 100644
--- a/drivers/crypto/caam/caampkc.c
+++ b/drivers/crypto/caam/caampkc.c
@@ -395,7 +395,7 @@ static int caam_rsa_set_pub_key(struct crypto_akcipher *tfm, const void *key,
unsigned int keylen)
{
struct caam_rsa_ctx *ctx = akcipher_tfm_ctx(tfm);
- struct rsa_key raw_key = {0};
+ struct rsa_key raw_key = {NULL};
struct caam_rsa_key *rsa_key = &ctx->key;
int ret;
@@ -441,7 +441,7 @@ static int caam_rsa_set_priv_key(struct crypto_akcipher *tfm, const void *key,
unsigned int keylen)
{
struct caam_rsa_ctx *ctx = akcipher_tfm_ctx(tfm);
- struct rsa_key raw_key = {0};
+ struct rsa_key raw_key = {NULL};
struct caam_rsa_key *rsa_key = &ctx->key;
int ret;
diff --git a/drivers/crypto/caam/ctrl.c b/drivers/crypto/caam/ctrl.c
index a79937d68c26..be62a7f482ac 100644
--- a/drivers/crypto/caam/ctrl.c
+++ b/drivers/crypto/caam/ctrl.c
@@ -365,11 +365,8 @@ static void kick_trng(struct platform_device *pdev, int ent_delay)
*/
val = (rd_reg32(&r4tst->rtsdctl) & RTSDCTL_ENT_DLY_MASK)
>> RTSDCTL_ENT_DLY_SHIFT;
- if (ent_delay <= val) {
- /* put RNG4 into run mode */
- clrsetbits_32(&r4tst->rtmctl, RTMCTL_PRGM, 0);
- return;
- }
+ if (ent_delay <= val)
+ goto start_rng;
val = rd_reg32(&r4tst->rtsdctl);
val = (val & ~RTSDCTL_ENT_DLY_MASK) |
@@ -381,15 +378,12 @@ static void kick_trng(struct platform_device *pdev, int ent_delay)
wr_reg32(&r4tst->rtfrqmax, RTFRQMAX_DISABLE);
/* read the control register */
val = rd_reg32(&r4tst->rtmctl);
+start_rng:
/*
* select raw sampling in both entropy shifter
- * and statistical checker
+ * and statistical checker; ; put RNG4 into run mode
*/
- clrsetbits_32(&val, 0, RTMCTL_SAMP_MODE_RAW_ES_SC);
- /* put RNG4 into run mode */
- clrsetbits_32(&val, RTMCTL_PRGM, 0);
- /* write back the control register */
- wr_reg32(&r4tst->rtmctl, val);
+ clrsetbits_32(&r4tst->rtmctl, RTMCTL_PRGM, RTMCTL_SAMP_MODE_RAW_ES_SC);
}
/**
@@ -545,13 +539,13 @@ static int caam_probe(struct platform_device *pdev)
else
BLOCK_OFFSET = PG_SIZE_64K;
- ctrlpriv->ctrl = (struct caam_ctrl __force *)ctrl;
- ctrlpriv->assure = (struct caam_assurance __force *)
- ((uint8_t *)ctrl +
+ ctrlpriv->ctrl = (struct caam_ctrl __iomem __force *)ctrl;
+ ctrlpriv->assure = (struct caam_assurance __iomem __force *)
+ ((__force uint8_t *)ctrl +
BLOCK_OFFSET * ASSURE_BLOCK_NUMBER
);
- ctrlpriv->deco = (struct caam_deco __force *)
- ((uint8_t *)ctrl +
+ ctrlpriv->deco = (struct caam_deco __iomem __force *)
+ ((__force uint8_t *)ctrl +
BLOCK_OFFSET * DECO_BLOCK_NUMBER
);
@@ -630,8 +624,8 @@ static int caam_probe(struct platform_device *pdev)
ring);
continue;
}
- ctrlpriv->jr[ring] = (struct caam_job_ring __force *)
- ((uint8_t *)ctrl +
+ ctrlpriv->jr[ring] = (struct caam_job_ring __iomem __force *)
+ ((__force uint8_t *)ctrl +
(ring + JR_BLOCK_NUMBER) *
BLOCK_OFFSET
);
@@ -644,8 +638,8 @@ static int caam_probe(struct platform_device *pdev)
!!(rd_reg32(&ctrl->perfmon.comp_parms_ms) &
CTPR_MS_QI_MASK);
if (ctrlpriv->qi_present) {
- ctrlpriv->qi = (struct caam_queue_if __force *)
- ((uint8_t *)ctrl +
+ ctrlpriv->qi = (struct caam_queue_if __iomem __force *)
+ ((__force uint8_t *)ctrl +
BLOCK_OFFSET * QI_BLOCK_NUMBER
);
/* This is all that's required to physically enable QI */
@@ -803,7 +797,7 @@ static int caam_probe(struct platform_device *pdev)
&caam_fops_u32_ro);
/* Internal covering keys (useful in non-secure mode only) */
- ctrlpriv->ctl_kek_wrap.data = &ctrlpriv->ctrl->kek[0];
+ ctrlpriv->ctl_kek_wrap.data = (__force void *)&ctrlpriv->ctrl->kek[0];
ctrlpriv->ctl_kek_wrap.size = KEK_KEY_SIZE * sizeof(u32);
ctrlpriv->ctl_kek = debugfs_create_blob("kek",
S_IRUSR |
@@ -811,7 +805,7 @@ static int caam_probe(struct platform_device *pdev)
ctrlpriv->ctl,
&ctrlpriv->ctl_kek_wrap);
- ctrlpriv->ctl_tkek_wrap.data = &ctrlpriv->ctrl->tkek[0];
+ ctrlpriv->ctl_tkek_wrap.data = (__force void *)&ctrlpriv->ctrl->tkek[0];
ctrlpriv->ctl_tkek_wrap.size = KEK_KEY_SIZE * sizeof(u32);
ctrlpriv->ctl_tkek = debugfs_create_blob("tkek",
S_IRUSR |
@@ -819,7 +813,7 @@ static int caam_probe(struct platform_device *pdev)
ctrlpriv->ctl,
&ctrlpriv->ctl_tkek_wrap);
- ctrlpriv->ctl_tdsk_wrap.data = &ctrlpriv->ctrl->tdsk[0];
+ ctrlpriv->ctl_tdsk_wrap.data = (__force void *)&ctrlpriv->ctrl->tdsk[0];
ctrlpriv->ctl_tdsk_wrap.size = KEK_KEY_SIZE * sizeof(u32);
ctrlpriv->ctl_tdsk = debugfs_create_blob("tdsk",
S_IRUSR |
diff --git a/drivers/crypto/caam/jr.c b/drivers/crypto/caam/jr.c
index 757c27f9953d..7331ea734f37 100644
--- a/drivers/crypto/caam/jr.c
+++ b/drivers/crypto/caam/jr.c
@@ -489,7 +489,7 @@ static int caam_jr_probe(struct platform_device *pdev)
return -ENOMEM;
}
- jrpriv->rregs = (struct caam_job_ring __force *)ctrl;
+ jrpriv->rregs = (struct caam_job_ring __iomem __force *)ctrl;
if (sizeof(dma_addr_t) == sizeof(u64))
if (of_device_is_compatible(nprop, "fsl,sec-v5.0-job-ring"))
--
2.4.4
^ permalink raw reply related
* Re: [PATCH 2/2] kthread: don't use to_live_kthread() in kthread_park() and kthread_unpark()
From: Thomas Gleixner @ 2016-11-09 8:45 UTC (permalink / raw)
To: Oleg Nesterov
Cc: Andy Lutomirski, Roman Pen, Andy Lutomirski, Peter Zijlstra,
Ingo Molnar, Tejun Heo, linux-kernel@vger.kernel.org,
Chunming Zhou, Alex Deucher
In-Reply-To: <20161031200823.GC19430@redhat.com>
On Mon, 31 Oct 2016, Oleg Nesterov wrote:
> I think we need to unexport kthread_park/unpark, and either make it return
> "void" or actually fix the race with kthred_stop/exit. This patch just adds
> WARN_ON(PF_EXITING) for now.
I'll have a look.
> The usage of kthread_park() in cpuhp code (cpu.c, smpboot.c, stop_machine.c)
> is fine. It can never see an exiting/exited kthread, smpboot_destroy_threads()
> clears *ht->store, smpboot_park_thread() checks it is not NULL under the same
> smpboot_threads_lock. cpuhp_threads and cpu_stop_threads never exit, so other
> callers are fine too.
>
> But it has two more users:
>
> - watchdog_park_threads() and it does not look nice. The code is actually
> correct, get_online_cpus() ensures that kthread_park() can't race with
> itself (note that kthread_park() can't handle this race correctly), but
> imo it should not use kthread_park() directly.
Should we provide an interface through the smpboot thread infrastructure for
this?
> - drivers/gpu/drm/amd/scheduler/gpu_scheduler.c and I think it should not
> use kthread_park() too.
>
> But this patch should not break this code. kthread_park() must not be
> called after amd_sched_fini() which does kthread_stop(), otherwise even
> to_live_kthread() is not safe because task_struct can be already freed
> and sched->thread can point to nowhere.
Right. That's why the smpboot thread code holds a task ref which is only
released after the thread has been stopped.
I can see why that gpu driver wants to use the park mechanism and I guess
there are other legitimate use cases as well. I prefer to implement a
park/unpark variant which is safe to use on arbitrary kthreads over forcing
driver writers to come up with even more broken open coded implementations
of that.
> Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
^ permalink raw reply
* Re: Patch "scsi: megaraid_sas: Fix data integrity failure for JBOD (passthrough) devices" has been added to the 4.8-stable tree
From: Greg KH @ 2016-11-09 8:49 UTC (permalink / raw)
To: Sumit Saxena
Cc: Kashyap Desai, emilne, hare, martin.petersen, thenzl, stable,
stable-commits
In-Reply-To: <a48ab14b1e168f2bee2fcc75f3f440ff@mail.gmail.com>
On Wed, Nov 09, 2016 at 02:15:10PM +0530, Sumit Saxena wrote:
> >-----Original Message-----
> >From: gregkh@linuxfoundation.org [mailto:gregkh@linuxfoundation.org]
> >Sent: Wednesday, November 09, 2016 1:49 PM
> >To: kashyap.desai@broadcom.com; emilne@redhat.com;
> >gregkh@linuxfoundation.org; hare@suse.com; martin.petersen@oracle.com;
> >sumit.saxena@broadcom.com; thenzl@redhat.com
> >Cc: stable@vger.kernel.org; stable-commits@vger.kernel.org
> >Subject: Patch "scsi: megaraid_sas: Fix data integrity failure for JBOD
> >(passthrough) devices" has been added to the 4.8-stable tree
> >
> >
> >This is a note to let you know that I've just added the patch titled
> >
> > scsi: megaraid_sas: Fix data integrity failure for JBOD (passthrough)
> devices
> >
> >to the 4.8-stable tree which can be found at:
> > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-
> >queue.git;a=summary
> >
> >The filename of the patch is:
> > scsi-megaraid_sas-fix-data-integrity-failure-for-jbod-passthrough-
> >devices.patch
> >and it can be found in the queue-4.8 subdirectory.
> >
> >If you, or anyone else, feels it should not be added to the stable tree,
> please let
> ><stable@vger.kernel.org> know about it.
>
> There will be follow up patch which I will be sending in sometime so
> follow patch needs to be applied along with this patch.
Does that mean that this patch on its own is broken?
confused,
greg k-h
^ permalink raw reply
* [PATCH] arm64: dts: marvell: add unique identifiers for Armada A8k SPI controllers
From: Marcin Wojtas @ 2016-11-09 8:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8737j1m44b.fsf@free-electrons.com>
Thanks a lot!
Marcin
2016-11-09 9:47 GMT+01:00 Gregory CLEMENT <gregory.clement@free-electrons.com>:
> Hi Marcin,
>
> On mar., nov. 08 2016, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:
>
>> Hello,
>>
>> On Tue, 8 Nov 2016 17:31:32 +0100, Marcin Wojtas wrote:
>>> Enabling SPI controllers, which are attached to different busses
>>> inside an SoC, may result in overlapping enumeration and cause
>>> sysfs registration failure. Example log after enabling two
>>> controllers on Armada 8040 SoC with same identifiers:
>>>
>>> [ 3.740415] sysfs: cannot create duplicate filename
>>> '/class/spi_master/spi0'
>>> [ 3.747510] ------------[ cut here ]------------
>>> [ 3.752145] WARNING: at fs/sysfs/dir.c:31
>>> [...]
>>> [ 4.002299] orion_spi: probe of f4700600.spi failed with error -17
>>>
>>> spi-orion driver offers dedicated DT property ('cell-index'), that
>>> allow setting unique identifiers. Recently added support for CP110-slave
>>> HW block introduced two new SPI controllers' nodes with same ID as
>>> ones from CP110-master.
>>>
>>> This commit fixes the issue by assigning different 'cell-index' values
>>> for CP110-slave SPI controllers.
>>>
>>> Fixes: 4eef78a0091b ("arm64: dts: marvell: add description for the slave
>>> CP110 in Armada 8K")
>>> Signed-off-by: Marcin Wojtas <mw@semihalf.com>
>>
>> It's sad that we need to hardcode those indexes in the Device Tree
>> (which by no means are a description of the HW by the way), but that's
>> what the SPI framework expects I believe. Therefore:
>>
>> Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>
>
> Applied on mvebu/fixes with acked-by from Thomas.
> In the same time I also applied "arm64: dts: marvell: fix clocksource
> for CP110 slave SPI0" which didn't find his way to mainline yet.
>
> Thanks,
>
> Gregory
>
>
>>
>> Thomas
>> --
>> Thomas Petazzoni, CTO, Free Electrons
>> Embedded Linux and Kernel engineering
>> http://free-electrons.com
>
> --
> Gregory Clement, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com
^ permalink raw reply
* Re: [PATCH] arm64: dts: marvell: add unique identifiers for Armada A8k SPI controllers
From: Marcin Wojtas @ 2016-11-09 8:50 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Thomas Petazzoni, linux-kernel,
linux-arm-kernel@lists.infradead.org, Sebastian Hesselbarth,
Andrew Lunn, Jason Cooper, Will Deacon, Rob Herring, Mark Rutland,
nadavh, Lior Amsalem, jaz@semihalf.com, Tomasz Nowicki
In-Reply-To: <8737j1m44b.fsf@free-electrons.com>
Thanks a lot!
Marcin
2016-11-09 9:47 GMT+01:00 Gregory CLEMENT <gregory.clement@free-electrons.com>:
> Hi Marcin,
>
> On mar., nov. 08 2016, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:
>
>> Hello,
>>
>> On Tue, 8 Nov 2016 17:31:32 +0100, Marcin Wojtas wrote:
>>> Enabling SPI controllers, which are attached to different busses
>>> inside an SoC, may result in overlapping enumeration and cause
>>> sysfs registration failure. Example log after enabling two
>>> controllers on Armada 8040 SoC with same identifiers:
>>>
>>> [ 3.740415] sysfs: cannot create duplicate filename
>>> '/class/spi_master/spi0'
>>> [ 3.747510] ------------[ cut here ]------------
>>> [ 3.752145] WARNING: at fs/sysfs/dir.c:31
>>> [...]
>>> [ 4.002299] orion_spi: probe of f4700600.spi failed with error -17
>>>
>>> spi-orion driver offers dedicated DT property ('cell-index'), that
>>> allow setting unique identifiers. Recently added support for CP110-slave
>>> HW block introduced two new SPI controllers' nodes with same ID as
>>> ones from CP110-master.
>>>
>>> This commit fixes the issue by assigning different 'cell-index' values
>>> for CP110-slave SPI controllers.
>>>
>>> Fixes: 4eef78a0091b ("arm64: dts: marvell: add description for the slave
>>> CP110 in Armada 8K")
>>> Signed-off-by: Marcin Wojtas <mw@semihalf.com>
>>
>> It's sad that we need to hardcode those indexes in the Device Tree
>> (which by no means are a description of the HW by the way), but that's
>> what the SPI framework expects I believe. Therefore:
>>
>> Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>
>
> Applied on mvebu/fixes with acked-by from Thomas.
> In the same time I also applied "arm64: dts: marvell: fix clocksource
> for CP110 slave SPI0" which didn't find his way to mainline yet.
>
> Thanks,
>
> Gregory
>
>
>>
>> Thomas
>> --
>> Thomas Petazzoni, CTO, Free Electrons
>> Embedded Linux and Kernel engineering
>> http://free-electrons.com
>
> --
> Gregory Clement, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com
^ permalink raw reply
* Re: [PATCH v2 1/2] pinctrl: sunxi: Add support for interrupt debouncing
From: Linus Walleij @ 2016-11-09 8:50 UTC (permalink / raw)
To: Maxime Ripard
Cc: Alexandre Courbot,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring,
Chen-Yu Tsai
In-Reply-To: <7dbb47b16d83b843705aa05d4a5f1f7dfdc4e9a3.1478636546.git-series.maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On Tue, Nov 8, 2016 at 9:24 PM, Maxime Ripard
<maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> The pin controller found in the Allwinner SoCs has support for interrupts
> debouncing.
>
> However, this is not done per-pin, preventing us from using the generic
> pinconf binding for that, but per irq bank, which, depending on the SoC,
> ranges from one to five.
>
> Introduce a device-wide property to deal with this using a microsecond
> resolution. We can re-use the per-pin input-debounce property for that, so
> let's do it!
>
> Signed-off-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
I like this! Minor nits inline:
> +- clocks: phandle to the clocks feeding the pin controller:
> + - "apb": the gated APB parent clock
> + - "hosc": the high frequency oscillator in the system
> + - "losc": the low frequency oscillator in the system
> +
> +Note: For backward compatibility reasons, the hosc and losc clocks are only
> +required if you need to use the optional input-debounce property. Any new
> +device tree should set them.
> +
> +Optional properties:
> + - input-debounce: Array of debouncing periods in microseconds. One period per
> + irq bank found in the controller
Looks good to me. Cutting the DT people some slack to look at this
before merging.
> +static int sunxi_pinctrl_compute_debounce(struct clk *clk, int freq, int *diff)
> +{
> + unsigned long clock = clk_get_rate(clk);
> + unsigned int best_diff = ~0, best_div;
> + int i;
> +
> + for (i = 0; i < 8; i++) {
> + int cur_diff = abs(freq - (clock >> i));
> +
> + if (cur_diff < best_diff) {
> + best_diff = cur_diff;
> + best_div = i;
> + }
> + }
> +
> + *diff = best_diff;
> + return best_div;
> +}
Kerneldoc or function name should reflect that what this function
does is to find the best divisor.
> +static int sunxi_pinctrl_setup_debounce(struct sunxi_pinctrl *pctl,
> + struct device_node *node)
> +{
> + unsigned int hosc_diff, losc_diff;
> + unsigned int hosc_div, losc_div;
> + struct clk *hosc, *losc;
> + u8 div, src;
> + int i, ret;
> +
> + /* Deal with old DTs that didn't have the oscillators */
> + if (of_count_phandle_with_args(node, "clocks", "#clock-cells") != 3)
> + return 0;
Clever, nice.
> + /* If we don't have any setup, bail out */
> + if (!of_find_property(node, "input-debounce", NULL))
> + return 0;
> +
> + losc = devm_clk_get(pctl->dev, "losc");
> + if (IS_ERR(losc))
> + return PTR_ERR(losc);
> +
> + hosc = devm_clk_get(pctl->dev, "hosc");
> + if (IS_ERR(hosc))
> + return PTR_ERR(hosc);
> +
> + for (i = 0; i < pctl->desc->irq_banks; i++) {
> + unsigned long debounce_freq;
> + u32 debounce;
> +
> + ret = of_property_read_u32_index(node, "input-debounce",
> + i, &debounce);
> + if (ret)
> + return ret;
> +
> + debounce_freq = USEC_PER_SEC / debounce;
Arithmetics! Would you like to use
DIV_ROUND_UP()? or DIV_ROUND_CLOSEST()?
Apart from that I like this patch a lot.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [Bug 98638] Panic on shutdown with AMDGPU and Ubuntu Plymouth
From: bugzilla-daemon @ 2016-11-09 8:51 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-98638-502@http.bugs.freedesktop.org/>
[-- Attachment #1.1: Type: text/plain, Size: 322 bytes --]
https://bugs.freedesktop.org/show_bug.cgi?id=98638
--- Comment #3 from Michel Dänzer <michel@daenzer.net> ---
The bootsplash doesn't (directly) affect netconsole though, does it? Can you
try getting more complete output from netconsole?
--
You are receiving this mail because:
You are the assignee for the bug.
[-- Attachment #1.2: Type: text/html, Size: 1104 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [PATCH v2 0/3] ASoC: intel: atom: Add FW version information
From: Sebastien Guiriec @ 2016-11-09 8:47 UTC (permalink / raw)
To: alsa-devel, vinod.koul, pierre-louis.bossart, liam.r.girdwood
Cc: Sebastien Guiriec
This patch series is adding FW version information of SST. Version is both
log as dev_info and sysfs entry.
Update since V1:
- sysfs entry is set to "FW not yet loaded" in case we do not have
loaded the FW once
Sebastien Guiriec (3):
ASoC: intel: atom: Add debug information related to FW version
ASoC: Intel: atom: save FW version
ASoC: Intel: atom: Add sysfs entry in order to store FW version
sound/soc/intel/atom/sst/sst.c | 39 ++++++++++++++++++++++++++++++++++++++
sound/soc/intel/atom/sst/sst.h | 1 +
sound/soc/intel/atom/sst/sst_ipc.c | 10 +++++++++-
3 files changed, 49 insertions(+), 1 deletion(-)
--
2.9.3
---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris,
92196 Meudon Cedex, France
Registration Number: 302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
^ permalink raw reply
* [PATCH v2 1/3] ASoC: intel: atom: Add debug information related to FW version
From: Sebastien Guiriec @ 2016-11-09 8:47 UTC (permalink / raw)
To: alsa-devel, vinod.koul, pierre-louis.bossart, liam.r.girdwood
Cc: Sebastien Guiriec
In-Reply-To: <20161109084736.28265-1-sebastien.guiriec@intel.com>
This patch is adding debug information related to SST FW version.
Signed-off-by: Sebastien Guiriec <sebastien.guiriec@intel.com>
---
sound/soc/intel/atom/sst/sst_ipc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/sound/soc/intel/atom/sst/sst_ipc.c b/sound/soc/intel/atom/sst/sst_ipc.c
index 8afa6fe..92ffeaa 100644
--- a/sound/soc/intel/atom/sst/sst_ipc.c
+++ b/sound/soc/intel/atom/sst/sst_ipc.c
@@ -236,6 +236,9 @@ static void process_fw_init(struct intel_sst_drv *sst_drv_ctx,
retval = init->result;
goto ret;
}
+ dev_info(sst_drv_ctx->dev, "FW Version %02x.%02x.%02x.%02x\n",
+ init->fw_version.type, init->fw_version.major,
+ init->fw_version.minor, init->fw_version.build);
ret:
sst_wake_up_block(sst_drv_ctx, retval, FW_DWNL_ID, 0 , NULL, 0);
--
2.9.3
---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris,
92196 Meudon Cedex, France
Registration Number: 302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
^ permalink raw reply related
* [PATCH v2 2/3] ASoC: Intel: atom: save FW version
From: Sebastien Guiriec @ 2016-11-09 8:47 UTC (permalink / raw)
To: alsa-devel, vinod.koul, pierre-louis.bossart, liam.r.girdwood
Cc: Sebastien Guiriec
In-Reply-To: <20161109084736.28265-1-sebastien.guiriec@intel.com>
After the boot of the SST FW the firmware version is send back
to the driver. This patch is saving the FW version inside the
driver.
Signed-off-by: Sebastien Guiriec <sebastien.guiriec@intel.com>
---
sound/soc/intel/atom/sst/sst.h | 1 +
sound/soc/intel/atom/sst/sst_ipc.c | 5 +++++
2 files changed, 6 insertions(+)
diff --git a/sound/soc/intel/atom/sst/sst.h b/sound/soc/intel/atom/sst/sst.h
index 3f49386..5c9a51cc 100644
--- a/sound/soc/intel/atom/sst/sst.h
+++ b/sound/soc/intel/atom/sst/sst.h
@@ -436,6 +436,7 @@ struct intel_sst_drv {
*/
char firmware_name[FW_NAME_SIZE];
+ struct snd_sst_fw_version fw_version;
struct sst_fw_save *fw_save;
};
diff --git a/sound/soc/intel/atom/sst/sst_ipc.c b/sound/soc/intel/atom/sst/sst_ipc.c
index 92ffeaa..8e88211 100644
--- a/sound/soc/intel/atom/sst/sst_ipc.c
+++ b/sound/soc/intel/atom/sst/sst_ipc.c
@@ -240,6 +240,11 @@ static void process_fw_init(struct intel_sst_drv *sst_drv_ctx,
init->fw_version.type, init->fw_version.major,
init->fw_version.minor, init->fw_version.build);
+ /* Save FW version */
+ sst_drv_ctx->fw_version.type = init->fw_version.type;
+ sst_drv_ctx->fw_version.major = init->fw_version.major;
+ sst_drv_ctx->fw_version.minor = init->fw_version.minor;
+ sst_drv_ctx->fw_version.build = init->fw_version.build;
ret:
sst_wake_up_block(sst_drv_ctx, retval, FW_DWNL_ID, 0 , NULL, 0);
}
--
2.9.3
---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris,
92196 Meudon Cedex, France
Registration Number: 302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
^ permalink raw reply related
* [PATCH v2 3/3] ASoC: Intel: atom: Add sysfs entry in order to store FW version
From: Sebastien Guiriec @ 2016-11-09 8:47 UTC (permalink / raw)
To: alsa-devel, vinod.koul, pierre-louis.bossart, liam.r.girdwood
Cc: Sebastien Guiriec
In-Reply-To: <20161109084736.28265-1-sebastien.guiriec@intel.com>
This patch is adding a sysfs entry in order to be able to get
access to SST FW version.
Signed-off-by: Sebastien Guiriec <sebastien.guiriec@intel.com>
---
sound/soc/intel/atom/sst/sst.c | 39 +++++++++++++++++++++++++++++++++++++++
1 file changed, 39 insertions(+)
diff --git a/sound/soc/intel/atom/sst/sst.c b/sound/soc/intel/atom/sst/sst.c
index a4b458e..9d35706 100644
--- a/sound/soc/intel/atom/sst/sst.c
+++ b/sound/soc/intel/atom/sst/sst.c
@@ -27,6 +27,7 @@
#include <linux/pm_qos.h>
#include <linux/async.h>
#include <linux/acpi.h>
+#include <linux/sysfs.h>
#include <sound/core.h>
#include <sound/soc.h>
#include <asm/platform_sst_audio.h>
@@ -241,6 +242,32 @@ int sst_alloc_drv_context(struct intel_sst_drv **ctx,
}
EXPORT_SYMBOL_GPL(sst_alloc_drv_context);
+static ssize_t firmware_version_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct intel_sst_drv *ctx = dev_get_drvdata(dev);
+
+ if (ctx->fw_version.type == 0 && ctx->fw_version.major == 0 &&
+ ctx->fw_version.minor == 0 && ctx->fw_version.build == 0)
+ return sprintf(buf, "FW not yet loaded\n");
+ else
+ return sprintf(buf, "v%02x.%02x.%02x.%02x\n",
+ ctx->fw_version.type, ctx->fw_version.major,
+ ctx->fw_version.minor, ctx->fw_version.build);
+
+}
+
+DEVICE_ATTR_RO(firmware_version);
+
+static const struct attribute *sst_fw_version_attrs[] = {
+ &dev_attr_firmware_version.attr,
+ NULL,
+};
+
+static const struct attribute_group sst_fw_version_attr_group = {
+ .attrs = (struct attribute **)sst_fw_version_attrs,
+};
+
int sst_context_init(struct intel_sst_drv *ctx)
{
int ret = 0, i;
@@ -314,8 +341,19 @@ int sst_context_init(struct intel_sst_drv *ctx)
dev_err(ctx->dev, "Firmware download failed:%d\n", ret);
goto do_free_mem;
}
+
+ ret = sysfs_create_group(&ctx->dev->kobj,
+ &sst_fw_version_attr_group);
+ if (ret) {
+ dev_err(ctx->dev,
+ "Unable to create sysfs\n");
+ goto err_sysfs;
+ }
+
sst_register(ctx->dev);
return 0;
+err_sysfs:
+ sysfs_remove_group(&ctx->dev->kobj, &sst_fw_version_attr_group);
do_free_mem:
destroy_workqueue(ctx->post_msg_wq);
@@ -329,6 +367,7 @@ void sst_context_cleanup(struct intel_sst_drv *ctx)
pm_runtime_disable(ctx->dev);
sst_unregister(ctx->dev);
sst_set_fw_state_locked(ctx, SST_SHUTDOWN);
+ sysfs_remove_group(&ctx->dev->kobj, &sst_fw_version_attr_group);
flush_scheduled_work();
destroy_workqueue(ctx->post_msg_wq);
pm_qos_remove_request(ctx->qos);
--
2.9.3
---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris,
92196 Meudon Cedex, France
Registration Number: 302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
^ permalink raw reply related
* Re: [PATCH 8/9] xfs: fuzz every field of every structure
From: Darrick J. Wong @ 2016-11-09 8:52 UTC (permalink / raw)
To: Eryu Guan; +Cc: david, linux-xfs, fstests
In-Reply-To: <20161109080924.GT27776@eguan.usersys.redhat.com>
On Wed, Nov 09, 2016 at 04:09:24PM +0800, Eryu Guan wrote:
> On Fri, Nov 04, 2016 at 05:18:00PM -0700, Darrick J. Wong wrote:
> > Previously, our XFS fuzzing efforts were limited to using the xfs_db
> > blocktrash command to scribble garbage all over a block. This is
> > pretty easy to discover; it would be far more interesting if we could
> > fuzz individual fields looking for unhandled corner cases. Since we
> > now have an online scrub tool, use it to check for our targeted
> > corruptions prior to the usual steps of writing to the FS, taking it
> > offline, repairing, and re-checking.
> >
> > These tests use the new xfs_db 'fuzz' command to test corner case
> > handling of every field. The 'print' command tells us which fields
> > are available, and the fuzz command can write zeroes or ones to the
> > field; set the high, middle, or low bit; add or subtract numbers; or
> > randomize the field. We loop through all fields and all fuzz verbs to
> > see if we can trip up the kernel.
> >
> > Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
>
> The first test gave me a kernel crash :) xfs/1300 crashed your kernel
> djwong-devel branch. I appended the console log at the end of this mail
> if you have interest to see it.
>
> And another xfs/1300 run gave me this failure message:
>
> +/mnt/testarea/scratch: Kernel lacks GETFSMAP; scrub will be less efficient. (xfs.c line 661)
> +/mnt/testarea/scratch: Kernel cannot help scrub metadata; scrub will be incomplete. (xfs.c line 661)
> +/mnt/testarea/scratch: Kernel cannot help scrub inodes; scrub will be incomplete. (xfs.c line 661)
> +/mnt/testarea/scratch: Kernel cannot help scrub extent map; scrub will be less efficient. (xfs.c line 661)
>
> Is this known issue or something should be filtered out in the test?
That's strange, the djwong-devel branch should have getfsmap & scrub in it...
...are you running the djwong-devel kernel and xfsprogs code? The scrub
ioctl structure has shifted some over the past few months, though GETFSMAP
hasn't changed in ages.
Wait, "another xfs/1300 run" ... so after the first crash, did you go
back to a vanilla kernel without all my crazypatches? :)
> And ext4/1300 generated large .out.bad file (51M), containing something
> like:
>
> +/mnt/testarea/scratch/test/68/S_IFREG.FMT_ETREE: extent (1101381632/2469888/4096) ends past end of filesystem at 31457280. (generic.c line 272)
> +/mnt/testarea/scratch/test/68/S_IFREG.FMT_ETREE: extent (1101389824/2478080/4096) starts past end of filesystem at 31457280. (generic.c line 264)
> +/mnt/testarea/scratch/test/68/S_IFREG.FMT_ETREE: extent (1101389824/2478080/4096) ends past end of filesystem at 31457280. (generic.c line 272)
> +/mnt/testarea/scratch/test/68/S_IFREG.FMT_ETREE: extent (1101398016/2486272/4096) starts past end of filesystem at 31457280. (generic.c line 264)
> +/mnt/testarea/scratch/test/68/S_IFREG.FMT_ETREE: extent (1101398016/2486272/4096) ends past end of filesystem at 31457280. (generic.c line 272)
> +/mnt/testarea/scratch/test/68/S_IFREG.FMT_ETREE: extent (1101406208/2494464/4096) starts past end of filesystem at 31457280. (generic.c line 264)
> +/mnt/testarea/scratch/test/68/S_IFREG.FMT_ETREE: extent (1101406208/2494464/4096) ends past end of filesystem at 31457280. (generic.c line 272)
> +/mnt/testarea/scratch/test/68/S_IFREG.FMT_ETREE: extent (1101414400/2502656/4096) starts past end of filesystem at 31457280. (generic.c line 264)
> +/mnt/testarea/scratch/test/68/S_IFREG.FMT_ETREE: extent (1101414400/2502656/4096) ends past end of filesystem at 31457280. (generic.c line 272)
>
> Seems like scrub found something wrong (real problems) and became very
> noisy?
Hmm that's even stranger. I'll try to reproduce tomorrow.
> More comments inline below.
>
> > ---
> > common/fuzzy | 49 ++++++++++++++++++++++++++++++------
> > common/populate | 10 ++++---
> > common/rc | 15 +++++++++++
> > tests/ext4/1300 | 60 ++++++++++++++++++++++++++++++++++++++++++++
> [snip]
> >
> > diff --git a/common/fuzzy b/common/fuzzy
> > index 6af47f1..dbff744 100644
> > --- a/common/fuzzy
> > +++ b/common/fuzzy
> > @@ -85,32 +85,47 @@ _scratch_scrub() {
> > # Filter the xfs_db print command's field debug information
> > # into field name and type.
> > __filter_xfs_db_print_fields() {
> > + filter="$1"
> > + if [ -z "${filter}" ] || [ "${filter}" = "nofilter" ]; then
> > + filter='^'
> > + fi
> > grep ' = ' | while read key equals value; do
> > - fuzzkey="$(echo "${key}" | sed -e 's/\([a-zA-Z0-9_]*\)\[\([0-9]*\)-[0-9]*\]/\1[\2]/g')"
> > - if [[ "${value}" == "["* ]]; then
> > + # Filter out any keys with an array index >= 10, and
> > + # collapse any array range ("[1-195]") to the first item.
> > + fuzzkey="$(echo "${key}" | sed -e '/\([a-z]*\)\[\([0-9][0-9]\+\)\].*/d' -e 's/\([a-zA-Z0-9_]*\)\[\([0-9]*\)-[0-9]*\]/\1[\2]/g')"
> > + if [ -z "${fuzzkey}" ]; then
> > + continue
> > + elif [[ "${value}" == "["* ]]; then
> > echo "${value}" | sed -e 's/^.//g' -e 's/.$//g' -e 's/,/\n/g' | while read subfield; do
> > echo "${fuzzkey}.${subfield}"
> > done
> > else
> > echo "${fuzzkey}"
> > fi
> > - done
> > + done | egrep "${filter}"
> > }
> >
> > # Navigate to some part of the filesystem and print the field info.
> > +# The first argument is an egrep filter for the fields
> > +# The rest of the arguments are xfs_db commands to locate the metadata.
> > _scratch_xfs_list_metadata_fields() {
> > + filter="$1"
> > + shift
> > if [ -n "${SCRATCH_XFS_LIST_METADATA_FIELDS}" ]; then
> > - echo "${SCRATCH_XFS_LIST_METADATA_FIELDS}" | sed -e 's/ /\n/g'
> > + echo "${SCRATCH_XFS_LIST_METADATA_FIELDS}" | \
> > + sed -e 's/ /\n/g' | __filter_xfs_db_print_fields "${filter}"
> > return;
> > fi
> >
> > (for arg in "$@"; do
> > echo "${arg}"
> > done
> > - echo "print") | _scratch_xfs_db | __filter_xfs_db_print_fields
> > + echo "print") | _scratch_xfs_db | __filter_xfs_db_print_fields "${filter}"
> > }
> >
> > # Get a metadata field
> > +# The first arg is the field name
> > +# The rest of the arguments are xfs_db commands to find the metadata.
> > _scratch_xfs_get_metadata_field() {
> > key="$1"
> > shift
> > @@ -124,6 +139,9 @@ _scratch_xfs_get_metadata_field() {
> > }
> >
> > # Set a metadata field
> > +# The first arg is the field name
> > +# The second arg is the new value
> > +# The rest of the arguments are xfs_db commands to find the metadata.
> > _scratch_xfs_set_metadata_field() {
> > key="$1"
> > value="$2"
> > @@ -136,6 +154,9 @@ _scratch_xfs_set_metadata_field() {
> > }
> >
> > # Fuzz a metadata field
> > +# The first arg is the field name
> > +# The second arg is the xfs_db fuzz verb
> > +# The rest of the arguments are xfs_db commands to find the metadata.
> > _scratch_xfs_fuzz_metadata_field() {
> > key="$1"
> > value="$2"
> > @@ -263,12 +284,24 @@ _scratch_xfs_list_fuzz_verbs() {
> > sed -e 's/[,.]//g' -e 's/Verbs: //g' -e 's/ /\n/g'
> > }
> >
> > -# Fuzz the fields of some piece of metadata
> > -_scratch_xfs_fuzz_fields() {
> > - _scratch_xfs_list_metadata_fields "$@" | while read field; do
> > +# Fuzz some of the fields of some piece of metadata
> > +# The first argument is an egrep filter
> > +# The rest of the arguments are xfs_db commands to locate the metadata.
> > +_scratch_xfs_fuzz_some_fields() {
> > + filter="$1"
> > + shift
> > + echo "Fields we propose to fuzz: $@"
> > + _scratch_xfs_list_metadata_fields "${filter}" "$@"
> > + _scratch_xfs_list_metadata_fields "${filter}" "$@" | while read field; do
> > _scratch_xfs_list_fuzz_verbs | while read fuzzverb; do
> > __scratch_xfs_fuzz_mdrestore
> > __scratch_xfs_fuzz_field_test "${field}" "${fuzzverb}" "$@"
> > done
> > done
> > }
> > +
> > +# Fuzz all of the fields of some piece of metadata
> > +# All arguments are xfs_db commands to locate the metadata.
> > +_scratch_xfs_fuzz_fields() {
> > + _scratch_xfs_fuzz_some_fields '' "$@"
> > +}
>
> I think all the fuzz update here should be folded to patch 7/9.
(I'll look at the patch fixes in a separate reply tomorrow.)
> > diff --git a/common/populate b/common/populate
> > index 15d68fc..7d103f0 100644
> > --- a/common/populate
> > +++ b/common/populate
> > @@ -180,13 +180,13 @@ _scratch_xfs_populate() {
> > # FMT_EXTENTS with a remote less-than-a-block value
> > echo "+ attr extents with a remote less-than-a-block value"
> > touch "${SCRATCH_MNT}/ATTR.FMT_EXTENTS_REMOTE3K"
> > - $XFS_IO_PROG -f -c "pwrite -S 0x43 0 3k" "${SCRATCH_MNT}/attrvalfile" > /dev/null
> > + $XFS_IO_PROG -f -c "pwrite -S 0x43 0 $((blksz - 300))" "${SCRATCH_MNT}/attrvalfile" > /dev/null
> > attr -q -s user.remotebtreeattrname "${SCRATCH_MNT}/ATTR.FMT_EXTENTS_REMOTE3K" < "${SCRATCH_MNT}/attrvalfile"
> >
> > # FMT_EXTENTS with a remote block-size value
> > echo "+ attr extents with a remote one-block value"
> > touch "${SCRATCH_MNT}/ATTR.FMT_EXTENTS_REMOTE4K"
> > - $XFS_IO_PROG -f -c "pwrite -S 0x44 0 4k" "${SCRATCH_MNT}/attrvalfile" > /dev/null
> > + $XFS_IO_PROG -f -c "pwrite -S 0x44 0 ${blksz}" "${SCRATCH_MNT}/attrvalfile" > /dev/null
> > attr -q -s user.remotebtreeattrname "${SCRATCH_MNT}/ATTR.FMT_EXTENTS_REMOTE4K" < "${SCRATCH_MNT}/attrvalfile"
> > rm -rf "${SCRATCH_MNT}/attrvalfile"
> >
> > @@ -482,8 +482,8 @@ _scratch_xfs_populate_check() {
> > __populate_check_xfs_aformat "${btree_attr}" "btree"
> > __populate_check_xfs_agbtree_height "bno"
> > __populate_check_xfs_agbtree_height "cnt"
> > - test -n $is_rmapbt && __populate_check_xfs_agbtree_height "rmap"
> > - test -n $is_reflink && __populate_check_xfs_agbtree_height "refcnt"
> > + test $is_rmapbt -ne 0 && __populate_check_xfs_agbtree_height "rmap"
> > + test $is_reflink -ne 0 && __populate_check_xfs_agbtree_height "refcnt"
> > }
>
> And these folded to patch 1/9?
>
> >
> > # Check data fork format of ext4 file
> > @@ -609,7 +609,7 @@ _scratch_populate_cached() {
> > rm -rf "$(find "${POPULATE_METADUMP}" -mtime +2 2>/dev/null)"
> >
> > # Throw away cached image if it doesn't match our spec.
> > - meta_descr="FSTYP ${FSTYP} MKFS_OPTIONS ${MKFS_OPTIONS} ARGS $@"
> > + meta_descr="FSTYP ${FSTYP} MKFS_OPTIONS $(_scratch_mkfs_options) ARGS $@"
> > cmp -s "${POPULATE_METADUMP_DESCR}" <(echo "${meta_descr}") || rm -rf "${POPULATE_METADUMP}"
> >
> > # Do we have a cached image?
>
> This to patch 6/9?
>
> Because we usually don't introduce something in patch 1 and fix them in
> patch 2, I think :)
Generally, yes. :)
> > diff --git a/common/rc b/common/rc
> > index d904582..ec1f5de 100644
> > --- a/common/rc
> > +++ b/common/rc
> > @@ -1870,6 +1870,21 @@ _require_xfs_finobt()
> > _scratch_unmount
> > }
> >
> > +# Do we have a fre
> > +_require_scratch_finobt()
> > +{
> > + _require_scratch
> > +
> > + if [ $FSTYP != "xfs" ]; then
> > + _notrun "finobt not supported by scratch filesystem type: $FSTYP"
> > + return
> > + fi
> > + _scratch_mkfs > /dev/null
> > + _scratch_mount
> > + xfs_info $SCRATCH_MNT | grep -q 'finobt=1' || _notrun "finobt not supported by scratch filesystem type: $FSTYP"
> > + _scratch_unmount
> > +}
> > +
> > # this test requires xfs sysfs attribute support
> > #
> > _require_xfs_sysfs()
> > diff --git a/tests/ext4/1300 b/tests/ext4/1300
> > new file mode 100755
> > index 0000000..3f8135e
> > --- /dev/null
> > +++ b/tests/ext4/1300
>
> [all the tests look fine to me, snip]
>
> > --- a/tests/xfs/group
> > +++ b/tests/xfs/group
> > @@ -333,3 +333,34 @@
> > 345 auto quick clone
> > 346 auto quick clone
> > 347 auto quick clone
> > +1300 dangerous_fuzzers scrub
>
> ext4/1300 is "auto quick scrub", I think xfs/1300 should be in auto
> group too?
>
> Thanks,
> Eryu
>
> P.S. console log of xfs/1300 crash
>
> [165877.766244] BUG: unable to handle kernel NULL pointer dereference at 0000000000000038
> [165877.774197] IP: [<ffffffffa0680c13>] xfs_scrub_get_inode+0xc3/0x1c0 [xfs]
> [165877.781162] PGD 179c1b067 [165877.783784] PUD 14d994067
Ohhh... I suspect this happens when xfs_scrub_op_ok tries to use sc->tp
after some error happens, which we can't do because this function is
used in the process of initializing sc.
Gonna go cry in my beer for a day or two or something,
--D
> PMD 0 [165877.787130]
> [165877.788722] Oops: 0000 [#1] SMP
> [165877.791951] Modules linked in: dm_delay dm_zero btrfs xor raid6_pq dm_thin_pool dm_persistent_data dm_bio_prison dm_snapshot dm_bufio loop dm_flakey xfs libcrc32c binfmt_misc ip6t_rpfilter ipt_REJECT nf_reject_ipv4 nf_conntrack_ipv4 nf_defrag_ipv4 ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 xt_conntrack nf_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge stp llc ip6table_mangle ip6table_security ip6table_raw iptable_mangle iptable_security iptable_raw ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter coretemp kvm_intel kvm irqbypass crc32_pclmul ghash_clmulni_intel aesni_intel lrw iTCO_wdt gf128mul glue_helper ipmi_devintf cdc_ether iTCO_vendor_support ablk_helper cryptd usbnet i2c_i801 lpc_ich mii pcspkr i2c_smbus sg i7core_edac mfd_core ipmi_si edac_core ipmi_msghandler shpchp ioatdma dca acpi_cpufreq nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables ext4 jbd2 mbcache sr_mod sd_mod cdrom mgag200 i2c_algo_bit drm_kms_hel!
pe!
> r syscopyarea sysfillrect sysimgblt fb_sys_fops ttm ata_generic pata_acpi drm ata_piix libata crc32c_intel megaraid_sas serio_raw i2c_core bnx2 dm_mirror dm_region_hash dm_log dm_mod [last unloaded: scsi_debug]
> [165877.898708] CPU: 5 PID: 26242 Comm: xfs_scrub Tainted: G W 4.9.0-rc3.djwong+ #16
> [165877.907308] Hardware name: IBM System x3550 M3 -[7944OEJ]-/90Y4784 , BIOS -[D6E150CUS-1.11]- 02/08/2011
> [165877.917124] task: ffff88017a286a40 task.stack: ffffc9000cca0000
> [165877.923126] RIP: 0010:[<ffffffffa0680c13>] [<ffffffffa0680c13>] xfs_scrub_get_inode+0xc3/0x1c0 [xfs]
> [165877.932503] RSP: 0018:ffffc9000cca3ad0 EFLAGS: 00010246
> [165877.937898] RAX: 0000000000000000 RBX: fffffffffffffffe RCX: 0000000000000017
> [165877.945111] RDX: 0000000000000000 RSI: ffffc9000cca3ce8 RDI: 0000000000001123
> [165877.952328] RBP: ffffc9000cca3b20 R08: 0000000000000003 R09: 0000000000000014
> [165877.959544] R10: 0000000000000000 R11: 0000000000000000 R12: ffff880278f59680
> [165877.966759] R13: ffffc9000cca3ba8 R14: ffffc9000cca3ce8 R15: 0000000000000000
> [165877.973976] FS: 00007f3d099f9700(0000) GS:ffff88017bb00000(0000) knlGS:0000000000000000
> [165877.982143] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [165877.987969] CR2: 0000000000000038 CR3: 000000016ad2d000 CR4: 00000000000006e0
> [165877.995185] Stack:
> [165877.997286] ffff880278f59680 0000000000000000 ffff880220cc5c00 ffff880265190780
> [165878.004840] ffff880101a67800 ffffc9000cca3ba8 ffff880278f59680 ffff88025a9e6000
> [165878.012396] ffffc9000cca3ce8 0000000000000000 ffffc9000cca3b58 ffffffffa0681a61
> [165878.019950] Call Trace:
> [165878.022551] [<ffffffffa0681a61>] __xfs_scrub_setup_inode.isra.63+0x81/0x280 [xfs]
> [165878.030236] [<ffffffffa0681c70>] xfs_scrub_setup_inode+0x10/0x20 [xfs]
> [165878.036963] [<ffffffffa068f57f>] xfs_scrub_metadata+0x2ff/0x450 [xfs]
> [165878.043607] [<ffffffffa066aa1d>] xfs_ioc_scrub_metadata+0x4d/0x80 [xfs]
> [165878.050424] [<ffffffffa066d029>] xfs_file_ioctl+0x9c9/0xb10 [xfs]
> [165878.056689] [<ffffffff8110692f>] ? get_futex_key+0x1df/0x360
> [165878.062516] [<ffffffff81106b31>] ? futex_wake+0x81/0x150
> [165878.068003] [<ffffffff812189c6>] do_vfs_ioctl+0x96/0x5b0
> [165878.073482] [<ffffffff81218f59>] SyS_ioctl+0x79/0x90
> [165878.078621] [<ffffffff81003997>] do_syscall_64+0x67/0x180
> [165878.084191] [<ffffffff816a6c2b>] entry_SYSCALL64_slow_path+0x25/0x25
> [165878.090714] Code: 8b 14 24 49 8b 75 00 85 c0 41 89 c7 44 0f b6 82 93 00 00 00 44 0f b6 8a 94 00 00 00 0f b6 8a 53 02 00 00 49 8b 55 08 48 8b 7e 08 <4c> 8b 62 38 75 38 48 8b 7d d0 8b 46 10 39 87 98 03 00 00 74 21
> [165878.110930] RIP [<ffffffffa0680c13>] xfs_scrub_get_inode+0xc3/0x1c0 [xfs]
> [165878.117938] RSP <ffffc9000cca3ad0>
> [165878.121512] CR2: 0000000000000038
> [165878.129219] ---[ end trace d23e56c58f53ccb9 ]---
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 8/9] xfs: fuzz every field of every structure
From: Darrick J. Wong @ 2016-11-09 8:52 UTC (permalink / raw)
To: Eryu Guan; +Cc: david, linux-xfs, fstests
In-Reply-To: <20161109080924.GT27776@eguan.usersys.redhat.com>
On Wed, Nov 09, 2016 at 04:09:24PM +0800, Eryu Guan wrote:
> On Fri, Nov 04, 2016 at 05:18:00PM -0700, Darrick J. Wong wrote:
> > Previously, our XFS fuzzing efforts were limited to using the xfs_db
> > blocktrash command to scribble garbage all over a block. This is
> > pretty easy to discover; it would be far more interesting if we could
> > fuzz individual fields looking for unhandled corner cases. Since we
> > now have an online scrub tool, use it to check for our targeted
> > corruptions prior to the usual steps of writing to the FS, taking it
> > offline, repairing, and re-checking.
> >
> > These tests use the new xfs_db 'fuzz' command to test corner case
> > handling of every field. The 'print' command tells us which fields
> > are available, and the fuzz command can write zeroes or ones to the
> > field; set the high, middle, or low bit; add or subtract numbers; or
> > randomize the field. We loop through all fields and all fuzz verbs to
> > see if we can trip up the kernel.
> >
> > Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
>
> The first test gave me a kernel crash :) xfs/1300 crashed your kernel
> djwong-devel branch. I appended the console log at the end of this mail
> if you have interest to see it.
>
> And another xfs/1300 run gave me this failure message:
>
> +/mnt/testarea/scratch: Kernel lacks GETFSMAP; scrub will be less efficient. (xfs.c line 661)
> +/mnt/testarea/scratch: Kernel cannot help scrub metadata; scrub will be incomplete. (xfs.c line 661)
> +/mnt/testarea/scratch: Kernel cannot help scrub inodes; scrub will be incomplete. (xfs.c line 661)
> +/mnt/testarea/scratch: Kernel cannot help scrub extent map; scrub will be less efficient. (xfs.c line 661)
>
> Is this known issue or something should be filtered out in the test?
That's strange, the djwong-devel branch should have getfsmap & scrub in it...
...are you running the djwong-devel kernel and xfsprogs code? The scrub
ioctl structure has shifted some over the past few months, though GETFSMAP
hasn't changed in ages.
Wait, "another xfs/1300 run" ... so after the first crash, did you go
back to a vanilla kernel without all my crazypatches? :)
> And ext4/1300 generated large .out.bad file (51M), containing something
> like:
>
> +/mnt/testarea/scratch/test/68/S_IFREG.FMT_ETREE: extent (1101381632/2469888/4096) ends past end of filesystem at 31457280. (generic.c line 272)
> +/mnt/testarea/scratch/test/68/S_IFREG.FMT_ETREE: extent (1101389824/2478080/4096) starts past end of filesystem at 31457280. (generic.c line 264)
> +/mnt/testarea/scratch/test/68/S_IFREG.FMT_ETREE: extent (1101389824/2478080/4096) ends past end of filesystem at 31457280. (generic.c line 272)
> +/mnt/testarea/scratch/test/68/S_IFREG.FMT_ETREE: extent (1101398016/2486272/4096) starts past end of filesystem at 31457280. (generic.c line 264)
> +/mnt/testarea/scratch/test/68/S_IFREG.FMT_ETREE: extent (1101398016/2486272/4096) ends past end of filesystem at 31457280. (generic.c line 272)
> +/mnt/testarea/scratch/test/68/S_IFREG.FMT_ETREE: extent (1101406208/2494464/4096) starts past end of filesystem at 31457280. (generic.c line 264)
> +/mnt/testarea/scratch/test/68/S_IFREG.FMT_ETREE: extent (1101406208/2494464/4096) ends past end of filesystem at 31457280. (generic.c line 272)
> +/mnt/testarea/scratch/test/68/S_IFREG.FMT_ETREE: extent (1101414400/2502656/4096) starts past end of filesystem at 31457280. (generic.c line 264)
> +/mnt/testarea/scratch/test/68/S_IFREG.FMT_ETREE: extent (1101414400/2502656/4096) ends past end of filesystem at 31457280. (generic.c line 272)
>
> Seems like scrub found something wrong (real problems) and became very
> noisy?
Hmm that's even stranger. I'll try to reproduce tomorrow.
> More comments inline below.
>
> > ---
> > common/fuzzy | 49 ++++++++++++++++++++++++++++++------
> > common/populate | 10 ++++---
> > common/rc | 15 +++++++++++
> > tests/ext4/1300 | 60 ++++++++++++++++++++++++++++++++++++++++++++
> [snip]
> >
> > diff --git a/common/fuzzy b/common/fuzzy
> > index 6af47f1..dbff744 100644
> > --- a/common/fuzzy
> > +++ b/common/fuzzy
> > @@ -85,32 +85,47 @@ _scratch_scrub() {
> > # Filter the xfs_db print command's field debug information
> > # into field name and type.
> > __filter_xfs_db_print_fields() {
> > + filter="$1"
> > + if [ -z "${filter}" ] || [ "${filter}" = "nofilter" ]; then
> > + filter='^'
> > + fi
> > grep ' = ' | while read key equals value; do
> > - fuzzkey="$(echo "${key}" | sed -e 's/\([a-zA-Z0-9_]*\)\[\([0-9]*\)-[0-9]*\]/\1[\2]/g')"
> > - if [[ "${value}" == "["* ]]; then
> > + # Filter out any keys with an array index >= 10, and
> > + # collapse any array range ("[1-195]") to the first item.
> > + fuzzkey="$(echo "${key}" | sed -e '/\([a-z]*\)\[\([0-9][0-9]\+\)\].*/d' -e 's/\([a-zA-Z0-9_]*\)\[\([0-9]*\)-[0-9]*\]/\1[\2]/g')"
> > + if [ -z "${fuzzkey}" ]; then
> > + continue
> > + elif [[ "${value}" == "["* ]]; then
> > echo "${value}" | sed -e 's/^.//g' -e 's/.$//g' -e 's/,/\n/g' | while read subfield; do
> > echo "${fuzzkey}.${subfield}"
> > done
> > else
> > echo "${fuzzkey}"
> > fi
> > - done
> > + done | egrep "${filter}"
> > }
> >
> > # Navigate to some part of the filesystem and print the field info.
> > +# The first argument is an egrep filter for the fields
> > +# The rest of the arguments are xfs_db commands to locate the metadata.
> > _scratch_xfs_list_metadata_fields() {
> > + filter="$1"
> > + shift
> > if [ -n "${SCRATCH_XFS_LIST_METADATA_FIELDS}" ]; then
> > - echo "${SCRATCH_XFS_LIST_METADATA_FIELDS}" | sed -e 's/ /\n/g'
> > + echo "${SCRATCH_XFS_LIST_METADATA_FIELDS}" | \
> > + sed -e 's/ /\n/g' | __filter_xfs_db_print_fields "${filter}"
> > return;
> > fi
> >
> > (for arg in "$@"; do
> > echo "${arg}"
> > done
> > - echo "print") | _scratch_xfs_db | __filter_xfs_db_print_fields
> > + echo "print") | _scratch_xfs_db | __filter_xfs_db_print_fields "${filter}"
> > }
> >
> > # Get a metadata field
> > +# The first arg is the field name
> > +# The rest of the arguments are xfs_db commands to find the metadata.
> > _scratch_xfs_get_metadata_field() {
> > key="$1"
> > shift
> > @@ -124,6 +139,9 @@ _scratch_xfs_get_metadata_field() {
> > }
> >
> > # Set a metadata field
> > +# The first arg is the field name
> > +# The second arg is the new value
> > +# The rest of the arguments are xfs_db commands to find the metadata.
> > _scratch_xfs_set_metadata_field() {
> > key="$1"
> > value="$2"
> > @@ -136,6 +154,9 @@ _scratch_xfs_set_metadata_field() {
> > }
> >
> > # Fuzz a metadata field
> > +# The first arg is the field name
> > +# The second arg is the xfs_db fuzz verb
> > +# The rest of the arguments are xfs_db commands to find the metadata.
> > _scratch_xfs_fuzz_metadata_field() {
> > key="$1"
> > value="$2"
> > @@ -263,12 +284,24 @@ _scratch_xfs_list_fuzz_verbs() {
> > sed -e 's/[,.]//g' -e 's/Verbs: //g' -e 's/ /\n/g'
> > }
> >
> > -# Fuzz the fields of some piece of metadata
> > -_scratch_xfs_fuzz_fields() {
> > - _scratch_xfs_list_metadata_fields "$@" | while read field; do
> > +# Fuzz some of the fields of some piece of metadata
> > +# The first argument is an egrep filter
> > +# The rest of the arguments are xfs_db commands to locate the metadata.
> > +_scratch_xfs_fuzz_some_fields() {
> > + filter="$1"
> > + shift
> > + echo "Fields we propose to fuzz: $@"
> > + _scratch_xfs_list_metadata_fields "${filter}" "$@"
> > + _scratch_xfs_list_metadata_fields "${filter}" "$@" | while read field; do
> > _scratch_xfs_list_fuzz_verbs | while read fuzzverb; do
> > __scratch_xfs_fuzz_mdrestore
> > __scratch_xfs_fuzz_field_test "${field}" "${fuzzverb}" "$@"
> > done
> > done
> > }
> > +
> > +# Fuzz all of the fields of some piece of metadata
> > +# All arguments are xfs_db commands to locate the metadata.
> > +_scratch_xfs_fuzz_fields() {
> > + _scratch_xfs_fuzz_some_fields '' "$@"
> > +}
>
> I think all the fuzz update here should be folded to patch 7/9.
(I'll look at the patch fixes in a separate reply tomorrow.)
> > diff --git a/common/populate b/common/populate
> > index 15d68fc..7d103f0 100644
> > --- a/common/populate
> > +++ b/common/populate
> > @@ -180,13 +180,13 @@ _scratch_xfs_populate() {
> > # FMT_EXTENTS with a remote less-than-a-block value
> > echo "+ attr extents with a remote less-than-a-block value"
> > touch "${SCRATCH_MNT}/ATTR.FMT_EXTENTS_REMOTE3K"
> > - $XFS_IO_PROG -f -c "pwrite -S 0x43 0 3k" "${SCRATCH_MNT}/attrvalfile" > /dev/null
> > + $XFS_IO_PROG -f -c "pwrite -S 0x43 0 $((blksz - 300))" "${SCRATCH_MNT}/attrvalfile" > /dev/null
> > attr -q -s user.remotebtreeattrname "${SCRATCH_MNT}/ATTR.FMT_EXTENTS_REMOTE3K" < "${SCRATCH_MNT}/attrvalfile"
> >
> > # FMT_EXTENTS with a remote block-size value
> > echo "+ attr extents with a remote one-block value"
> > touch "${SCRATCH_MNT}/ATTR.FMT_EXTENTS_REMOTE4K"
> > - $XFS_IO_PROG -f -c "pwrite -S 0x44 0 4k" "${SCRATCH_MNT}/attrvalfile" > /dev/null
> > + $XFS_IO_PROG -f -c "pwrite -S 0x44 0 ${blksz}" "${SCRATCH_MNT}/attrvalfile" > /dev/null
> > attr -q -s user.remotebtreeattrname "${SCRATCH_MNT}/ATTR.FMT_EXTENTS_REMOTE4K" < "${SCRATCH_MNT}/attrvalfile"
> > rm -rf "${SCRATCH_MNT}/attrvalfile"
> >
> > @@ -482,8 +482,8 @@ _scratch_xfs_populate_check() {
> > __populate_check_xfs_aformat "${btree_attr}" "btree"
> > __populate_check_xfs_agbtree_height "bno"
> > __populate_check_xfs_agbtree_height "cnt"
> > - test -n $is_rmapbt && __populate_check_xfs_agbtree_height "rmap"
> > - test -n $is_reflink && __populate_check_xfs_agbtree_height "refcnt"
> > + test $is_rmapbt -ne 0 && __populate_check_xfs_agbtree_height "rmap"
> > + test $is_reflink -ne 0 && __populate_check_xfs_agbtree_height "refcnt"
> > }
>
> And these folded to patch 1/9?
>
> >
> > # Check data fork format of ext4 file
> > @@ -609,7 +609,7 @@ _scratch_populate_cached() {
> > rm -rf "$(find "${POPULATE_METADUMP}" -mtime +2 2>/dev/null)"
> >
> > # Throw away cached image if it doesn't match our spec.
> > - meta_descr="FSTYP ${FSTYP} MKFS_OPTIONS ${MKFS_OPTIONS} ARGS $@"
> > + meta_descr="FSTYP ${FSTYP} MKFS_OPTIONS $(_scratch_mkfs_options) ARGS $@"
> > cmp -s "${POPULATE_METADUMP_DESCR}" <(echo "${meta_descr}") || rm -rf "${POPULATE_METADUMP}"
> >
> > # Do we have a cached image?
>
> This to patch 6/9?
>
> Because we usually don't introduce something in patch 1 and fix them in
> patch 2, I think :)
Generally, yes. :)
> > diff --git a/common/rc b/common/rc
> > index d904582..ec1f5de 100644
> > --- a/common/rc
> > +++ b/common/rc
> > @@ -1870,6 +1870,21 @@ _require_xfs_finobt()
> > _scratch_unmount
> > }
> >
> > +# Do we have a fre
> > +_require_scratch_finobt()
> > +{
> > + _require_scratch
> > +
> > + if [ $FSTYP != "xfs" ]; then
> > + _notrun "finobt not supported by scratch filesystem type: $FSTYP"
> > + return
> > + fi
> > + _scratch_mkfs > /dev/null
> > + _scratch_mount
> > + xfs_info $SCRATCH_MNT | grep -q 'finobt=1' || _notrun "finobt not supported by scratch filesystem type: $FSTYP"
> > + _scratch_unmount
> > +}
> > +
> > # this test requires xfs sysfs attribute support
> > #
> > _require_xfs_sysfs()
> > diff --git a/tests/ext4/1300 b/tests/ext4/1300
> > new file mode 100755
> > index 0000000..3f8135e
> > --- /dev/null
> > +++ b/tests/ext4/1300
>
> [all the tests look fine to me, snip]
>
> > --- a/tests/xfs/group
> > +++ b/tests/xfs/group
> > @@ -333,3 +333,34 @@
> > 345 auto quick clone
> > 346 auto quick clone
> > 347 auto quick clone
> > +1300 dangerous_fuzzers scrub
>
> ext4/1300 is "auto quick scrub", I think xfs/1300 should be in auto
> group too?
>
> Thanks,
> Eryu
>
> P.S. console log of xfs/1300 crash
>
> [165877.766244] BUG: unable to handle kernel NULL pointer dereference at 0000000000000038
> [165877.774197] IP: [<ffffffffa0680c13>] xfs_scrub_get_inode+0xc3/0x1c0 [xfs]
> [165877.781162] PGD 179c1b067 [165877.783784] PUD 14d994067
Ohhh... I suspect this happens when xfs_scrub_op_ok tries to use sc->tp
after some error happens, which we can't do because this function is
used in the process of initializing sc.
Gonna go cry in my beer for a day or two or something,
--D
> PMD 0 [165877.787130]
> [165877.788722] Oops: 0000 [#1] SMP
> [165877.791951] Modules linked in: dm_delay dm_zero btrfs xor raid6_pq dm_thin_pool dm_persistent_data dm_bio_prison dm_snapshot dm_bufio loop dm_flakey xfs libcrc32c binfmt_misc ip6t_rpfilter ipt_REJECT nf_reject_ipv4 nf_conntrack_ipv4 nf_defrag_ipv4 ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 xt_conntrack nf_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge stp llc ip6table_mangle ip6table_security ip6table_raw iptable_mangle iptable_security iptable_raw ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter coretemp kvm_intel kvm irqbypass crc32_pclmul ghash_clmulni_intel aesni_intel lrw iTCO_wdt gf128mul glue_helper ipmi_devintf cdc_ether iTCO_vendor_support ablk_helper cryptd usbnet i2c_i801 lpc_ich mii pcspkr i2c_smbus sg i7core_edac mfd_core ipmi_si edac_core ipmi_msghandler shpchp ioatdma dca acpi_cpufreq nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables ext4 jbd2 mbcache sr_mod sd_mod cdrom mgag200 i2c_algo_bit drm_kms_helpe!
> r syscopyarea sysfillrect sysimgblt fb_sys_fops ttm ata_generic pata_acpi drm ata_piix libata crc32c_intel megaraid_sas serio_raw i2c_core bnx2 dm_mirror dm_region_hash dm_log dm_mod [last unloaded: scsi_debug]
> [165877.898708] CPU: 5 PID: 26242 Comm: xfs_scrub Tainted: G W 4.9.0-rc3.djwong+ #16
> [165877.907308] Hardware name: IBM System x3550 M3 -[7944OEJ]-/90Y4784 , BIOS -[D6E150CUS-1.11]- 02/08/2011
> [165877.917124] task: ffff88017a286a40 task.stack: ffffc9000cca0000
> [165877.923126] RIP: 0010:[<ffffffffa0680c13>] [<ffffffffa0680c13>] xfs_scrub_get_inode+0xc3/0x1c0 [xfs]
> [165877.932503] RSP: 0018:ffffc9000cca3ad0 EFLAGS: 00010246
> [165877.937898] RAX: 0000000000000000 RBX: fffffffffffffffe RCX: 0000000000000017
> [165877.945111] RDX: 0000000000000000 RSI: ffffc9000cca3ce8 RDI: 0000000000001123
> [165877.952328] RBP: ffffc9000cca3b20 R08: 0000000000000003 R09: 0000000000000014
> [165877.959544] R10: 0000000000000000 R11: 0000000000000000 R12: ffff880278f59680
> [165877.966759] R13: ffffc9000cca3ba8 R14: ffffc9000cca3ce8 R15: 0000000000000000
> [165877.973976] FS: 00007f3d099f9700(0000) GS:ffff88017bb00000(0000) knlGS:0000000000000000
> [165877.982143] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [165877.987969] CR2: 0000000000000038 CR3: 000000016ad2d000 CR4: 00000000000006e0
> [165877.995185] Stack:
> [165877.997286] ffff880278f59680 0000000000000000 ffff880220cc5c00 ffff880265190780
> [165878.004840] ffff880101a67800 ffffc9000cca3ba8 ffff880278f59680 ffff88025a9e6000
> [165878.012396] ffffc9000cca3ce8 0000000000000000 ffffc9000cca3b58 ffffffffa0681a61
> [165878.019950] Call Trace:
> [165878.022551] [<ffffffffa0681a61>] __xfs_scrub_setup_inode.isra.63+0x81/0x280 [xfs]
> [165878.030236] [<ffffffffa0681c70>] xfs_scrub_setup_inode+0x10/0x20 [xfs]
> [165878.036963] [<ffffffffa068f57f>] xfs_scrub_metadata+0x2ff/0x450 [xfs]
> [165878.043607] [<ffffffffa066aa1d>] xfs_ioc_scrub_metadata+0x4d/0x80 [xfs]
> [165878.050424] [<ffffffffa066d029>] xfs_file_ioctl+0x9c9/0xb10 [xfs]
> [165878.056689] [<ffffffff8110692f>] ? get_futex_key+0x1df/0x360
> [165878.062516] [<ffffffff81106b31>] ? futex_wake+0x81/0x150
> [165878.068003] [<ffffffff812189c6>] do_vfs_ioctl+0x96/0x5b0
> [165878.073482] [<ffffffff81218f59>] SyS_ioctl+0x79/0x90
> [165878.078621] [<ffffffff81003997>] do_syscall_64+0x67/0x180
> [165878.084191] [<ffffffff816a6c2b>] entry_SYSCALL64_slow_path+0x25/0x25
> [165878.090714] Code: 8b 14 24 49 8b 75 00 85 c0 41 89 c7 44 0f b6 82 93 00 00 00 44 0f b6 8a 94 00 00 00 0f b6 8a 53 02 00 00 49 8b 55 08 48 8b 7e 08 <4c> 8b 62 38 75 38 48 8b 7d d0 8b 46 10 39 87 98 03 00 00 74 21
> [165878.110930] RIP [<ffffffffa0680c13>] xfs_scrub_get_inode+0xc3/0x1c0 [xfs]
> [165878.117938] RSP <ffffc9000cca3ad0>
> [165878.121512] CR2: 0000000000000038
> [165878.129219] ---[ end trace d23e56c58f53ccb9 ]---
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 11/14] Revert "crypto: caam - get rid of tasklet"
From: Russell King - ARM Linux @ 2016-11-09 8:53 UTC (permalink / raw)
To: Horia Geantă, Thomas Gleixner
Cc: Herbert Xu, David S. Miller, linux-crypto
In-Reply-To: <1478681184-9442-12-git-send-email-horia.geanta@nxp.com>
Please include Thomas in this.
On Wed, Nov 09, 2016 at 10:46:21AM +0200, Horia Geantă wrote:
> This reverts commit 66d2e2028091a074aa1290d2eeda5ddb1a6c329c.
>
> Quoting from Russell's findings:
> https://www.mail-archive.com/linux-crypto@vger.kernel.org/msg21136.html
>
> [quote]
> Okay, I've re-tested, using a different way of measuring, because using
> openssl speed is impractical for off-loaded engines. I've decided to
> use this way to measure the performance:
>
> dd if=/dev/zero bs=1048576 count=128 | /usr/bin/time openssl dgst -md5
>
> For the threaded IRQs case gives:
>
> 0.05user 2.74system 0:05.30elapsed 52%CPU (0avgtext+0avgdata 2400maxresident)k
> 0.06user 2.52system 0:05.18elapsed 49%CPU (0avgtext+0avgdata 2404maxresident)k
> 0.12user 2.60system 0:05.61elapsed 48%CPU (0avgtext+0avgdata 2460maxresident)k
> => 5.36s => 25.0MB/s
>
> and the tasklet case:
>
> 0.08user 2.53system 0:04.83elapsed 54%CPU (0avgtext+0avgdata 2468maxresident)k
> 0.09user 2.47system 0:05.16elapsed 49%CPU (0avgtext+0avgdata 2368maxresident)k
> 0.10user 2.51system 0:04.87elapsed 53%CPU (0avgtext+0avgdata 2460maxresident)k
> => 4.95 => 27.1MB/s
>
> which corresponds to an 8% slowdown for the threaded IRQ case. So,
> tasklets are indeed faster than threaded IRQs.
>
> [...]
>
> I think I've proven from the above that this patch needs to be reverted
> due to the performance regression, and that there _is_ most definitely
> a deterimental effect of switching from tasklets to threaded IRQs.
> [/quote]
>
> Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
> ---
> drivers/crypto/caam/intern.h | 1 +
> drivers/crypto/caam/jr.c | 25 ++++++++++++++++---------
> 2 files changed, 17 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/crypto/caam/intern.h b/drivers/crypto/caam/intern.h
> index 5d4c05074a5c..e2bcacc1a921 100644
> --- a/drivers/crypto/caam/intern.h
> +++ b/drivers/crypto/caam/intern.h
> @@ -41,6 +41,7 @@ struct caam_drv_private_jr {
> struct device *dev;
> int ridx;
> struct caam_job_ring __iomem *rregs; /* JobR's register space */
> + struct tasklet_struct irqtask;
> int irq; /* One per queue */
>
> /* Number of scatterlist crypt transforms active on the JobR */
> diff --git a/drivers/crypto/caam/jr.c b/drivers/crypto/caam/jr.c
> index 7331ea734f37..c8604dfadbf5 100644
> --- a/drivers/crypto/caam/jr.c
> +++ b/drivers/crypto/caam/jr.c
> @@ -73,6 +73,8 @@ static int caam_jr_shutdown(struct device *dev)
>
> ret = caam_reset_hw_jr(dev);
>
> + tasklet_kill(&jrp->irqtask);
> +
> /* Release interrupt */
> free_irq(jrp->irq, dev);
>
> @@ -128,7 +130,7 @@ static irqreturn_t caam_jr_interrupt(int irq, void *st_dev)
>
> /*
> * Check the output ring for ready responses, kick
> - * the threaded irq if jobs done.
> + * tasklet if jobs done.
> */
> irqstate = rd_reg32(&jrp->rregs->jrintstatus);
> if (!irqstate)
> @@ -150,13 +152,18 @@ static irqreturn_t caam_jr_interrupt(int irq, void *st_dev)
> /* Have valid interrupt at this point, just ACK and trigger */
> wr_reg32(&jrp->rregs->jrintstatus, irqstate);
>
> - return IRQ_WAKE_THREAD;
> + preempt_disable();
> + tasklet_schedule(&jrp->irqtask);
> + preempt_enable();
> +
> + return IRQ_HANDLED;
> }
>
> -static irqreturn_t caam_jr_threadirq(int irq, void *st_dev)
> +/* Deferred service handler, run as interrupt-fired tasklet */
> +static void caam_jr_dequeue(unsigned long devarg)
> {
> int hw_idx, sw_idx, i, head, tail;
> - struct device *dev = st_dev;
> + struct device *dev = (struct device *)devarg;
> struct caam_drv_private_jr *jrp = dev_get_drvdata(dev);
> void (*usercall)(struct device *dev, u32 *desc, u32 status, void *arg);
> u32 *userdesc, userstatus;
> @@ -230,8 +237,6 @@ static irqreturn_t caam_jr_threadirq(int irq, void *st_dev)
>
> /* reenable / unmask IRQs */
> clrsetbits_32(&jrp->rregs->rconfig_lo, JRCFG_IMSK, 0);
> -
> - return IRQ_HANDLED;
> }
>
> /**
> @@ -389,10 +394,11 @@ static int caam_jr_init(struct device *dev)
>
> jrp = dev_get_drvdata(dev);
>
> + tasklet_init(&jrp->irqtask, caam_jr_dequeue, (unsigned long)dev);
> +
> /* Connect job ring interrupt handler. */
> - error = request_threaded_irq(jrp->irq, caam_jr_interrupt,
> - caam_jr_threadirq, IRQF_SHARED,
> - dev_name(dev), dev);
> + error = request_irq(jrp->irq, caam_jr_interrupt, IRQF_SHARED,
> + dev_name(dev), dev);
> if (error) {
> dev_err(dev, "can't connect JobR %d interrupt (%d)\n",
> jrp->ridx, jrp->irq);
> @@ -454,6 +460,7 @@ static int caam_jr_init(struct device *dev)
> out_free_irq:
> free_irq(jrp->irq, dev);
> out_kill_deq:
> + tasklet_kill(&jrp->irqtask);
> return error;
> }
>
> --
> 2.4.4
>
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [Bug 98638] Panic on shutdown with AMDGPU and Ubuntu Plymouth
From: bugzilla-daemon @ 2016-11-09 8:54 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-98638-502@http.bugs.freedesktop.org/>
[-- Attachment #1.1: Type: text/plain, Size: 381 bytes --]
https://bugs.freedesktop.org/show_bug.cgi?id=98638
--- Comment #4 from Ernst Sjöstrand <ernstp@gmail.com> ---
Perhaps the netconsole runs into problems because of the panic?
I'll try to turn on some more debug options in my kernel perhaps...
And maybe just try a few times and see if I'm lucky.
--
You are receiving this mail because:
You are the assignee for the bug.
[-- Attachment #1.2: Type: text/html, Size: 1163 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* RE: [PATCH] mwifiex: fix memory leak in mwifiex_save_hidden_ssid_channels()
From: Amitkumar Karwar @ 2016-11-09 8:53 UTC (permalink / raw)
To: Ricky Liang
Cc: Nishant Sarmukadam, Kalle Valo,
open list:MARVELL MWIFIEX WIRELESS DRIVER,
open list:NETWORKING DRIVERS, open list
In-Reply-To: <1478662648-70698-1-git-send-email-jcliang@chromium.org>
> From: Ricky Liang [mailto:jcliang@chromium.org]
> Sent: Wednesday, November 09, 2016 9:07 AM
> Cc: Ricky Liang; Amitkumar Karwar; Nishant Sarmukadam; Kalle Valo; open
> list:MARVELL MWIFIEX WIRELESS DRIVER; open list:NETWORKING DRIVERS; open
> list
> Subject: [PATCH] mwifiex: fix memory leak in
> mwifiex_save_hidden_ssid_channels()
>
> kmemleak reports memory leak in mwifiex_save_hidden_ssid_channels():
>
> unreferenced object 0xffffffc0a2914780 (size 192):
> comm "ksdioirqd/mmc2", pid 2004, jiffies 4307182506 (age 820.684s)
> hex dump (first 32 bytes):
> 00 06 47 49 4e 2d 32 67 01 03 c8 60 6c 03 01 40 ..GIN-2g...`l..@
> 07 10 54 57 20 34 04 1e 64 05 24 84 03 24 95 04 ..TW 4..d.$..$..
> backtrace:
> [<ffffffc0003375f4>] create_object+0x164/0x2b4
> [<ffffffc0008e3530>] kmemleak_alloc+0x50/0x88
> [<ffffffc000335120>] __kmalloc_track_caller+0x1bc/0x264
> [<ffffffc00030899c>] kmemdup+0x38/0x64
> [<ffffffbffc2311cc>] mwifiex_fill_new_bss_desc+0x3c/0x130 [mwifiex]
> [<ffffffbffc22ee9c>] mwifiex_save_curr_bcn+0x4ec/0x640 [mwifiex]
> [<ffffffbffc22f45c>]
> mwifiex_handle_event_ext_scan_report+0x1d4/0x268 [mwifiex]
> [<ffffffbffc2375d0>] mwifiex_process_sta_event+0x378/0x898 [mwifiex]
> [<ffffffbffc224dc8>] mwifiex_process_event+0x1a8/0x1e8 [mwifiex]
> [<ffffffbffc2228f0>] mwifiex_main_process+0x258/0x534 [mwifiex]
> [<ffffffbffc258858>] 0xffffffbffc258858
> [<ffffffc00071ee90>] process_sdio_pending_irqs+0xf8/0x160
> [<ffffffc00071efdc>] sdio_irq_thread+0x9c/0x1a4
> [<ffffffc000240d08>] kthread+0xf4/0x100
> [<ffffffc0002043fc>] ret_from_fork+0xc/0x50
> [<ffffffffffffffff>] 0xffffffffffffffff
>
> Signed-off-by: Ricky Liang <jcliang@chromium.org>
> ---
> drivers/net/wireless/marvell/mwifiex/scan.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/net/wireless/marvell/mwifiex/scan.c
> b/drivers/net/wireless/marvell/mwifiex/scan.c
> index 97c9765..98ce072 100644
> --- a/drivers/net/wireless/marvell/mwifiex/scan.c
> +++ b/drivers/net/wireless/marvell/mwifiex/scan.c
> @@ -1671,6 +1671,10 @@ static int
> mwifiex_save_hidden_ssid_channels(struct mwifiex_private *priv,
> }
>
> done:
> + /* beacon_ie buffer was allocated in function
> + * mwifiex_fill_new_bss_desc(). Free it now.
> + */
> + kfree(bss_desc->beacon_buf);
> kfree(bss_desc);
> return 0;
> }
Acked-by: Amitkumar Karwar <akarwar@marvell.com>
Regards,
Amitkumar
^ permalink raw reply
* [PATCH RESEND] tools-powerpc: Return false instead of -1
From: Andrew Shadura @ 2016-11-09 8:55 UTC (permalink / raw)
To: linuxppc-dev, linux-api, linux-kernel
Cc: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Shuah Khan, Cyril Bur
From: Peter Senna Tschudin <peter.senna@gmail.com>
Returning a negative value for a boolean function seem to have the
undesired effect of returning true. require_paranoia_below() is a
boolean function, but the variable used to store the return value is an
integer, receiving -1 or 0. This patch convert rc to bool, replace -1
by false, and 0 by true.
This issue was found by the following Coccinelle semantic patch:
<smpl>
@@
identifier f, ret;
constant C;
typedef bool;
@@
bool f (...){
<+...
ret = -C;
...
* return ret;
...+>
}
</smpl>
Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com>
Signed-off-by: Andrew Shadura <andrew.shadura@collabora.co.uk>
---
tools/testing/selftests/powerpc/pmu/lib.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/testing/selftests/powerpc/pmu/lib.c b/tools/testing/selftests/powerpc/pmu/lib.c
index 8b992fa..5bf5dd4 100644
--- a/tools/testing/selftests/powerpc/pmu/lib.c
+++ b/tools/testing/selftests/powerpc/pmu/lib.c
@@ -193,9 +193,9 @@ bool require_paranoia_below(int level)
long current;
char *end, buf[16];
FILE *f;
- int rc;
+ bool rc;
- rc = -1;
+ rc = false;
f = fopen(PARANOID_PATH, "r");
if (!f) {
@@ -218,7 +218,7 @@ bool require_paranoia_below(int level)
if (current >= level)
goto out_close;
- rc = 0;
+ rc = true;
out_close:
fclose(f);
out:
--
2.9.3
^ permalink raw reply related
* Re: [PATCH v4 00/14] ARM: dts: r8a779x: use demuxer for I2C
From: Geert Uytterhoeven @ 2016-11-09 8:55 UTC (permalink / raw)
To: Simon Horman; +Cc: Wolfram Sang, Linux-Renesas, Linux I2C
In-Reply-To: <20161109084406.GA22213@verge.net.au>
Hi Simon,
On Wed, Nov 9, 2016 at 9:44 AM, Simon Horman <horms@verge.net.au> wrote:
> I am not in a position to test silk or porter at this time.
FWIW, Magnus has a Porter in his farm.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.